Hacker News Reader

Comment by ianferrel | Hacker News Reader

The author relies on the assumption that one can try 100 passwords per second (or, fewer, in the case of an extra delay), but that doesn't correspond to real-world security breaches.

The danger of having an insecure password is not that someone will bombard the server with login requests. That can easily be detected and stopped by even the most cursory of server security. The danger is that they crack the server and get the list of password hashes, at which point the time to crack a password is dictated by the hardware at their disposal and the hashing algorithm. Your server capacity or timeout protocols are irrelevant.

So, the 100 attempts/sec number is essentially a fiction. It applies only to a manufactured threat. The real threat is much worse, which means that a password like "this is fun" is not reasonably secure.

View on HN

To be more specific they are dictated by the hashing algorithm and how it is set up.

Say you have something like a straight md5/sha256/etc. It's fairly likely that there exist rainbow tables that will insta(for some reasonable value of insta) crack any reasonable password.

On the other hand, if you use a salted hash you arn't vulnerable to rainbow tables, but an attacker can still try an altogether silly number of passwords per second given enough hardware. (or again, more specifically GPUS against most common salted hashes).

On the other other hand, if you use a memory hard key derivation function (scrypt/etc.), you can quite easily set things up such that even with a ridiculous amount of hardware it is infeasible to launch any sort of attack. The problem then, is that the harder you make it for attackers to attack your passwords, the slower normal logins are for you, affecting scaling.

So at the end of the day you need to weight off how much of a problem this is in the specific circumstances you are in which will then dictate the solution you can provide.

Bcrypt is a good hashing algorithm to use, as you can tailor the difficulty level to find a good balance. A 100ms hashing time probably won't make much of a difference as far as scaling goes (unless your users are actually doing the login process multiple times per day), but it makes a huge difference in how long it takes to brute force.

Everyone should just use bcrypt, period. (Or scrypt if you follow and trust cperciva)

It was my understanding, having read the scrypt paper, that scrypt is significantly more secure then bcrypt (hence its existence).

What about using a unique salt for each user. For example, if you use the user's login name. Then, the hacker would have to make a rainbow table for each user, in essence.

I think bcrypt is probably still more secure? Or maybe the best would be to combine both.

Bcrypt would be more secure.

The problem is that by using a unique salt per user, you can't simply create one salted hash and use it on every user hash simultaneously, however you can still check one password each hash you generate. Bcrypt/scrypt are more secure as it requires much more effort to check each password.

Right; see "Salt will not help you" here: http://codahale.com/how-to-safely-store-a-password/

The standard hash algorithms are designed to be fast executing. They're built for determining uniqueness quickly, not for securing passwords.

Are you saying there are salting systems that don't use a unique salt for each user?

Yeah - normally crappy hand rolled PHP ones.

i think the point is that increased password length can make easy to remember passwords that are more secure than shorter, hard to remember passwords.

even though "this is fun" isn't secure in your scenario, its still more secure than the "j63<2a" password in the same scenario.

That's true, but the construction of the argument gives a false sense of security. "j63<2a" is more secure than "password" as well, but since they are both effectively useless (as is "this is fun"), we probably shouldn't waste time comparing their relative terribleness.

The proper solution to passwords isn't to come up with a slightly longer phrase that can still be cracked in a reasonable amount of time, it's to use a 30-character randomly generated password for each login, and keep them in a privately encrypted password safe of some sort.

Except that's a usability nightmare, and the majority of password field (annoyingly) won't accept a 30 char password.

I aim to use a short phrase that includes punctuation and a number if required, and to have the sentence be thematically linked slightly to the system I'm logging in to. This produces a long string that meets the criteria and is memorable by following the original train of thought from that led me to form the sentence. This I believe is "good enough" in all scenarios, since I should be able to type it quickly, and never write it down or share it.

The only remaining issues are max-length password fields and keyloggers (apparently a parabolic microphone can be used as a keylogger!)

You run the risk of making it a lot easier to figure out your password for other sites once one of them is known though, right?

Say you create an account at fakecompany.com where they happily and naively save their passwords in plain text in their database. Wouldn't it be easy for that site admin to then figure out your facebook.com, for example, password?

I do this too. You just have to make sure your passwords have sufficient complexity, yet have an algorithm that is easy for you to remember. Just start off a base, let's say oUb$r8!A. Now let's use a simple algorithm of taking the first letter and last letter and injecting it somewhere into the base. So your new password for amazon.com is oUAb$r8!nA. For facebook.com it's oUFb$r8!kA. To the casual observer it looks just like any other password and it beats using the same password over and over again. You can of course make it even more obscure by changing the algorithm, just as long as it's easy to hash out in your head.

Yep, that makes sense. Thanks for clarifying.

> The danger is that they crack the server and get the list of password hashes

This isn't an argument either way. The service poorly handling passwords is even more culpable than the user with poor password complexity. Passwords should never be stored as plain hashes.

Did he imply that they were unsalted?

No, he did not :\. I was reading into it too much, and inferred he was wandering towards the rainbow-tables fallacy.

Your argument does essentially shoot down any merit to 5 second login attempt delays, and a cap on the number of attempts in 15 minutes.

Not particularly. An attack that leaves the attacker with password hashes is rare, as opposed to regular "brute force" attacks of various flavours.

(Couldn't a hacker have 500 connections and, though trying each only every 5 secs as permitted, still get 100/s overall?)

Only in the case of a very badly configured server.

If you include a serious delay (like, "10 attempts to guess a user's password and we lock the account for an hour" or if you lock accounts & require admin unlocking), this is a great way to set yourself up for a quiet DoS. I don't have to bring your server to its knees -- I can lock our any user with only 10 requests, ha ha...

If you save the limit in the browser session, well, it's easy to start a new session for each attempt (just don't send in any established cookie). Limiting per IP is a bit stronger, but with large NATs this is still as risk of DoSing.

If you use just a small timeout -- like 5 seconds -- that means any individual attempt will take 5 seconds to return. Let's say I submit 100 requests in 100 threads. Will it take 500 seconds to return? Nope -- each thread will take 5 seconds, concurrently, and I'll have the results back in request tine + 5 seconds.

Also don't forget that an attacker is not required to choose a single email address and try to brute-force passwords. In fact, it's probably more efficient to take one common password at a time and try likely usernames.

Huh -- yet another wrinkle. If you track by IP address, you may have serious problems in the UK, where many ISPs are filtering all of their users through a few proxy servers (so it will then appear as if all users routed through a given proxy server are all on the same IP...).

http://grimboy.co.uk/blawg/in-the-uk-being-told-youre-alread...

Reply on news.ycombinator.com