9 ms·

Instapaper stores only salted SHA-1 hashes of passwords, so those are relatively safe. -- Obligatory statement on NEVER USING SHA-1 HASHES to make passwords "

• IgorPartola 15y ago
  I have been thinking about switching everything to bcrypt, but there is definitely way too much confusion about bcrypt vs scrypt, how many rounds to set for bcrypt, etc. What is the definitive source for figuring out what the new standard should be? Does anyone have any links to something that's peer-reviewed and approved for use by someone with enough authority to do so?
  • tptacek 15y ago
    No there isn't. You only think that because when geeks discuss anything that involves one or more knobs, a huge debate must necessarily ensue about the proper values of those knobs. Just use the bcrypt defaults. You will be fine. You will in particular be so much better off than salted SHA-1 that this topic will be mooted. Later on, maybe in 5-10 years, you can re-engage with the debate about what a good cost factor for bcrypt will be in 2020.
    • IgorPartola 15y ago
      Thanks. I am just trying to navigate the sea of misinformation that spews forth everywhere about salted hashes vs bcrypt vs scrypt. I can see that lots of people claim that bcrypt is better, but I am not aware of anything about it other than the original paper. Basically, I want to know what the chances are that two months after I implement bcrypt a huge issue with it will be discovered and I'll have to move everything to some new scheme.
      • tptacek 15y ago
        There is virtually no chance that, after selecting bcrypt, you will be forced to scramble to replace it in 2 months. There is no chance that, after selecting bcrypt, you will be forced to scramble to replace it with salted SHA-1 hashes. bcrypt is strictly better than what you're doing now.
        • IgorPartola 15y ago
          Fantastic. One more question: does increasing the work factor automagically upgrade existing passwords in some way? As in, will bcrypt passwords created today be strong enough in 2020?
          • tptacek 15y ago
            No; you'd upgrade them incrementally.
          • getsat 15y ago
            The Ruby on Rails auth system I use, Devise [1], will automatically update a user's password to use your new work factor on their next login. You could do something similar. [1] https://github.com/plataformatec/devise https://github.com/plataformatec/devise
          • daeken 15y ago
            getsat and tptacek have already answered your question, so I won't rehash that (pun wholly intended), but I should point out that one interesting property of PBKDF2 is that you can increment the work factor (number of iterations). PBKDF2(password, iterations=10) == PBKDF2(PBKDF2(password, iterations=5), iterations=5) Thus you could, say, increase the number of iterations every month. All that said, you should still use bcrypt; this is just an interesting property IMO.
            • keeperofdakeys 15y ago
              That does introduce a security concern though. While it might be hard in practise, if you have a copy of a hashed password iterated 200 times, then a copy of the same hashed password iterated 300 times and have cracked the 200 iteration hash, you could verify the other hash is the same by applying 100 iterations to the hash. To solve this you would want to change the salt whenever you change the password, which involves doing all the iterations again. Then you are no better off then using a non-incrementing solution like bcrypt. The only situation where you wouldn't be able to make a new salt, however, is if the user hasn't logged in for a while (which is quite possible for single-use accounts on websites).
    • JabavuAdams 15y ago
      What's a ready to go bcrypt library for C/C++? I mean include headers, link lib / so, and call a function. I've been looking into this over the past few days, and I've decided to just extract the relevant files from py-bcrypt, and get rid of the compatibility layer.
      • pdebruic 15y ago
        The C reference implementation is here: http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libc/crypt/ http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libc/crypt/ Its from OpenBSD and implemented by the developers of the algorithm. It is what the Python/Ruby/Lisp/PHP etc. versions are derived from or wrap
        • JabavuAdams 15y ago
          Thanks!
    • thaumaturgy 15y ago
      In the defense of geeks, this probably follows from the mantra that you should never ever run any command on your system ever without completely and fully understanding what it does and all of its options and etc. etc. So now people are twitchy about "just use the defaults", especially when it comes to something they don't really understand, like cryptography.
      • tptacek 15y ago
        As a geek let me just say that it is all love with me and the geeks. Just: in this case, you can just take the defaults and be better off.
        • thaumaturgy 15y ago
          OK. By the way, in case you haven't heard it lately, thanks for hanging around and demystifying this stuff for so many people. It's a huge help.
          • aphrax 15y ago
            as is your comment.
        • deleted 15y ago
          [deleted]
    • eneveu 15y ago
      I got into a debate on StackOverflow over bcrypt vs salted SHA1: http://stackoverflow.com/questions/3722780/do-any-security-experts-recommend-bcrypt-for-password-storage/3722893#3722893 http://stackoverflow.com/questions/3722780/do-any-security-e... I think I'm right in choosing bcrypt, but one interesting argument against it was that, being slower, it would facilitate DoS attacks. You want the password hashing to be slow to prevent brute-forcing, but, if it's too slow, attackers could supposedly DoS your login system by trying tons of passwords. I'm not a security expert, and I didn't know what to respond to that. How would one mitigate this problem? Is it even really a problem?
      • dekz 15y ago
        One of the fundamental ideas of cryptology is using the right algorithm for the type of data and the length of its required security. If the cost required to break an algorithm is greater than the value of of the encrypted data, you're probably safe. You can always store the password of the users again and update the crypto used, (more iterations, different digest algorithm). It's never a question of if it will be broken, but when. Choosing iterations for a PBKDF takes a bit of common sense, yes if you're going to roflscale and think 100000000 iterations is a good idea currently, then you may run into performance issues. The correct balance is performance vs security and you can only choose one. You want to authenticate the user as fast as possible while also making it unfeasible to recover the data. As with everything, a little common sense and knowledge goes a long way.
      • Joakal 15y ago
        Just like you don't want over 60 requests per second from a client, you don't want them to be able to allow that much log in attempts. Look at Gmail failed login process. A captcha is required after 3 failed attempts is preferable to a "you can't login after this many attempts" that I remember getting on a forum.
  • seiji 15y ago
    scrypt slides: http://www.tarsnap.com/scrypt/scrypt-slides.pdf http://www.tarsnap.com/scrypt/scrypt-slides.pdf Takeaway: Cost to crack one MD5 password: $1. Cost to crack one scrypt password: $50M to $200B. You want your login to be slow compared to the rest of your application. It's okay to take half a second to verify a login.
    • tptacek 15y ago
      scrypt is better than bcrypt, but not by the same margin that bcrypt is better than salted hashes. Salted hashes are a straight-up vulnerability. bcrypt is a best practice. Note that almost nobody uses scrypt. We don't recommend it, not because it's insecure, but because it's painful to implement for most companies. But use either. Or just use PBKDF2. All of the adaptive hashes are fine.
      • StavrosK 15y ago
        > Salted hashes are a straight-up vulnerability. I find this a bit of a misnomer. I understand what you mean in context, of course, but, strictly speaking, bcrypt is a "hash", and "salted" is always good.
        • tptacek 15y ago
          What was your goal with this comment?
          • StavrosK 15y ago
            Clarification. Right now we have > Salted hashes are a straight-up vulnerability. -- tptacek
            • JoachimSchipper 15y ago
              "Salted or unsalted versions of common hash functions (MD5, SHA-1, SHA-2, SHA-3) are not to be used to store passwords."
  • deleted 15y ago
    [deleted]
• cheez 15y ago
  Can you describe why it's better?
  • 5l 15y ago
    He already did: "Any normal person can brute force millions of SHA-1 hashes (salted however much you want) per second on a GPU." This is not true of bcrypt.
  • tptacek 15y ago
    http://codahale.com/how-to-safely-store-a-password/ http://codahale.com/how-to-safely-store-a-password/ (Be prepared for your comment score to visit the grey depths if you attempt to relitigate Coda's blog post here and don't know exactly what you're talking about.)
    • cheez 15y ago
      That might be the most awesome page I've ever read. Bcrypt it is :-)
    • davidhollander 15y ago
      Why is bcrypt better than simply recursively hashing SHA512 ~2^11 times to produce an equivalent work factor? Assume wall time is held constant at 1 second per password using both methods: is there an entropy loss or weakness associated with recursive hashing that bcrypt avoids?
      • eneveu 15y ago
        What you are referring to is called "stretching". It's a lot better than a simple salted hash, but bcrypt would still be better. I'm no crypto expert, but I think this is due to the way bcrypt was designed, and their use of a pessimized Blowfish cypher. SHA512 was designed for speed, which is the opposite of what you want with a password hashing scheme. tptacek talks a little about this in this blog post: http://chargen.matasano.com/chargen/2007/9/7/enough-with-the-rainbow-tables-what-you-need-to-know-about-s.html http://chargen.matasano.com/chargen/2007/9/7/enough-with-the... "Bcrypt uses Blowfish instead of MD5. Blowfish is a block cipher with a notoriously expensive setup time. To optimize Blowfish to run much faster, you’d have to contribute a major advance to cryptography. We security practioners are all “betting people”, and we usually like to place our bets on the side that “demands major advances in cryptography”." Other interesting links: http://stackoverflow.com/questions/3722780/do-any-security-experts-recommend-bcrypt-for-password-storage http://stackoverflow.com/questions/3722780/do-any-security-e... http://en.wikipedia.org/wiki/Bcrypt http://en.wikipedia.org/wiki/Bcrypt
• getsat 15y ago
  > can brute force millions Modern consumer video cards can do billions per second now. You might as well just store them in plaintext instead of using SHA1/MD5 with or without salting. :/
  • mwytock 15y ago
    I dont understand. If you can use mixed-cased, letters and symbols you have 26 * 2 + 20 = 72 possible characters. 72^8 >> 1e9 It would still take more than 8 days to brute force at 1 billion/sec. And using a longer password (16 chars?) would make this a very long time. Or is there other trick that makes this fast? Or, is it simply that people don't choose random, long passwords?
    • tptacek 15y ago
      Secure password hashes don't protect users, and particularly not users who use one-time effectively-random passwords. Secure password hashes protect application developers from the disclosure of hundreds or thousands of user passwords from their database. It allows them to attest to their userbase "your password is cryptographically stored in a manner that makes them hard to break even by dedicated hardware; you should consider changing your password if it's weak and shared", instead of, "expect to see your password on Pastebin any day now".
      • kragen 15y ago
        To clarify, I assume you mean that using secure password hashes instead of insecure ones does not help users who use one-time effectively-random passwords, because those users are already safe? That is true. However, it seems to me that the combination of an effectively-random password and password hashing does protect users, because their password is not effectively crackable in a situation like this. Additionally, there's a tradeoff between how secure your password hashing is and how much randomness users need to put into their password: every additional factor of 1000 in the iterations of the hash saves you a random character or two.
        • 15y ago
• mbreese 15y ago
  That was my first thought too. Not only does the FBI have the salted hashes, but they also have a copy of the code for the website. So they know what the salt values are. This makes it even easier to brute force the hashes.
  • tptacek 15y ago
    You've been downmodded because password hash salts are public nonce values; usually, schemes that depend on "secret salts" are crackpot alternatives to secure password hashes. (I didn't downmod you).
    • encoderer 15y ago
      thomas, another programmer in the office just asked this question which I haven't a good answer for: Instead of using a known salt stored in, say, a config file, or prepended to the stored hash, why not derive the salt from some substr of the supplied password? His example was, salt would be concat(left3chars, right3chars). And so when the user inputs his password into the system, you just derive the salt using that same consistent algorithm, and supply both that derived salt and the password into the algorithm. My only answer was "It's always a bad thing to be clever with crypto, just do it by the book" but he asked for more and I couldn't give him a sound debunking (or an authoritative endorsement). I build systems -- and do it very well -- and all I know about crypto is what I've had to learn to implement other peoples crypto systems.
      • tptacek 15y ago
        The purpose of a salt is to randomize the password hashes so you can't easily precompute them. A "salt" derived from the password itself isn't random; it's deterministic. Salts don't add much security, but they do defeat precomputation. The scheme your coworker proposed doesn't do that.
        • encoderer 15y ago
          I'm not going to lie and say I was already thinking that, but I did have a notion that, in such a scheme, if somebodies passowrd was "1111111" then your salt + password would be the unimpressive 1111111111111. But if you don't mind a follow-up, wouldn't it still defeat rainbow tables? Why not?
• joevandyk 15y ago
  So if I'm using SHA-1 already to store passwords, what are my options for moving to a different system? I assume there's no way to rehash the passwords?
  • mapgrep 15y ago
    Convert as sessions expire and people sign in again. You'll obviously need a db column to keep track of which passwords are converted/unconverted, e.g. password_algo.
  • meow 15y ago
    You can bcrypt your current sha1 hashes.
  • holdenk 15y ago
    I've had the "joy" of doing password migrations in the past when moving authentication systems. We made our auth chain support both methods and then when someone logged in with an old method it stored the password in the new method and deleted the old record. This was on a system with only a few hundred users though, so YMMV.
  • Xk 15y ago
    You have two choices that I see: 1. The next time a user logs in to your system and you verify against the SHA-1 hash that they are who they say they are, recompute the correct hash for bcrypt. Then, delete the SHA-1 hash. It does you no good to have a bcrypt version if you keep the SHA-1 version around. 2. Generate the bcrypt hash from the SHA-1 hash. That is, pretend that the SHA-1 hash is the user's password. This isn't as clean (your password authentication software will then have to do SHA-1 followed by bcrypt) but it means you'll be able to migrate your entire database all at once if you so choose. This also causes a very (very, very) slightly higher chance of password collisions, although there's not much to worry about from that.
    • StavrosK 15y ago
      Or you can do both, migrate everything to bcrypted SHA for now and then replace these with straight up bcrypt the next time the user logs in. You ostensibly have a hash method identifier per hash, so just create "sha+bc" and "bc" along with your current "sha". Also, why is the risk of a collision greater? It seems to me that, if anything, it should be lower, as SHA hashes always consist of a fixed number of bits, and thus aren't as likely to collide when hashed to bcrypt, assuming the length of a bcrypt hash is the same (or larger) number than a SHA one. Basically, it seems to me that, if they're going to collide, they're more likely to collide at the SHA level, which is a problem either way.
• oskarkv 15y ago
  I'm just wondering: What if I used SHA-1 a million times on the password, i.e. hashing the hash over and over. Wouldn't that make it much more time-consuming for an attacker? Or am I missing something? The input every time but the first would be a random-looking 160 bit number, so it would be hard to guess. And if the attacker wanna look for common passwords in a dictionary the attacker must hash them a million times, no?
  • rdl 15y ago
    Absolutely. That's essentially PBKDF2 (http://en.wikipedia.org/wiki/PBKDF2 http://en.wikipedia.org/wiki/PBKDF2). You usually add a salt (an additional string which is stored in the clear, but which makes your local instance globally unique, so the attacker can't precompute value to hash mappings ("Rainbow Tables" [which are faster to make if you have alien technology, from what I've heard]) for all sites. I'd still suggest using bcrypt or scrypt.
    • JonnieCache 15y ago
      Bcrypt typically generates and stores the salt with the rest of the hash, all on its own, which reduces the chance for developer error. It's idiot-proof basically.
      • rdl 15y ago
        Of course, the other key thing is to avoid giving attackers offline access to the hash database if possible. Even with scrypt, if you let someone try offline, he will get good results on 100 password attempts per account. Users are often using such weak passwords that being only an online oracle and able to shut down after a number of tries on a password, or at least to do app level rate limiting, is still useful.
  • deleted 15y ago
    [deleted]
• derrickpetzold 15y ago
  Just store in plaintext because I am already assuming you are. All the this talk about sha-1 vs bcrpyt vs scrpyt is nice and all but I have little faith that most companies care about this as much as HN does. I believe that most people are using the default password storage mechanism for their framework which are already known to be easy to break if the database is compromised. But all of that is mute anyways. Unless you have access to the site's source how would you know if they are hashing at all much less which one they are using? The best practice is to use a random password for each site you use. I just don't see any point in having an rememberable password for websites and hashing just leaves a false sense of security as illustrated by md5.
  • Xk 15y ago
    ... what? > Just store in plaintext because I am already assuming you are. No, actually, I don't think I will store plaintext passwords. > All the this talk about sha-1 vs bcrpyt vs scrpyt is nice and all but I have little faith that most companies care about this as much as HN does. So what? Just because other people don't do it doesn't mean you don't have to also. Fortunately for us, there are a lot of startup founders here who might read this and learn something. > I believe that most people are using the default password storage mechanism for their framework which are already known to be easy to break if the database is compromised. I disagree. I think most people use SHA-1 because they know better than to store plaintext passwords. What they don't know is that it's terribly broken. > But all of that is mute anyways. No, it's really not. > Unless you have access to the site's source how would you know if they are hashing at all much less which one they are using? There are two problems here. (1) If you have access to the site's password database, there's a really good chance you have access to the entire database, and can look up how they're doing it. (2) Even if you can't lookup how they're doing it, you just try them all and find which one it is. I'd bet you money that if someone's hashing passwords, they're using one of {MD4, MD5, SHA0, SHA1, SHA2, DES}. If, god forbid, they're not using one of those and actually wrote their own hashing algorithm, you have even more to worry about. > The best practice is to use a random password for each site you use. For sure, no doubt about it. But what we're talking about here is the best practice for application developers, not the users. The users can't do anything about how their password is stored. > I just don't see any point in having an rememberable password for websites and hashing just leaves a false sense of security as illustrated by md5. Or, you know, you could use bcrypt and be secure about it.
• bonaldi 15y ago
  Was far happier when he didn't store passwords at all, tbh.
  • lwat 15y ago
    Are you joking?
    • Stormbringer 15y ago
      He probably isn't. I wrote a login system for an ecommerce and b2b site a while ago. Got heavily into the salting/hashing side of things back then. Based on that... I think that most of the people pop-pooing salts in this thread don't know what they're talking about. This security layer is the only code I've ever written that years later would still cause me to wake up in the middle of the night thinking "oh no! What if an attacker did X, Y and Z??!!" Note: as far as I know, the security I put on it has never been broken. But it still caused nightmares even so.
    • bonaldi 15y ago
      No, not at all. Until a few months ago, Instapaper didn't require users to set a password -- you could (and originally were encouraged to) use it without a password at all. This makes a lot of sense. If more sites storing non-critical data did this we'd have far less password fatigue and people more wary about what they trust to such sites. Just now they see their "password1" as impenetrable security when they might as well have no password at all. Not having a password has a similar psychological effect as showing the password field in plain text, I think.
      • lwat 15y ago
        So how did you authenticate?
• kindly 15y ago
  I currently use a sha hash (with salt) but rehash it x amounts of times. I have changed x over the years to be larger to get an acceptable trade off in computation time. Why is bcrypt much better than this? Is it because the algorithm is less gpu friendly?
  • Xk 15y ago
    What you describe is basically PBKDF1. If you wanted to make it slightly better, you could go with PBKDF2. It's true that bcrypt is better in some ways, but you're fine with what you're doing now. If you really wanted to improve on things you could go with scrypt which eats memory also, but it's more difficult to get things to work right.
• dspace 15y ago
  This is more "crypto nerd imagination", a la the XKCD comic. The FBI doesn't care about the encrypted passwords because it has access to all the content in plaintext. And what else would they need the passwords for? Other accounts on other services? They can just confiscate those servers too, where the content is most likely also in plaintext. So in this case, where the FBI is involve, using a SHA-1 hash poses no extra security vulnerability.
  • spoondan 15y ago
    They can just confiscate those servers too, where the content is most likely also in plaintext. I imagine that many companies are better prepared to deal with the FBI than this data center was. I have a hard time imagining the FBI going into a Google data center and easily walking out with a few racks. But even if that's too optimistic, I doubt the FBI could go about seizing servers for very long. If nothing else, this would eventually piss off big companies who will lobby Congress to curtail the FBI.
  • tankenmate 15y ago
    In this case since the warrant probably didn't allow for the seizure of Instapaper's servers / data you run a serious Fourth Amendment risk of any evidence within being inadmissible. That said even if it is inadmissible the FBI now know things they might not have known before. There is the obvious point that there is very little likelihood of any direct evidence of a crime in Instapaper's data, there maybe indirect or circumstantial evidence though.
  • adrianscott 15y ago
    "So in this case, where the FBI is involve, using a SHA-1 hash poses no extra security vulnerability." meeeh... remember the fbi is not a person, it's an organization. the org can have bad actors in it who might be able to access the encrypted passwords but not be able to confiscate servers. also, confiscating a server(s) is much more visible / detectable...