Ask Slashdot: Definitive Password Management Best Practices Using OSS?

jmcbain writes: I am an software engineer for a client-server user account system handling both Web and smartphone clients. I have been searching for definitive and crystal-clear best practices for managing user account and password data using open-source software, but I have only cobbled together a complete picture from dozens of websites. I currently have a system that sends passwords over SSL and performs bcrypt hashing for storage and authentication checking at the server side. Is that good enough? The recent Ashley Madison breach and the exposure of MD5-hashed passwords (as opposed to bcrypt) has me worried again. Can someone please suggest a definitive, cookbook-style Web resource or book on how to use open-source software to handle user passwords for multiple client-server scenarios? I would like answers to questions such as: Where do I perform hashing (smartphone/web client or server)? What hash algorithm should I use? How do I store the hashes? How can clients recover forgotten passwords? etc.

Comments

Solved...

[Anonymous Coward]

Owasp authentication cheat sheet:

https://www.owasp.org/index.php/Authentication_Cheat_Sheet

Re:Solved...

[Jane Q. Public]

There are simply too many variables involved for someone to write down the simple step-by-step instructions they seem to be asking for.

There is one point that is pretty much cast in stone: there is no such thing as "secure password recovery".

Maybe OP did not mean that literally, but if a password can be "recovered", it isn't secure. There is no way to have both.

Passwords are replaced using a reset process, not recovered.

"How can clients recover forgotten passwords?"

[Gaygirlie]

No. Just.. no. They should *NEVER* be able to retrieve forgotten passwords, ever. If they forget a password you should provide a mechanism to generate a new one and then providing them with that, but you should never offer a mechanism to retrieve the old password. If you can retrieve their old password then anyone who gains access to your servers can also do that.

Re:"How can clients recover forgotten passwords?"

[w3woody]

If you use a one way hash that has been properly salted (i.e., HASH(SALT + password) ), then you should never be able to retrieve forgotten passwords, ever. If you can retrieve a lost password for a user, then you've screwed it up, because if you can recover a lost password, someone who scraped your database can recover a lost password.

The worst, by the way, are web sites which require you to pick a super-secure password (at least 12 characters long, must contain punctuation, both upper and lower case letters, a number character, an Egyptian hieroglyph, and must not match the last 15 passwords used in the past and must be changed ever 30 days)--then stores the password and password history as plain text in the user database. Those are the guys I'd love to murder in cold blood.

Personally I've always liked using some element of a user record attribute as part of the SALT--such as having a UUID associated with each user record that becomes part of the salt for the hash (i.e., HASH(SALT + password + UUID) )--because this means if someone does scrape your database it's computationally a little more difficult to reverse engineer the passwords in the database because even a bunch of people use "123456" as their password, the hashes will be different for each of those users. Of course the UUID must never change or else you'll lock your users out.

I'm also a fan of the POP3 protocol's APOP authentication mechanism, where sending credentials over the 'net requires two transactions: (1) obtaining a unique token for that session, then (2) hashing the password against that token to transmit to the back end. Of course this means you wind up hashing the plain text password *twice*: since you don't have the password on the back end (but its hash) you can only compare against HASH(TOKEN + hashed_password), and on the front end you wind up calculating HASH(TOKEN + HASH(SALT + password + UUID) ). But that requires a lot of work in the client.

Simply sending HASH(SALT + password + UUID) rather than hashing the hash with an additional token means you're subject to a replay attack, where a third party could listen in on the conversation and simply replay the login packet you send to connect to the server.

And while I know a lot of folks claim that all of this is mitigated by using SSH, it doesn't protect against man-in-the-middle attacks, including incidental man-in-the-middle attacks created by certain proxy gateways which use their own certs in order to decrypt HTTP traffic to sniff for viruses or enforce corporate guidelines for acceptable use.

Ultimately security won't stop the most determined hackers; you're not stopping the NSA, for example. But you can stop the script kiddies and disgruntled employees by taking some precautions--such as never storing sensitive information in a database (like credit cards) unencrypted, and using one-way hashes to store passwords.

Oh, and as a footnote: unless you have a Ph.D. in cryptography, don't write your own random functions or hash functions. Yes, I've seen it in the field. Instead, use a cryptographically secure hash function. Heck, even MD-5 is going to be better than anything you try to roll on your own.

Re:"How can clients recover forgotten passwords?"

[Michael Woodhams]

The worst, by the way, are web sites which require you to pick a super-secure password (at least 12 characters long, must contain punctuation, both upper and lower case letters, a number character, an Egyptian hieroglyph, and must not match the last 15 passwords used in the past and must be changed ever 30 days)--then stores the password and password history as plain text in the user database. Those are the guys I'd love to murder in cold blood.

No, cold-blood-murder is reserved for sites that do all of the above and also send you a confirmation e-mail containing your password in clear text.

Use OpenLDAP and Kerberos

[Zombie Ryushu]

Use Kerberos with one of the heftier encryption types. Don't use the default Crypt Password type used in Shadow Passwords, and store your accounts in OpenLDAP, not a SQL Database

Re:Use OpenLDAP and Kerberos

[Zombie Ryushu]

OpenLDAP (and similar LDAP like Databases are meant for Authorization and Authentication functions. They can use ACLs and are better designed for this use, and th ACLs can make them resistant to data leakage. If you must use a SQL database for other custom things, link some form of User ID in LDAP to a corresponding field in SQL.

Re:Use OpenLDAP and Kerberos

[AchilleTalon]

One important reason you should use something like Kerberos, is the usability. The users will not have a different password on each machine with its own rules and expiration date, etc. This quickly lead to users to write down their passwords on a post-it or use the bad practices to manage the security of their own passwords because they have to periodically change their passwords on many machines. Also, you will have a single or a limited number of password repositories to secure instead of having one on each machine.

You are also better to enforce longer passwords than byzantine rules for passwords to get enough entropy. I have even seen password rules which instead of leading to stronger security were leading to weaker security. It is not because a password is difficult to remember by a human it is difficult to crack by an automated program. There is no link between difficult to remember and good password.

Answers

[Lord Duran]

Where do I perform hashing (smartphone/web client or server)?
You hash twice, with different salts - once on the client side and once again (i.e., hash the hash) on the server side. The doubly-salted, doubly-hashed password is the one you store.

What hash algorithm should I use?
You said it yourself - bcrypt. bcrypt allows you to set a cost, which increases password brute-forcing difficulty but also increases computational cost on every verification. Set the cost to be the maximum you can handle - if you have a stronger computer and fewer users, you can set a higher cost.

How do I store the hashes?
Chrome uses encrypted SQLite for browser saved passwords. Which encryption depends on the platform - Windows has CryptProtectData, KDE and Gnome have keyrings. The basic idea for all of these is to use some symmetric encryption algorithm (e.g. AES) with the key derived from some set of hashes on machine-specific data, like hardware serial numbers. If you want to go hardcore, use a hardware encryption dongle (HSM).
Note that it is important to encrypt the file on disk, but it is also important to make sure that decrypted hashes stay in server memory for as little as possible.

How can clients recover forgotten passwords?
They can't recover forgotten passwords - you're only storing hashes, remember? What they can do is reset their password. Two factor authentication is best (a verified email account and phone number, if you can send SMSes or automated calls), but at least email and a security question seems to be the standard.

Re:Answers

[DamonHD]

Security questions IMHO *lower* overall security for a number of reasons and I refuse to use them.

2FA is a good idea.

Rgds

Damon

Re:Answers

[bill_mcgonigle]

Security questions IMHO *lower* overall security for a number of reasons and I refuse to use them.

I often don't have a choice, but my bank only knows that my favorite dog's name was #tg57(747R86$vX. "Old Hashy", we'd call him.

AFAIK, no password vault solutions help the user deal with this kind of nonsense.

Re:Hashing

[Bert64]

Doing the hash client side will open you up to pass the hash attacks...
Trying fixed size hashes won't be a real advantage, there are usually many more possible hashes than actual passwords (assuming you use a sensible hashing algorithm)...
Doing it client side also makes it impractical/pointless to use salts.

You want to authenticate using public/private keys and/or a two factor system if you can, passwords really are a lowest common denominator.