Hacker News Reader

Comment by tptacek | Hacker News Reader

Please don't just use MD5 or SHA1 with a salt.

http://www.matasano.com/log/958/enough-with-the-rainbow-tabl...

I upvoted you because that's a good link and good advice in a sense. I don't agree fully with your exact phrasing and would put it a bit milder for someone asking this kind of question.

I'd personally advise: Use a respected library or at least an MD5 or SHA1 approach with a strong salt. There are better ways that you should consider (link), especially if you're writing an authentication package for reuse by others.

It's painful to see someone recommend "at least" MD5+salt, when that solution is a single for() loop away from being at least adequate. If you're wondering why I'm using such strong words, it's because you talked about "strong salt" (which means nothing), but ignored stretching, which actually does improve security.

SHA1+"strong salt" is extremely weak. It mitigates only one attack, which every respected authentication system has been invulnerable to since the '70s. I blame Microsoft for reviving rainbow table lore, but still, thorax. Come on.

Your article is great advice. As I worded it, I'm providing practical advice to a new web developer. Let me elaborate on my position:

First and foremost, don't write the password handling yourself if you can avoid it. If you do it yourself, I'm only firing the developers who put the password in plain text, and I'm not even going to give grief to the ones who at least use a rainbow-dodging salt and hash (like what most major web frameworks include by default for user auth management). I.e., if they use django defaults or Code Igniter defaults, then they're not in trouble.

Any senior engineers on the team are going to get some whining from me if the framework supports crypt/bcrypt and they didn't enable that, but if they forgot and the site launched without it, I'm not going to die.

It the team is making an authentication package for a web framework or especially for a native framework, they need to consider heavily using bcrypt (or other state-of-the-art approaches) for password handling unless there's some major compelling reason we cannot or should not.

What I'm trying to be is realistic and give the guy a side that's non-religious.

I agree with you as a hacker, but on the practical side, no coding decision is all-or-nothing with me.

If you're a new developer and have read this far and want to know where to find decent bcrypt packages for your favorite language, Google's AWT page has a good explanation and handy links to those (scroll down):

http://code.google.com/p/google-web-toolkit-incubator/wiki/L...

Also here's instructions for using crypt with Django auth:

http://docs.djangoproject.com/en/dev/topics/auth/#changing-p...

Two responses.

First, we don't have pages and pages of comments and discussions because the topic isn't cut-and-dry. The topic is cut-and-dry. It just takes 5-10 round trips to explain to someone why clientside Javascript crypto is a bad idea.

Second, I agree with you. I'm not firing someone for using SHA1+nonce. But I will bitch if you recommend it, because even though it's not a game-over mistake, it's still a mistake.

Rainbow Table is unavoidable. Block those IPs which have more than certain times of failed password. And, people usually cannot access to those hashed passwords.

Three sentences, three fallacies.

(1) Not only are rainbow tables avoidable, but they've been trivially avoidable since Unix crypt(3) was invented in the '70s. The only way you can become susceptable to them is if you make the mistake of designing your own scheme. So don't do that.

(2) There's a reason that no mainstream consumer application actually does this: as soon as you lock a normal user out of their account for an hour, you probably lose the user forever. Ok, there are two reasons: this technique doesn't add any security. Anybody nuts enough to brute-force your login page has as many IPs as they want. But that's not how they do it.

(3) People get to access password hashes as soon as you mess up a single database query. The idea behind storing safe hashes is to prevent your stupid mistakes from screwing over every one of your users. The stupidest people of all are the ones who assume they aren't going to make stupid mistakes.

I think it's more of an issue of what is most pragmatic. Do you know how many hour-long conversations I've had on freenode about the best method to generate hashes? At the end of the day, most people are not targets of the Russian Mafia. And a lot of people are building something that might never get used by more than 50 people, so they don't care. If you're a Department of Defense contractor, I could understand why you would go out of your way.

I think it's fine if you block IPs after they've hit a fail threshold for logins. Or at least freeze the account for a certain period of time (see failed iPhone login attempts).

Think about what you're saying. "Security doesn't matter for these applications because they have almost no users, so we'll do something that will royally piss off the few users we're desperately trying to retain, and which will add no security. What's more, by implementing it ourselves, we'll pay extra to do that."

I agree with you. People talk about this stupid hashing thing far, far too much. Especially because there's already a "right answer". Just use whichever auth plugin is most popular and provides bcrypt.

You're correct that rainbow tables are trivially avoidable, but it shouldn't take a single stupid mistake to expose your database. Password hashing is a last line of defense, not something that should ever be necessary unless something has gone very wrong indeed.

It shouldn't take a single stupid mistake to turn a string copy into a passwordless remote software update mechanism. $3+Bn USD of "shouldn't", down the drain.

Can we talk about the real world, now? The reason Microsoft is driving modern offensive computing researchers nuts isn't that they got rid of the "stupid errors"; it's that they figured out how to make the runtime mitigate those errors with ASLR, NX, safe exceptions, and checked heaps.

In the real world --- and I am speaking from bitter and recent experience with very, very, very smart clients here --- you should assume you are going to make stupid mistakes, and do everything you can reasonably do to keep those mistakes from totally screwing over your customers.

Could you give an example of a stupid mistake that could expose the database? SQL injection attacks are pretty hard to accidentally put into any reasonably well-built system, so I'm curious if you know of any other mechanism through which you could entice a database dump out of a web application.

I guess you could go after the OS or the web server, but I was under the impression you were talking about stupid mistakes from the web developer, not the developers of the OS or web server.

"(2) There's a reason that no mainstream consumer application actually does this: as soon as you lock a normal user out of their account for an hour, you probably lose the user forever."

I don't know, it seems to work pretty well for Microsoft

Security is an never ending war. It is evolving. And, there is always a way to crack whatever you want(it may take time). But, the question is: do you really have to waste so much time on secure something? Or, you can use your time to implement something useful.

You are right. Use whatever auth system which is available.

Reply on news.ycombinator.com