7 ms·

It would allow you to bruteforce the passwords without any sort of rate limiting. So, if you used a dictionary, you probably could get quite a few weak password

It would allow you to bruteforce the passwords without any sort of rate limiting. So, if you used a dictionary, you probably could get quite a few weak passwords in a short amount of time relative to a system that had proper rate limiting to prevent these kinds of attacks.

Olscore 10y ago
Ah derp. Totally forgot about rate limiting. Thank you.
- sintaxi 10y ago
  I thought bcrypt was a deliberately slow algorithm so it cant necessarily be brute forced.
  - WA 10y ago
    But still much faster than an HTTP request to an Auth API that allows only, say, 5 requests per minute.
  - Olscore 10y ago
    Right, but you would still bypass the rate limiting of the server whether that be login attempts, http requests per second, firewall rules, latency or whatever when checking.
    - dogma1138 10y ago
      That's another rate limiting that has nothing to do with the hash strength. Good password hashing functions have internal rate limits that reduce the likelihood of anyone being able to break the hashes easily because they will be expensive even when fully implemented in hardware. For how long are they resilient it's another question but bcrypt is pretty good, it's quite slow, and is expensive to implement in ASIC/FPGA.
      - sintaxi 10y ago
        This is what I was thinking about. Thanks.
imdsm 10y ago
You'd still need the salt though, right?
- 15155 10y ago
  Bcrypt salts are ordinarily colocated with the hashes and the number of rounds used to compute them.
- valleyer 10y ago
  The salt is typically stored with the hashed value. Its purpose is simply to prevent you from being able to use a single dictionary attack on all users.
- andruby 10y ago
  The salt is usually stored with the hash. It prevents using pre-calculated rainbow tables. Without a salt you can check a password guess against all passwords. With a salt you can only test the guess against a single password.
cm2187 10y ago
Depends what you mean by short amount of time. Depending on the strength selected with bcrypt, it can easily take a second to check a hash. On a 30m password database, this will take a year on one machine to check just who is using "monkey" as a password.
- fit2rule 10y ago
  > it can easily take a second to check a hash On what hardware?
  - cm2187 10y ago
    An i7 laptop. But even if you use an 18 cores server, it doesn't really change the point. It might take a month instead of a year. But it still doesn't scale, even to only check the most common passwords.
    - iagooar 10y ago
      How can you say it doesn't scale? You just need to spin up a cluster that is powerful enough to get down to let's say a week. The cost of this would be a joke for a company / institution of a certain size.
      - cmdrfred 10y ago
        1 week only tests 1 password. It would have to run for years to get a decent set of results. I don't see how a company can afford all that hardware and power to do something that is illegal to begin with. How do they monetize it to get a return?
        iagooar 10y ago
        You just need to target certain accounts, no need for all.
        iagooar 10y ago
        And don't forget, that every 18 months, the amount of processing power you get for a modest price, doubles.
xerophyte12932 10y ago
wouldn't the slowness of bcrpyt be a hindrance enough? Of course rate limiting is a much greater barrier, but I thought the whole point of using bcrypt is that its naturally slow and prevents checking several passwords in a short time
- TACIXAT 10y ago
  You can set the work factor (log rounds). Bcrypt is also cool because it doesn't scale well to GPUs, so it's still pretty slow even if you have decent hardware. The rounds are a trade off between how long your users will wait to login and how strong the hashes will be. The current recommendation is between 8 and 12 depending where you look. The best practice is to just check on the system you are running, I usually aim for the number of rounds nearest a half a second.

Olscore 10y ago

Ah derp. Totally forgot about rate limiting. Thank you.

sintaxi 10y ago
I thought bcrypt was a deliberately slow algorithm so it cant necessarily be brute forced.
- WA 10y ago
  But still much faster than an HTTP request to an Auth API that allows only, say, 5 requests per minute.
- Olscore 10y ago
  Right, but you would still bypass the rate limiting of the server whether that be login attempts, http requests per second, firewall rules, latency or whatever when checking.
  - dogma1138 10y ago
    That's another rate limiting that has nothing to do with the hash strength. Good password hashing functions have internal rate limits that reduce the likelihood of anyone being able to break the hashes easily because they will be expensive even when fully implemented in hardware. For how long are they resilient it's another question but bcrypt is pretty good, it's quite slow, and is expensive to implement in ASIC/FPGA.
    - sintaxi 10y ago
      This is what I was thinking about. Thanks.

imdsm 10y ago

You'd still need the salt though, right?

15155 10y ago
Bcrypt salts are ordinarily colocated with the hashes and the number of rounds used to compute them.
valleyer 10y ago
The salt is typically stored with the hashed value. Its purpose is simply to prevent you from being able to use a single dictionary attack on all users.
andruby 10y ago
The salt is usually stored with the hash. It prevents using pre-calculated rainbow tables. Without a salt you can check a password guess against all passwords. With a salt you can only test the guess against a single password.

cm2187 10y ago

Depends what you mean by short amount of time. Depending on the strength selected with bcrypt, it can easily take a second to check a hash. On a 30m password database, this will take a year on one machine to check just who is using "monkey" as a password.

fit2rule 10y ago
> it can easily take a second to check a hash On what hardware?
- cm2187 10y ago
  An i7 laptop. But even if you use an 18 cores server, it doesn't really change the point. It might take a month instead of a year. But it still doesn't scale, even to only check the most common passwords.
  - iagooar 10y ago
    How can you say it doesn't scale? You just need to spin up a cluster that is powerful enough to get down to let's say a week. The cost of this would be a joke for a company / institution of a certain size.
    - cmdrfred 10y ago
      1 week only tests 1 password. It would have to run for years to get a decent set of results. I don't see how a company can afford all that hardware and power to do something that is illegal to begin with. How do they monetize it to get a return?
      - iagooar 10y ago
        You just need to target certain accounts, no need for all.
      - iagooar 10y ago
        And don't forget, that every 18 months, the amount of processing power you get for a modest price, doubles.

xerophyte12932 10y ago

wouldn't the slowness of bcrpyt be a hindrance enough? Of course rate limiting is a much greater barrier, but I thought the whole point of using bcrypt is that its naturally slow and prevents checking several passwords in a short time

TACIXAT 10y ago
You can set the work factor (log rounds). Bcrypt is also cool because it doesn't scale well to GPUs, so it's still pretty slow even if you have decent hardware. The rounds are a trade off between how long your users will wait to login and how strong the hashes will be. The current recommendation is between 8 and 12 depending where you look. The best practice is to just check on the system you are running, I usually aim for the number of rounds nearest a half a second.