Security of Password Managers

At USENIX Security this year, there were two papers studying the security of password managers:

It’s interesting work, especially because it looks at security problems in something that is supposed to improve security.

I’ve long recommended a password manager to solve the very real problem that any password that can be easily remembered is vulnerable to a dictionary attack. The world got a visceral reminder of this earlier this week, when hackers posted iCloud photos from celebrity accounts. The attack didn’t exploit a flaw in iCloud; the attack exploited weak passwords.

Security is often a trade-off with convenience, and most password managers automatically fill in passwords on browser pages. This turns out to be a difficult thing to do securely, and opens up password managers to attack.

My own password manager, Password Safe, wasn’t mentioned in either of these papers. I specifically designed it not to automatically fill. I specifically designed it to be a standalone application. The fast way to transfer a password from Password Safe to a browser page is by using the operating system’s cut and paste commands.

I still recommend using a password manager, simply because it allows you to choose longer and stronger passwords. And for the few passwords you should remember, my scheme for generating them is here.

EDITED TO ADD (9/12): The second paper was updated to include PasswordSafe. And this 2012 paper on password managers does include PasswordSafe.

Tags: , , , ,

Posted on September 5, 2014 at 5:18 AM • 91 Comments

Comments

Robert Oe • September 5, 2014 5:39 AM

One advantage with password manager that automatically fills in username/passwords is that it makes phishing so much more difficult since the password manager see the real URL and will not fill in anything on the fake page.

Henry • September 5, 2014 6:01 AM

Bruce, great you still recommend them. I use Sticky Password and they have not been mentioned in the studies as well. They do autofill the info, but as you say, it does not matter if I will copy and paste it myself or make the password manager do it. It is still safer then any other way. But what is sad is that tons of people have still the same weak passwords. We should not aim to discredit password managers, but to stress the importance of having strong and unique passwords.

Brian W • September 5, 2014 6:08 AM

I’d consider the lack of any rate limiting or lockouts on the iCloud API as a pretty big security flaw.

bob • September 5, 2014 6:21 AM

Is autofill safer than cut&paste in the sense that monitoring everything on the clipboard is trivial? “That looks like a user name, I’ll log it and the next couple of entries.”

Mathew Schwartz • September 5, 2014 6:45 AM

Bruce: Disagree that the iCloud attack exploited weak passwords. Much related research to date suggests attackers used, at least in part, phishing attacks and social engineering to capture targets’ Apple ID and password. Didn’t matter is those passwords were weak/strong. Also used the password-reset feature, allowing them to input “secret questions.” Again, the strength of the password didn’t matter.

But a great use of password managers, beyond generating strong/unique passwords for every site, would be to:
1) Let you like on secret questions
2) Record your secret question lies

Thus making secret questions tougher for attacker to guess.

TedH • September 5, 2014 7:04 AM

I use passwdsafe and mostly just let the program generate the password for me, so it is totally random. I don’t have any clue what most of my passwords are since I always cut and paste them from the PW manager. I would like that program to allow the configuration of the length of password generated. Since I never really have to enter them, they may as well be 20 characters instead of 8 or 10.
I use Dropbox to keep the encrypted password file sync’ed to the cloud and a few other devices.

Same • September 5, 2014 7:18 AM

I don’t think Bruce’s pw technique of choosing the first letter of each word in a sentence is secure. Some letters are more common than other letters, esp. when it’s narrowed to the first letter of a word. Also, people are likely to choose a sentence that is not so rare, and further reduces the randomness of the password.

This entire phrase, not just the first letters, was used as a password protecting the genesis block for NXT cryptocurrency, and it was cracked:
It was a bright cold day in April, and the clocks were striking thirteen.
It’s the first line from the novel 1984.

Gerard van Vooren • September 5, 2014 7:22 AM

I think that, besides running a standalone password manager, this password manager should also run in a sandbox that is unable to connect to everything except its own directory and of course the screen/keyboard and cut and paste functionality of the OS. For Windows I always liked Sandboxie. For *nix there are lots of solutions.

Steve Bolton • September 5, 2014 7:37 AM

Who vets the password applications? They provide a rich collection of passwords for an attacker.

How does someone buying a password safe vet the security of the product, or indeed trust the provider. It would seem logical for attackers to author password safe software and then use it to emit passwords to hackers.

. • September 5, 2014 7:38 AM

One other aspect of the recent iCloud “hack” is the fact that some of the data there was actually deleted by the users 4-5 years ago but stayed on iCloud

Just an Australian • September 5, 2014 7:41 AM

What can we do about sites and apps that don’t let you paste the password from your password manager? do they hate security or something? Mostly, I simply won’t use them (fools) but every so often, I have no choice.

BJP • September 5, 2014 8:19 AM

I admit I’m in the minority here, but I do not trust any password managers at all. Text files on encrypted partitions.

Do you REALLY need 24/7/365 access to ALL of your passwords from anywhere in the world? Have you ever been at work and really really needed to do something on one of your secure online accounts (financial, medical) that could not wait until you got home? Why on earth accept the additional risk of exposure at any time from anywhere on the planet?

In the USA there is a public service advertisement campaign to urge people not to SMS while driving, with a catch phrase that “It can wait”. Guess what — whatever you’re doing online can wait, too, whether it’s until you get back to your hardened personal machine or until you copy a complex random string from your encrypted text file.

(Don’t tell me any of you people are telling the truth on security questions. What’s your favorite pizza topping? Concrete. What was your third grade teacher’s name? Buzz Aldrin. What’s your pet’s name? Mozzarella and ricotta. Save these domain-inappropriate lies to the same encrypted text file as your passwords. You’ll need them often because you also delete cookies and get asked for security questions frequently to reconfirm your identity. Right? Right?)

Mike the goat (horn equipped) • September 5, 2014 8:23 AM

Steve: agreed, you’re consolidating the risk and effectively providing a neat little package for an attacker.

I don’t like password managers, but I do recognize the importance of using strong unique passwords across diverse websites to eliminate the risks inherent in credential re-use. My method is pretty simple although certainly not fool-proof and involves me hashing a secret with the name of the site through SHA1 and then base64ing the resulting hash.

There are several cryptographic weaknesses in this approach, but it works quite well for protecting my low security everyday websites. I have memorized strong passwords for the really important stuff like my PGP passphrases etc.

The other cool thing is I don’t need to rely on a third party password manager, nor is anything stored on disk or the cloud. This makes travel a lot more secure at border searches etc. Not recommending this scheme as it has several weaknesses – but my point is, with a little bit of ingenuity password management doesn’t need to be that much of a hassle – certainly not enough to introduce third party managers that bring risks of their own into the equation.

The best solution IMO is to simply develop a mnemonic device that allows you to generate and memorize non-dictionariable (invented word ;-)) passwords. There is no substitute for keeping it all in your head…

André Mello • September 5, 2014 8:28 AM

I personally use the most secure password manager yet, which is my own brain. Of course, this reduces the quantity of passwords I can use at one time, but as long as I can remember a few very secure passwords (sequences of 18 to 64 computationally random characters, mixing any printable character), I feel more safe than I would be relying on unknown software.

Of course the reduced set means I reuse some passwords, but never where it really matters and often, as I create new ones, I mix, mutate and demote the safer passwords to less important credentials, so even those stay secure enough.

Reply to Just an Australian • September 5, 2014 9:20 AM

“What can we do about sites and apps that don’t let you paste the password from your password manager? do they hate security or something? Mostly, I simply won’t use them (fools) but every so often, I have no choice. ”

Agreed, those sites (e.g. Paypal!) are idiotic.

FWIW I found there is a solution, depending on your browser. E.g. in Firefox, browse about:config
and change dom.event.clipboardevents.enabled to disabled.
(Found via link in http://www.troyhunt.com/2014/05/the-cobra-effect-that-is-disabling.html about this problem of stupid websites forbidding you to paste your password.)

Thoth • September 5, 2014 9:41 AM

Some simple features most Password Managers have not implemented:

  • Quorum over K/N split of encrypted sensitive mats.
  • Make data files inconspicuous. Obfuscate names of files and what not. Remove association of data files and possible password programs.

Anyway, constructing passwords inside an untrusted module is considered compromise. Password Managers or not, as long as the setup is in an insecure and untrusted environment, everything down the line is still insecure.

What is necessary is a trusted platform to do computations and secure storage (rarely exists and expensive).

Sasparilla • September 5, 2014 10:01 AM

“One other aspect of the recent iCloud “hack” is the fact that some of the data there was actually deleted by the users 4-5 years ago but stayed on iCloud”

That’s because the bad guys went for the really valuable data on iCloud which were the iThingy backups – which of course contain the old data – including deleted photos, e-mail and message strings etc..

Frankly, I’d turn off the iCloud backup feature and make sure existing iCloud backups were deleted (guessing this happens automatically if the feature is turned off, but it’d be worth verifying) and just backup locally.

Nicholas weaver • September 5, 2014 10:12 AM

Interestingly, 1password (which I use) does not do full autofill, but always requires user interaction, which has really low cognitive burden while avoiding most of the problems mentioned in the first paper.

If someone compromises my computer, I’m screwed anyway, so the fact that they can get all my passwords when I unlock the password manager is something I can live with, since they will get all the ones that matter with just a bit of lurking anyway.

Tom • September 5, 2014 10:19 AM

I find most of the comments here too idealistic. 99% of users don’t think anywhere near like us security guys. Explain the difference between auto-fill and paste to them if you dare. What they DO understand is the convenience factor of auto-fill.

Passwords are fundamentally broken as a security mechanism and we should focus our time on inventing better authentication schemes instead if making a dead horse run faster or discuss which saddle for it fits better.

keiner • September 5, 2014 10:35 AM

From the philosophical point of view this is so absurd:

  1. Passwords are not safe (at least those you can remember)
  2. Therefore get some technical system to keep safe passwords (lots of them)
  3. Secure this system by a password you can remember.

Goto 1

THAT IS SO BIZAAAAAAR, why not take an Apple solution, or better as for an NSA password safe.

andy • September 5, 2014 12:17 PM

Imitation is the sincerest form of flattery. I wrote a Passwørd Safe application that uses scrypt and AES-256 in EAX mode.

The reason I did this is twofold: first, I needed an app that runs on Windows as well as Mac and Linux, and second, I don’t undersrtand why v3 of the original Password Safe file format contains a hash of the encryption key in the clear. While it may not be an easily expoitable hole, I feel there is absolutely no reason for it there. What do you think, Bruce?

JayB • September 5, 2014 12:31 PM

What do you all think of this manager-less approach

Pick a long, complicated password root

A7b546!pk*Btwl87

Memorize the string and then add keywords to the end relevant to each login

A7b546!pkBtwl87 twitter
A7b546!pkBtwl87 facebook
A7b546!pkBtwl87 bank
A7b546!pkBtwl87 email

This way you get a long, hard to crack password that is easy to remember (once you memorize the random string) and can be used on multiple sites but still protects you from offline attacks as the hashes are all different due to the “pin-like” keyword.

I’ve been using this scheme for a while and it works well for me. I’ve written about it here.

http://sidfishes.wordpress.com/2014/03/28/a-password-scheme-you-can-live-with-and-is-probably-pretty-secure/

4o3ign3g3oigjo • September 5, 2014 12:50 PM

PasswordSafe is susceptible to window class sniffing, thread input sniffing, and inline patching to get passwords to safes, and the safe files and their backups are based on an open source format handler. You could give the process a dedicated user or sandbox, but it’d only take specific handling by malware(most secure only needing a UAC UI spoof or to dump some driver stack or heap for token details)..

I like USB dongles, but they all, including ironkey, are susceptible to specific programming attacks. For example with IronKey once you use libusb and implement it’s exchange handler it’s as simple as keylogging it’s x86 process.

Gerard van Vooren • September 5, 2014 1:23 PM

@ JayB

What do you all think of this manager-less approach

What if you use a website that has incompetent sysadmins that store your password as plain text? Do you know what is going on at the other side of the line? Once they have one password, they have them all. And before you know it all your passwords are on the street, just look at Adobe.

I think the approach of Mike the Goat is a lot more sane.

Ray • September 5, 2014 1:23 PM

Here’s my essay about password managers:

http://dillingers.com/blog/2014/06/11/computer-security-a-vote-of-no-confidence/

TLDR: In order to trust a password manager you have to trust the environment it’s running on and the people who wrote it.

And the environments they’re running on are insecure and the people who wrote them are usually unknown, refuse liability, are responding to market pressures that value convenience over security, and working with a business model that aggregates theft targets.

If you want secure storage of passwords, don’t put them where software can get them.

dsansot • September 5, 2014 1:27 PM

@JayB, I do something similar and I like it for it’s simplicity. Also, it works well when two people need to share a password.

The biggest downside is you are relying on the websites to properly handle their passwords by storing a hash. If any of the plaintext of the passwords are leeked, it would be pretty easy to guess what your password is for other sites.

Password Hash • September 5, 2014 1:33 PM

Creating good passphrases that are easy to remember can be difficult but I have found a way that it is easy for me.

Think of a sentence with 15 words or more, I usually use 25 to 30 words, and then use just the first letter of each word to create a base passphrase that can be easily remembered.

Then hash the base passphrase and then use the hash of the base passphrase as the actual passphrase that you use to create PGP keys, for symmetric key encryption of files, for passphrases for cloud storage, and for email accounts.

For best security I use the Tails live DVD to create hashes of text base passphrases for PGP keys, for encrypting and decrypting files, for creating symmetric encrypted files, and for logging into cloud or email accounts.

The Tails 1.1.1 live DVD has a checksum application included, called GtkHash, and you can generate a number of different hashes of text or documents.

Example:

For best security I use the Tails live DVD to create hashes of text base passphrases

Base Passphrase: fbsiuttldtchotbp

Checksum using Digital Format Lowercase Hexadecimal setting.

MD5: f108158e11be54977eea4dab446f12dc
SHA1: 183a4c4b6ba8bc17d41dcc9575c8c2917e621f98
SHA256: 9a3eec53c7757d19ca84d648ec6bc108a650ed5143430ea0b2be420ac0060f2c

Checksum using Digital Format Using the Base64 setting.

MD5: 8QgVjhG+VJd+6k2rRG8S3A==

SHA1: GDpMS2uovBfUHcyVdcjCkX5iH5g=

SHA256: mj7sU8d1fRnKhNZI7GvBCKZQ7VFDQw6gsr5CCsAGDyw=

Keep in mind that I am not worried about the possible vulnerability of MD5 and SHA1. I am only trying to create passphrases that could not be guessed, or gotten with a dictionary attack or brute force attack.

As you can see an easy to remember base passphrase when hashed creates a much stronger passphrase.

Password Hash • September 5, 2014 1:50 PM

Also, for those who don’t know. When you hash a base text passphrase you will always get the same checksum that you have used for the useable passphrase.

The advantage again is you can create easy to remember base passphrases and hash then everytime you need to the useable passphrase.

Jeffrey Goldberg • September 5, 2014 2:02 PM

[Disclosure: I work for AgileBits, the makers of 1Password]

As you say about PWSafe, we made the same decision in 1Password about what Silver et al. call “automatic autofill”. We do not allow it for exactly the reasons listed.

I should point out that we have (potential) customers who state that they really need automatic autofill and that they will use a competing product if we don’t offer it. So far, we have resisted such pressure. It’s nice to have a solid paper that backs us up in our decision. There is an extended discussion of this on our forums.

JayB • September 5, 2014 2:21 PM

@ Gerard & dsansot – Mnemonics don’t work for me and I bet the majority of users. How are you going to remember 50+ different mnemonic phrases? I certainly can’t.

No question that if the someone got a plaintext of my password using that scheme, there is additional risk. However, I think that would have to be targeted specifically at me to some extent. (which, of course, is not beyond the possibility).

Yes it is true that if someone looks through the list and sees the password, has read my blog post or simply says “ooh I bet I know what you’re doing there” my other accounts are susceptible. However, I would think that in the vast majority of plaintext leaks, the table is going to be hashed and automatically run against other hashed tables. In that case, my plaintext pwd isn’t going to show up as a match and will likely be ignored. If there’s a concern there, you could always have 2 random stings with keywords, one for critical sites like banking and one for everything else.

I also think that while not perfect (hence the blog title containing the words “probably pretty secure”), it is a far more secure and easier to use alternative for most non-technical users (and old farts like me)

Sims19 • September 5, 2014 2:21 PM

@JayB

What if one of those web services exposes your password with its root. Then someone would know to change the ending and use the same root for “bank” “twitter” etc.

Nick P • September 5, 2014 2:56 PM

@ Mike the Goat

It seems we think alike again. My method for encrypting files for many years was an encryption tool whose key was strong password + file/resource name -> SHA-256 -> BASE64. This was especially useful with Truecrypt volume as its max was 64 characters and thats the size of SHA2/BASE64. The tool I used worked on top of fsum utility and I used fsum Front End GUI before that.

Note: Some had keyfiles too which were produced similarly.

Worked so well that the 3 drives in one month failure I experienced was unrecoverable. And there went years and years of work + signed references. Lesson learned: triple redundancy for assurance is illusion and maybe I needed to triple that.

DB • September 5, 2014 3:08 PM

@Password Hash

In the English language, certain letters are much much more common as first letters of words than others. This means that any scheme that uses the “first letter of each word of a phrase” is susceptible to cracking much more easily than you’d imagine using such statistics. Also if the phrase is grammatically correct or makes “sense” in any way, then certain words appear together much more commonly than others, for an even better improvement.

@ JayB

Gerard has pointed out the pitfalls of sharing any common parts or obvious roots of the password between multiple sites. Of course if you really don’t care if someone steals that account, then who cares (do I really care if someone pretends to be me posting to abc.com or nbc.com? not really). There are varying degrees of “who gives a hoot” vs “losing this would be the end of my life” with some accounts vs others 🙂

McGroarty • September 5, 2014 3:25 PM

As others have pointed out, the lack of throttling on some Apple ID services (including but not limited to Find My Phone) is indeed a flaw. It’s likely that it was exploited for at least some of these photo dumps.

The other problem is that even for users who turned on multi factor authentication, MFA is not used with several iCloud services that authenticate against an Apple ID. This includes Photo Stream and iCloud device restore. I could find no warning about this when setting up MFA. It’s easy to see where a user might have turned on MFA and felt comfortable selecting a weaker password, believing the weak password wouldn’t come into play as easily. Apple shares part of the blame here as well.

4o3ign3g3oigjo • September 5, 2014 3:44 PM

@Jeffrey Goldberg: Yeah.. I’m not sure what password algorithms and encryption have to do with side-channel attacks around USB dongle protocols and x86 process manipulation(the stuff governments and malware authors actually use).. Glad someone else at least ‘gets it’..

Sancho_P • September 5, 2014 6:13 PM

“The attack didn’t exploit a flaw in iCloud; the attack exploited weak passwords.”
(Bruce Schneier)

By all due respect (Apple and Bruce) I’d challenge that until they reveal details.

  • Cracking an online pwd is a server side issue. This should be a crime (of the service ! ).
  • A NOT secret question as a back up should be a crime, too,
    even in case you hint “Never tell the truth when being online”.

The service knows exactly which IP + device usually accessed the account.
Why not immediately inform the associated email that “this.ip.add.ress” tried to log in using “thiswrongpwd” and was rejected?
Twice.
And consequently access was blocked for 2 hours.
And that this device could never make a device restore until you reply.

BTW check what Anónimo linked on September 5, 2014 12:52 PM
http://unaaldia.hispasec.com/2014/09/la-arquera-y-su-manzana.html</a href>

Doug • September 5, 2014 6:28 PM

@JayB, I used to do something similar then realized that if my password was discovered on one site, any rational person might think ‘hmmmm, wonder if their amazon password ends in amazon’ and poof, you’re screwed.

One issue I don’t see discussed here is the idea that passwords are not mine but belong to me and my wife. A USB or local file system is a PITA because keeping passwords in sync is nearly impossible. At least with a web based system, all of the passwords go one place we both share.

And yes, I do need to log into sites from work or while on vacation or…so again, the web based system has the ability to secure my passwords in a way that is usable.

Anonymous Coward • September 5, 2014 7:19 PM

“The attack didn’t exploit a flaw in iCloud; the attack exploited weak passwords.”

According to Apple.

Relying on “security questions” and lacking a lockout-and-notify feature sound like flaws to me.

Mike the goat (horn equipped) • September 5, 2014 7:33 PM

Jay: the issue with that is that if one of the websites you use is compromised and a thinking human sees something like C!mplIc3t3DPassWdtwitter they’ll know to try it on a few other big websites substituting out the suffix.

Our methods are actually not all that dissimilar, except I take this string, hash and then base64 it. This way a human discovering your password (assume the website keeps them in plaintext for the sake of argument) doesn’t understand what you’re doing – and even if he did, they would have to use brute force or know your unhashed secret to generate others. Not worth it.

Nick P: I had the exact same thing happen to me about five years ago. Three Seagate 160GB HDDs died in quick succession (ie within hours of each other). Do you think my array had enough spares to cope with that kind of failure?

Nick P • September 5, 2014 7:50 PM

@ Mike the Goat

Mine were different brands, different times, and different (nearby) locations. You’re situation might have been a single environmental event. Electrical surge comes to mind if you didn’t have a surge protector or it was hit by a surge before without you replaced it. Many will block one surge then continue functioning without surge protection. Get any power fluctuations or lightening where you were living?

Somebody • September 5, 2014 8:07 PM

I realize password managers are a practical necessity for most user, but they are a horrible kludge. Passwords were designed to be memorized by users. If users cannot remember them it’s time to move on to something else.

If you have the computing power to run a password manager you usually have the computing power to run a better challenge-response, perhaps based on public key encryption or zero-knowledge proofs.

This could solve a lot of problems, including cut and paste, poor server side
security, eavesdropping, and would allow users to seamlessly chose more secure hardware implementations if they cared to.

A password in a password manager is not “something you know”, it’s “something you have”. Time to change the model to what we are actually doing.

Thoth • September 5, 2014 8:15 PM

Passwords for transactions have been know to be a gonna but there is always the beating of the dead horse hoping it comes back well and good.

If stronger entropy permutative keys are used in transactions instead of passwords, attackers need to always guess your permutations instead of a single password but that means rewriting the entire authentication principle used online for years (which is both good and bad).

Presuming the environment is a TCB platform on both ends or at least non the client end his keys are stored in a secure device, the user can generate a keypair (probably DHIES keypair) and during registration over a secure channel sends a key over and the server permutates the user’s key which sends a response and the user picks the response and keys into his secure device which will permutates his other keypair to achieve some sort of a DH Key Agreement of sorts. Every transaction on the user account would permutate the key irreversibly (probably HOTP). During the login session, session challenge and response (not the key itself) is keyed into the login fields and on the user’s secure device and the server the key negotiations and authentication protocol takes place. Essentially the user is keying in challenge and response codes that are one time materials and replay and stealing of these OTP codes are kind of useless. The challenge-response codes should be long enough to prevent collision with other login session’s challenge and response code (no coincidences) and probably a 256 bit permutated code could be used. It is similar to OTP device but the problem with OTP is the short character string that makes it as good as low entropy password halves due to it’s nature to supplement low entropy passwords.

Mike the goat (horn equipped) • September 5, 2014 9:59 PM

Nick: the box was in a data center and no power events were reported. The unit was a dual PSU commercial grade server and neither power supply had tripped. You’d hope that the PSU would die before sending an over voltage into its low voltage side…

A few months later I heard through the grape vine that there were a bad batch of drives that had issues, but it wasn’t from a reliable source so who knows.

Luckily I had a tar of the whole box but it was about a week old. Oh well, guess sh*t happens ;-).

4o3ign3g3oigjo • September 6, 2014 12:32 AM

@John: I also point out the safes have an open format and the process is a standard NT PE with no obfuscation or anti-debug. You can literally mine it with every known key-log method and either scan by extension for safes or hook file API inline.. Using UAC policies on the x86 process only requires a little more specific programming for the attacker(about 30 mins worth)..

It’s the same with most things mentioned here though. If you’re talking about password algorithms and encrypting files through standard file systems, you’re not even paying attention to what is actually being done by malware and governments.. Case in point: 2FA being bypassed with MITB but still being pushed by all the big domains right now..

You have 4086 RSA or 256 AES? Nice.. I bypassed it with two-hours worth of trivial code and ZERO research on password algorithms or storage encryption..

Sandra • September 6, 2014 2:59 AM

It was also very much a flaw in iCloud, as the weak passwords wouldn’t have been guess if iCloud had brute force protection. They have now fixed this flaw.

Sandra • September 6, 2014 3:06 AM

It was also very much a flaw in iCloud, as the weak passwords wouldn’t have been guess if iCloud had brute force protection. They have now fixed this flaw.

Please correct that, as your blog will very like be used in court cases. No doubt Apple would like to use your post to lie about their lack brute force protection.

Clive Robinson • September 6, 2014 7:23 AM

@ Steve Bolton et al,

I agree with you and the others that password managers are like putting all your eggs in a basket and then going bungie jumping with it.

Most peoples computers have more holes in them than a second hand string vest, and are of less use security wise than Elizers bucket.

What is needed is a seperate “unconnected” device of some kind.

Back in the mists of time Bruce suggested a piece of paper in your wallet as being suitable for most people. And to be honest it’s still reasonably good advice.

The down side is that it can be stolen or somebody can look over your shoulder etc. So what gets written on the paper needs to be an aid to memory unique to the user rather than the password it’s self.

One simple way is to use a sentance which contains the equivalent of “stop words” that get realise replaced with other words, phrases or random but memorable mini passwords.

Overly simply you could have “The Cat sat on the Mat” where “the” acts as either stop word or an indicator to the next word etc.

Thus you might have,

“The brown Cat sat on the green mat” or “The Dog&Frog sat on Ann&Mike’s old mat”. You can then compress the sentance to “TD&FsoA&M$om” for the password.

Of course the hard part is to remember which replacments belong to different services, but there are well known memory tricks such as “make a story in your head” to do that.

Sancho_P • September 6, 2014 7:33 AM

@ Mike the goat (horn equipped):

Your system would imply that my standard-pwd “Belinda1984” is safe
*** if ***
the site’s pwd dialog would hash + bas64 both my username and that pwd&URL
already in my browser before sending it to the server?

If true,
this would be the “minimal accepted technical standard” to protect user data,
any service that holds personal information
would be liable if they don’t have it by 2015?

Wouldn’t they already be liable if they store it in plaintext?
Or transmit it in plain http?
Or do not have brute force protection?

@ Sandra:

Everyone here knows that it was a flaw, you can name it as such.
This was a PR gag for the celebrities, no court will be involved except for the poor leaker.

CallMeLateForSupper • September 6, 2014 10:36 AM

A current Wired article comprises three tips “to make yourself more hack-proof”.
http://www.wired.com/2014/09/dont-get-hacked/
1. don’t re-use passwords
2. set up two-factor authentication
3. use a password manager

Two-factor authentication is OK as far as it goes, but, as currently employed, it is useful only to those who use a device that receives SMS. What is there for the population who eschew cell phones? (Either conform or go away, I guess.)

“Dashlane, 1Password, Keeper and LastPass are all great options.”
Bruce! The author disses you by omission! This is the final straw; I’m dumping my Wired subscription. No, wait….

John • September 6, 2014 10:39 AM

Re: Somebody

“A password in a password manager is not “something you know”, it’s “something you have”. Time to change the model to what we are actually doing.”

And I prefer to have something (in some unknown, faraway place) than to know something, considering the UK legal framework, where you can legally extorted from the contents of your mind.

Laurence • September 6, 2014 10:58 AM

Many sites (relying parties) actively work to defeat password managers. Banks and enterprises do this. They want to know that the human of interest was truly present at the time the authentication happened. Also, most password managers run on OS’s that are not that trustworthy.

Seems to me that password guessers are good and getting better so much so that there are no passwords that we can expect the general population of the Internet to be able to remember that will also stand up to password guessers. When bruce showed that the XKCD password scheme wasn’t strong enough, I came to this conclusion.

This means that web sites MUST a) have a password guessing throttle and b) not lose the password data base, even if it is encrypted.

Those of us that want to take the trouble with really long password can to defend ourselves against web sites that don’t do the above, but it is too much to expect most people to do so.

A long term solution to this may be FIDO or FIDO-like systems involving biometrics and secure execution environments like smart cards, TPMs and such. The cool thing about these is that the server only stores public keys. The scary thing is that you have to trust the smart card, TPM and such.

Nick P • September 6, 2014 11:22 AM

@ Lawrence

A simple appliance to prevent password database hacking

Alternate solution that meets your requirements is a high assurance appliance for the password handling with vendor-provided code for client side in numerous platforms. The appliance will take passwords in, but never let them leave. The interface between transport computer and password processing computer might enforce this security property:

  1. Only certain kinds of messages are allowed in.
  2. Only a tiny, response type message is allowed out.
  3. The response message must have a destination matching one of the incoming messages. This part might be improved on to mitigate some risks.
  4. A response can only be produced when a valid message goes in.

  5. Messages might be sent individually or in batches to ensure the atomicity that this implies won’t hurt performance too much.

  6. A designated administrator machine can send authenticated commands to it that result in internal actions or responses to admin’s machine.

Using the old guard strategy, this takes three boxes that are pretty cheap. It can also scale vertically and horizontally. A separation/microkernel approach can do it in software with less assurance. The guard portion that does the checks could also be a dedicated chip with high speed pattern matching, crypto, network processing, and IOMMU. Many possibilities but simplest one just uses 2-3 computers that are $50-300 each. Then you keep adding more until performance requirement is met.

Note: Many sites notice patterns in log-ins where they can schedule maintenance or cost-optimize their setup. If the service using my scheme is like that, then they can use the front-ends to my password appliances for other purposes when logins aren’t needed. That the password systems contribute to company’s operations in other ways increases their ROI and might save money on other hardware.

4o3ign3g3oigjo • September 6, 2014 5:48 PM

Check this out: ‘offline’ startup scanner and AV scan, password manager with dedicated ACLs and runtime user. Sandbox everything that uses network API.. “hack proof” unless there is an escalation zero-day used with specific programming; in which case you need hardware TCM and signed binaries.

As for celebrity hacks.. I argue that these people time traveled to distant geographical locations and either manually accessed the devices with the pictures or used PAN or protocol based generic vulnerabilities to grab files. Saying a central target was targeted is too logical even if it IS the only logically possible explanation outside of botnet databases..

Can we go back to making extremely poor observations of password manager design now? I feel like I’m talking to the people who designed them..

RonK • September 7, 2014 12:36 AM

@ Same

Yes, the NXT genesis block password was not intended to be secure: see URL https://nextcoin.org/index.php?topic=3752.0

I don’t think Bruce’s pw technique of choosing the first letter of
each word in a sentence is secure.

My impression was that Bruce’s position has always been that any passphrase that you can remember without help is insecure.

To add a bit more security to that scheme, use a sequence of digits d_i and instead of taking the first letter of each word, take the (d_i % len(word))-th letter.

Alex • September 7, 2014 4:22 AM

A password manager should be strong enough even for a compromised environment. Which is most likely the case in the real world. A few seconds access to your manager password compromise everything you have. A zero day access malware could install for few minutes, enough to take your main password and data file then auto-erase forever.

  • assume that the existence of some password managers it to get all your data at once. If you memorize several passwords its hard to get everything individually.
  • assume that every keyword you type is logged – it should allow virtual keyboards which should have some kind of protection against mouse click recording (variable letters position etc), fake mouse clicks, fake keys, obfuscation (like pushing abc in keyboard buffer then backspace) or image passwords.
  • assume that the clipboard is logged. The password manager should try to overload and mangle the clipboard, if something is stored there probably will be a big file on disk. There may be other methods too.
  • also you may assume that the keyboard buffer is logged, in case of direct key push.
  • There should be some other protection against other side attacks like memory dumps etc.
  • Best keep data file on an external device.
  • the key stretching functions or the decryption routines should have enough loops to make everything slow to protect against possible brute force attacks.
  • A password manager should allow plugins for adding custom data encryption over the existing one.
  • and of course to be Open Source.
  • assume that every password you enter from keyboard has low entropy to be brute force by a lot of organizations. Probably a 20 characters long password even with digits, caps and other characters is a matter of minutes for a huge botnet network or a security agency supercomputer or custom hardware decryption device, depending on encryption used.
  • choose as long main passwords is possible, with all characters / digits combination
  • you can memorize part of it, put other part in your wallet, and a third part of the main password be from an image generated password….. like moving the mouse on the picture to certain position.
  • never use only dictionary words, but in case you do just modify each one… like adding “^_$” after the third letter, doubling / triple fourth letter, changing cases etc

The password remain the best method so far for to personal access. You cant change your fingerprint for every website, everything relays on fingerprints reader on client side, if this is compromised what you gonna do, cut your finger? Use your toe?

Alex • September 7, 2014 4:42 AM

I forgot to mention something important, the usage of password manager is also important, not only its existence. If you’re using Windows, always remember that most likely you are running important programs with the same user as all other installed software.
If you are logging to your online bank account for example, stop all other running software, restart your browser in safe mode (“no addon” mode, not “porn” mode), so the browser is “clean”, I mean only Microsoft or Mozilla can take (steal) your password, not everybody. Then you can input password with your password manager.
As for Android, every app you install wants access to everything, including camera and contact lists, you never know what they really do… Cant do much without root.

ronys • September 7, 2014 1:01 PM

@TedH: “I would like that program to allow the configuration of the length of password generated.”
PasswordSafe Manage->Password Policies…
Select “Default Policy”, click on Edit, change Password Length field to desired value, OK, OK.

@kermi: “Wouldn’t it be prudent to digitally sign the installer for PasswordSafe?”
Sure. That’s why each uploaded image has a corresponding GPG signature file (.sig suffix).

@4o3ign3g3oigjo: “PasswordSafe is susceptible to …” If an attacker can mount an attack against any of the vulnerabilities you’ve listed (and some you haven’t), then he can do a much simpler attack of replacing the program with an evil clone. As others have pointed out, a password manager cannot be more secure than the platform it runs on.

4o3ign3g3oigjo • September 7, 2014 1:44 PM

@ronys: In the case of PS there is literally no attempt at security outside of binary encryption on the open source ‘safe’ format. This heavily contradicts it’s marketing and website taglines..

I argue that no password manager outside of some signed-process dongles even makes a vague attempt at security, but they don’t hesitate to market based on the contrary..

Windows has PE signing, unlimited PE based obfuscation and encryption techniques, ASLR, ring 0, software and hardware DEP, so it’s not like there aren’t options. Heck, you can even have a TCM opt-in where the hardware supports it.

Thoth • September 7, 2014 10:40 PM

@Lawrence, et. al.

Password Security Module

Due to my recent experiment in experimenting with the Thales nCipher series of HSM, I have to say I like some features of the nCipher model of HSM Thales produce albeit obvious weaknesses I noticed. It’s idea (called a Security World) of using the Administrative Cardsets (a quorum of a Asymm key) to administer (encrypt/sign) a module key (AES) and which cascade to administer a raw key (encrypt/sign) or administer a sub-world (Operator Cardsets which is another set of Assym key) that will further administer raw keys in the sub-world. I hope my understanding of the nCipher World concept is correct unless someone more experienced can point out as I am working on a blackbox HSM. It is not a perfect design but an interesting concept.

My idea is based on something like a HSM but for passwords on FIPS level 3 mode or higher. The module allows network connectivity (you can use guards and filters in between) and only sends a True or False to request for login. For administrative purposes, the module has a built in screen, keyboard and scroller where you walk up to the machine and administrate password changes directly. The operator will use his Operator Card token, insert into the module, enter his PIN and perform the required operation. No one is allowed to look or retrieve the password. A user can change his password by using his existing password to encrypt the new password and submit to the operator or he administrate himself. If the module successfully decrypts (using a format) and retrieves the new password, it will be updated.

So essentially, it is assumed no one knows the exact password except the secure module assuming the Password Security Module machine is properly implemented in clean hardware and software circumstances and proper firewalls, guards and physical security are deployed.

Thoth • September 7, 2014 10:50 PM

Hmmm.. tried to post but failed. Re-post again.

@Lawrence & et al

Password Security Module

Due to my recent experiment in experimenting with the Thales nCipher series of HSM, I have to say I like some features of the nCipher model of HSM Thales produce albeit obvious weaknesses I noticed. It’s idea (called a Security World) of using the Administrative Cardsets (a quorum of a Asymm key) to administer (encrypt/sign) a module key (AES) and which cascade to administer a raw key (encrypt/sign) or administer a sub-world (Operator Cardsets which is another set of Assym key) that will further administer raw keys in the sub-world. I hope my understanding of the nCipher World concept is correct unless someone more experienced can point out as I am working on a blackbox HSM. It is not a perfect design but an interesting concept.

My idea is based on something like a HSM but for passwords on FIPS level 3 mode or higher. The module allows network connectivity (you can use guards and filters in between) and only sends a True or False to request for login. For administrative purposes, the module has a built in screen, keyboard and scroller where you walk up to the machine and administrate password changes directly. The operator will use his Operator Card token, insert into the module, enter his PIN and perform the required operation. No one is allowed to look or retrieve the password. A user can change his password by using his existing password to encrypt the new password and submit to the operator or he administrate himself. If the module successfully decrypts (using a format) and retrieves the new password, it will be updated.

So essentially, it is assumed no one knows the exact password except the secure module assuming the Password Security Module machine is properly implemented in clean hardware and software circumstances and proper firewalls, guards and physical security are deployed.

Craig McQueen • September 7, 2014 11:18 PM

@Ray

If you want secure storage of passwords, don’t put them where software can get them.

So… write it on a sticky note and stick it on your monitor?

Winter • September 8, 2014 1:25 AM

@RonK
“To add a bit more security to that scheme, use a sequence of digits d_i and instead of taking the first letter of each word, take the (d_i % len(word))-th letter.”

Why not type out the whole sentence?

Is “CaAhalhiÜ” really more secure than “Carrot and Angua had a lovely haggish in Überwald” ?

Figureitout • September 8, 2014 1:31 AM

Craig McQueen
So… write it on a sticky note and stick it on your monitor?
–You write fake PW’s on your screen. And keep the real ones on paper in a briefcase. You could also use an entirely separate device, something like a Mooltipass at hackaday or even something simpler like a graphing calculator (can also encrypt them too). See “Susan” or “Patrick” (lol I don’t know) come sneaking up trying to shoulder surf your passwords, you can turn off the calc. pretty quick.

All of which doesn’t mean jack-sh*t if you have a keylogger somewhere on your computer or somewhere in your internet connection, or the site you’re connecting too.

Alex • September 8, 2014 2:14 AM

@Craig McQueen
if your smartphone got compromised, its enough to take a look at it in front of your desktop computer and the sticky notes will be streamed. Or one of your friends phone could do the same job, all smartphones have proximity devices detection and could act redundant if necessary. Just a theory, of course :).

Mike Amling • September 8, 2014 12:05 PM

@Somebody: “If you have the computing power to run a password manager you usually have the computing power to run a better challenge-response, perhaps based on public key encryption or zero-knowledge proofs.”

Exactly.

@Clive Robinson: “What is needed is a separate ‘unconnected’ device of some kind.”

Exactly.

I see the hurdle as doing the two-way (for ZK) transfer of even 80 bits between the browser and the device. It’s more than most people would care to key in, but USB or BlueTooth would introduce more problems. Keying 256 or more bits is fine for setup, but per-transaction manual data entry should be limited.

@Clive Robinson: “Back in the mists of time Bruce suggested a piece of paper in your wallet as being suitable for most people. And to be honest it’s still reasonably good advice.”

Yep. Picking my pocket would be implausibly tailored access.

–Mike Amling

kuhty • September 10, 2014 6:14 AM

Why do password managers leak lot of metadata? They seem to use as small as possible file sizes and also the last modified/last access time gives out information. Therefore it’s easy for an attacker to guess which password file is the main one, or which file was used to access some website (assuming that the attacker has the time of access).

Why don’t password managers do following very simply steps:

<

ul>

  • have a minimum password database file size of 50kB, increase the size by 50kB increments if necessary. This would prevent attacker from knowing wherever do you have one or 1000 passwords in your database.
    • when creating a password database, create multiple files with similar names, one being the correct one and rest having random content. This would add few extra bits of security against brute force attacks.
    • for every password database operation (open, read, write, close), update the last modified and last access time of ALL database files (including the fake ones mentioned previously and other databases that weren’t touched at all).

    One could take this idea further. Now the hard drive space is cheap, so why not create multiple random files with of size of 1-10GB upon the OS installation? Naturally, a disk encryption software that works on containers would be also installed by default. If you want to utilize the encryption, just pick one of “containers” and start using it. This would also add one layer of plausible deniability since everybody would have an encryption software with “containers”, therefore their existence on your computer don’t prove that you are actually using encrypted containers.

    • Clive Robinson • September 10, 2014 9:46 AM

    @ Kuhty,

    You don’t need filesystem timestamps to tell the age of a file or when it was last writen to. It usually is easily determind by the position of the file with respect to the other files around it in the disk sectors and cylinders.

    It’s one of the checks more experienced filesystem forensics bods do as a sanity check on looking for tampered files etc.

    kuhty • September 11, 2014 7:11 AM

    @Clive

    This could work on HDDs (but not on SSDs). However in my example all the password files are created at the same time, and have a fixed size, the position of the files on the disk won’t reveal which one is really in use.

    VinnyG • September 11, 2014 11:13 AM

    Using Password Safe for want of a better practical solution (lots of great concepts in this thread, but ~0 that one can just transition to immediately). Understand its limitations and am reasonably satisfied with it. I am confused by Bruce’s statement that it does not offer autotype capabilities. My version (3.29) clearly offers that as an option and I did experiment with it. I abandoned it because it was too dependent on the widget understanding the format of the web page authentication form and page load timing – passwords were all too frequently typed into the user name field if the page load was interrupted (or the format was weird), and even if I extend limited trust to the page developer (and protocols) to protect what is typed into the pw field, zero percent of that limited trust carries over to the user field.

    SteveMB • September 11, 2014 11:29 AM

    @DB: Acronym (first letters of words in a phrase) passwords aren’t quite as good as true random ones; as you note, first-letter frequencies aren’t equal.

    To test the extent of the effect, I pulled some sample texts (Gutenberg text files of Huckleberry Finn, The War of the Worlds, and Little Fuzzy, if someone cares to check the results), extracted the first letters, and crunched some numbers. The Shannon entropy of the first letters turned out to be 4.07 bits per letter (true random would be 4.70 bits per letter), confirming that nonequal letter frequencies weakens the randomness a bit.

    To see how much “certain words appear together much more commonly” affects the result, I computed the entropy of the digraphs (consecutive first-letter pairs). It was 8.08 bits per digraph — just slightly less than twice the entropy per letter, indicating very weak correlation. Certain words do follow certain other words more often, but when it’s stripped down to just first letters, apparently “word beginning with H” (or whatever) gives virtually no information about what beginning letter will appear next.

    Commenter • September 18, 2014 6:29 PM

    HI Bruce,
    Just to note, Apple has updated Safari for MacOS to 7.1 today. Their security notes said that they put fixes in the autofill problems and even cited the authors of the first paper you posted.

    Joseph R. Jones • September 1, 2015 7:24 PM

    You need to consider moving Password Safe away from SourceForge (which has shown itself to be untrustworthy) and to either a self-hosted source code repository or at least something a bit more trusted like Github. I don’t think people can trust a binary distribution from sourceforge anymore.

    At minimum, could you post a hash here on schneier.com? Since the domain is TLS that would enable concerned users to verify the binaries.

    Karen • October 25, 2016 7:37 AM

    Non-computer-security person here. I have no desire to read a research paper full of computer jargon I won’t understand so I’d like to ask directly.

    I have about 20 different passwords that I feel are of good quality running through my head. Only problem is I frequently forget which password I used for what site, or which version of said password I used. Thus, I have to reset the stupid thing, putting one more password in my head. I’d really like to use this little fingerprint reader on my laptop for all my passwords or for that matter a retinal scanning device but, alas, that will not do.

    I was really hoping for a yes password managers are a good idea, or only if you use a good one (examples), or no don’t use them-a piece of paper is safer. Would someone please respond with one of those choices please?
    Thanks

    Clive Robinson • October 25, 2016 9:34 AM

    @ Karen,

    Would someone please respond with one of those choices please?

    The problem is there are many solutions that have both strong points and week points. And those points vary wildly with which threat you are designing against. Worse is that some services only alow eight character passwords or other limitations, which weaken the available password candidates.

    For instance writing random pass words/phrases on a piece of paper has the advantage of allowing truly random thus very difficult to guess or dictionary attack pass words/phrases of any desired length. But they are easily revealed to any other person who has access to the piece of paper long enough to make a copy of some form (could be a second or two if they have a “photographic memory” and shoulder surfs or has access to a high resolution security camera etc). Further the more secure the pass word/phrase the more likely you are to be seen using the piece of paper…

    Password managers come in two basic flavours accessable by online attackers and those not. As with the piece of paper your concern is with others accessing it. Thus having a password manager on a computer or other device that can be somehow accessed from online is not a smart move nomatter how good the actuall software is. Because the attacker could just “shim” the “HCI” (keyboard and display drivers).

    Thus you might want to take extra precautions on the assumption your pass word/phrase repository be it paper, software or token gets accessed by others. So you could use a prefix or postfix you keep in your head or other method by which only partial information is kept in your repository.

    Beyond the above there is not much more people can say without knowing the specifics of your “use case”, which for obvious reasons you should not make public.

    ab praeceptis • October 25, 2016 2:27 PM

    Karen

    In case you are looking for a magic silver bullet – that doesn’t exist.

    As Clive correctly stated much depends on your use case. In order to recommend a good pw manager, we should at least know your operating system (windows? linux? …).

    Generally speaking and assuming you don’t have highly sensitive state secrets on your notebok, a password manager is a good approach at your “too many sites, too many passwords” problem.

    Fingerprint readers are a two edged thing. On one side they are, oh so comfy. On the other side one shouldn’t put too much trust in them.

    All in all I’d suggest to use a good password manager along with one single high quality password (for the manager). This would reduce your problem very much (to only 1 password rather than many).
    You may or may not add fingerprint reading to that, if the password manager can handle it, depending on your trust in that.

    Finally, and again given that the password manager supports that, you might want to additionally (to the password) use some external “I have” factor such as a smartcard reader or a usb device.
    For company or high sensitivity use that might be attractive, for purely average private use it might be overkill.

    Finally, some practical “mindset” advice: There is no perfect security. All we can strive for is better security, e.g. by making it harder for attackes. You have already done something good by using different passwords for different sites/services. That’s more than what most do. Finally, it’s not only important what one does but also how it’s done. Again, you are on a good way by asking for advice.

    If you tell us more about your use case and your operating system we will quite probably be able to offer you some practical recommenadations.

    Karen • October 26, 2016 3:55 PM

    I use windows mostly. I have no big state secrets, just personal stuff. I’d like to avoid others using my identity and my money. I’m not too worried about shoulder lurkers as mostly I do my personal stuff at home. However, pieces of paper have a tendency to get lost and I do worry about that. I also record my pw’s in code. However, my code is starting to fail me as complexity and extra characters come into play – especially when I get to a page that doesn’t allow certain characters that I’ve built in. That one little tweak messes me up.

    However, my real worries are more broad. Perhaps I’m paranoid about the unknown but, earlier this year my email server ‘lost’ a list of passwords. Directly following my account was hit from Vietnam and Germany with people searching to exploit any info they could. Thankfully, my multiple password strategy kept them from getting access to any important systems. Thus, regardless of the effort I put into security, my greatest fear for vulnerability is my passwords being hacked at random and sold on the black market.

    Hope this helps you better understand my needs. I really am just trying to find something more flexible than a scrap of paper that I may or may not have with me when I need it.

    Thanks

    ab praeceptis • October 26, 2016 5:27 PM

    Karen

    Have a look at http://keepass.info/. That’s quite a nice pw manager with quite good security (the real problem is windows, not the pw manager).

    In case you don’t like it: Whatever you chose or do: Stay away from “Cloud-based” or similar BS.

    Leave a comment

    Login

    Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

    Sidebar photo of Bruce Schneier by Joe MacInnis.