Comments on: Identity on the web is broken

By: Dave Raggett

Dave Raggett — Thu, 01 Apr 2010 14:18:09 +0000

OpenID and human nature means that most people will use the same URI for most sites, making it easy to track them and thereby eroding their privacy. An alternative is to disclose your identity provider, but not your identity. Essentially, you get your identity provider to provide credentials bound to the session id. However, a bigger issue remains, how do we avoid websites requiring the use of just a tiny handful of giant corporate identity providers. Certificate chains could provide a solution, e.g. enabling a website in Nebraska to accept the Swedish government as an identity provider. This raises significant social issues on an international scale.

By: uriel

uriel — Thu, 05 Nov 2009 21:00:44 +0000

> Authentication should be a feature of the protocol

No it should not: http://doc.cat-v.org/plan_9/4th_edition/papers/auth

Including auth as part of the protocol has bee a mistake over and over again, it is inflexible, insecure, and just a pain.

As for the rest HTTP auth is a joke, OpenID is an insanely complex nightmare, and OAuth is a few magnitude orders worse than that.

Add something like factotum to firefox, and there might be some hope that perhaps some day the auth problem in the web might be solved, but I’m not counting on it.

By: Anant

Anant — Wed, 04 Nov 2009 07:19:10 +0000

@David: What you describe is the *current* state of HTTP Auth, and that is what I say in my post: we should have fixed it in HTTP/1.1 by adding support for “logging out” and other such things needed in an authentication model. Instead, we decided to adopt the cookie approach which I think is ugly, messy, and just doesn’t feel right

@Robert: That is true for HTTP Basic Auth, but HTTP Digest Authentication (http://en.wikipedia.org/wiki/Digest_access_authentication) which is also part of the spec doesn’t require the password to be transmitted in plaintext.

By: Robert Kaiser

Robert Kaiser — Tue, 03 Nov 2009 20:35:21 +0000

Regarding HTTP Auth, you forget the fact that it always sends the password and username as plain text with every request to any page, which is really not the best idea. Most plain HTTP sites at least only need you to send this plaintext password once per session…

By: David Illsley

David Illsley — Tue, 03 Nov 2009 08:58:31 +0000

Anant, I used to have the same view on HTTP Authentication until I spoke to people building sites which have non-trivial security requirements. They aren’t in a position to use HTTP Auth because it doesn’t include a session timeout and doesn’t allow the server to invalidate the session and require the user to re-auth. This is important for secure sites given how computers are shared (or simply left unlocked when people go for a coffee). With HTTP Auth, once I’ve logged in to a site, that access is valid until I restart the browser.
Hopefully going forward we can find solutions which are technologically nicer than html forms+cookies, but that also leave the server in enough control that secure sites feel comfortable using them.
David

By: Mardeg

Mardeg — Tue, 03 Nov 2009 05:12:37 +0000

It always will be broken until multi-factor identification is the base standard.

Something you know: password or tune or rhythm
which is used as the salt for
Something you are: biometrics
which is used to activate
Something you have: yubikey or smart phone

Although this combination is still vulnerable to being mugged by a telepath that also cuts off your thumb.