4 ms·

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 mo

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.
- derrickpetzold 15y ago
  > 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. Yes I hope there are. > 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. SHA-1 is the default on django and its easy to break that my entire point. It leaves a false sense of security. > 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. They might as well be using ROT-13 if they are using any of those. Now with todays GPUs and rainbow tables the passwords might as well be in plaintext. The real solution is site security not password security. > Or, you know, you could use bcrypt and be secure about it. For how long? 4-5 years? Who will be maintaining your site then?
  - Xk 15y ago
    > The real solution is site security not password security. That does not imply you don't worry about it though -- it's defense in depth. In the same way sometimes you'll need to go through two sets of doors locked with different keys to access a secured server room (or anything else, for that matter), it's worthwhile to protect everything you can as best you can. > They might as well be using ROT-13 if they are using any of those. Now with todays GPUs and rainbow tables the passwords might as well be in plaintext. The real solution is site security not password security. Exactly my point. That's why you use bcrypt. > For how long? 4-5 years? Who will be maintaining your site then? First, the premise of that question is that bcrypt is going to be secure for only 4-5 years, which is entirely wrong. You can modify the work factor on bcrypt as time goes by. I could, for example, make it take twice as long to generate a hash every year. I could have the program do this automatically. As for you actual question, which isn't terribly relevant, either (1) me or (2) the next guy, who I hope will have knowledge about security as well, but if he doesn't, then I just have to hope he'd keep the workfactor increases in the code.

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.

derrickpetzold 15y ago
> 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. Yes I hope there are. > 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. SHA-1 is the default on django and its easy to break that my entire point. It leaves a false sense of security. > 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. They might as well be using ROT-13 if they are using any of those. Now with todays GPUs and rainbow tables the passwords might as well be in plaintext. The real solution is site security not password security. > Or, you know, you could use bcrypt and be secure about it. For how long? 4-5 years? Who will be maintaining your site then?
- Xk 15y ago
  > The real solution is site security not password security. That does not imply you don't worry about it though -- it's defense in depth. In the same way sometimes you'll need to go through two sets of doors locked with different keys to access a secured server room (or anything else, for that matter), it's worthwhile to protect everything you can as best you can. > They might as well be using ROT-13 if they are using any of those. Now with todays GPUs and rainbow tables the passwords might as well be in plaintext. The real solution is site security not password security. Exactly my point. That's why you use bcrypt. > For how long? 4-5 years? Who will be maintaining your site then? First, the premise of that question is that bcrypt is going to be secure for only 4-5 years, which is entirely wrong. You can modify the work factor on bcrypt as time goes by. I could, for example, make it take twice as long to generate a hash every year. I could have the program do this automatically. As for you actual question, which isn't terribly relevant, either (1) me or (2) the next guy, who I hope will have knowledge about security as well, but if he doesn't, then I just have to hope he'd keep the workfactor increases in the code.