Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

So what is the ‘standard’ then that doesn’t suck?


https://pages.nist.gov/800-63-3/sp800-63b.html#memsecret

Basically, 8 characters or more, but prevent the user from picking a password that appears on any of the leaked password lists. Store in pbkdf2 or better; use argon2id per https://cheatsheetseries.owasp.org/cheatsheets/Password_Stor...

That's it. Simple. No mandatory symbols. No mandatory changes after a period of time. A password strength estimation meter is optional.

If it needs to be more secure, I might require more minimum characters, but no other restrictions.


What's your opinion on zxcvbn[0]?

It dynamically analyzes a password's cracking time, score, and gives feedback based on the password. imo it's a pretty good ux if used right

[0]: https://github.com/dropbox/zxcvbn


Misused, zxcvbn offers its own security issues.

First, it's not either-or. You can match against zxcvbn strength and some passwordlist.

Second, think of the output of zxcvbn as a very weak hash with a low collision rate. E.g. 'correct-battery-horse-staple' maps to an estimated 213811968952000000000 guesses. In addition to being potentially algorithmically reversible, attackers can simply perform an offline attack against the value 213811968952000000000. So, this metric should never be exposed (e.g. in log files, on screen, etc.)

Third, having the estimated entropy helps a lot when password cracking. If you have the password hash digest and the zxcvbn metrics, then it makes the cracker's job much easier by reducing the search space. (Think, going from checking each molecule of an apple to checking only each molecule on the peel of an apple.)

Further, it's not perfect. The zxcvbn library I used suggests 'correct-battery-horse-staple' is a very strong password!


It indeed is. The bad password you're thinking of is "correct-horse-battery-staple".


Both are bad passwords, and zxcvbn states both are good. Try it here: https://lowe.github.io/tryzxcvbn/

Zxcvbn is imperfect by design. It's a tradeoff it makes for being fast and small.


You might want to re-read the introductory article [0] where the authors themselves look at that specific password.

[0]: https://dropbox.tech/security/zxcvbn-realistic-password-stre...


Yes, I'm very very familiar with this :) I stand by my assertion, "correct-horse-battery-staple" is a weak password to use today. Zxcvbn reporting it as secure is an example of where it's weak.

That XKCD comic came out August 2011, and this article was released April 2012, eight months later. At the time, it made sense to use that as an example of a "highly entropic password" in a blogpost targeting a general technical audience.

It has now been 156.5 months since that comic was released, and 164.5 since zxcvbn was originally trained on its 2011 dataset. "Correct-horse-battery-staple" and its variations are widely used strings and is no longer an example of a strong password.

It's worth being careful about our definition of entropy. The same highly-entropic source generates "hunter2" just as often as it generates "aaaaaaa" just as often as it generates "jpnj6i3".

A "good password" is one that is unlikely to be guessed by an offline cracker. But there are countless strategies an attacker might choose, most of which involve taking a list of passwords and applying rules to them. This is why a highly-entropic source is important (e.g. of all the 32-character passwords, 'weak' ones like "aaaaa..." make a negligible percentage of them) as well as uniqueness ("mP7t6e8TAH..." is a weak password the moment it's leaked in a breach.)

You can't know what strategy the attacker will pick beforehand-- the idea is that it's negligibly likely that an attacker chooses a strategy that cracks your password in a few guesses.

Zxcvbn intentionally takes compromises to be a performant best-effort estimation of how many guesses an attacker would take for your password. (It would improve its estimation of guesses by actually trying to guess your password with `hashcat` and the antipublic combolist, or whatever people are using nowadays, but then it would take eons to provide an estimation rather than milliseconds.)


8 chars is not sufficient. The Hive strength estimates switched to Bcrypt this year but there are still weak systems out there and you should set passwords assuming MD5 which currently demands at least 12 chars for typical users.


Ah, yet another standard. How many years do you think before it’s obsolete?

Also, the ‘no previously leaked passwords’ are gonna piss off a lot of customers.


I think you just picked up the goalposts and brought them home with you. Why ask for a standard in the first place?


Because this is what, the third NIST standard on it?


Things can change? The newer standards improve upon the errors of the old ones and presumably make the old ones deprecated




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

Search: