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.
He 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.
Say 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?
I 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.
So 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.
that'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.
Many 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.
The 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.
A 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.
No, 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.
> 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.
HTTP 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.
Surely Digest Auth is a UI ontop of HTTP authentication?
The browser does the work - there is absolutely no need for millions of hand rolled web login forms.
Digest authentication isn't a UX change to HTTP Authentication; it's an inferior mechanism to protect credentials in flight (most real web apps use TLS to do this now, which is vastly superior) that happens to mandate weak password storage on the serverside.
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.