4 ms·

You're massively overestimating the strength of bcrypt here. olcHashcat on a single modern GPU will do several thousand hashes per second, depending on work fa

You're massively overestimating the strength of bcrypt here. olcHashcat on a single modern GPU will do several thousand hashes per second, depending on work factor and GPU speed.

facepalm 10y ago
Then why even bother with bcrypt?
- jfindley 10y ago
  Because something with a cryptographic hash, like sha256, you can do millions (or in some cases billions) of hashes per second on the same GPU. Password hashes, like bcrypt, PBKDF2 and scrypt, are massively slower. That doesn't mean they're uncrackable, it just means they are expensive to crack, so a strong password in a well implemented password hash will take a long time (and cost a lot of money) to crack, by which time the user has hopefully noticed and had time to change their password.
  - _asummers 10y ago
    Additionally, there's a new player in town called Argon2 that attempts to solve the problems with bcrypt and scrypt. It's the most recent winner of the password hashing competition. https://github.com/P-H-C/phc-winner-argon2 https://github.com/P-H-C/phc-winner-argon2
    - kerkeslager 10y ago
      What problems with bcrypt/scrypt does argon2 solve?
      - jfindley 10y ago
        bcrypt is limited to 72 characters (admittedly this is not that big a practical limitation), and scrypt is an excellent KDF, but wasn't designed as a password hash, and thus doesn't have great GPU defence. In practice, they're still both great, but that doesn't mean we should stop trying to do even better. Argon2 looks really interesting, but it is still relatively new.
        huxley 10y ago
        If someone isn't ready to go with Argon2 and truncating past 72 characters is an issue, Django (and possibly other implementations that I'm not aware of) overcome that by first hashing the password with SHA256 before passing it to bcrypt.
        baby 10y ago
        > scrypt is an excellent KDF, but wasn't designed as a password hash, and thus doesn't have great GPU defence Last time I heard of scrypt, it was being used in Litecoin, a fork of bitcoin, because it was preventing GPU based crackers.
        Forbo 10y ago
        I don't know if it has anything to do with GPUs, I had thought it was due to memory, as referenced on the wiki page for Litecoin: "Litecoin uses scrypt in its proof-of-work algorithm, a sequential memory-hard function requiring asymptotically more memory than an algorithm which is not memory-hard."
      - Someone1234 10y ago
        It rate limits via IO (specifically memory IO) rather than processing power (CPU/GPU).
        kerkeslager 10y ago
        Ah, that's interesting enough to be worth looking into.
  - lurkinggrue 10y ago
    Yes if your password looks like: z1c4KzC*ITtt4Ka%vVDeei!aFSuEOTiDFCJ2NXc8Z7Jz then we are looking at enough time for you as a user to not care.
- sdlion 10y ago
  When you have a massive leak, it's better to have under 10 angry users about that they have been hacked (increasing at a slow pace) than most of your userbase raging at you and leaving your service.
lkbm 10y ago
> depending on work factor Right, but therein lies the strength of bcrypt. You can set it so it will be several thousand per second, or several seconds per thousand. This comment seems a little like saying "I can run faster than a car, depending on how hard you press the accellertor."
- jfindley 10y ago
  The work factor also increases the work the server has to do to handle users logging on, which is a big cost both in UX and hosting fees. In practice, reasonable work factors for bcrypt are between 10 and 12. What application could tolerate a full second of delay (and 100% usage of a server core) just to hash the users password? Also, a few thousand hashes per second (and that's on a GPU, and bcrypt is decidedly GPU unfriendly due to memory allocation patterns) won't allow you to do much more than a dictionary / rule + dictionary attack, so in the short term you're only going to get weak passwords.
  - cm2187 10y ago
    I don't think anyone has any expectation that a login should be as fast as any other page load. Same thing for authorising a payment. I don't think a 1 sec delay when authenticating is unreasonable. To me the risk with using bcrypt is DOS. If you have a high work factor, all an attacker has to do is to run a lot of logon (no need to be successful, they just need to relate to real users) to sink your servers.
    - giovannibajo1 10y ago
      No matter what you do, you always need to have a rate limiter / DOS mitigation for your login APIs / pages.
  - seanwilson 10y ago
    > The work factor also increases the work the server has to do to handle users logging on, which is a big cost both in UX and hosting fees. In practice, reasonable work factors for bcrypt are between 10 and 12. What application could tolerate a full second of delay (and 100% usage of a server core) just to hash the users password? Is there a way client side processing power could be leveraged to help calculate the final hash value so that the computational cost could be practically increased? I'm aware that having the client calculate and send the final hash value by themselves is a bad idea though.

You're massively overestimating the strength of bcrypt here. olcHashcat on a single modern GPU will do several thousand hashes per second, depending on work factor and GPU speed.

facepalm 10y ago

Then why even bother with bcrypt?

jfindley 10y ago
Because something with a cryptographic hash, like sha256, you can do millions (or in some cases billions) of hashes per second on the same GPU. Password hashes, like bcrypt, PBKDF2 and scrypt, are massively slower. That doesn't mean they're uncrackable, it just means they are expensive to crack, so a strong password in a well implemented password hash will take a long time (and cost a lot of money) to crack, by which time the user has hopefully noticed and had time to change their password.
- _asummers 10y ago
  Additionally, there's a new player in town called Argon2 that attempts to solve the problems with bcrypt and scrypt. It's the most recent winner of the password hashing competition. https://github.com/P-H-C/phc-winner-argon2 https://github.com/P-H-C/phc-winner-argon2
  - kerkeslager 10y ago
    What problems with bcrypt/scrypt does argon2 solve?
    - jfindley 10y ago
      bcrypt is limited to 72 characters (admittedly this is not that big a practical limitation), and scrypt is an excellent KDF, but wasn't designed as a password hash, and thus doesn't have great GPU defence. In practice, they're still both great, but that doesn't mean we should stop trying to do even better. Argon2 looks really interesting, but it is still relatively new.
      - huxley 10y ago
        If someone isn't ready to go with Argon2 and truncating past 72 characters is an issue, Django (and possibly other implementations that I'm not aware of) overcome that by first hashing the password with SHA256 before passing it to bcrypt.
      - baby 10y ago
        > scrypt is an excellent KDF, but wasn't designed as a password hash, and thus doesn't have great GPU defence Last time I heard of scrypt, it was being used in Litecoin, a fork of bitcoin, because it was preventing GPU based crackers.
        Forbo 10y ago
        I don't know if it has anything to do with GPUs, I had thought it was due to memory, as referenced on the wiki page for Litecoin: "Litecoin uses scrypt in its proof-of-work algorithm, a sequential memory-hard function requiring asymptotically more memory than an algorithm which is not memory-hard."
    - Someone1234 10y ago
      It rate limits via IO (specifically memory IO) rather than processing power (CPU/GPU).
      - kerkeslager 10y ago
        Ah, that's interesting enough to be worth looking into.
- lurkinggrue 10y ago
  Yes if your password looks like: z1c4KzC*ITtt4Ka%vVDeei!aFSuEOTiDFCJ2NXc8Z7Jz then we are looking at enough time for you as a user to not care.
sdlion 10y ago
When you have a massive leak, it's better to have under 10 angry users about that they have been hacked (increasing at a slow pace) than most of your userbase raging at you and leaving your service.

lkbm 10y ago

> depending on work factor Right, but therein lies the strength of bcrypt. You can set it so it will be several thousand per second, or several seconds per thousand. This comment seems a little like saying "I can run faster than a car, depending on how hard you press the accellertor."

jfindley 10y ago
The work factor also increases the work the server has to do to handle users logging on, which is a big cost both in UX and hosting fees. In practice, reasonable work factors for bcrypt are between 10 and 12. What application could tolerate a full second of delay (and 100% usage of a server core) just to hash the users password? Also, a few thousand hashes per second (and that's on a GPU, and bcrypt is decidedly GPU unfriendly due to memory allocation patterns) won't allow you to do much more than a dictionary / rule + dictionary attack, so in the short term you're only going to get weak passwords.
- cm2187 10y ago
  I don't think anyone has any expectation that a login should be as fast as any other page load. Same thing for authorising a payment. I don't think a 1 sec delay when authenticating is unreasonable. To me the risk with using bcrypt is DOS. If you have a high work factor, all an attacker has to do is to run a lot of logon (no need to be successful, they just need to relate to real users) to sink your servers.
  - giovannibajo1 10y ago
    No matter what you do, you always need to have a rate limiter / DOS mitigation for your login APIs / pages.
- seanwilson 10y ago
  > The work factor also increases the work the server has to do to handle users logging on, which is a big cost both in UX and hosting fees. In practice, reasonable work factors for bcrypt are between 10 and 12. What application could tolerate a full second of delay (and 100% usage of a server core) just to hash the users password? Is there a way client side processing power could be leveraged to help calculate the final hash value so that the computational cost could be practically increased? I'm aware that having the client calculate and send the final hash value by themselves is a bad idea though.