3 ms·

I don't think the problem is that storing passwords is too hard, at least not for the majority of startups not dealing with PCI compliance. Setting up a user sy

I don't think the problem is that storing passwords is too hard, at least not for the majority of startups not dealing with PCI compliance. Setting up a user system with bcrypt/scrypt is pretty trivial. The problem is you have several apps that were built before "just use bcrypt" became a meme and switching to bcrypt or some kind of hardened "appliance" just isn't seen as a priority, especially if it would require changes in several legacy systems. It's like telling people to backup their databases. Everyone knows they should do it. It's not hard. But it doesn't directly bring in revenue so therefore some people will inevitably just never get around to it (until they get get hacked and it becomes a PR issue).

pbreit 14y ago
_Beginning_ to use bcrypt/etc may not be that hard but migrating existing users from some other scheme to bcrypt/etc takes a bit more thought and planning. And the "use bcrypt" crowd _never_ provides any guidance on that.
- jleader 14y ago
  I've heard 2 ways to do it: 1. Add a flag column to your password database; whenever anyone signs in without the flag set, encrypt their password the old way (for checking against their old entry in the database) and the new way (for storage in the database) and set their flag. The only trouble is, users who never log in don't get migrated. 2. It's possible to treat the old encrypted form of the password as if it's plaintext, salt that, encrypt with bcrypt, and store the result in the database. Then password checking becomes: encrypt password with old algorithm, salt, encrypt with bcrypt, and check against the database. It lets you convert everyone at once, but makes the login code a little more complicated, forever. If you can't convert everyone's database entry at once, you might still want a flag column, so you can migrate more gradually. There are still all the usual headaches of QA, release management, etc., but presumably you already know how to handle them. What else am I missing?
stcredzero 14y ago
This would be a good selling point for companies once they have a little funding. Save yourself some embarrassment and plop down $1000 for a properly secured password db. There's also a strong selling point for the sites that have gotten hacked.

pbreit 14y ago

_Beginning_ to use bcrypt/etc may not be that hard but migrating existing users from some other scheme to bcrypt/etc takes a bit more thought and planning. And the "use bcrypt" crowd _never_ provides any guidance on that.

jleader 14y ago
I've heard 2 ways to do it: 1. Add a flag column to your password database; whenever anyone signs in without the flag set, encrypt their password the old way (for checking against their old entry in the database) and the new way (for storage in the database) and set their flag. The only trouble is, users who never log in don't get migrated. 2. It's possible to treat the old encrypted form of the password as if it's plaintext, salt that, encrypt with bcrypt, and store the result in the database. Then password checking becomes: encrypt password with old algorithm, salt, encrypt with bcrypt, and check against the database. It lets you convert everyone at once, but makes the login code a little more complicated, forever. If you can't convert everyone's database entry at once, you might still want a flag column, so you can migrate more gradually. There are still all the usual headaches of QA, release management, etc., but presumably you already know how to handle them. What else am I missing?

stcredzero 14y ago

This would be a good selling point for companies once they have a little funding. Save yourself some embarrassment and plop down $1000 for a properly secured password db. There's also a strong selling point for the sites that have gotten hacked.