[whatwg] fixing the authentication problem

Vanguard Investments has an interesting approach:

1- User enters an identification but not a password
This page is an HTTPS one, by the way.

2- On a subsequent page (also HTTPS), the user enters the password
Additionally, there is an identifying image that is associated with the user:
	"Your security image	... You'll see your image whenever you log on."
Sometimes, based on a variety of factors, there is an intermediate page that challenges with a security question.

Please don't consider this to be, in any way, a criticism of the proposal. The above is just an example of what appears to be a very
good security regimen within the current constraints.
-----Original Message-----
From: whatwg-bounces@lists.whatwg.org [mailto:whatwg-bounces@lists.whatwg.org] On Behalf Of Eduard Pascual
Sent: Tuesday, 2008 October 21 10:37
To: Aaron Swartz; whatwg at lists.whatwg.org
Subject: Re: [whatwg] fixing the authentication problem

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.

Received on Tuesday, 21 October 2008 07:52:33 UTC