Re: [apps-discuss] [saag] [websec] [kitten] HTTP authentication: the next generation

[Yaron Sheffer <[e-mail]>]

Just like the phrase "I am not a lawyer" is always followed by amateur 
legal advice (I know that for sure, I've done it myself), the same goes 
for "I am not a UI expert".

Two comments:

- There are in fact a few security-usability experts. I don't know if 
any of them participate in the IETF. This is an emerging research field, 
see e.g. http://oreilly.com/catalog/9780596008277.

- (I am not a UI expert, but...) Devising UI cues is extremely 
difficult. People will gladly enter their password when the web site 
displays a JPEG-rendered padlock icon. In fact *legitimate* sites have 
been known to display such icons, strange as it may sound.

Thanks,
	Yaron

On 12/13/2010 03:08 PM, Yoav Nir wrote:
>
> On Dec 13, 2010, at 2:14 PM, Carsten Bormann wrote:
>
>> 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.
>
> Yes. That's a big part of the problem. To get the security result we're looking for, the login field has to be clearly marked. A user should never be allowed to make the mistake of thinking that a regular input field is actually the password field. With Basic Auth you get some very distinctive clues (like the sheet in Safari).  So if we invent<input type="password_2.0" />, how can the browser show it that would not be possible to replicate with HTML/CSS/JS ?
>
>>
>> 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.
>
> Agree.
>
>> 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.
>
> I don't think the security requirements can be met using this (although I'd love to hear differently from browser people). Maybe if we could customize the authentication dialog with some kind of icon (like favicon), and maybe a frame or a div with some HTML elements (buttons, links).  I am not a UI expert (IANAUIE ?) but I think it's important that user authentication be quite distinct from the rest of the flow. IOW the user should know that at this point, she is not just surfing, but actually authenticating to a particular server, and if she's ever presented with some web form that says "username:_______ password:_______" she's going to know that something is wrong.
>
>>
>> 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.
>
> Fully agree. We really need to hear from both browser people and web application developers. No point in designing something really secure if the people in google/amazon/BOA then say "no, we'll never use that"
>
>>
>> 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.
>>
>> _______________________________________________
>> websec mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/websec
>>
>> Scanned by Check Point Total Security Gateway.
>
> _______________________________________________
> saag mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/saag