Never store passwords in a database!

Posted by Tom Moertel Fri, 15 Dec 2006 18:25:00 GMT

Recently, the folks behind Reddit.com confessed that a backup copy of their database had been stolen. Later, spez, one of the Reddit developers, confirmed that the database contained password information for Reddit’s users, and that the information was stored as plain, unprotected text. In other words, once the thief had the database, he had everyone’s passwords as well.

Had the folks at Reddit salted and hashed the passwords and then stored the salts and resulting hashes in the database instead, the thief would now be in a very different situation. Instead of holding all the keys to the kingdom, he would face the prospect of a potentially expensive search for each and every user’s password he wanted to extract from the database. The expense of the search would likely have dissuaded him from making the attempt in earnest, given how little exploitable value a Reddit account represents. In short, the passwords would have been secure, even though the database had fallen into the thief’s hands.

Why, then, didn’t Reddit’s programmers salt and hash the passwords? Because, according to the earlier post by spez, they wanted to be able to send forgotten passwords to users via email. It was a design decision: they weighed the risks of having plain-as-day passwords in the database against the convenience of being able to email users their forgotten passwords and decided that, in the balance, convenience carried more weight. It’s a decision they now regret. (It’s a doubly unfortunate decision because the reasoning behind it is faulty: you don’t need to store passwords in your user database in order to offer convenient account recovery.)

The reason I’m writing about this event isn’t to kick the good folks at Reddit while they’re down. Rather, I’m trying to make a point:

If you are storing passwords in a database, you are almost certainly making a mistake.

The guys at Reddit are known for being smart. They thought they had a good reason for storing passwords in their database. They were wrong. If smart programmers can make this mistake, lots of programmers can. Do you think you have a good reason for storing passwords in your database? If so, you’re probably wrong, too.

How can I be so sure? Because, when it comes to web-app authentication, cutting corners doesn’t buy you anything. It doesn’t save you coding time. It doesn’t give your users a better experience. All it does is weaken the security of your web site, needlessly putting your users, your employer, and yourself at risk.

So please let me take this opportunity to ask if you know of (or perhaps work on) any software systems that store passwords in a database. If so, fix your software now:

  • Salt and hash each and every password (use an expensive hashing function such as bcrypt that was designed for password applications)
  • Store the salt and hash – not the password – in your database.
  • Throw the password itself away.

You’ll be glad you did.

Update: Minor edits for clarity.

Update 2007-02-13: Salting and hashing does not get in the way of account recovery. You do not need to email users their forgotten passwords: there are other account-recovery options that are just as convenient but much more secure. See Don’t let password recovery keep you from protecting your users for more.

Update 2007-10-03: Revised text slightly to emphasize that there is no benefit to be had by implementing a weak password system, and therefore there is no reason not to implement a secure system. Pointed more directly to bcrypt, too.

Posted in ,
Tags , , , ,
55 comments
no trackbacks
Reddit Delicious

Comments

Leave a response

  1. lazy said about 2 hours later:

    Yeah, God forbid someone log into my account and piss off all you whiney ass crybabies or vote up a story I disagree with. Damn you reddit for giving away the kingdom!

  2. Chad said about 2 hours later:

    ok lazy, but what if you were a dumbass and used the same password for your email account (also on file with reddit) as you do for your reddit account?

  3. lazy said about 2 hours later:

    Then the evil hackers that lurk the internet could rape my ass by downloading all the spam I get for being an idiot while surfing the net.

  4. Cory Boston said about 3 hours later:

    Storing passwords in a database per se isn’t wrong only if storing them un-encrypted. An easy solution to their problem would be to simply delete the (encrypted) password in the database and either send them an email with a new temporary password or a link to a page to set a new password (via email to authenticate).

  5. Drew said about 4 hours later:

    If you store the salt in the database, and the database is compromised, then the salt is absolutely worthless. The salt must be stored somewhere else to be worth any extra security at all.

    An attacker that gets your salt can use it to brute-force the password hashes offline.

  6. Rob said about 4 hours later:

    I disagree Drew. First imagine that there are no salts. The attacker can build a single dictionary to simultanously attack every password at once. Now imagine everyone has a different salt which the attacker knows. The bruteforce dictionary attack now needs a dictionary for each salt, which signficantly increases the amount of computation needed.

    See http://en.wikipedia.org/wiki/Password_cracking#Salting

  7. ryan said about 4 hours later:

    Some authentication protocols, such as CHAP, REQUIRE access to the plaintext password.

  8. Tom Moertel said about 5 hours later:

    Drew, the salt is far from worthless. It prevents the use of precomputed-dictionary attacks. These attacks make it possible to assault the entire database of hashed passwords at a very low cost. (See, e.g., RainbowCrack.)

    With the addition of per-password salt, however, each and every password must be attacked individually and without the benefit of precomputed dictionaries – each dictionary term must be rehashed anew for each password under attack. Thus salt makes the prospect of assaulting the entire database several orders of magnitude more expensive.

  9. Bart said about 5 hours later:

    If you really want a send-me-my-password feature without forcing it to be reset, you could ENCRYPT the passwords in the database using a key that is only available to the application.

    You could put the key directly in the code or if you are really feeling adventurous, require that it be entered by a system administrator when the app/web starts up.

    At least this way, the thief needs to steal both a copy of the data and a copy of the server application.

    Not perfect, but certainly better than storing the passwords in plain text.

  10. Damien said about 5 hours later:

    “Never store passwords in a database”

    Why not? Did you mean to say “Never store passwords in clear text”?

  11. PineappleClock said about 5 hours later:

    A bruteforce attack on salted passwords in only feasable if the attacker knows how the plaintext was altered with the salt. If the alteration is’nt something simple like concatenation, storing the salt in the same database is safe.

  12. Pete said about 5 hours later:

    Drew -> different salt for every password, like, I dunno, Unix has been doing for the last 25 years or so.

  13. Tom Moertel said about 5 hours later:

    Damien,

    By “never store passwords in a database” I do, indeed, mean “never store cleartext passwords in a database.” I used the first wording, however, because it makes sense to people who may not know what “cleartext” means.

    Cheers. —Tom

  14. Jason said about 6 hours later:

    Reddit does not use secure transmission so if you’re worried about your password well then, I think you know where this is going…

  15. Keith McLaughlin said about 6 hours later:

    Very misleading title! It’s fine to store passwords in a database, providing it’s not clear text.

  16. Ed said about 6 hours later:

    Well, duh!

    Anyway, it is also possible to store the original passwords in the database so that you can send them out when required but not in cleartext. We have to do this in an app at work that stores sensitive data. You can store the encrypted text and give some extra special thought to how and where from the app gets the encryption keys from. In the case of our project, if the web-app code and the database are both stolen they still won’t be able to decrypt the data.

    Also, if salting it’s pretty convenient to salt with at least something like the hash of the username, that way they need a computed dictionary for each user. Using the contents of some access-controlled file on the server as a second part of the salt is a further idea.

  17. Tom Bortels said about 7 hours later:

    Pfftt. The real lesson is “make sure your password database is secure”. Storing plaintext passwords so that you can, if necessary, send them to users is a valid design decision – and you have to weigh it against the possible downside of exposure.

    We’re not talking about nuclear secrets, life or death, or even financial information here – we’re talking about bragging rights and preferences on a link site. Frankly, the information protected by that password isn’t all that valuable, unless people are dumb enough to use the same password all over the place (in which case, reddit having their plaintext is the LEAST of their problems). Hell – the list of usernames (and email and whatever else was stored there) is probably more valuable than the passwords.

    Yeah – they probably shouldn’t have stored them as plaintext. But if the password isn’t protecting anything terribly important, and if being able to send the plaintext password to the user is, it’s not always a bad decision.

    Frankly, if you want real security, you don’t even want to salt/hash – you want to move to a challenge-response architecture, and only store an intermediate hash (someone mentioned above you need plaintext for APOP and such – no, you don’t, you can pre-hash the password portion, then hash again with the timestamp). Man, I’m a dork.

    But make the security effort be proportional to the information being secured…

  18. Jerry said about 8 hours later:

    No guys, the wording is absolutely correct. Don’t store passwords in your database. Storing a one way hash of a password+salt is not storing the password. Its not storing it encrypted either. Its not storing it at all, and is the correct way to do it.

  19. Jelloman said about 8 hours later:

    The ultimatum to NEVER store passwords in a database makes about as much sense as an ultimatum that ALL doors must have locks.

    The level of security should match the importance of the thing being secured. In the case of most non-commerce web sites, passwords (and the integrity of identities) really aren’t that important. The point is usually just to create a small hurdle to using another person’s identity, and password protection is a damn simple and easy-to-use way to do that. The downside of an identity being compromised in a typical web forum is typically slim to none. Whereas the benefit of being able to email the user their password without changing it is underrated… personally it always bugs me when a site with a password that basically protects nothing forces me through all kinds of secret-question and password-resetting hoops when I forget my password. Just email me the #$%! thing.

    I’m not claiming that all web forums and discussion sites need the same level of security. I’ve been building karma on Slashdot for years, so I’d expect slightly stronger security there. Likewise for the official forums for an online game, where the integrity of identity is important, especially if it bridges into the game.

  20. Jelloman said about 8 hours later:

    Indeed Tom… you just made the same point better than I did.

  21. Stray said about 9 hours later:

    bullshit, Jelloman – people reuse passwords between Reddit and their bank accounts

    if you don’t think that’s true, then you’re pretty damn ignorant

    NEVER, EVER, EVER…store passwords in cleartext in a database

    YOU DON’T HAVE TO RESEND PEOPLE THEIR PASSWORDS IN AN E-MAIL, FOR GOD’S SAKE!

    RESET IT TO A TEMP!

  22. Manfred said about 10 hours later:

    I recently had this happen to me. You use an insecure password which you don’t care about on a (secondary) e-mail account. Attacker guesses username and password from another account (reddit gets compromised or whatever). They then reset passwords that link to that e-mail account. In my case, my excite email was the culprit (who knows how they got that password.) they took over my rarely used ebay account. luckily my paypal account (and all financial accounts) had other passwords, so my system didn’t fail outright…but I lost an e-mail and my ebay account. What would happen to you in the same situation? People reuse usernames and passwords (it’s impossible to remember them otherwise). So what are the damages? With reddit’s blunder, I just lost my least secure password again. Luckily it isn’t tied to any e-mail accounts, or anything important, so I’m good. The moral is, e-mail accounts are more powerful than you think: USE A DIFFERENT PASSWORD FOR YOUR E-MAIL!

  23. Lex said about 10 hours later:

    I’ve recently started using the Django python framework (djangoproject.com), and was pleasantly surprised to see salting and hashing was built in!

  24. Tom Bortels said about 11 hours later:

    Stray – those people also have passwords that are vulnerable to trivial dictionary attacks – better than 5% of them will be “password”, “password1”, or their username [1] (or they were when I did my Crack analysis of the actual 80,000+ dialup passwords I used to have to deal with). That same “secret” password is stored on 20 other sites on the net, and is transferred in plaintext hundreds of times in a day of their surfing. It’s silly to worry too much that this breach has any real effect on the world – the people with secure passwords had a different one for this site, and have likely already changed theirs, and the other 98% of them don’t know or care.

    NEVER, EVER, EVER accept absolute rules in anything, security included. Encryption and Hashing are excellent ideas, of course, but they are by no means a requirement – plaintext password storage has a place and purpose – and it can be argued that when the information/access you’re trying to protect is worth little, and ease of customer service is worth a lot (like we have here), plaintext is a valid choice. You’d want to back that up with better database security of course [2], but that’s another story.

    [1] That’s why Salting doesn’t help all that much. You can try a small custom dictionary – username, username backwards, “password”, and variants, and still have an excellent hit rate. Salting is useful to stop large-dictionary attacks – but you don’t need a large dictionary for a big percentage of insecure passwords. Salting might reduce your hit rate from 5% to 3% – happy for the 2% who got missed, but who cares, you’re in now.

    [2] We don’t really know how this happened – database breach is a likely guess, but it could have been an inside job – and if it was (say someone modified the cgi and logged passwords), then any encryption did in the database would mean nothing. There is no silver bullet – site security is best done on a holistic basis, not bit by bit.

  25. Tom Moertel said about 12 hours later:

    Tom Bortels:

    Some recent data on real-world passwords suggest that people (in this sample, MySpace users) are much better at picking passwords these days:

    • Less than 4 percent of passwords were dictionary words.
    • Only 0.34 percent of users had their user name as their password.
    • Less than 1 percent of passwords were any variation on “password”. (The most-popular variant, “password1”, was used on 0.22 percent of accounts.)

    Regarding this:

    NEVER, EVER, EVER accept absolute rules in anything, security included.

    Let me clarify: I’m not arguing that there are zero cases where it makes sense to store passwords in a database. Rather, I’m arguing that there are so few legitimate cases for storing passwords in a database that it makes sense to adopt the policy of never doing it as the default.

    I think that this point was clear in my article (hint: read the part in bold toward the end of the article), but if you must insist on interpreting natural language in a mathematical or logical sense, you should know that in natural usage it is understood that absolutes are not in fact strictly absolute. The terms “always” and “never,” like all terms in natural usage, imply a certain degree of imprecision and contextual interpretation.

    If you, however, want to ignore the difference between natural and mathematical language, here’s your decoder ring: Whenever you see the word “never,” mentally replace it with “almost never” because that is almost always what the author meant. That’s why authors can write things such as, “Never argue with a police officer,” and, “Never swim after eating a large meal,” and be perfectly understood, even though we can all think of cases where it would make sense to do those things that we should “never” do.

    Cheers. —Tom

  26. Ricky said about 13 hours later:

    For the sake of clarity the title should be amended. The people saying a hash isn’t “the password” are just being pedantic and boring.

  27. ivanof said about 13 hours later:

    yes, but if the theif got away with the database, had it been salted he could not access the passwords unless he had pepper. if he had pepper then he would also need papprika, even then sugar too might be needed to decrypt the passwords. if he was smart he could remove the salt from the database by submerging it in water and boiling it to remove the salt, but then the risks losing data.

  28. Markus said about 15 hours later:

    You ask for the passwords not to be stored in a database. But where else ?

    In the fine print you talk about salting and hashing, but your headline should say: Don’t store clear-text passwords !

  29. pcdinh said about 19 hours later:

    Reddit seems not to be a PHP application. Almost PHP applications store hashed passwords in a database so it is rather difficult to guess them out even the database are stolen.

    Is Reddit implemented in Python or Ruby?

  30. Noah Slater said about 19 hours later:

    pcdinh, your argument makes no sense. PHP is a language, not a framework, and so each application is likely to store passwords as per the developers preference.

  31. Binny V A said about 19 hours later:

    If you hash the password(MD5/SHA1), retrieval is impossible. So ‘Forgot Password’ will not work. Yes, you can reset the password – but that tends to irritate the users.

    If you are maintaining a critical website – where unauthenticated access can create real problems, there is no excuse for not hashing the password. But in the case of reddit, that is not so important.

    The lesson to be learned here is not to use the same password on all sites.

  32. Noah Slater said about 20 hours later:

    Binny V A, hashed passwords can be recovered using dictionary attacks.

  33. lexandro said about 21 hours later:

    Dear Tom!

    I translated your post to hungarian and posted to my blog with your blog’s URL

    Lex

  34. J. Random Hacker said about 21 hours later:

    Ow, the stupid. It hurts us, precious.

    The average user has maybe one or two passwords, so it’s a disservice to them to store their passwords in the clear.

    The slightly more clever user has good, unique passwords for everything important, and a couple of disposable login/passwords combos for everything else. (I know, everybody here uses a randomly-generated 12-character alphanumeric string for each and every Web 2.0 site. But we’re talking about everybody else, not you.)

    So, any way you look at it, salting and hashing passwords is the way to go. You could also use an iterated SHA1 hash, applying it perhaps 50 times. This slows down authentication slightly, but proportionally increases the work required for a dictionary attack.

  35. oldmangettingold said about 21 hours later:

    The best way to store passwords is not storing it. Whenever an user creates an account and provides a password, the following technique can be used to make the life of hackers difficult: 1. use some unique technique should be used to generate a salt, 2. concatenate the salt to the password, 3. use a hashing algorithm such MD5 or SHA1 to hash the password 4. Encrypt the hashed key and save it to database

    To authenticate: 1. After the user enters the password, use SSL to transfer the password to the server, add the salt and take a hash, retrieve the encrypted hash, decrypt the hash and match the hashes to authenticate the user.

    Though, the above method is bit cumbersome and will take time to develop, but it works good and makes the life of a hacker much more difficult.

  36. Nate said about 23 hours later:

    Just a copy of my comment on reddit:

    It’s not incompetence but a common design decision of 95% of the “fun” sites everyone here uses every day. Go look at YouTube and MySpace, no SSL and they both send back the original passwords in email. 37Signals sends back forgotten passwords in email. Everyone here then should spread this outrage around with all those sites too.

    If the site isn’t using SSL for logins, then it doesn’t really matter if these passwords are cleartext in the database. And if you move to SSL logins, then that makes logging in one extra click for everyone. (since the login form can’t be embedded right on the page anymore, or your form is prone to a ‘man in the middle’ attack)

    I expect my Mom maybe to use the same password at Reddit and at her bank, but the people here!? Why would you trust any site with the same password that you might use somewhere that’s important?

    I like these Reddit guys a lot, but Aaron is one shady looking mofo. :) I just assume that he’d try to use my password at every bank site he could find to funnel money into his porno slush fund.

  37. Noah Slater said 1 day later:

    Nate, why can the login form NOT be embedded on the same page?

  38. Jonas said 1 day later:

    Storing passwords in a database in cleartext is, as someone mentioned above, /required/ for some protocols, but then it’s very important to encrypt the backups with GPG. This doesn’t help the security of the runtime database but it sure helps securing backups.

  39. Peter said 1 day later:

    Tom Moertel:

    Natural language usage doesn’t have to be sloppy. That in itself is a design decision by the user.

  40. Anony Moose said 2 days later:

    Alternate design: The “I forgot my password” handler generates a cryptographically strong new password, then sends that out to the user, who can then reset their own password back to the name of their dog.

    Well, ok, sending passwords by email isn’t entirely perfect, but it would have been less bad.

    And it avoids screwing around with encrypting passwords in the database and thus needing to protect the key used to decrypt the passwords. If the hackers can get the database, they can get the key – and if they can’t get the key, then the database could have been protected.

    And if the protocol “requires” the password to be stored in plain text, perhaps you’re asking for trouble by using that protocol. But if you don’t have a damn good reason to require the password to be stored as plaintext, then doing so is just wrong. It’s nowhere near necessary enough to be worth the risk.

  41. neuroxik said 11 days later:

    One method that could be used if one feels it’s better to send back a password by email than requiring a reset is to atleast use a homegrown encryption algorithm. Now I’m not talking about writing a 100K class, just something rather simple and append random chars, make it equal to 16 or 32 bytes to make it resemble a md5/sha1 hash and use that same algo to restore the password. Of course, that would be to use only on “fun” sites.

  42. Unni said 55 days later:

    Definitely, its bad idea of storing password in plain text in database,rather store it in salting hash. BUT i have no idea how to DECRYPT the salted hash. I want to know, if user FORGETS his/her password then HOW we are going to get back the password? I am creating a login page & i have to add “FORGET PASSWORD” feature also. How can i do it??

  43. Tom Moertel said 55 days later:

    Unni, the primary benefit of using a hash is that it is one way. Once you salt and hash the password, there is no practical way to retrieve it, not for would-be attackers, nor for you. Thus when users forget their passwords, you cannot mail their passwords to them.

    How, then, can they log in? If your site requires no stronger authentication than knowing that users own the email addresses they claim to own, you can use the following method.

    Say Joe has lost his password and wants to recover his account. Here’s how you do it:

    1. Generate a big, random, unique token and stuff it into Joe’s account record in the database along with the current date and time.
    2. Send an email to Joe, but instead of enclosing his password (which you can’t recover), tell Joe to click on the enclosed account-recovery link, which of course includes the random token: http://example.com/recover-account?token=pCIqq1unxntVqc8XtCXg.
    3. Joe receives the email and follows the link, which sends his token to your site.
    4. Look up the token in the user database. Is it there?
      1. No? Render “Sorry, bub, that token is bogus, so we cannot recover your account.” Stop.
      2. Yes? Excellent. Grab the user record associated with the token. (It will, of course, be Joe’s record.)
    5. Is the date and time stamp on that record more than a few hours old?
      1. Yes? Render “Sorry, bub, that token has expired.” Stop.
      2. No? Congratulations. Joe has effectively authenticated himself via his email address.
    6. Render a confirmation screen that explains the following to Joe:
      1. His account password is going to be reset to the following random string: ocZodbew. (Generate a new random password each time.)
      2. If he likes the password, great. If not, he can use the change-password feature immediately after the password is reset.
      3. If he understands the above and wants to reset his account password, confirm by clicking the big “Reset My Account Password” button.
    7. Joe clicks the big button.
    8. You, in response, do the following:
      1. Delete the recovery token from Joe’s user record in the database. (This prevents somebody who steals a copy of Joe’s mail from using the old token to steal his account.)
      2. Replace the salt and hash for Joe’s old password with a new salt and the salted-hash of the new, randomly generated password from above.
      3. Render a screen saying, “Joe, your password has been changed to ocZodbew. If you would like to change it, just visit Change Password in your account preferences.” (Provide a link.)
    9. And you’re done!

    If that seems like a complicated process, you should know that the code required to make it happen is shorter than the explanation above. In any case, it’s a small price to pay to protect your users’ passwords.

    Cheers,
    Tom

  44. Parker said 55 days later:

    I use a program called Secret Server. It uses all that good stuff (SHA512, AES26)and works well for multi-users because you can share and audit.

  45. Coda Hale said 67 days later:

    This is why engineers look down on programmers.

    “Yeah, but you only need that kind of support if you’re going to have a lot of cars on the bridge. Duct tape will do fine—you can always replace it once you’ve got a lot of cars on the bridge.”

    “There are no fixed rules with high-voltage electricity. That’s why we use dried-up oatmeal as an insulator.”

    “But if you can’t kick through the walls of the building, then how will people get inside?”

    “Look, responsible people should be wearing parachutes at all times. That way, when a bridge collapses they won’t have to die. It’s common sense, and people who drive on bridges without parachutes get what they deserve. They should know better.”

    “You’re probably better off inventing your own steel alloy, like maybe 30% iron, 10% old GI Joe figurines, and 60% margarine. If you paint it rust-colored, people won’t know the difference. But that’s really just for ‘fun’ skyscrapers.”

    “I don’t see why we should have to spend so much time making sure the dam doesn’t burst. I mean, someone could just use a garden hose and flood the houses downstream just as easily.”

    Jesus wept. Tom, thanks for the article—always nice to see a flash of competency in muddy water. “How would you design an authentication system” just became my #1 job interview question.

  46. Andy Chilton said 72 days later:

    I wrote an article (in Sep 2006) on storing passwords. This was after hearing of a few places where plaintext passwords were being use. You might like to check it out:

    http://kapiti.geek.nz/random/setting-a-good-example-with-passwords.html

    I agree, salting and hashing your passwords is the way to go.

    Thanks for the article pointing out Reddit’s mistake.

  47. Coda Hale said 76 days later:

    FWIW, I went out and implemented state-of-the-art password hashing for Ruby:

    http://blog.codahale.com/2007/02/28/bcrypt-ruby-secure-password-hashing/

    
require "bcrypt" 

password = BCrypt::Password.create("secret")
password #=> "$2a$10$zMW2EmVgmKLRtHZLHUPZk.yydsOQPkqMvko2A8GYpJT0o7QVlNrq." 
password == "wrong password" #=> false
password == "secret"         #=> true

password = BCrypt::Password.new("$2a$10$zMW2EmVgmKLRtHZLHUPZk.yydsOQPkqMvko2A8GYpJT0o7QVlNrq.")
password == "wrong password" #=> false
password == "secret"         #=> true

    It doesn’t get any easier than that. Don’t be Reddit.

  48. brianeleahy@cox.net said 268 days later:

    More then likely it wasn’t smart programmers that dropped the ball.

    I bet it was dumb managers insisting that the functionallity of emailing someone their forgotten password was of dire importance.

  49. David said 350 days later:

    bcrypt is not nearly as secure a hash as sha1 or even md5.

  50. James Law said 467 days later:

    Forgive me for asking a possibly obvious question but what stops your application from unencrypting the password from the database and then sending it to the user via email?

    Just for the record I do disagree with this method of password recovery as email isn’t a secure medium.

  51. Tom Moertel said 468 days later:

    James, thanks for your question.

    In answer, what stops a (reasonably secure) application from unencrypting the password from the database and then sending it to the user is that the password isn’t encrypted or stored in the database. Rather, the password was fed to a one-way hashing function, and the resulting hash value, which cannot be “decrypted” into the original password, was stored in the database instead. The password itself was thrown away and is long gone by the time a user might need to recover his account.

    Cheers! —Tom

  52. Hurricane said 620 days later:

    I was looking for links about the typical password-stored issue and found this.

    I’ve read the comments an I can only add this : encrypted passwords is BAD.

    Why ?

    _ Because there is a way to decrypt them. _ Because it means YOU know the password of your users. And if you are a company it means that the disgrunted guy you just fired knows them too.

    If a user loses his password, start an recovery using a question and contact him by email/fax/phone/... to allow him to reset.

    Digests are good :

    A digest using a salt, login and password will not allow an opponent to retrieve the password easily. He may find something that matches the digest but it will most probably not be the original password of the user. (So he is safe, which is what matters)

    You can also use a few random bits in your digest. It means you will have to try&error all the bits to see if one matches but it means the brute-force attacker will have to too. It will be less expensive for you than for him. (Just check the last OpenPGP specifications)

  53. chaos said 755 days later:

    Could we add in “for God’s sake stop sending me the password I just signed up with in cleartext in an account creation email?”

  54. movax said 910 days later:

    SRP protocol is very interesting option. But is hard to implement. Salted SHA256 with 8000 iterations is simpler :)

    Anyway of this, entier backup should be encrypted.

  55. movax said 910 days later:

    scrypt (which is very very slow = 60ms per password, and needs lots of memory, so even hardware brute force attack is impossible) is even better. (it uses few millions iterations of SHA256, salsa cipher, and needs real random memory).

Trackbacks

Use the following link to trackback from your own site:
http://blog.moertel.com/articles/trackback/267

RSS feed for this post trackback uri

(leave url/email »)

   Comment Markup Help Preview comment