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

Ask HN: Which login method do you use?

news.ycombinator.com

Post reply on HN
Print view View original

31–40 of 58 posts

Re: Ask HN: Which login method do you use?

#31

Post by thorax »

tptacek wrote: post #7
jmtame wrote: post #3

I have always created my own. Although I've been doing PHP, I'm currently using RoR and it has a plugin that handles all of this. PHP with a database is very easy, especially if you use CodeIgniter, there are form validation helper classes. On registration: - Ask for username and password (do form validation, ie passwords match, xss clean, etc). toLowercase() the login. - Create a hash of some type for the password.…

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.

Re: Ask HN: Which login method do you use?

#32

Post by jmtame »

tptacek wrote: post #15
siong1987 wrote: post #14

Earlier quoted context omitted.

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 f…

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).

Re: Ask HN: Which login method do you use?

#33

Post by tptacek »

thorax wrote: post #31
tptacek wrote: post #7

Earlier quoted context omitted.

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.

Re: Ask HN: Which login method do you use?

#34

Post by weavejester »

tptacek wrote: post #15
siong1987 wrote: post #14

Earlier quoted context omitted.

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 f…

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.

Re: Ask HN: Which login method do you use?

#36

Post by tptacek »

jmtame wrote: post #32
tptacek wrote: post #15

Earlier quoted context omitted.

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 f…

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…

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.

Re: Ask HN: Which login method do you use?

#37

Post by tptacek »

weavejester wrote: post #34
tptacek wrote: post #15

Earlier quoted context omitted.

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 f…

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.

Re: Ask HN: Which login method do you use?

#39

Post by lsc »

tptacek wrote: post #29
lsc wrote: post #27

Earlier quoted context omitted.

do you think a hashed password is going to last long against an attacker? considering how cheap computing resources are (and the common use of botnets, and the fact that most passwords are dictionary words) I treat password hashes as if they were cleartext passwords. But I suppose that if you are using https, you get most of the advantages of digest anyhow.

If the password is hashed well, with stretched SHA1/SHA256 or (better yet) bcrypt, then yes: breaking the hash would involve a significant advance in cryptography.

hm? I'm trying to say that once you have the hash, you can run a dictionary attack against it without any advances in anything. I can use whatever procedure the server uses to verify logins, and just try passwords. You can make the dictionary attack more expensive by using an expensive hash like bcrypt, but that's going to slow down your app, too. (http auth re-authenticates every page load.) so really, you can't make your hash calculation any slower than, say, 50ms without users complaining.

Lets say you can crack the average user account with 40,000 hits from a dictionary attack (I imagine most passwords fall much faster) if each lookup takes 50ms, 20 lookups a second, it'll take around 30 minutes of cpu time to crack each password. assuming a reasonable-sized botnet, that's not much.

Post reply on HN