6 ms·

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-wo

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.

ominous_prime 16y ago
> 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.
- pavel_lishin 16y ago
  Did he imply that they were unsalted?
  - ominous_prime 16y ago
    No, he did not :\. I was reading into it too much, and inferred he was wandering towards the rainbow-tables fallacy.
andylei 16y ago
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.
- ianferrel 16y ago
  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.
  - glenjamin 16y ago
    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!)
    - gusper 16y ago
      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?
      - mcao 16y ago
        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.
phamilton 16y ago
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.
- asharp 16y ago
  Not particularly. An attack that leaves the attacker with password hashes is rare, as opposed to regular "brute force" attacks of various flavours.
  - queensnake 16y ago
    (Couldn't a hacker have 500 connections and, though trying each only every 5 secs as permitted, still get 100/s overall?)
    - asharp 16y ago
      Only in the case of a very badly configured server.
- jtheory 16y ago
  Login delays have serious problems anyway. 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.
asharp 16y ago
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.
- jarin 16y ago
  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.
  - Locke1689 16y ago
    Everyone should just use bcrypt, period. (Or scrypt if you follow and trust cperciva)
  - asharp 16y ago
    It was my understanding, having read the scrypt paper, that scrypt is significantly more secure then bcrypt (hence its existence).
- notJim 16y ago
  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.

ominous_prime 16y ago

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

pavel_lishin 16y ago
Did he imply that they were unsalted?
- ominous_prime 16y ago
  No, he did not :\. I was reading into it too much, and inferred he was wandering towards the rainbow-tables fallacy.

andylei 16y ago

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.

ianferrel 16y ago
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.
- glenjamin 16y ago
  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!)
  - gusper 16y ago
    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?
    - mcao 16y ago
      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.

phamilton 16y ago

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.

asharp 16y ago
Not particularly. An attack that leaves the attacker with password hashes is rare, as opposed to regular "brute force" attacks of various flavours.
- queensnake 16y ago
  (Couldn't a hacker have 500 connections and, though trying each only every 5 secs as permitted, still get 100/s overall?)
  - asharp 16y ago
    Only in the case of a very badly configured server.
jtheory 16y ago
Login delays have serious problems anyway. 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.

asharp 16y ago

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.

jarin 16y ago
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.
- Locke1689 16y ago
  Everyone should just use bcrypt, period. (Or scrypt if you follow and trust cperciva)
- asharp 16y ago
  It was my understanding, having read the scrypt paper, that scrypt is significantly more secure then bcrypt (hence its existence).
notJim 16y ago
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.