5 ms·
How many username/password forms are there on the web? Millions? They function basically identically, but they all had to be written (or at least configured) in
by bct 15y ago
How many username/password forms are there on the web? Millions? They function basically identically, but they all had to be written (or at least configured) independently. It's outrageous when you think about it, as if every language required you to write your own string library before you start coding.
The system smells; the problem is being solved in the wrong place.
The sad thing is that 15 years ago this could have been solved easily. Now any solution has an uphill struggle.
- tptacek 15y agoHow could this have been solved easily 15 years ago?
- buro9 15y agoHe doesn't mean that a solution existed 15 years ago, just that a significantly smaller number of applications would have been impacted by a solution coming into existence 15 years ago, than if one appeared now. I still like the idea of certificates in browsers authenticating me. But almost nothing out there that I use has the implemented.
- tptacek 15y agoSay we adopted certificate authentication. What happens when you want to get your mail from a friend's machine, or log in somewhere to print a boarding pass from a kiosk?
- buro9 15y agoI would hope that certificates are also paired with USB encryption tokens, and I could insert the one from my (physical) key ring and access the mail as usual. And once I'd withdrawn my token that access would be denied as expected.
- tptacek 15y agoSo now, when we log into machines, we have to carry special physical tokens? That's not realistic. You can thus see one of the reasons we didn't standardize on cert auth.
- ristretto 15y agothat's not unrealistic at all. I carry my keys with me all day, yet i only use them for a few seconds per day. On the other hand, given the risks of interception, i think the best is to have a centralized password system that will require frequent password changes.
- tptacek 15y agoMany tens of millions of people log into web applications every day, and you are proposing that they all somehow be issued PKI certificates and USB fobs, and that that be the primary way they get access to their data. You should talk to someone who manages fob deployments at a Fortune 500 company. These are environments supporting hundreds or thousands of users, not millions, and virtually all those users are highly paid, not fixed-income retirees. In particular, ask them about how easy it is to handle lost, damaged, and stolen fobs. Clearly, we weren't going to standardize on everyone getting a certificate on a USB key --- even had USB keys actually been feasible 15 years ago.
- ensignavenger 15y agoThe Department of Defense uses smart cards with X.509 certificates. I am not aware of all the details of this deployment, but I think they have millions of users.
- deleted 15y ago[deleted]
- yxhuvud 15y agoI know of banks that use cert auth for when their users is accessing their pages, so it is certainly realistic for certain applications.
- bct 15y agoA decent UI on top of HTTP authentication would have been an improvement, and it's something that more sophisticated systems can be built on top of while maintaining compatibility.
- tptacek 15y agoNo, a better UI HTTP authentication would have been a setback. HTTP auth doesn't make backend authentication code easier to write. In virtually all apps, it doesn't obviate the need to do session management, or solve the user demand for "remember me" cookies. What it does do is shoehorn applications into a single inadequate login UX, one that (almost at the protocol level) is not amenable to basic security measures like gracefully logging out sessions. Clearly there's quite a bit more wrong with HTTP auth than that (for instance, it does a terrible job of handling errors, it doesn't handle "forgot password", &c &c) but I'm not particularly interested in the counterfactual argument of what could have been had browser vendors only built a "good" version of it. The fact remains that even the hypothetically "good" version of HTTP auth would at best be only marginally better than what we have now, and would leave all the hard problems this "definitive guide" is trying to address still on the table.
- bct 15y ago> HTTP auth doesn't make backend authentication code easier to write. It makes it easier to shove into a library or middleware. Most of the issues you list are UI problems that could have been solved with a non-modal login prompt, a "remember this login" option, and a "stop sending the Authentication header" button. My point isn't that existing HTTP auth schemes are great, because they're not (even if they weren't saddled with a terrible UI). It's that migrating from those mediocre schemes would have been easier than migrating from the mediocre schemes we're using now will be.
- tptacek 15y agoHTTP auth has literally nothing to do with where the backend code for authentication lives. In our forms-auth world, there already are quite a few authentication libraries. I just disagree flat-out that HTTP authentication would have done anything to make the problems this guide is trying to grapple with easier. And in the meantime, HTTP auth as it exists in the standards today adds problems.