Bcrypt at 25
usenix.org
usenix.org
Out of curiosity, what was his competing proposal?
https://www.gnu.org/philosophy/stallman-kth.en.html
"...But that machine wasn't designed also to support the phenomenon called “tourism.” Now “tourism” is a very old tradition at the AI lab, that went along with our other forms of anarchy, and that was that we'd let outsiders come and use the machine. Now in the days where anybody could walk up to the machine and log in as anything he pleased this was automatic: if you came and visited, you could log in and you could work. Later on we formalized this a little bit, as an accepted tradition specially when the Arpanet began and people started connecting to our machines from all over the country. Now what we'd hope for was that these people would actually learn to program and they would start changing the operating system. If you say this to the system manager anywhere else he'd be horrified. If you'd suggest that any outsider might use the machine, he'll say “But what if he starts changing our system programs?” But for us, when an outsider started to change the system programs, that meant he was showing a real interest in becoming a contributing member of the community. We would always encourage them to do this..."
Stallman talks about anarchy, a system that seems to have been in place there at the time; one of the central tenet of anarchism is conviviality and building a community together. Everyone who is part of the community is trusted. In this system, you don't need passwords.
It's amazing he didn't destroy the entire movement.
> Stallman found a way to decrypt the passwords and sent users messages containing their decoded password, with a suggestion to change it to the empty string (that is, no password) instead, to re-enable anonymous access to the systems.
Later on, and still today as default in GNU software, he also objected to the 'wheel' group that would restrict the ability to call 'su' to just the members of 'wheel'. He wanted everyone who somehow obtained the root password to be able to become root.
Not that surprising. It's hard to think of any better alternative. Attempts at replacing passwords results in worse user experience or added complexity.
So despite all the flaws, it's the least bad thing we've come up with that doesn't cause an explosion of user support issues. Any replacement is going to need to be at least that easy.
Let me be a lesson to everyone. Plan for total disaster. Have a plan B and plan C. Don't go through all the work I went through to get your life back on track.
Your email still requires password. Besides making it someone else's problem it doesn't solve the issue of not having a password so all the same.
scrypt is better than bcrypt. it's widely available and it's good enough (though arguably bcrypt is good enough as well)
argon2id is better than both bcrypt and scrypt
We use Yubikeys for SSH and it is pretty flawless experience once set up
I couldn't get vitest to work with code that imports WASM, and I couldn't get vite to bundle WASM code for web workers.
Or really anything where you need or want client side encryption protected by a passport.
For example, make a login management framework that is feature-complete and does not require the dev to implement their own "hooks" into its methods. Instead use a config file to tell the framework how to work (expose this HTTP endpoint, use this data backend, etc) and just send it data in the way it expects, and have it respond with booleans. I assume devs might hate this, but it does give the business what it needs without relying on devs to implement it correctly (or have to wait on them to do it).
There are some overcomplicated examples of this already (keycloak) but we could make simpler things too that are secure, and more of them. Particularly I think SQL frameworks, REST API frameworks, HTTP daemons, container image builders, Cloud authentication methods, Git repositories, etc could easily implement stronger guardrails to force development to be secure by default.
The fact that most Cloud software today still tells devs to give it a static infinitely-lived authentication key is absurd. That just should not be possible; take that shit out of the software. We can do way better.
> tell the framework how to work [...] and just send it data in the way it expects
What is that, if not also "hooks"? I've long thought about this and tried many different solutions, and there's only 2 sane points to implement a library/framework like this in an unopinionated way IMHO (without prescribing the DB schema, etc): you provide a library like passport.js with lower level hooks (data hashing, vendor connections, etc), or you provide a framework integration with higher level hooks (API, DB schemas, etc); the problem with the higher level hooks is that you'll need many more hooks, with the only advantage that the dev might need to write a bit less code overall.
As an example, let's see password recovery. With lower level hooks, the dev writes the recover page fully, the API endpoint and backend for it, and somewhere in this backend has a small integration with the hashing the new password; which then the dev saves in the DB. The dev has to do all of this, but in exchange the hook integration is just "hash the password".
However for a higher-level (let's assume a JSON API) integration as you seem to suggest, now you need to use the hooks from the front-end to the custom API, two endpoints that hopefully work as expected. And then you need to use the hooks to connect from the data generation to the DB, again at least 3-4 hooks to check for the valid user, check for duplicated password (maybe?), save the new password. And error handling here and to the front-end, which is going to be a monster.
(or an opinionated way like Firebase where you bring the whole house, but let's leave that for another post)
I'm actually suggesting the most opinionated thing imaginable. Definitely it would need its own schema, database (logical database; you could still put it in the same SQL server instance).
I've implemented this before, it works fine. Basically imagine that your app can only talk to some login system through a command-line tool, and the command like tool deals with the database. You have absolutely no control over the login code or database. You can just run commands and give arguments and get something back. Again, programmers hate it, but it works great and is secure by default.
Now you have a CMS like Wordpress, no longer a library or even framework, which has so many moving parts that is def not "secure by default".
I could be misunderstanding your point, but cloud software is encouraged to rely on infrastructure introspection and role inheritance to achieve machine-to-machine authentication. There is also the problem when authenticating between user owned services, which can be achieved with services like Consul. Keycloak as far as I understand solves a lot of human-to-machine authentication scenarios.
In any case, I agree with the point that developing a secure application is hard enough that people might get it wrong even when actually trying to build it right. The development tools should induce secure development by default, but I believe the many particularities and use cases make it a hard problem to solve in a simple way. My point is that companies develop vulnerable application not because they want to in many cases, but because there is no right, clear, unabiguous way to do so that fits their particular use case.
When there's a new more secure practice, we should use abstractions that make switching to the new mode as simple as changing some external dependency. The mechanism should be abstracted away into something that isn't code, like how running a program with arguments and stdin isn't reliant on some particular programming language.
Instead let some other, separate program deal with the security-centric work, so if you change from "LDAP authentication" to "OAuth2", the business app doesn't ever need to be updated, and you can just change the configuration for the "login app" that the business app talks to. (This kind of already exists, in forms like the OAuth2 Proxy)
Who's we? Who are they integrating with? A protocol? A business? A government?
This has been tried in a multitude of ways. There's always a bit too much friction or cost.
HTTP got basic auth, which is crap because plaintext password transmission happens, also the browsers never got around to implement any sensible UI (e.g. you cannot log off). Then it got digest auth, which at least wasn't plaintext in transmission, but required plaintext password storage on the server. Then came negotiate, which only worked with some proprietary products, had even worse UI and was unusable outside a company's internal net.
Alongside that, there was HTTPS client auth, where, instead of fixing known problems, standards devolved into "sorry, we don't support that anymore". Also, the UI was crap.
Alongside that, there are homegrown methods using web forms, cookies, a lot of spit and maybe some javascript, which everyone uses atm. Everyone rolls their own, because over decades, standard bodies couldn't get their shit together. Also, everyone suffered from the corresponding attacks on all the weak and broken homegrown crap out there.
There is friction and cost, but those come from a lack of trying and a lack of giving a fuck by the people building web browsers, web servers and web standards. They basically declared the problem solved after the invention of cookies.
It would be cool if the challenge could specify the URL of an image to appear in the login dialog.
Plaintext submission happens with HTML forms too. The problem with Basic is the password goes with every request. That means you're exposing a long term credential to a higher risk. We want to exchange the long term credential for a short term one, ideally scope limited. That is far less catastrophic to revoke, and gives you some power of granularity (you can at the very least have some operations prompt for the password again). It also means you can limit risk on the server: only one page has access to the long term credentials, which can be more easily audited, or even hosted on dedicated servers.
WebAuthn has been the real savior here. Real cryptography has always been desirable for this, and removing per-site passwords is honestly just a bonus.
WebAuthn might solve a problem for the likes of Google and Facebook. But definitely not for the average web developer or server admin. And not for the user of some HTTP-based API. And the problem WebAuthn solves isn't really "we need better Auth", it is rather "we need better customer lock-in". Because the complexity and incompatibility of WebAuthn will just reproduce the debacle that was OpenID, only with the added "bonus" of being coupled to some hardware.
FWIW in firefox you can go to "clear recent history" and then uncheck everything but "active logins". This will wipe out any currently logged in basic auth.
A lot of cloud software doesn't allow you to create the keys automatically in the first place.
Ideally only component with persistent key would be one that distributes temporary keys to the rest of the components but that's usually pretty complicated.
* https://www.wired.com/story/bcrypt-password-hashing-25-years...
Argon2 and scrypt do this more efficiently than Bcrypt (which in turn does this substantially more efficiently than PBKDF2, which is still widely used, in part because there are regs that lock it into place), but you can more or less throw a dart at any of these algorithms to competently choose a password hash.
What I understand Niels to be saying here is that passwords are nearing the end of the road. I see why people think that! But it's also been an annual prediction since the 1990s, so I'm a bit skeptical.
> To address this scarcity of talent, I've pursued a very unconventional approach. I've embarked on a new venture as an EDM (Electronic Dance Music) producer under the artist name Activ8te, creating cybersecurity-themed EDM tracks. My goal is to captivate a younger audience and ignite their interest in security topics. Some of my recent tracks, like "Teardrop Falling" and "I Am Tracking You," explore challenging security themes such as denial of service, censorship, and the risks to our privacy posed by sophisticated spyware (Activ8te, 2022). By raising awareness and enthusiasm for the field, I hope to contribute to the expansion of a skilled security professional pipeline.
mac(bcrypt(mac(password, secret_key)), secret_key)
1) The output of `mac` might need to be encoded in an ASCII-clean way, e.g. using base64, as some implementations don't do well with embedded nulls or 8-bit data.
2) `mac` should produce 72 bytes of data or more. Truncating is better than padding.
3) An appropriate cost should be chosen, 12 or 13 seem to be common choices and should provide a large enough security margin.
You got that backwards. Alternatives like Argon2 are way more expensive for attackers because they can be configured to be memory hard
Don't do stuff like this.