Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Rethinking Passwords (acm.org)
46 points by jnazario on Jan 1, 2013 | hide | past | favorite | 28 comments



Most sites suck because they want seemingly random passwords that are hard for people to remember. Most sites seem deathly afraid of spaces too and want relatively short passwords.

While many sites would think this is a good password "x5tRwz3m" Length: 8 Strength: Weak. Entropy: 36 bits. Charset Size: 62 characters Is impossible for me to remember. A easy to remember mixed (seemly, but not random) password like that is much easier to generate and use in a off-line dictionary attack.

"I like Microsoft's login page." Length: 30 Strength: Very Strong. Entropy: 147.3 bits Charset Size: 73 characters

is a sentence and people are pretty good at remembering them.

Add in a tiny bit of complexity "I like M?icrosoft's login p!age."

Length: 32 Strength: Very Strong. Entropy: 163.5 bits. Charset Size: 83 characters.

It is exceptionally unlikely that a cracking attempt will reveal that password and that some other type of flaw will be needed to reveal the password or gain access to the account.


What did you use to calculate entropy? 147.3 bits for "I like Microsoft's login page."? Looks highly unlikely that a proper sentence consisting of 5 dictionary words has 147.3 bits of entropy. For comparison, a truly random string of 30 characters from 73 charset has ~185 bits.



Yeah, password strength estimators are often wrong.


How did you find the entropy of these passwords? By my calculations 8 random characters from a set of 62 is 47.6 bits, not 36. (log(2,62)* 8 = 47.6) On a logarithmic scale, this is a huge difference.

For the passphrase, 30 characters chosen from 73 is 185.7 bits (log(2,73)* 30). Even this isn't correct though, because the characters aren't randomly chosen. As the author says: "Not so for human-created passwords, where a sea of associations and language rules greatly reduces the search space." In other words, knowing that the first word is "I" limits the possibilities for the next word, and so on.


The site I used was http://rumkin.com/tools/password/passchk.php

How would an attacker know what the first letter is? Yes an attacker can guess if sentence passwords are used that (a|A),(the|The),and (i|I) would be very common starters but after that the bigger search space complicates things.

https://www.grc.com/haystack.htm

Read the sections on entropy and padding. Just using sentences alone does present attackers the ability to use an encyclopedia attack, but a few randomly placed symbols (padding) turns the endeavor back in to an exhaustive search.


An attacker might be looking over your shoulder, and see the first characters of your password.

Or he might read HN, and see that your preferred passphrase method is composed of english sentences with common substitutions.

Maybe a website you're using leaks its password DB, and your "padding method" is exposed, reducing the search space back to what it was before the padding. I'm going to have to disagree with GRC here. "D0g.........." is a very bad password, especially if you use ".........." as your padding on every website.

Even without this, common substitutions like '3' for 'e' or '!' or 'i' are accounted for in everything but the most naive cracking tools.

Perhaps less likely, a timing attack in the auth system exposes the first few characters of your password, but not the rest.

Why put up with these issues, when something like xkcd's 4 random words works well, is easy to remember and type, and calculates entropy in a uncontroversial way?


Randomly chosen letters have fairly high entropy, about 4 or 5 bits per character. Written English has much, much lower entropy, generally around 1 bit per character. You can see this if you compress written text. Most compressors on normal English will get to 12-15% of the original size.


A diceware passphrase is much more secure than a regular English sentence.

(http://world.std.com/~reinhold/diceware.html)

And substituting some symbols for letters doesn't add much security. Depending on the mode of attack there are precomputed sentences with a variety of substitution.

Be careful with GRC. Some people don't have a high opinion of his analyses:

(http://radsoft.net/news/roundups/grc/20060119,00.shtml)


Even allowing a very generous 2 bits of entropy per letter, that is still just 60 bits worth, not over a hundred bits. Keep in mind that Shannon estimated the entropy of English text to be from 0.6 to 1.5 -- So 147.3 bits for any sentence from natural language seems awfully high.

The actual randomness of such a password is a factor when using some intelligent means to walk the keys pace, such as Markov chains.


One guideline for passwords isnt exicitly mentioned here which is that passwords should be kept secret. People are bad at keeping secrets and there are many reasonable justifications for sharing your password with a trusted friend. Passwords proved identity only if secrecy is assumed. Who is responsible/suffers more if I share my passwords, me or the system administrator?


I'm looking forward to the day that I can use more than just English letters and a couple special characters. It was pretty disappointing to me that I couldn't open the kana keyboard while setting the lock password on my iDevice. Unlike stuff on the web, their system is closed and serves just that one purpose. Am I missing something horribly obvious here?


Yes, encoding and character sets are difficult. Having say even a simple ü in your password brings up a ton of encoding nightmare. Solvable nightmare, but not one i'd want to tackle for passwords. Could they be used, sure, but there is a lot to it. Also you can turn off the simple lock numeric lock screen and use the japanese keyboard if you want (or any others you've turned on). Just swipe off simple passcode under passcode lock.


I've never used the simple lock– I have a long passphrase that I prefer. It still won't let me change keyboards, despite setting the OS language being set to Japanese. It's up-to-date software wise, but was purchased in the US so...


> The question for today's security specialists is, what still makes sense from the 1985 guidelines?

Indeed. Today every webapp developer is a security specialist.

> Certain audit reports (e.g., date and time of last login) should be provided by the system directly to the user.

In 2013, this still makes sense, but is not often implemented.


Supergenpass. Remember one password, generate a unique one per domain. Use a browser extension. Or Android App. The one master password never leaves the local machine. Want something more? Use a Yubikey to store your master password or a postfix of the master password -- that's how I log into my banks, type in a password and then touch my Yubikey Nano which adds another huge amount of characters (the Yubikey needs to be reprogrammed to store a fixed password not an OTP).


Supergenpass is only okay(-ish) if your master password is a large enough completely random string (e.g. 128-bit string: `head -c16 /dev/urandom | base64`). If you use weak password (e.g. the one you can remember), it's trivial to bruteforce it, as it uses

    MD5(master_password || ':' || domain || length)
to derive passwords.

Another problem with any Supergenpass-like password generator is that once the attacker steals or guesses your master password, she will be able to generate your future passwords. I describe password generators like Supergenpass as a rough equivalent of password manager with the attacker having a permanent read-only access to the encrypted database.


Passwords are bullshit. Passwords are the way that the IT moves the responsibility for the users' data, privacy and money over to the users. Of course, users will never use passwords that are any safe, but now they are to blame for this. It's so horribly hypocritial that it makes me cry. We should all be ashamed of this and not get any sleep until the matter is resolved. The problem is: we sleep just fine and make our sin worse.


Your comment is bullshit. Allow me to explain why, I'm not attacking you but the idea that this is an IT problem. IT has nothing to do with the problems of passwords in computer security. Their policies, while likely now outdated are there to act as CYA "industry best practices". The issue they're up against is they cannot secure your data with bad or poorly chosen passwords in the current environment.

Your vitriol is misguided here, while at the same time understandable. The "requirements" of things like one upper case letter, a digit, a nonchar etc... were put in place when systems had only 8 characters for passwords. Ideally these wouldn't be hard requirements but work on a sliding scale based on length. In other words, 8 chars NEEDS the extra entropy and character classes to work. The longer you go however the less need you have for this requirement. Not that it goes away mind you, just that once you reach 12 char passwords, requiring those character classes becomes less useful than optimizing for something a human can remember.

Basically I agree, requiring many character classes is non-useful and harmful. But only for long passwords, or passphrases rather. "one two three four" is a much harder password to crack, even with perfect foreknowledge that I only used lowercase words, didn't capitalize, and didn't put a punctuation character on the end than say "Ab&2x.!(" is. The latter looks like it would be harder to guess, but its length betrays its search space. It is also less secure in that it encourages users to write the password down.

Moving on to the real crux of the issue.

The bigger underlying problem you elude to, but never enumerated, is that security wise, we've NEVER had mathematically proven security in computers up until about 3 years ago, if even that. Even then this is leading edge research. What I mean by that is cryptography right now has only recently had A mathematical proof of it doing what we want it to be doing. Basically, making sure that A and B can communicate without worrying about third party C reading it. Even then this new cryptography could be flawed.

Read up on homomorphic encryption, Craig Gentry's Phd thesis paper: http://crypto.stanford.edu/craig/craig-thesis.pdf

And a more general introduction to its concepts (the math is quite involved): http://www.americanscientist.org/issues/pub/2012/5/alice-and...

The problem here is we are in the dark ages of cryptography and computers. We like to think we're running on advanced things here, but the truth is this stuff is anything but. Things change, slowly. But you can't make fundamental shifts quickly just by hunkering down to solve things. It has to be provably useful.

As to alternatives to passwords, I can't find the research paper right now but there was research done that would have you play games/type stuff and look at how you type/do things. The best part is you yourself don't even know your own password, it is a tertiary aspect of you behavior. The intention was for securing data for military purposes so that even under torture you wouldn't be able to give up your own secrets. This too is only a few years old.

Hopefully some security minded people can correct me on my hastily written reply here or tell me why I myself am wrong. >.<


I memorize one pass-phrase to an encrypted file of machine-generated random passwords for the sites I use. Downside is the extra protection needed for that file, but it's encrypted 256bit and only viewed behind a secure network. Any better way?


I would still prefer lastpass with 2 factor authentication enabled. Any reason you are not going this route?

Sidenote: I wish my 2nd factor for passwords opened my front door and started my car. Kill physical keys, keep passwords.


Basically I feel more comfortable managing my own encrypted vault rather than sharing it (even encrypted) with a 3rd party.


You need a password you can remember? Here's a starting point:

http://www.multicians.org/thvv/gpw-js.html


Yes I can remember Forbidden.


if you like GPW check out anything that's FIPS181 compliant:

http://www.itl.nist.gov/fipspubs/fip181.htm

APG is one of those: http://www.adel.nursat.kz/apg/

but it's old, around ten years since its last update.


Yeah, don't use it:

  pik = Math.random(); // random number [0,1]


What exactly is the problem there? (considering context)





Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: