Bcrypt at 25: A retrospective on password security | Hacker News Reader

Bcrypt at 25: A retrospective on password security

blog.apnic.net

32 pointstodsacerdoti16 comments

    As one of the creators of bcrypt back in 1997, I find it somewhat surprising that, 25 years later, we still rely heavily on passwords.

I’m curious to hear from someone who agrees - why would this be surprising? Knowing a password has been a security measure since before computers, and the newer security measures I’ve heard of have terrible support for account recovery.

In 1997, everyone knew we'd be switching to client certs/keys for authentication real soon now.

Using smartcards, for the cool kids.

How do passwords support account recovery?

Passwords are simple to implement and easy for users to adopt

For a long time security wasn't a top priority for many companies if we are frank about this.

Today we have standardized implementations and guidelines, we have many additional options like TOTP or U2F which are pretty robust.

Nowadays if someone wants to implement good user identity/authentication they can.

Webauthn is a dumpster fire to implement compared to passwords or totp.

I specifically didn't mention WebAuth...

U2F(Yubikeys utilize it) and TOTP are both great options.

even push to login is quite common these days.

You have great options.

For chrome u2f was replaced by webauthn. Regardless, both are hard to implement compared to passwords

IMO good algorithms can only get you so far, even if you use modern high resistance hashing if your user uses 'password1234' it will be cracked, as computation power grows we need to use stronger and stronger passwords, this is a losing game especially for the average Joe.

Modern solutions move away from passwords to MFA and/or digital/physical tokens which there we can control the security level with high precision.

Users are the weakest link as the author stated.

Pair it with a solution like zxcvbn and you can stop your users from their worst impulses as far as passwords.

That's called a dictionary attack and it's not a function of computing power.

If you obtain a hash and want to brute force it with a dictionary attack, the amount of time it takes is still a function of computing power since you have to hash the strings & compare. The success rate is of course not

You don't understand how dictionary attacks work.

1) Dictionaries are TINY compared to the number of possible hashes. Something you could reasonably fit on a single hard drive in many cases. Humans really aren't that creative when it comes to choosing passwords.

2) You don't hash every entry in the dictionary on-the-fly. That's stupid. You store the hashes in a large lookup tree and compare hash-to-hash. There's basically no processing power required, especially compared to actual hashing work.

what is your point exactly?

really bizarre response, if you don't have something good to say, don't.

why not combine the two different algorithms?

f.e. scrypt(argos(password)) ? Obviously, there are additional computing costs, but if they are tolerable what are the downsides?

pointless because these modern algorithms support "Adaptable work factor" what it means is that you can control computational work to your likings

you can set the option to compute a billion rounds for each password.

Reply on news.ycombinator.com