Share via


Security Briefs

Mind Those Passwords!

Keith Brown

Code download available at:SecurityBriefs0407.exe(349 KB)

Contents

Internet Explorer and Passwords
Writing Down Passwords
A Better Solution: The Password Multiplexer
Password Minder
From Master Password to Master Key
Picking a Good Master Password
Defense in Depth
More on Stretching
Conclusion

Passwords are necessary evils. The way most password-based authentication works these days, the length and complexity of your password is directly related to how difficult it would be for an attacker to impersonate you. For example, if you choose "password" as your password, an attacker will usually guess this on his second try (his first try would probably be an empty string). Even if you were to use a six-character randomly generated password like 2=w\Z9, the entropy would be less than 40 bits, meaning it would take less than 240 guesses to discover the password in a brute-force attack. Depending on how the system is implemented, a brute-force attack may not even be necessary.

Many Web sites store passwords in cleartext (data in its original and unencrypted form), or using simple non-keyed "ciphers" such as a Caesar-shift, which is reversible without a key. Even sites that encrypt user passwords have to store the key somewhere, and Web server compromise can lead to compromise of this key, which can lead to the unveiling of all the cleartext passwords stored there. The recommended approach for storing passwords is to hash them and only store the hash values (preferably salted and stretched, techniques which I'll cover later in this column). This way, passwords cannot be stolen (the site doesn't store them), but the site can still verify a user's credentials by hashing a password and comparing it to the stored hash value.

Even if you choose a really long, randomly generated password and use it everywhere, you're still at significant risk. It only takes a single Web site with lousy security to disclose your password to an attacker, and chances are good that he can then use your login name (typically your e-mail address) and password at other sites that you frequent. Plus, why trust the administrator of one site with the password you use at another site? This is really scary stuff considering that many people use the Web to do banking, stock trading, and so on.

What you really need to do is choose a unique password for each and every Internet site you visit. Ideally, this password should be as long as allowed by the site, complex, and preferably randomly generated. Of course, there are very few humans in the world who can randomly generate a complex password without the help of a tool. But don't worry, there are a lot of tools out there to help you. Of course, you should only use tools from sources you really trust.

This column describes a tool I wrote, Password Minder, to solve this problem. Even if you don't use it yourself, you'll find its implementation to be instructive.

Internet Explorer and Passwords

Microsoft® Internet Explorer has built-in support for helping you remember passwords. So why is it that most companies (ironically, including Microsoft) encourage their employees to avoid this feature? Well, let's think about how the feature might be implemented. Given that the browser never asks you for any other secret before auto-filling a password field, it's very likely that it's using your login credentials (your Windows® password) to derive an encryption key for the passwords that it remembers for you. There are a couple of Win32® APIs that make it really easy to encrypt data using your login credentials as the source of an encryption key: CryptProtectData and CryptUnprotectData (this functionality is provided to managed applications via a new class in the .NET Framework Library called ProtectData in the .NET Framework 2.0).

But think about this for a moment. If the browser can decrypt these passwords at any time without requiring any further secret from you, then it's possible for any other code on your machine running in your logon session to do the same thing! Imagine a virus that used the same algorithm as Internet Explorer to decrypt your passwords, uploading them to an FTP site of the attacker's choosing. If you were to inadvertently run the virus code, perhaps by opening a malicious attachment in an e-mail, any passwords that Internet Explorer manages for you would be up for grabs. Remember that the virus can call CryptUnprotectData just as easily as your browser can. Frankly I'm amazed that some of the more successful viruses haven't already done this (Nimda, for example). Certainly the ubiquity of this feature makes it a very juicy target. The thought that accidentally opening a malicious e-mail attachment could unleash an attack like this should make you reconsider whether you'd want to have your browser managing passwords for you.

Another problem with browser-managed passwords is that you are the one who chooses each password in the first place, and humans typically pick really bad passwords. "asdf7890" is not a good password unless you qualify goodness as how easy it is to type. You should have a good random source of password material. One technique I've seen is to throw dice to generate each character in a password. That's a great method, but I don't know of many people who would be patient enough to use this technique on a daily basis. Besides, I can just see you trying to explain to your boss that you're not playing games when he walks in on one of your password-generation sessions.

Writing Down Passwords

A lot of people joke about writing down passwords, but sometimes it's a reasonable approach. As long as you don't do something silly like use a sticky note on your monitor to store your passwords, writing them down is arguably a better idea than letting the browser remember them. A virus that can decrypt your passwords and ship them wholesale to an attacker cannot pull that little piece of paper out of your wallet and read it.

But once again, you've probably got way too many passwords to write them all down and store them in your wallet. Besides, if you use really good passwords, it's very difficult to read them and type them without making any mistakes. And what happens if that little piece of paper goes through the wash? What happens if your wallet is stolen or misplaced?

I've seen some people keep passwords in a file on their computer. When done carefully, this isn't a half bad approach either, and it's easier because you can transfer passwords via the clipboard. You can use the encrypting file system to achieve about the same level of security that your browser would give you, effectively encrypting your password file with your login credentials. One of my friends used this approach until the day I told him that I'd just accidentally glanced at his list of passwords (he'd left it sitting open on his laptop and walked away).

A Better Solution: The Password Multiplexer

A couple of years ago, I decided to solve my own password management problem by writing a password multiplexer. My requirements were as follows: I only wanted to have to remember one really good master password (this is different from my Windows login password, so technically I have to remember two strong passwords). Once logged into Windows, whenever I would find myself prompted for a password, I wanted to simply type in my master password and somehow have the system automatically convert this into a unique password for the site I'm visiting. My goal was to have a long, unique, randomly generated password for each site I'd visit, but I didn't ever want to have to actually see those passwords or type them manually. I also wanted this to work in other apps in addition to the browser. For example, when I set up a VPN connection to a client's network, I wanted to use my password multiplexer.

So, what would be the difference between my password multiplexer and letting the browser remember my passwords? Well, assuming my collection of real passwords is encrypted using a key derived from my single master password, my multiplexer would require me to type my master password each time I wanted to retrieve one of my real passwords. Because I would not be using my Windows login credentials to encrypt my passwords, they wouldn't automatically be available to any malicious software that might slip into my system. It's not perfect, of course. A root compromise of my system would allow an attacker to install a keyboard driver that reads all of my keystrokes, for example, but it's a heck of a lot safer than having my browser remember my passwords.

Frankly I didn't know how to build a password multiplexer that satisfies all of these requirements, but the final design turned out to require only a few extra keystrokes beyond my original stated goal, and I have been using this tool for a couple of years now and have been really happy with it.

Before settling on my final design, I considered simply deriving passwords for each site directly from my master password. For example, for each site I'd simply store a salt value, which is just a bunch of randomly generated bits. I could then hash this salt plus my master password to obtain password material for the site. This would make the multiplexer implementation really easy. But it also would make it rather difficult to change my master password: I'd need to change my passwords at all the sites at the same time. And I have about 50 passwords that I manage at the moment.

Another problem with this solution is that many sites have restrictions on the passwords they allow. A lot of sites won't allow you to have punctuation characters in a password. Even more sites place arbitrary restrictions on the length of the password; I've seen some sites that won't allow longer than six characters. What's worse is that often these limitations aren't even documented. Apparently, nobody expects you to use a really long password. So, if you happen to be developing a Web site that requires a password, please make it very clear what types of passwords you'll accept. And if at all possible, allow very long passwords. What's the harm in allowing someone to give you a 100-character password? Few people will do it, but you should allow those of us who want really good security to be able to get it.

Finally, I have a few smartcards that I use from time to time, and they require PIN codes that are four characters long. With all of these problems, it quickly became clear that I wasn't going to be able to simply generate my passwords directly from a single master key. But it was a fun idea. From a cryptographic perspective, it was also not the best idea. If someone got access to a large sample of the derived passwords, they could try to guess the master password.

Password Minder

What I ultimately built was a tool called Password Minder. I probably should have named it Password Multiplexer, but I thought that it might be used by nontechnical folks who might shy away from such an odd name. Because there was no safe way for me to integrate my software with the operating system so that I could hook every possible password edit field automatically, I opted for a very simple approach: I just wired up Password Minder to a hotkey combination by creating a shortcut on my desktop and configuring the "Shortcut Key" setting via the shortcut's property sheet. Whenever I find myself on a password field in a Web form or dialog box, I just hit my hotkey combination (Control-Shift-P), and up pops a little prompt asking me for my master password (see the dialog box in Figure 1).

Figure 1 Master Password Prompt

Figure 1** Master Password Prompt **

Once I enter my password, the system performs some calculations to obtain a master key. Later I'll go into detail about the motivation and mechanics for these calculations, but for now, suffice it to say that after a couple of seconds another form pops up showing a list of Web sites and applications for which Password Minder is managing my passwords. Most sites simply use my e-mail address as my user name, but other sites like my bank require something different, so my list reminds me at a glance what user name I use at these more finicky sites. Figure 2 shows what my list looks like (blanking out the user names I've chosen). Note the scrollbars. I wasn't kidding when I said that I've got tons of passwords that I have to manage. But each one is unique, random, and as strong as the site or application will allow.

Figure 2 Password List

Figure 2** Password List **

I hate taking my hands off the keyboard, so at this point I'll just hit the first letter of the site name to scroll through the list and quickly get to the password I need, pressing Enter to select it. Password Minder then uses my master key to decrypt just that one password, and types it for me by inserting keystroke messages into my input queue. Password Minder then immediately exits to reduce the exposure of my master key. Because any given use of Password Minder typically lasts just a few seconds, my master key is only exposed in memory for very a brief period during the day.

In reality, because Password Minder is a managed application, it's very difficult to ensure that the master key is wiped from memory once I'm done with it. This is a big problem in any language (such as .NET and Java) that uses garbage collection (though in the .NET Framework 2.0, the new SecureString class would make it easier). This is why I designed Password Minder to immediately shut down after typing a password, at least by default. I can then rely on the operating system's guarantee that any other process that ends up using the same memory that Password Minder just vacated will have the memory zeroed before being mapped into the new process. This isn't perfect (the master key could end up sitting in the swap file some time), but it's good enough for me. If my computer is compromised so badly that the swap file is up for grabs, my keystrokes are probably also being monitored as well, which means the attacker already has my master password anyway.

Oddly enough, I benefit by using a password management tool that is not built into the operating system. Not everyone who owns Windows has this tool, which makes it a less likely target for attackers. Not that I rely on this, though. As you'll see shortly, Password Minder takes security very seriously, and even if an attacker were to obtain my password file, since I use a strong master password and a password-stretching technique, even an offline brute-force or dictionary attack against my password file should ultimately fail.

From Master Password to Master Key

Once Password Minder gets my master password from the dialog in Figure 1, it must solve a little puzzle to figure out the master key for my password file. This technique is called password stretching, and it can take a good password and strengthen it so even the most well-funded attacker cannot discover it via a brute-force attack. The technique Password Minder uses is documented in the Public Key Cryptography Standards (PKCS) for password-based cryptography. It's technically called the Password Based Key Derivation Function 2 (PBKDF2), and it works by running a cryptographic pseudo-random number generator over and over again, seeded with your master password and a salt value. At the heart of this pseudo-random number generator is a hash algorithm, and you can use any hash algorithm you like, so I've chosen the 256-bit version of the Secure Hash Algorithm (SHA-256) based on recommendations from well-respected cryptographers Niels Ferguson and Bruce Schneier in their fine book, Practical Cryptography (John Wiley & Sons, 2003).

I'm currently using 218 iterations of this algorithm, which effectively adds 18 bits of security to my password. Why? If an attacker somehow gets a copy of my password file, he can mount a brute-force attack against my master key by simply trying every possible password, calculating the master key, and decrypting one of the passwords in my list. If he eventually guesses my master password, he'll know he's found it because the decryption will result in a plaintext byte stream that represents a password in UTF-8 encoding, and only certain characters will be present in any of my passwords. He can then further confirm that he's found the correct password by using the master key to decrypt the other passwords in the same fashion, checking to see if they are also valid UTF-8 encodings of passwords.

But how many attempts will the attacker have to make before he happens upon the correct password? The master password I'm using this month is 12 characters long, does not contain any words found in a dictionary, has both uppercase and lowercase letters, numbers, and punctuation. This means each character comes from a possible set of 26+26+10+32=94 alternatives, if you count the punctuation characters you'll find on my English keyboard. So my password comes from a possible set of 9412 passwords, which is pretty close to 279, and a 79-bit key is pretty strong. But since I don't really use all of the possible letters, numbers, and punctuation characters in a uniform distribution, I really can't rely on having the true strength of 79 bits. That's where the puzzle comes in.

By forcing the attacker to perform 218 iterations of a pseudo-random number generator based on SHA-256, I'm significantly increasing the work he must perform in a brute-force attack. For each password guess, he has to perform 218 extra steps. So you can think of this as "stretching" the password strength by 18 bits. Instead of 279 steps to find my password, a brute-force attack takes up to 297 steps. Now, as I said before, I don't really have 279 bits of entropy in my master password. But you can see that this stretching helps strengthen any password that I choose. By combining a really strong password with a stretching technique like PBKDF2, you can get some serious protection against anyone who might obtain a copy of your password file. This is important if you want your password file to be mobile because you'll often carry it with you or post it on a network share to make it easy to access.

Picking a Good Master Password

Password Minder also offers a measure of entropy whenever you provide a password. For example, when I type a new master password, Password Minder displays the maximum possible entropy the password can have by checking the types of characters I am using and the length of the password. Password Minder won't accept anything less than 60 bits of entropy for a master password. Of course, nothing stops me from using a lousy master password like P@ssw0rd!!, which will register with a maximum entropy value of 66 bits since it uses all the categories of characters that the program checks for.

To help me pick a long master password that I can remember, I imagine a picture and tell myself a little story about it: "Dark leaves fall to the ground as the Autumn wind howls around my house," collapses to DlfttgatAwhamh. Then I throw in a little dance around the keyboard somewhere in there, say @#32 and I'll end up with a nice long password: Dlfttg@#32atAwhamh. This is surprisingly easy to do. I've even pasted a real picture in my office for the first few days while I was memorizing a new passphrase. They say a picture paints a thousand passwords, right? Well, something like that, anyway.

Defense in Depth

Given the high strength of my long master password coupled with password stretching, I must say that I still won't post my password file on my Web site for all to see. I think it's important to have a layered defense, so I guard my password file carefully. Password Minder stores password files in my user profile, where the default access controls on the directory only allow me or an administrator to view the files stored there (note, though, that if your enterprise has set up "roaming profiles," this data will roam between machines you log into and could conceivably be captured en-route). And if I choose to store my password file somewhere else, Password Minder will manually set the access control list the same way (granting only myself and administrators permission to read and write the file) each time it's used. Of course, for password files that I keep on a FAT partition such as a USB memory stick that I carry around with me, Password Minder skips this step. By limiting access to the file, encouraging strong master passwords, and stretching those passwords before using them, Password Minder provides you with defense in depth.

More on Stretching

Since stretching the password takes some time, and computer speeds differ wildly these days, Password Minder allows me to configure the number of iterations it performs during the stretch. I can change this value each time I reset my master password, which Password Minder reminds me to do every 90 days. If you try it out, you'll notice that on its first run, Password Minder will present you with a wizard to help you set up your password file. That wizard will allow you to test your computer speed to figure out what level of stretching you're comfortable with, as shown in Figure 3.

Figure 3 Testing Computer Speed

Figure 3** Testing Computer Speed **

Each tick on the slider bar represents another bit of stretching. The current implementation allows a minimum of 216 iterations, the lowest setting on the slider bar. On my laptop, which is about a year old, this takes a second to calculate. The highest slider setting would be 225, and I've honestly never waited long enough for this to complete. But since Moore's law results in faster computers, someday that setting might make sense.

Conclusion

Next time I'll show you the guts of Password Minder, including the class that implements the PBKDF2 algorithm, and describe how the program encrypts user names and passwords using unique keys derived from the master key. If you can't wait to see the code, which is primarily in C#, you can download it, along with the binaries for Password Minder and instructions for using it from the link at the top of this article. The current version is built with .NET Framework 1.1, which you'll need if you want to run Password Minder.

If you don't have the .NET Framework, consider using Bruce Schneier's Password Safe program, which you can find via https://www.schneier.com/passsafe.html. What really matters is that you pick a password management tool that you trust and that you use it consistently. Don't settle for using the same password everywhere you go!

Send your questions and comments for Keith to  briefs@microsoft.com.

Keith Brown is an independent consultant specializing in application security. He authored Programming Windows Security (Addison-Wesley, 2000) and has just finished his new book, A .NET Developer's Guide to Windows Security (both published by Addison-Wesley). Read the new book online at https://www.pluralsight.com/keith.