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

Bcrypt Step-by-Step

qvault.io

Post reply on HN
Print view View original

21–27 of 27 posts

Re: Bcrypt Step-by-Step

#21

Post by cperciva »

cj wrote: post #4
luizfelberti wrote: post #2

Step 1) Use Scrypt instead Step 2) There is no step 2

https://github.com/Tarsnap/scrypt Side note, I've seen a number of places (including the Scrypt repo) compare bcrypt brute-force benchmarks without specifying the bcrypt work factor. It's very frustrating to see this, considering the time to compute a single bcrypt hash can be I'm not familiar with scrypt, but it looks like instead of providing a work factor, you can provide inputs like "max time to compute hash" and…

I've seen a number of places (including the Scrypt repo) compare bcrypt brute-force benchmarks without specifying the bcrypt work factor.

It's specified implicitly in the scrypt README file: "if 5 seconds are spent computing a derived key". It's explicit in the conference paper (cost = 16).

Re: Bcrypt Step-by-Step

#22

Post by luizfelberti »

fractionalhare wrote: post #18
luizfelberti wrote: post #12

Earlier quoted context omitted.

While I agree with the sentiment of what you're saying, I take issue with this part specifically: > For the vast majority of developers, bcrypt, scrypt, argon and PBKDF2 provide functionally equivalent security 1) The "vast majority of developers" should not be implementing login systems, period. The chances most people have of not falling for any OWASP gotcha, making sound security choices, and implementing them cor…

> The "vast majority of developers" should not be implementing login systems, period. Yep, agree. This also supports the idea that you shouldn't get too hung up on which to use, because hopefully that decision was made for you and one of these was selected. > They do not, categorically, provide "functionally equivalent security" Eh, disagree, if your database is breached and your digests are salted, any of these is f…

I originally used categorically to mean "unambiguously explicit and direct", but adding to what you said (with which I mostly agree), Scrypt actually does provide a categorical increment to security by being ASIC-resilient.

There are differences among them between classes of attacks they're susceptible to, provable security properties, and how paranoid should you should be in respect to advances cryptanalysis.

I tend to weigh these as significant factors given that the dynamics of password-based auth can very well lead to a database leak screwing someone over 20 years into the future, although I admit that you can't get too picky nowadays and I'd be very glad if we, as a species, could have what you described as a lower-bound (with the exception of PBKDF2, of course :P)

Re: Bcrypt Step-by-Step

#23

Post by pbsd »

hinkley wrote: post #13
tzs wrote: post #10

> Why not compare passwords directly? Back in the days before hashed or encrypted passwords, there was an interesting security hole in TOPS-10 on the PDP-10 due to direct password comparison. Guess the password "aaaaaaaa", but put it in memory so that a page boundary falls between the first and second "a", and the second page is not resident. TOP-10 allowed a user process to ask to handle its own page faults. Do that…

That page fault issue is mentioned in books about OS design as an example of how some features (like being able to register user space callbacks for page faults) can have unintended consequences.

Indeed; I've always known it as the Tenex bug [1], the Tenex being the system designed by BBN prior to being bought by DEC and renamed to TOPS-20.

[1] http://www.bwlampson.site/33-Hints/Acrobat.pdf

Re: Bcrypt Step-by-Step

#24

Post by gperciva »

cj wrote: post #4
luizfelberti wrote: post #2

Step 1) Use Scrypt instead Step 2) There is no step 2

https://github.com/Tarsnap/scrypt Side note, I've seen a number of places (including the Scrypt repo) compare bcrypt brute-force benchmarks without specifying the bcrypt work factor. It's very frustrating to see this, considering the time to compute a single bcrypt hash can be I'm not familiar with scrypt, but it looks like instead of providing a work factor, you can provide inputs like "max time to compute hash" and…

The algorithm itself takes three cost&memory values N, r, p, and if you're calling the `crypto_scrypt()` function in C or C++ as a KDF you need to specify those.

The command-line binary generally takes "max time" and "max ram" (as percent and/or raw value) and estimates appropriate cost values. As of version 1.3.1, you can manually specify cost values for the binary if you want.

Re: Bcrypt Step-by-Step

#25

Post by captn3m0 »

I was curious about why OrpheanBeholderScryDoubt was chosen, found a unanswered question on security.se[0]. Did some more research, and found out the likely reason:

Most probably just a nod to OpenBSD (look at the initials), since the algorithm was made for it. Here[1] is the original commit that introduced the string.

[0]: https://security.stackexchange.com/a/237690/2876

[1]: https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libc/crypt...

Re: Bcrypt Step-by-Step

#26

Post by tialaramex »

luizfelberti wrote: post #12
fractionalhare wrote: post #6

Earlier quoted context omitted.

For the vast majority of developers, bcrypt, scrypt, argon and PBKDF2 provide functionally equivalent security. It's not generally productive to nitpick between secure password hashing/key derivation functions. Unless you specifically know you can't use one of these in particular, you should just pick whichever one has a safe implementation in a secure cryptographic library that you can use. Basically, just don't use…

While I agree with the sentiment of what you're saying, I take issue with this part specifically: > For the vast majority of developers, bcrypt, scrypt, argon and PBKDF2 provide functionally equivalent security 1) The "vast majority of developers" should not be implementing login systems, period. The chances most people have of not falling for any OWASP gotcha, making sound security choices, and implementing them cor…

No. Your parent was right, it doesn't really matter.

The password hashes buy you an improvement for the narrow range of passwords that are bad but not that bad against adversaries who are powerful but not that powerful. It's pretty much the definition of a marginal win. Which hash you choose slightly tweaks the margin.

It's essentially impossible that this is the lowest hanging fruit for your system security and so "use a different password hash" ought to be nowhere near close enough to the top of the TODO pile to get done if you're already using any of these decent password hashes listed such as PBKDF2.

If your users have strong passwords (e.g. a 20 alphanumeric random password from a typical password manager) it makes no difference at all. Even plain MD5() of such a password is as safe for the user and for you as Scrypt or Argon2 or other choices.

If your users have very weak passwords then once again it makes no difference. Your heavily tuned Scrypt password hashing doesn't prevent me guessing that Steevo412's password on your site might be something obvious like "letmein" - on a lowly mid-range laptop before I get bored.

So all this work is to achieve a marginal improvement in the middle. Maybe if Steevo412 has picked "LetMeInNOW" and maybe the script kiddies who stole the database ran out of stolen Amazon credits, they don't "crack" his password this time. Maybe.

And none of this makes you any safer from inadvertently leaking the plaintext passwords, which your system unavoidably needs to know during authentication, or numerous other pitfalls that have nothing to do with dick-measuring contests about which hash is better.

OR if security actually is important you could deploy something that's actually a clear improvement such as WebAuthn and stop trying to sweep the problems with password storage under increasingly complicated rugs.

Re: Bcrypt Step-by-Step

#27

Post by luizfelberti »

tialaramex wrote: post #26
luizfelberti wrote: post #12

Earlier quoted context omitted.

While I agree with the sentiment of what you're saying, I take issue with this part specifically: > For the vast majority of developers, bcrypt, scrypt, argon and PBKDF2 provide functionally equivalent security 1) The "vast majority of developers" should not be implementing login systems, period. The chances most people have of not falling for any OWASP gotcha, making sound security choices, and implementing them cor…

No. Your parent was right, it doesn't really matter. The password hashes buy you an improvement for the narrow range of passwords that are bad but not that bad against adversaries who are powerful but not that powerful. It's pretty much the definition of a marginal win. Which hash you choose slightly tweaks the margin. It's essentially impossible that this is the lowest hanging fruit for your system security and so "…

> Which hash you choose slightly tweaks the margin

Yes, but only if you assume that an adversary's power is stable over time, and that it's safe to amortize the risk over an extended period of time, both of which are wrong assumptions.

> If your users have strong passwords (e.g. a 20 alphanumeric random password from a typical password manager) it makes no difference at all

Yes, except that is not the world we live in, which makes this a pointless argument.

> If your users have very weak passwords then once again it makes no difference. Scrypt password hashing doesn't prevent me guessing that Steevo412's password might be something obvious

> None of this makes you any safer from inadvertently leaking the plaintext passwords, which your system unavoidably needs to know during authentication

Yes, if you frame the question as "being able to defend against threat models you can't effectively defend against under this authentication model" then indeed none of this matters, but that's a self-propelling argument, and also not the discussion we're having.

The discussion we're having is that given we know password-based auth is a bad security model, and that people have shit security practices, how do we squeeze the most value out of whatever entropy is given to us, in a way that will last as much as possible, since passwords are often recycled, rarely rotated, and you can get pwned decades into the future because of a leak that happened in 2004.

Password-based auth is a reality, and will keep on being for a long time. It's just not a defensible position to argue that there is no point in leveraging given entropy to the max because "we're all doomed anyways", or that since it's a bad model we shouldn't care.

The goal is explicitly to protect knowingly reckless users from themselves. Saying that "if they all used random passwords from a password manager it wouldn't matter" is not realistic or helpful.

> If security actually is important you could deploy something that's actually a clear improvement such as WebAuthn

I don't think anyone at any point in this thread defended passwords as a solid threat model, and I made this same point in another comment. WebAuthn is awesome, but passwords are a reality and will keep on being for a foreseeable future, we just have to deal with it

Post reply on HN