from Hacker News

How To Safely Store A Password (2010)

by baddate on 12/3/20, 10:30 AM with 61 comments

  • by skrebbel on 12/3/20, 1:53 PM

    This blog post was instrumental in convincing large swaths of programmers 10 years ago why normal hashing doesn't cut it. This was in a time that PHP code snippets doing md5($password) were widespread. If people were even hashing passwords at all. It was a time when lots of crypto was hard to use for programmers, and the jargon gap between cryptographers and programmers was even bigger than it was now. A blog post that unambiguously told people what to was uncommon and much needed.

    This post truly is internet history. Complaining that there's alternatives today that solve the same problem better than bcrypt is beside the point. The fundamental insight hasn't changed, only the best available algorithm.

  • by Ciantic on 12/3/20, 2:46 PM

    With password storing, you want to cover your ass. One way to do it is follow guidelines of known authority, e.g. NIST or OWASP.

    OWASP has nice document: https://cheatsheetseries.owasp.org/cheatsheets/Password_Stor...

    It boils down to this:

    > Bcrypt is the most widely supported of the algorithms and should be the default choice unless there are specific requirements for PBKDF2, or appropriate knowledge to tune Argon2.

  • by Straw on 12/3/20, 12:39 PM

    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 protection than plain cryptographic hashes.

  • by OliverJones on 12/3/20, 1:24 PM

    For what it's worth the php implementation of password hashing offers a function to determine whether it's time to rehash a password. https://www.php.net/manual/en/function.password-needs-rehash...

    The idea is to alert an application program to the need to regenerate the hash at the time it has the plaintext password in hand (when the user has just presented it for login).

    This is a great idea; rehashing a long-standing bcrypt password with a larger work factor makes it safer.

    And, an extension or new version of the runtime can add a new hashing scheme.

    It would be sweet if other password-hashing APIs added the same kind of thing. User accounts can last far longer than LTS versions of software runtimes, and this can help future-proof them.

  • by _wldu on 12/3/20, 3:24 PM

    I cracked a lot of sha512crypt and PBKDF2-HMAC-SHA256 hashes with a cheap GPU at Defcon this year. Here's the write-up.

    (Cracking Passwords with Cheap Hardware at Defcon):

    https://github.com/62726164/cmiyc2020

  • by wagslane on 12/3/20, 1:53 PM

    I recently did a write up on Bcrypt, for anyone who is unfamiliar with it's technicalities: https://qvault.io/2020/08/24/bcrypt-step-by-step/

  • by bob1029 on 12/3/20, 3:04 PM

    I have started to look at a model where the device itself is the password. How often do we realistically need to concern ourselves with the scenario where multiple users are utilizing the same physical device in 2020?

    Imagine every device has a cookie/token with 256-512 CSPRNG bytes which uniquely identify it. The server uses this as the exclusive means of authentication. For sensitive application scenarios, an in-app PIN mechanism can be used as a soft protective measure (e.g. Robinhood mobile apps use this). The device you initially sign up on can be used to activate additional devices by way of scanning a QR code, offline recovery codes, SMS, etc.

    This model makes it so that a user has no username or password to remember. They just need to make sure they have a backup device and/or offline recovery options available. I find that side-stepping the problem altogether might be the best solution for all involved. Users loathe remembering passwords. Developers screw up password hashing constantly. Malicious actors should grow to strongly dislike this approach.

    This also provides a much stricter chain of custody over how additional devices are added to an account. You have to already have a trusted device to bring another. Making the "What you have" (device) the first factor, and the "What you know" (i.e. pin code) the second factor seems to work out a lot better looking forward.

  • by mijoharas on 12/3/20, 2:48 PM

    So there's a bunch of people here saying Argon2, whereas I thought one of the current best recommendations was scrypt. Can someone explain the trade-off between them?

    Why would you pick one over the other? Or are both "pretty much fine" for most workloads and a casual user shouldn't worry too much?

  • by dang on 12/3/20, 6:54 PM

  • by rendall on 12/3/20, 2:50 PM

    Several days ago I favorited this comment, which is a list of authentication vendors and open source projects:

    https://news.ycombinator.com/item?id=25212694

  • by edf13 on 12/3/20, 2:13 PM

    This works for me...

    https://www.google.co.uk/amp/s/nakedsecurity.sophos.com/2013...

    (Apologies for the blasted Amp link... on my phone)

  • by jonathanstrange on 12/3/20, 1:47 PM

    Cryptographic hashing decreases entropy because it is based on a compression function. Most password stretching algorithms are not optimal in that respect, especially if they repeatedly lengthen the plaintext before hashing it again.

    There are constructions to avoid this problem but they are not commonly used.

  • by neallindsay on 12/3/20, 4:47 PM

    Just me quibbling about language, but this article should really be titled "How To Safely Store A Hash That Lets You Verify A Password". Nobody who knows what they're doing (including the author) advocates storing passwords, even encrypted.

    But an article with that title would probably be less visible to the audience that really needs to read it.

  • by WorldMaker on 12/3/20, 6:13 PM

    How To Safely Store a Password (2020): Don't

    Feeling glib, but passwords are hot potatoes best to avoid if you can. There are plenty of OpenID Connect providers to pass off the buck to, or an increasing number of "passwordless" options including the simple scheme of one-time codes delivered to user email addresses.

  • by jgalt212 on 12/3/20, 5:42 PM

    > So I’m not saying salts are without purpose, I’m saying that they don’t prevent dictionary or brute force attacks (which they don’t)

    Only true if you don't know the salt. Of course, most folks store the hash and salt in the same table or column (Django).

  • by kordlessagain on 12/4/20, 4:51 AM

    Just get rid of passwords.

  • by _wldu on 12/3/20, 1:01 PM

    Ten years ago, bcrypt was a fine suggestion. Today, I'd suggest Argon2.

  • by theandrewbailey on 12/3/20, 1:34 PM

    > Use bcrypt. Use bcrypt. Use bcrypt. Use bcrypt. Use bcrypt. Use bcrypt. Use bcrypt. Use bcrypt. Use bcrypt.

    Use argon2. Use argon2. Use argon2. Use argon2. Use argon2. Use argon2. Use argon2. Use argon2. Use argon2.

    https://github.com/P-H-C/phc-winner-argon2

  • by kemiller2002 on 12/3/20, 1:41 PM

    I always say the best piece of advice on this is, "Don't store passwords." Like shown in other comments, the landscape of what should be used changes frequently. Truthfully, I haven't had to write anything that stores passwords for several years, and until now I hadn't heard of Argon2. That's frightening to me and shows how far out of the game I am now.

    Finding a trusted 3rd party who's responsibility is to stay on top of it, is definitely the way to go if you're not in the security space. It's scary how many people don't understand the basics of hashing and encryption that have written authentication systems. When people ask me if we should do something like this, I normally say, "If you're asking me, then you probably already know the answer."