> This came over the strenuous objections of Richard Stallman who famously tried to resist the introduction of passwords at MIT in the 1970s (Levy, 1984).
Out of curiosity, what was his competing proposal?
Background to his desire for open (non locked down) systems (covers the period when the MIT AI lab went from the completely open in-house developed ITS to a proprietary Digital system):
"...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..."
It's naïve in our system where problems are not solved as a group, but as a sum of individuals. If you don't trust someone to do something on your computer, then you also probably don't trust them to do much more outside; how can they be a part of the community if they aren't to be trusted ? We have abandoned all community-building to the state, and the state decides collective rules even though the state cannot manage a group this size with the best intents, especially considering the political-economic system we're in; it must assume everyone is problematic by default, and everyone's interest is at odds with the state interest.
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.
> 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.
Equal rights for everyone, anyone can use any account.
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.
In OpenBSD at least, if there are users in the wheel group then this is enforced. If there are no users in the wheel group then anyone who knows the password can become root.
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.
Not that surprising. It's hard to think of any better alternative. Attempts at replacing passwords results in worse user experience or added complexity.
Yeah passwords have persisted because they are conceptually easy for people to understand. 2FA with a code sent by SMS is also easy for anyone with a phone. No apps to install, nothing to set up or manage. Just provide your phone number one time.
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.
Besides the usual tricks of emailing a magic link or using your 2FA as a super login code, I can see either some sort of hardware token (cost prohibitive for most people) or more likely something like SQRL[0][1].
I was incapacitated for many years and my phone plan lapsed, so I lost the number. My email account lapsed and so did all my domains, so I lost access to all my email addresses. I now have about 1000 online accounts that I have no way to access because there is no way to authenticate myself. 2FA can be a real pain in some situations, even though I still advise everyone I know to enable it on their most sensitive accounts as the alternatives aren't great.
What you went through must have been really awful, I’m sorry that happened to you. That being said, this sounds like a rare occurrence. I’m sure since then you’ve created some contingency plan especially if there is a potential for a repeat. This actually highlights one of my fears of everything being tied to a phone number because you can never truly own it and it can be canceled or you could be sim-swapped.
You would have think I would learn. But no, it happened all over again last year, and I again lost my phone number and access to my email, but this time a friend managed to renew all but one of my domains, so I've managed to access to about 50% of the new accounts I created. And all my possessions were burned up in a fire this time, so I lost all my ID, passport, birth certificate, SSN card etc, which made things ever harder - BUT my landlord saved my actual phone handset with all my TOTP codes on it, which helped a lot!
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.
It's a long story. Illegally arrested for a crime I didn't commit. Spent almost 10 years in jail because I couldn't get access to my money to pay my bond. Charges were dismissed by the court after five years, but as I was walking out of the jail they arrested me for other charges I wasn't guilty of. Spent another five years waiting for trial on those; finally got out of jail for a few months; was harassed by the police, Tweeted about it, sentenced to five months in jail for a Tweet which basically said "LOL here come the police again to harass me"; went to trial on the other charges, judge is mad about the Tweet, finds me guilty without a shred of evidence being offered. Sentenced to maximum sentence, despite no evidence of guilt; already served all the time so should have been released, but authorities won't accept the address I gave them for parole; sent to a supermax prison for three months, then a minimum prison for another month, then released; waiting for exoneration in a few months on appeal.
Gmail goes to some pretty extreme lengths to keep you logged in. Yes, you will need a password but that’s not super different from the case of the traditional way to handle this: a password manager.
I'd like to use Argon2 for web stuff but Web Crypto doesn't support it yet (https://github.com/WICG/proposals/issues/59) and the WASM flavor creates problems with bundling and testing. Stuck with PBKDF2 for now...
I wonder if it'd get anywhere. There's not enough CPU/memory allocated in a lot of these platforms to make it work e.g. Deno deploy and Cloudflare workers (bundled) has 50ms of CPU time.
Then that means those platforms are insecure and should not be used, or authentication moved to another layer that does not suffer from those limitations. My rule of thumb is that if authentication does not consistently require at least 1 second, passwords are probably stored insecurely. Fortunately password managers with unique generated passwords limit the blast radius.
Cloudflare Workers "Bundled" is a legacy mode that is not the default these days. Unbound mode (the default for paid subscriptions) offers 30s CPU time.
It actually wouldn't be that hard to make off the shelf security solutions for free. We just need to take away the developer's choice and force them to integrate with some simple functionality.
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.
> does not require the dev to implement their own "hooks" into its methods
> 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)
> in an unopinionated way IMHO (without prescribing the DB schema, etc)
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.
The fact you think it is possible, which runs against every experience we have had in this domain the past few decades, combined with the philosophical and mathematical underpinning of software itself running against what you describe too, should maybe give pause to re-evaluate the claim?
> The fact that most Cloud software today still tells devs to give it a static infinitely-lived authentication key is absurd. We can do way better.
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.
I'm saying we should remove the 'encouragement' and make secure operation the only mode.
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)
That would most likely require an API gateway of sorts to handle the security procedures transparently. Build bare APIs and run them isolated, exposed by a layer that provides security services through composition.
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.
Since everything is TLS now, basic auth no longer transmits in the clear. But I agree browser vendors have refused to bother putting in even the bare minimum of effort for years. I've been subscribed to the firefox ticket to allow http auth logout for my entire adult life.
> HTTP got basic auth, which is crap because plaintext password transmission happens...
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.
Imho WebAuthn is just the next problematic non-solution: Everything you do in WebAuthn you have to build up manually within the already-problematic forms+cookies+serverlogic+javascript stack. You cannot just instruct your webserver to do WebAuthn for /secret and everything works, no, you need tons and tons of code for it to work. Code that will have errors and problems. Code that is lots of complications on top of forms+cookies+serverlogic+javascript.
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.
>also the browsers never got around to implement any sensible UI (e.g. you cannot log off)
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.
> 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.
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.
It's weird to see people saying that Bcrypt's "moment is passing", because it isn't. The whole concept of adaptive hashing is that they're future-proofed: they're parameterized by the degree of pain they inflict on brute force guessers, and they take advantage of the imbalance between guessers and validators.
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.
Since this comment seems the be getting down voted, it might benefit from context: Activ8te is Niels Provos (author of this article)'s EDM pseudonym, where he's making music with cyber security themes:
> 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.
Thanks! As it happens we've now had a pleasant chat in PMs on SC and he has given me a little advice on my home (mainly energy) data -> house music thing! B^>
bscrypt is a modern alternative to bcrypt; also cache-hard and more suitable than Argon2 and Scrypt: cache-hard, easier to deploy on multi-user environments, as well as web browsers/mobile devices.
I don't have anything super productive to say here and this comment is more emotive than substantive but I'm going to say it anyways: it is remarkable to me how much peer review people demand from password hash constructions (which are quite unlikely to fail dramatically) than from every other cryptographic primitive they use.
Well, I don't know about that. I really want all algorithms and implementations checked out by at least a few people that write up a report. Even something like Blake3 could be a bit iffy under that criteria.
Sure, but the tree structure is "made up" and has had less scrutiny than something than SHA2 SHA384 for example. I use it, but that's where my border line is.
bcrypt has stood the test of time very well. It (unintentionally?) does better than some more modern algorithms which are optimized for the wrong kind of "computational hardness", i.e. cache/memory hard. That being said, to avoid all pertinent issues, it probably should only be used in a construction like: (where `mac` is HMAC, CMAC, the keyed mode of BLAKE etc.)
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.
The reason people suggest HMAC or keyed hashes with password hashes is that they believe this foils attackers who steal password databases but not the HMAC key. Of course, that begs a question: if you have a place to store an HMAC key where attackers can't get it, why not just store the password hashes there? In reality: if you've lost your password hash database, your application has been game-overed. You don't hash passwords to further protect your own app; you do it to protect everybody else who is exposed to the inevitably shared passwords that users use.
Due to my mental illness I always forget my passwords. It annoys me because frankly aside from my email and bank account IDGAF about the rest of my online identity. But no I need to have a 12 character password for the supermarket app!
Out of curiosity, what was his competing proposal?