Live data from Hacker News

How To Safely Store A Password (2010)

codahale.com

61–65 of 65 posts

Re: How To Safely Store A Password (2010)

#61
post #40
post #29

Earlier quoted context omitted.

Interesting how many corporate security policies act like they don't even know NIST exists. Password rotations for users are audit crown jewels but recommended against by NIST

The problem is really the opposite – too many organizations slavishly follow the pre-2017 NIST guidance! Per wikipedia: > From 2004, the “NIST Special Publication 800-63. Appendix A,”[2] advised people to use irregular capitalization, special characters, and at least one numeral. It also recommended changing passwords regularly, at least every 90 days. This was the advice that most systems followed, and was "baked in…

I agree. I cannot recall a single corporate password policy in my working life that did not require regular password resets. And now that I think about it, I am surprised that Google does not ask me to reset my password on a regular basis. I guess Google follows the latest NIST advice!

(For other readers: It seems that quote comes from here: https://en.wikipedia.org/wiki/Password_policy)

Re: How To Safely Store A Password (2010)

#62
post #58
post #29

Earlier quoted context omitted.

Interesting how many corporate security policies act like they don't even know NIST exists. Password rotations for users are audit crown jewels but recommended against by NIST

>recommended against by NIST As a layman who has too many passwords that rotate too often to keep in memory effectively, I'd like to pass this along to our IT department. Can someone post a link to the NIST best password practices?

This PDF is dated June 2017: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.S...

Re: How To Safely Store A Password (2010)

#63

Earlier quoted context omitted.

In general it is is not true that Argon2 should be recommended over bcrypt. Even even some of the people on the experts panel for the PHC (where Argon2 won) won’t recommend Argon2 over Bcrypt: https://twitter.com/TerahashCorp/status/1155129705034653698 Looks like for the typical case (~200ms calculating the hash) bcrypt beats argon2. I guess that’s what I understand from those discussions, I’m not an expert by any me…

Wow. Never heard that before. Would love a proper article on that. I wonder how scrypt holds up

I am not a security expert, but this looks pretty useful: https://security.stackexchange.com/questions/193351/in-2018-...

And that Twitter link (https://twitter.com/TerahashCorp/status/1155129705034653698) leads here: https://www.password-hashing.net/ ... but, on that website, I could not find an explanation about why to use argon2 over bcrypt.

Re: How To Safely Store A Password (2010)

#65
post #2

Bcrypt doesn't have memory-hardness, so has high susceptibility to ASIC attacks. In particular, it incurs the same or lower cost factor on the attacker than the user. More recent designs such as scrypt and Argon2 force high memory usage as well as computation time, incurring little cost on the users but making ASIC and GPU attacks significantly less cost-effective. Of course, any of these will still give better prote…

In general it is is not true that Argon2 should be recommended over bcrypt. Even even some of the people on the experts panel for the PHC (where Argon2 won) won’t recommend Argon2 over Bcrypt: https://twitter.com/TerahashCorp/status/1155129705034653698 Looks like for the typical case (~200ms calculating the hash) bcrypt beats argon2. I guess that’s what I understand from those discussions, I’m not an expert by any me…

Interesting, I hadn't seen this before. I find it hard to believe, as Argon2 does psuedorandom access over a large array. As soon as this array gets larger than the local GPU cache (much smaller than CPU cache), we should get pretty good protection. What have I missed?

In particular, in terms of ASIC attacks, bcrypt and other non-memory-hard KDFs have extremely efficient implementations. Silicon is cheap, computation is cheap, memory access is extremely expensive- both in terms of time and power usage.

Post reply on HN