Ask Slashdot: Definitive Password Management Best Practices Using OSS? 77
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.
Solved... (Score:5, Informative)
Owasp authentication cheat sheet:
https://www.owasp.org/index.php/Authentication_Cheat_Sheet
Re: (Score:1)
Mod parent up! That is a very useful resource.
Note that it doesn't meet the complete criteria of the question, because they're looking for a unicorn:
There are simply too many variables involved for someone to write down the simple step-by-step instructions they seem to be asking for.
most important (Score:2)
See the link from the paper here: https://www.youtube.com/watch?... [youtube.com]
Make them long - make them memorable forget the upper/number/Special nonsense.
Re: (Score:3)
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.
Re: (Score:2)
Off-topic, at least.
Re: (Score:1)
generate new passwords.
HASH on servers.
SHA seems pretty good these days. Y use a KNOWN WEAK and BROKEN HASH? Thats asking for trouble.
Make sure you have enough good entropy. HAVEGED Audio entropy, etc.etc. Theres network entropy too.
Re: (Score:3)
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.
Comment removed (Score:5, Insightful)
Re: (Score:2)
You may want to say I will use a Text Messages to a phone, this is also insecure. However it may work for low value websites.
A site would have to be pretty high value in order to require the user to subscribe to cellular service just to use the site.
Re:"How can clients recover forgotten passwords?" (Score:5, Informative)
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: (Score:3)
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.
Re: (Score:2)
"Use bcrypt. Just use bcrypt. Or PBKDF2 if you must. But really bcrypt. General hash (MD, SHA) != Cryptographic hash function. All that extra cleverness that you're doing with UUIDs is superfluous if you just use a proper HASH function (did I mention bcrypt?)."
The purpose of using a separate per-user token is so that when (not "if") someone takes your database, password similarity won't jump out at them. Meaning if a bunch of users use "123456" as their password, they won't be hashed to the same value in th
Re: (Score:1)
Re: (Score:1)
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.
You're supposed to use a new random salt for each password. That's why you store the salt alongside the hashed password in the database.
Re: (Score:2)
Re: (Score:1)
If you're not talking about using the same salt for each password, then I don't know why you're concerned about multiple users having the same hash simply because they have the same password. The different salts will ensure that they have different hashes even if the passwords are the same.
Re: (Score:2)
I remember stuff that is easy for humans to remember and let computers generate the hard stuff.
My slashdot password is echo -n [mysalt]+0100010001010011+slashdot.org | sha265
The hell if I actually remember that. I could generate it with a piece of paper given enough time. I can generate it on almost any OS I use daily.
Let mysalt be HorseBatteryStaple. Some inside joke, anything.
Re: (Score:1)
Re: (Score:2)
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.
Use OpenLDAP and Kerberos (Score:4, Informative)
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: (Score:2)
What are the advantages of using OpenLDAP over a SQL database for storing user accounts? Any real world experience that you could share?
Re: (Score:3)
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: (Score:3)
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 ea
Answers (Score:5, Informative)
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 (Score:4, Insightful)
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: (Score:3)
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: (Score:2)
I had a huge argument about this stuff about my bank and whether a fat middle aged bloke should have a favourite colour (and the entropy in the choices anyway) and was explicitly allowed to put rubbish in all the fields and the bank indeed replaced it all with 2FA soon after.
So sometimes there are choices.
Rgds
Damon
Re: (Score:2)
Re: (Score:2)
Because I wanted the bank staff (and I raised it to a fairly high level) to understand and accept that the 'security questions' could never reasonably used the way that the bank expected, and having gained that insight (and the firestorm of complaint in social media at the time) the bank fixed the issue reasonably well.
It's not perfect, but the current system works reasonably well.
So, argument and persuasion rather than just whining seemed to be winning.
Rgds
Damon
Re: Answers (Score:1)
Re: (Score:2)
Re: (Score:2)
I'm not an expert, but I'd be wary of storing passwords into a keyring that I can no longer open if some piece of hardware fails. Wouldn't a well-chosen master password be safer?
Re: (Score:2)
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?
How to handle passwords? Don't. (Score:1)
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 horrib
OpenID Connect providers decline to offer dyn-reg (Score:2)
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
Do you realy need passwords?? (Score:1)
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.
Sustainable password hashing (Score:1, Informative)
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 addition
Re: (Score:2)
Hmm, yes, when I was putting together security for an online financial system (eg worth stealing credentials for) many years ago, (7) was nagging at me and I might have made do with an upgrade in hash mechanism at next login after a policy change, but yours is nice and/or in combination.
Rgds
Damon
PS. (4) is also an interesting rule-of-thumb, thank you!
How can clients recover forgotten passwords? (Score:2)
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.
Re: (Score:2)
the act of a self service password reset should instantly nuke the old
I disagree. The old password ought to get nuked when the new one is pasted in twice from your password manager. Otherwise, an attacker can DOS your account by requesting a reset every hour.
Salted Password Hashing - Doing it Right (Score:2)
That's the title of this page [crackstation.net] and I found that to be truth in advertising - it's readable and informative.
Quickly outdated (Score:2)
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