- From: Carsten Bormann <cabo@tzi.org>
- Date: Mon, 13 Dec 2010 13:14:03 +0100
- To: General discussion of application-layer protocols <apps-discuss@ietf.org>, http-auth@ietf.org
- Cc: Common Authentication Technologies - Next Generation <kitten@ietf.org>, saag@ietf.org, websec <websec@ietf.org>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
On Dec 13, 2010, at 12:23, Dave Cridland wrote: > every webapp currently uses a form Yes. Nice demonstration of conflicting requirements. As a webapp developer, I want to control the user interface during authentication. Leaving the user alone with the bland and unforgiving browser user interface for HTTP auth is suicide. I want to provide extra buttons for forgotten passwords, maybe even password hints, and a "sign up" method. HTML/CSS/JS lends itself well to providing such a friendly user interface. As a security geek, I recognize this as exactly the problem that creates the potential for phishing. Having the user type credentials into a random form is never going to be secure, HSTS notwithstanding. Maybe the only way to address both requirements is to have something in HTML/CSS/JS that addresses authentication interactions. Replacing <input type="password"/> for the 21st century. This would allow web app designers to design a nice context for this interaction, and would allow running security protocols that are binding themselves to a browser-server security association that may be identical to or different from the TLS envelope. "Storing passwords" in the browser might turn into storing those security associations. This is not "HTTP authentication", but it might be more useful in the long run. We'll need the browser people to start any such effort. Gruesse, Carsten PS.: And I'd still like to have some better form of authentication for machine-to-machine that can be independent from the TLS envelope. But that is a completely different animal.
Received on Monday, 13 December 2010 12:14:43 UTC