Slashdot Mirror
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.
Owasp authentication cheat sheet:
https://www.owasp.org/index.php/Authentication_Cheat_Sheet
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.
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
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.
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.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
If at all possible don't do it. Use OpenID, etc. to let someone else have the passwords and worry about that aspect of security. (This is often made user-friendly by showing "Login with Google", etc. for all of the major OpenID providers.) If OpenID or something similar is not an option... then have a really good reason why not. You really don't want to be touching password hashes if you can avoid it.
If your smartphone app has support for typing in a password on the phone keyboard, something has gone horribly wrong. Once authenticated, the app should just store a certificate internally. To authenticate, use a login on a computer or an e-mail or support using the account the phone is logged in with (e.g. a Google account; I assume iOS has a similar login feature).
I'm tooting my own horn, but you might find my article on long-term password hashing strategies helpful:
https://medium.com/@uther_bendragon/sustainable-password-hashing-8c6bd5de3844
TL;DR version:
1) Use a one-way collision-resistant algorithm developed by professional cryptographers, and the implementation of which has been adequately studied and understood;
2) Do not use an algorithm with known vulnerabilities (this obvious step is sometimes not followed);
3) Use randomly-generated data—salt as additional input to the algorithm to minimize vulnerability to rainbow/lookup table attacks. The salt should be generated from a Cryptographically Secure Pseudo-Random Number Generator;
4) Use a long salt, preferably as long as the output of the hash function;
5) Use an adaptive hashing algorithm—that is to say, an algorithm with a configurable number of encryption iterations to slow attackers (a.k.a. key stretching). The number of iterations can be tuned as the speed of available hardware increases to keep the resulting hash secure. Such choices include PBKDF2, bcrypt and now scrypt.
6) At at some point you will need to change your hashing function, in fact, probably many times. So store the algorithm along with the hash e.g. ALG:HASH:SALT
7) secure legacy hashes by wrapping the obsolete hash with a new one e.g. encrypt the md5 hash of the guy who hasn't logged in for years in your new hashing algorithm and store it with a token like md5|pbkdf2:hash:salt
Even SHA256 ten times in a row has problems when used to derive a key from a password. The key isn't which hashing function you use as much as using it a couple thousand times.
This is often made user-friendly by showing "Login with Google", etc. for all of the major OpenID providers.
In the era of classic OpenID, the relying party could just provide a field to paste in the user's identifier, and then the login form would take to the provider's site to complete authentication. It was envisioned that users would use the browser's autofill feature to populate the identifier field. But in the era of OpenID Connect, only providers that support Dynamic Client Registration (dyn-reg) support the paste-an-identifier flow, and none of the major providers have chosen to implement dyn-reg. So each relying party needs to sign a contract with each provider to obtain an OAuth client key, which is an O(n^2) problem. So before going live, a site operator needs to sign up with each of "the major OpenID providers". How can a site operator tell what are "the major OpenID providers" at any given time, other than Google?
If your smartphone app has support for typing in a password on the phone keyboard, something has gone horribly wrong. Once authenticated, the app should just store a certificate internally. To authenticate, use a login on a computer
A mobile phone is a computer. If you meant specifically a desktop computer, not everybody who owns a mobile phone also owns a desktop computer, such as one of my former co-workers. Nor does everybody who owns a desktop computer also own a mobile phone with an active subscription to unlimited SMS. In countries where both the sender and receiver of a text message are billed, such as the United States, this can cause users to run up big cell bills when logging in with an OpenID Connect provider that uses two-factor authentication.
or an e-mail
I'm not understanding what you mean by this.
or support using the account the phone is logged in with (e.g. a Google account; I assume iOS has a similar login feature).
The user still has to put in the password for the Google account when logging into the Google account.
Allow me to correct this part of your question:
How can clients recover from forgotten passwords. I'm not saying that using the standard practice of implementing a mechanism whereby a user can reset their own password based on their username and email address is perfectly secure - nothing is - but under no circumstances should a password be retrievable in that manner. Also, the act of a self service password reset should instantly nuke the old.
Brought to you by Carl's Junior.
See the link from the paper here: https://www.youtube.com/watch?...
Make them long - make them memorable forget the upper/number/Special nonsense.
That's the title of this page and I found that to be truth in advertising - it's readable and informative.
"Money is a sign of poverty." - Iain Banks
I think the most important thing to remember on security related topics like this: The answers can get quickly outdated as technology progresses.
Books might be outdated by the time they appear in print, especially on a lot of practical details. What was considered impossible a few years ago might be done on a machine with a few big GPUs today. Technologies, ideas and theory advance a lot as there is a real war going on in the security field, both by big companies and more shady organisations. All with huge interests.
RogerWilco the Adventurous Janitor
It's still a valid question to respond to, if only because for every person who steps up to the plate asking questions to alleviate their ignorance, there are a hundred others out there implementing authentication on various public web sites who remain seeped in their own ignorance.
And programmers are an egotistical lot: when was the last time you ever told a programmer "leave that to the experts" and didn't get "fuck you, asshole; I know what I'm doing!!!" as a response?