A Popular Password Hashing Algorithm Starts Its Long Goodbye (wired.com) 17
An anonymous reader quotes a report from Wired: Bcrypt turns 25 this year, and Niels Provos, one of its coinventors, says that looking back, the algorithm has always had good energy, thanks to its open source availability and the technical characteristics that have fueled its longevity. Provos spoke to WIRED about a retrospective on the algorithm that he published this week in Usenix ;login:. Like so many digital workhorses, though, there are now more robust and secure alternatives to bcrypt, including the hashing algorithms known as scrypt and Argon2. Provos himself says that the quarter-century milestone is plenty for bcrypt and that he hopes it will lose popularity before celebrating another major birthday.
A version of bcrypt first shipped with the open source operating system OpenBSD 2.1 in June 1997. At the time, the United States still imposed stringent export limits on cryptography. But Provos, who grew up in Germany, worked on its development while he was still living and studying there. "One thing I found so surprising was how popular it became," he says. "I think in part it's probably because it was actually solving a problem that was real, but also because it was open source and not encumbered by any export restrictions. And then everybody ended up doing their own implementations in all these other languages. So these days, if you are faced with wanting to do password hashing, bcrypt is going to be available in every language that you could possibly operate in. But the other thing that I find interesting is that it's even still relevant 25 years later. That is just crazy."
Provos developed bcrypt with David Mazieres, a systems security professor at Stanford University who was studying at the Massachusetts Institute of Technology when he and Provos collaborated on bcrypt. The two met through the open source community and were working on OpenBSD. [...] Password security is always lagging, though, and both Provos and Mazieres expressed disbelief and disappointment that the state of passwords broadly has not evolved in decades. Even new schemes like passkeys are only just beginning to emerge. "Bcrypt should have been superseded already," Provos says. "It's surprising how much reliance we still have on passwords. If you had asked me 25 years ago, I would not have guessed that."
A version of bcrypt first shipped with the open source operating system OpenBSD 2.1 in June 1997. At the time, the United States still imposed stringent export limits on cryptography. But Provos, who grew up in Germany, worked on its development while he was still living and studying there. "One thing I found so surprising was how popular it became," he says. "I think in part it's probably because it was actually solving a problem that was real, but also because it was open source and not encumbered by any export restrictions. And then everybody ended up doing their own implementations in all these other languages. So these days, if you are faced with wanting to do password hashing, bcrypt is going to be available in every language that you could possibly operate in. But the other thing that I find interesting is that it's even still relevant 25 years later. That is just crazy."
Provos developed bcrypt with David Mazieres, a systems security professor at Stanford University who was studying at the Massachusetts Institute of Technology when he and Provos collaborated on bcrypt. The two met through the open source community and were working on OpenBSD. [...] Password security is always lagging, though, and both Provos and Mazieres expressed disbelief and disappointment that the state of passwords broadly has not evolved in decades. Even new schemes like passkeys are only just beginning to emerge. "Bcrypt should have been superseded already," Provos says. "It's surprising how much reliance we still have on passwords. If you had asked me 25 years ago, I would not have guessed that."
Has been obsolete for quite a while (Score:4, Informative)
At the very least since Argon 2 got standardized, so for about 10 years now. In particular, Bcrypt does not have a large-memory-property and that makes it unsuitable for modern use. It also makes the security comparison on its wikipedia page invalid because that one does not take memory into account at all. (Who wrote that crap?)
But it did do well for a surprisingly long time. Incidentally, do not use scrypt either. Anybody not using Argon 2 today is doing it wrong.
Re: (Score:2)
Clarification: The wikipedia page does not take memory into account for the Bcrypt to Argon 2 comparison.
Re: (Score:2)
But it did do well for a surprisingly long time. Incidentally, do not use scrypt either. Anybody not using Argon 2 today is doing it wrong.
Every couple of years a new ZOMG you are using the wrong algorithm realization surfaces. The old one is "broken", has too few bits and wasn't salted enough. All means very little when the fact limiting factor is never algorithm related but insufficient entropy of passwords themselves rendering them fundamentally incapable of surviving offline challenges.
Then came the never ending your key stretch is not stretchy enough as if multiplication factors have any substantive meaning vs. the exponents that descri
Re: (Score:1)
Evolving (Score:2)
Password security is always lagging, though, and both Provos and Mazieres expressed disbelief and disappointment that the state of passwords broadly has not evolved in decades.
People are comfortable doing what they're doing, it doesn't matter if something better comes along, people are afraid of change and will continue doing things the old way until they're forced to change.
Re: (Score:2)
In all honesty, if you update all your practices and libs as soon as one gets a better alternative out there, you will spend 100% of your time doing it and none to actually produce features that have business value. There is a fine balance to find here and it takes time and expertise to get it right for the context you're in.
Re: (Score:2)
It is actually pretty simple: Does it still adequately fulfill its purpose?
Yes -> No not change it. That would be wasted money. One exception: If it is part of a longer upgrade path, it can be a good idea to start when the old still works.
No -> You you need to replace it. No excuses.
Note that "we do not know" falls under "no".
The problem is that to make this decision, you need highly competent and experienced people. Actually making the decision is not a lot of effort in most cases, but unless you kno
Re: (Score:2)
It is actually pretty simple: Does it still adequately fulfill its purpose?
The answer to this question is *not* a boolean, but a value. How much effort does it takes to change it is another variable.
All in all, security is risk management. It doesn't unfold the same way if you handle a bank or a startup providing animated GIFs to integrate into Whatsapp.
So no, it is actually definitively *not* pretty simple.
Re: (Score:2)
As this is security, the situation is a bit different. Usually, it is ok to use something old as long as it stays reliable and does not cost too much to run. In security, the attackers are very much not afraid of change and will use the latest and best tech they can. Hence defenders need to move with them or they become less and less secure. Yes, that is costly and a bother. But otherwise things happen like non-hashed or weakly hashed passwords getting stolen and a few hours or days later other accounts (wh
Re: (Score:3)
There are still tons of services out there (not least among them, most small banks' web portals) that store passwords in plaintext somewhere. People cheering over the death of bcrypt and PBKDF2 are technically right, but they also have no idea how destitute things truly are.
I still use bcrypt (Score:2)
I added bcrypt support to my MUD server. Everyone connects with unencrypted TELNET and sends passwords over the Internet in plaintext. At least my account system is not the weakest link.
Re: (Score:2)
People naively think there is a single universal security bar to measure anything by. In realty it comes down to utility and difficulty: what can an attacker gain by compromising your system; and how much effort does it take them. If the effort exceeds the reward significantly, you're secure. If the reward outweighs the effort, you're not.
Security is a game of making sure that whatever you have of importance, getting at it without permission is more trouble than it's worth.
its not obsolete... its overkill (Score:2)
The reason why bcrypt is still around is because key stretching does not really solve any fundamental core problem. It was only ever a band aid and never a solution.
For websites and other remote servers, passwords are just inappropriate. Users should always authenticate with public key tech, such as webAuthn for websites or ssh key auth for console. Passwords should not be used for remote services in any circumstance.
The only place passwords should ever be used is for access to to local device, and for loca
Re: (Score:2)
For websites and other remote servers, passwords are just inappropriate. Users should always authenticate with public key tech, such as webAuthn for websites or ssh key auth for console. Passwords should not be used for remote services in any circumstance.
This is your opinion to which you are entitled. I don't share it. Security is a series of tradeoffs presenting with different value to different people.
If secure authentication algorithms are used there is no effective difference between local and remote password authentication.
The only place passwords should ever be used is for access to to local device, and for local passwords to be secure, it needs to have entropy, and nothing can really change that.
You can always punt responsibility to something else like a security chip to enforce restrictions on authentication attempts.
And the only effective way to get entropy into a password is to have them be machine chosen and not human chosen, and organized mnemonically, not littered with special characters.
Passphrases are a more realistic option for maximizing the amount of entropy able to be realistically memo
Windows still uses unsalted MD4 for passwords (Score:1)