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
Where do I perform hashing (smartphone/web client or server)?
This one should be fairly easy.
If you do the hashing on client side that means that a brute force attempt can be reduced to having the fixed known hash size rather than variable size. The hashing algorithm used will also be known so it won't protect against dictionary attacks either.
First line of defense is where server side begins, client side is already compromised.
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.
MD5 hashing has security advisories against it; it should not be used. It is ignorant and negligent for any organisation to use it to protect a client's information.
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.
Just disable ssh access to the box and you will be fine. I've been doing that for many years and so far never had a problem.
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).
At this point every user has at least one SSO since it's baked into google facebook etc etc etc. So the first thing should be to support as many of those as possible especially arbitrary ones, better ones let users do 2 factor auto use sll keys etc etc. Now you will need a fallback local password use ldap never transmit the password over the wire and use a hash thats not known to be insecure.
No sir I dont like it.
If you forget your password, Libération (http://www.liberation.fr/) will helpfully send it you in an email in plain text.
take a look at this:
https://www.forgerock.com/products/
based on Sun's most excellent suite called Open SSO, which Oracle then decided to pull off the market, these guys forked the codebase, kept it going and have substantially improved it in the process, while maintaining the OSS option.
Keys.
And don't be a douche that makes your developer douches do douchey things with their phones. At least not without a way to near-automagically revoke, recreate and reprovision keys. Because phones will get lost/stolen. So will laptops, for that matter.
If you absolutely, positively have to have a shitty control panel or something to log into in some shitty browser, allow and require passphrases.
Neither of these things is perfect. Both are far, far more resistant to brute force. And neither require a capital letter, a symbol, flashing a west coast gang sign and/or singing "I'm a little teapot" pitch perfectly.
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
it depends
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.
There are lots of DOD requirements about reusing passwords and
changing at least 15 characters and such that actually REQUIRE
you to retain the old passwords. Stupid in my opinion, but you don't
argue with the government.
(Same AC) All good points.
... So before going live, a site operator needs to sign up with each of "the major OpenID providers"...
I didn't realize it had gotten that bad. I don't really have a good answer other than try to provide as many external login methods as possible, but that's a lot less satisfying than just OpenID does everything.
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.
True, poor wording on my part.
If you only want to login with a single device, the answer is simple: at account creation, don't ask for a password at all. Just identify the user by a certificate generated in the background by your app. The main advantage of passwords that other authentication methods have trouble copying is that they let you login on any device because they only require some sort of keyboard.
I don't have a good answer for the SMS fees other than that some two-factor solutions let you use a phone app as a second factor instead of an SMS.
or an e-mail
I meant like how Steam and Humble use e-mail as a kind of second factor: when you do something special (e.g. log on from a computer you haven't used before or in a long time), you get sent an e-mail with a code and are asked to type in the code. It's similar to the text message codes except over e-mail. In security terms, it's more similar to a password reset e-mail, which your service probably supports if it supports e-mail anyway; you might as well make it a certificate reset e-mail instead and avoid involving typing a password on a mobile device's keyboard. If you assume the user gets e-mail on their device or has a camera for a QR code then you could make the code as long as you want but I think the idea is that the short codes expire quickly and only allow a few guesses so it doesn't actually matter.
The user still has to put in the password for the Google account when logging into the Google account.
On Android you have to do so when you first setup the phone or add an account, but afterward it just shows you a list of Google accounts and asks you which one you want to use. (Well, at least, that's how my Android device was setup by default, I assume you can make it ask for your password more often.) That's what I was thinking of because I've had a few apps use that as their login.
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'm not trying to be rude, but if you have to ask you shouldn't be handling this type of information. You need more security education instead of just reading comments from a slashdot post.
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?