Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Storing Passwords Securely

throwingfire.com

Post reply on HN
Print view View original

31–40 of 144 posts

Re: Storing Passwords Securely

#31

Post by pmylund »

indygreg2 wrote: post #26
tptacek wrote: post #24

Earlier quoted context omitted.

Try to explain how you would actually conduct that timing attack to see why it isn't one.

If you are going to go through all the effort to do it properly, you might as well use a proper comparison function. If nothing else, it reinforces the knowledge that string comparisons can be part of security (which goes overlooked by many).

I'm not sure I agree that it would matter, but, either way, using a constant-time equality function might have given readers the impression that my code was safe to use. It isn't. That was never the intention. One of my main points was that it's extremely hard to do properly. My (pseudo-code) examples were intended to explain the concepts of salting and stretching. Perhaps it's unfortunate that they're actually valid Python.

People should use proven KDFs for password authentication, not implement their own (including using my SHA-salting/iteration examples.)

Edit: removed "in web apps"

Re: Storing Passwords Securely

#32

Post by tptacek »

pmylund wrote: post #31
indygreg2 wrote: post #26

Earlier quoted context omitted.

If you are going to go through all the effort to do it properly, you might as well use a proper comparison function. If nothing else, it reinforces the knowledge that string comparisons can be part of security (which goes overlooked by many).

I'm not sure I agree that it would matter, but, either way, using a constant-time equality function might have given readers the impression that my code was safe to use. It isn't. That was never the intention. One of my main points was that it's extremely hard to do properly. My (pseudo-code) examples were intended to explain the concepts of salting and stretching. Perhaps it's unfortunate that they're actually valid…

Many timing attacks are viable in web applications. But there aren't timing attacks against password hash comparisons, for obvious reasons.

Re: Storing Passwords Securely

#33

Post by pmylund »

tptacek wrote: post #32
pmylund wrote: post #31

Earlier quoted context omitted.

I'm not sure I agree that it would matter, but, either way, using a constant-time equality function might have given readers the impression that my code was safe to use. It isn't. That was never the intention. One of my main points was that it's extremely hard to do properly. My (pseudo-code) examples were intended to explain the concepts of salting and stretching. Perhaps it's unfortunate that they're actually valid…

Many timing attacks are viable in web applications. But there aren't timing attacks against password hash comparisons, for obvious reasons.

You're right. That was an unfortunate choice of words.

Re: Storing Passwords Securely

#34

Post by apendleton »

rokhayakebe wrote: post #29

Why does everyone need to be an expert in password generation and storing? Would a password as a service would be feasible or even authentication as a service? (And I do not mean FB or Twitter auth)

Everyone doesn't, and shouldn't. That's why the best practice is not to implement your own hash function, and instead use a third-party library written by an expert.

I'm not sure that password-as-a-service would be worth the overhead involved, but password-as-a-library is functionally equivalent from a developer's perspective and is already the norm. The only question, then, is "which library?" which is what this article attempts to address.

Re: Storing Passwords Securely

#35

Post by indygreg2 »

tptacek wrote: post #27
indygreg2 wrote: post #26

Earlier quoted context omitted.

If you are going to go through all the effort to do it properly, you might as well use a proper comparison function. If nothing else, it reinforces the knowledge that string comparisons can be part of security (which goes overlooked by many).

The == operator is a proper string comparison function in this setting.

Assuming all the steps in the article are followed, yes, you are correct.

I still think any article talking about verifying credentials is obligated to mention that string comparison could be an attack vector.

Like I said, it plants a seed. And, I've seen way too many naive implementations where it is needed (like simple token-based auth systems) to know that this seed needs to be spread a lot more.

Re: Storing Passwords Securely

#36

Post by teyc »

If you happen to have a web app that stores passwords in clear text or SHA-1 hashed, all is not lost. You can apply further secure hashes to the existing value stored on db and update your authentication validator.

Re: Storing Passwords Securely

#37

Post by ticks »

yichi wrote: post #19
sillysaurus wrote: post #7

I know I won't be able to easily convince anyone of this, but I thought I'd mention... Colin Percival's "scrypt" password hash is: 1) production-ready (and has been for a long time) 2) superior to bcrypt, as it is designed to be expensive in both CPU and memory (hence, scrypt is "memory-hard", whereas bcrypt is not) I don't have time to go into further detail. I encourage you to check it out. It's quite simply "the f…

There are no known good implementation of scrypt in php ( http://stackoverflow.com/questions/10149554/are-there-any-ph... ) So I don't know how "production ready" that is considering php is the most popular platform for the web as much as I hate the language.

Even opting for bcrypt can be sketchy. Native support only appeared a few years ago, older versions rely on the OS - many of which didn't support blowfish without a patch. Fine if you control the server.

Re: Storing Passwords Securely

#38

Post by SkyMarshal »

sillysaurus wrote: post #7

I know I won't be able to easily convince anyone of this, but I thought I'd mention... Colin Percival's "scrypt" password hash is: 1) production-ready (and has been for a long time) 2) superior to bcrypt, as it is designed to be expensive in both CPU and memory (hence, scrypt is "memory-hard", whereas bcrypt is not) I don't have time to go into further detail. I encourage you to check it out. It's quite simply "the f…

Fyi, scrypt is in the Debian testing and unstable repos [1], and Ubuntu's universe repo [2]. Not sure about the RPM ecosystem, but I'm sure it's available there too. And there are a bunch of bindings and libs in various languages on github as well [3]. And there is always the source [4].

1. http://packages.debian.org/search?keywords=scrypt

2. http://packages.ubuntu.com/search?keywords=scrypt

3. https://github.com/search?q=scrypt&type=Repositories

4. http://www.tarsnap.com/scrypt.html

Re: Storing Passwords Securely

#39

Post by ticks »

pmylund wrote: post #6
fein wrote: post #3

I liked the article and it was a nice little afternoon read, but the whole thing could have been condensed to "use bcrypt for passwords". I'm not really sure where to stand on this. On one hand, we have PLENTY of security articles stating the same thing (bcrypt, bcrypt, and just in case you've forgotten... bcrypt), which leads to an observed over saturation of the same subject matter. On the other hand, we have a hug…

I agree there are a ton of articles saying "Use bcrypt." After Coda's post ( http://codahale.com/how-to-safely-store-a-password/ ) it's almost become a meme. I don't, however, think that the people who say "Use bcrypt!" tend to explain why they say that. I think the reason that this happens so often is that regular developers just don't care. But that's because they don't know why they should care. Given a proper exp…

Indeed. There's a developer bubble around Hacker News and websites like Stack Overflow, where topics like bcrypt have become second nature. Whereas standard developers, i.e. those that program solely as a job, they don't inhabit these places.

Re: Storing Passwords Securely

#40

Post by cpt1138 »

tptacek wrote: post #20
jontro wrote: post #17

Earlier quoted context omitted.

One issue that I have with scrypt and bcrypt for java is that there is no "official" support for the algorithms in java. When looking at jBCrypt for instance, they're only at version 0.3 with no updates since 2010, makes me really nervous of using it.

How many bugfixes do you think a hash function needs? Just use jBCrypt.

If you try to use the spec'ed 32 rounds the code borks. I fixed it in my own version of jBCrypt.
Post reply on HN