[whatwg] fixing the authentication problem

Tue Oct 21 07:36:54 PDT 2008

On Tue, Oct 21, 2008 at 2:16 PM, Aaron Swartz <me at aaronsw.com> wrote:
>
> Some major web services redirect the user to an SSL server for
> the login transaction, but SSL is too expensive for the vast majority
> of services.
The issue is not SSL being expensive: the only expensive part is
having a third party (the Certification Authority) to endorse your SSL
keys, but for basic authentication self-signed certificates *should*
be enough: when a user logs into a forum, for example, s/he shouldn't
care about example.com being actually owned by Example Inc.; but just
about the fact that the username and password will only be readable by
example.com, regardless of who is behind example.com.
The actual issue is that current UAs are over-paranoid about
self-signed certificates: of course, a CA-endorsed certificate is
safer than a self-signed one (specially for transactions involving
money); but a self-signed certificate is still safer than no
certificate enough (and definitely safe enough for login purposes):
browsers, however, treat a self-signed certificate as almost a
guarantee of fraud, while sending login data through unencrypted
connections doesn't even raise an eyebrow: this behavior is definitely
wrong, and this wrong behavior is the actual issue that should be
dealt with (I don't really know if it should fall within HTML5's scope
to deal with this, probably it doesn't). In essence, if UAs *lie* to
the user about security (treating "cheap" self-signed certificates for
login as fraud attempts; but unsecure communications as a non-issue),
then what's the point at all about security?

> My proposal: add something to HTML5 so that the transaction looks like this:
>
> Client: GET /login
> Server: <html><form method="post" pubkey="/pubkey.key">...
> Client: POST /login
> dXNlcj1qb2VzbWl0aDAxJnBhc3N3b3JkPXNlY3JldA==
> Server: 200 OK
> Set-Cookie: acct=joesmith01,2008-10-21,sj89d89asd89s8d
>
> where the base64 string is the form data encrypted with the key
> downloaded from /pubkey.key. This should be fairly easy to implement
> (for clients and servers), falls back to exactly the current behavior
> on browsers that don't support it, and solves a rather important
> problem on the Web.
What's the actual difference between this and https? Both mechanisms
are using public-key encryption to protect the communications; the
only difference being that with https the encryption is handled at the
protocol level; while your suggestion would (currently) require to
reinvent the wheel, encrypting the data on the client (maybe using
JavaScript?) and then decripting it on the server (probably via
server-side scripting).
Maybe there is a good point on that suggestion, and I'm simply failing
to see it. If that's the case, I invite you to enlighten me on it.