I’m an URGE subscriber. Since they have “merged” with Rhapsody, they migrated my account information. Once, long ago, I had tried Rhapsody out, and had reverted to their free 25-plays-a-month plan.
Now, as Jeff said: no one can remember all 30 username/passwords out there. So, I reuse a few. I happened to have the same login for Rhapsody’s old account and URGE’s new account. So, when they migrated, and I try to login, I get the message:
“You have 2 accounts with the exact same username/password combination. Please call customer support.”
Cheebus. I shudder to think what that stuff is stored in. Definitely not salty, probably very plain. Good for crackers.
Whenever I store user passes I always use a salted hash, with the salt stored in the database and unique to each user (just to make it that extra bit harder for the cracker). Using a unique hash per user means that AT MOST the cracker can get one password out of his hash table, before having to change the salt and start again. What does concern me is sites where they say “Alpha-numeric characters only”, or " Your password must be between x and y characters long" they just scream “I store my passwords in plaintext”.
Yeah I’ve been at places where they view this as really a non-issue since the only access that could be had would be into our system (and therefore not a huge deal as those systems weren’t really mission-critical). Management just couldn’t see any reason to not store passwords as plain-text… but for one system in particular, I just went ahead anyway and chose a very basic symmetric encryption method that incorporated salt. Yeah it wasn’t great and could be bypassed, but it was something and a lot better than plain-text!
The key point that management couldn’t seem to get was that these users are so very likely to be reusing their passwords! I may have a max of 5 unique (some very secure, some not so secure) passwords that I reuse with all the various username+password accounts around the Internet and in work-related systems. I highly doubt that many regular users have up to 5 unique passwords though…
What about the security of browsers storing user-names and passwords (i.e. Password Manager or AutoComplete)? Specifically Firefox and IE… I heavily rely on Firefox and its Password Manager, but I didn’t know until I checked right now that its encryption can be further tightened. How? [On Firefox 2.0] Here are the steps:
Tools - Options - Advanced tab
Encryption sub-tab - Security Devices button
under “NSS Internal FIPS PKCS #11 Module”, click “Change Password”. Set a secure password (gotta have one more don’t we??).
@Bob Armour - wow, you don’t get it 3 times as much as you thought you didn’t However, I think the idea is that the salt is “randomly generated vs. a dictionary word” rather than “randomly generated per database row”, otherwise there’s definitely an issue - you have to store the salt generated for each row.
@Jrn Zaefferer, Scott - Hashing passwords definitely stops the system from ‘remembering’ your password, however there are many 2-way encryption techniques that use a private key to turn a recognisable phrase into something effectively random for storage and back again when required. HTTPS is a prime example of this. Of course, you then need to ramp up the security on the private key
That’s the magic of it! You don’t really need to protect the “salting key.” Sure, it makes it harder if the attacker doesn’t know it, but even if they do, they still have to crack the hash (by dictionary attack, or generating a new rainbow table), which is a non-trivial operation.
“It’s unfortunate that sometimes storing passwords as plain text is a contractual requirement from the client because they don’t want to be forced to create a new one when they forget their original password. Sad world we live in.”
You still should not be storing in plaintext. You should be storing it using reversible encryption. That way if someone gets a backup copy of your database, as happened with Reddit, they still will not have will not have the encryption key you used.
“If the salt is random, how do we reliably generate the same salt value the next time the user logs in?”
You would have to either store the user-unique hash together with the salt used to generate it, or make the salt a function of some other piece of information unique to the user account, like the user name.
you know, I thought about using a random number as as salt.
in fact, I thought of using the unique installation ID for it, which is already stored in my database.
perfect.
but then I thought:
damn, if someone gets the database, he gets the unique installation ID along with it.
there goes the theory.
What you’re doing is essentially duplicating (to a lesser degree) the conversation that takes place during SSL negotiation. Running the login / register page over SSL allows you to bring the focus of your approach back to the server (since you’ve secured your login packets), where you can execute code in an environment you can trust.
FWIW, I’ve always used a per-user hash combined with machine-specific reversible encryption, such as DPAPI.
I’m not sure what the Facebook example has to do with password storage. They say right in the screen shot that they DON’T store passwords. It’s a one-time login, so they can access your address book, and it’s very convenient. How else would they do it? You’re right that it’s vulnerable to phishing though.
It’s fun to blithley throw around absolutes like “never store plaintext passwords,” but in the real world it’s rarely that easy.
I’d estimate that more than half of commonly used authentication protocols (e.g. APOP, HTTP Digest, CRAM-MD5, etc.) require storing plaintext passwords on the server side. These protocols have in common the ability to authenticate a client without either side sending the plaintext password over the wire. This is good, since the wire is typically easier to attack than the database.
It makes more sense to qualify that sentiment as “never store plaintext passwords when the client is expected to send plaintext passwords over the wire during authentication.”
@Arron G: Could you (or anyone else) elaborate on why the username would be a “far worse” choice for a salt than a “static” salt? I’m afraid I don’t see why that would be the case since by adding a unique salt on to each password, a new rainbow table would need to be generated for each user (assuming unique usernames is a constraint). This seems to be better than having the same salt added. What am I missing?
Send this post on over the American Express… Most of the companies in my area that I have to use for utilities need a good lesson on web security. They don’t allow special characters in passwords which drives me nuts – alphanumeric passwords are horrible. I’m just thankful my bank allows me to use my ‘secure’ password.
Another good note for anyone who uses the same password for many sites: append the URL’s acronym to the end of it. So, for example, if your password is “passwd” and the site is codinghorror.com, why not “passwdCH”
@Paul: Aaron G’s not exactly right on the whole “static salt”/password issue. A “static salt” isn’t really a salt at all because it doesn’t obscure identical passwords in a database any more than plain hashing does. Still, usernames aren’t great salts as they tend to be short and use a narrow range of characters rather than the full character set range. Long strings generated by a high-quality PRNG are better. There’s also the problem that if a user uses the same username and password on two sites, they both use the username as the salt, and they both generate their salted hashes the same way, it’s immediately apparent to a cracker that they’re using the same password on one site as the other. The thing about hashes is that their lossy. When the cracker uses rainbow tables to crack a hash, they don’t necessarily get back the original string, but they might get back an equivalent string. If the two sites use the same salt, once the user’s password is cracked on one, it’s cracked on the other, but by using different salts, it has to be cracked for the other as all the cracker might have is a string which hashes to the same value as the password given a certain salt and hash.
However, I think the idea is that the salt is “randomly generated vs. a dictionary word” rather than “randomly generated per database row”, otherwise there’s definitely an issue - you have to store the salt generated for each row.