[whatwg] fixing the authentication problem

2008-10-21 Thread Aaron Swartz
The most common way of authenticating to web applications is:

Client: GET /login
Server: htmlform method=post
Client: POST /login
user=joesmith01password=secret
Server: 200 OK
Set-Cookie: acct=joesmith01,2008-10-21,sj89d89asd89s8d

The obvious problem with this is that passwords are transferred in the
clear. 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. (We can hope ObsTCP will fix this, but that's a long way
away, if ever.)

Another alternative is HTTP Digest authentication, but I vaguely
remember Hixie saying it was insecure and, in any event, most Web
services will not adopt it because the browser UI isn't customizable.

My proposal: add something to HTML5 so that the transaction looks like this:

Client: GET /login
Server: htmlform 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.


Re: [whatwg] fixing the authentication problem

2008-10-21 Thread Aaron Swartz
 As I understand it: As an attacker, I can intercept that dXN...
 string. Then I can simply make a login POST request myself at any time
 in the future, sending the same encrypted string, and will get the
 valid login cookies even though I don't know the password. So it
 doesn't seem to work very well at keeping me out of the user's
 account. Also this seems vulnerable to dictionary attacks, e.g. I can
 easily encrypt user=joesmith01password=... for every word in the
 dictionary and will probably discover the user's password.

I was simplifying; in real life, I expect the server will include a
nonce with the form (as a hidden input), which they'll only permit to
be used once. (I also expect their cookie will have an ID that maps to
the username instead of the actual username. Or they'll just have the
cookie encrypted entirely instead of using an HMAC.) This, of course,
doesn't affect the HTML spec.


[whatwg] List of differences between whatwg and w3c spec?

2008-09-11 Thread Aaron Swartz
I notice there are specs for HTML5 dated today at:

http://www.whatwg.org/specs/web-apps/current-work/
http://www.w3.org/html/wg/html5/

diff -u shows a lot of difference, but most are cosmetic. (I gather
they're there because Hixie disagrees with some W3C pubrules but can't
get them changed.) Is there any page that lists the substantive
differences? Presumably the generation of the drafts is automated; is
the source file for the drafts published?


[whatwg] Repetition templates missing

2008-09-11 Thread Aaron Swartz
In the 11 September 2008 edition, section 1.6 of the HTML5 WD
(http://www.whatwg.org/specs/web-apps/current-work/#structure) links
to Repetition Templates at #repetition but there is no element with
that ID.

In a recent interview
(http://blogs.techrepublic.com.com/programming-and-development/?p=718)
Ian Hickson says For example, the repetition templates proposal is
almost certainly going to be dropped.

Can you please say why? I was quite fond of this proposal and we're
using it on OpenLibrary.org, where it's been a great boon to our
development.