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

[Adrien de Croy <[e-mail]>]

you might want to reconsider.

for instance what would you propose for non-browsers, which perform a 
large proportion of all HTTP transactions.

Also, it seems like it would make the problem about a billion times 
worse putting the auth into the application, where there are no 
standards, and therefore it would need to be re-implemented for each 
different application... kinda like what we have now already.

SASL is an orthogonal concept.  It's just a framework to negotiate auth, 
whether that's over HTTP or something else.  So, it's a bit of a red 
herring in this.

Yoav is correct, the auth must be in the protocol (1 of these) as 
opposed to the application (too many of these).

The trick is to get the application to actually use the auth of the 
protocol.

Adrien


On 13/12/2010 11:25 p.m., Dave Cridland wrote:
> On Sun Dec 12 22:06:29 2010, Yoav Nir wrote:
>> - It has to be integrated in the protocol, not the application
>
> What?! No. It must be integrated in the application. If nothing else 
> can be learnt, then learn this one thing - we have had Basic and 
> Digest support in the protocol for years, but because they cannot 
> easily be integrated into the application, no serious consumer 
> applications use them, even though what they provide is never any 
> better than Basic.
>
> If I could wave a magic wand and have all my wishes come true, I'd 
> embed SASL into the web browser such that:
>
> - Users are presented with visually-distinct controls embedded into a 
> web page for authentication, much like Extended Validation. Perhaps 
> focussing them turns the address bar red or something.
> - The SASL message exchanges happen over a WebSocket or equivalent 
> low-latency bidirectional channel. (Perhaps even HTTPS, I suppose - I 
> imagine a webbrowser gets given one or more URIs to use for 
> communications).
> - The result of this is a one-time password intializer.
> - Subsequent requests and responses occur with traditional HTTP auth, 
> using some OTP mechanism that requires only a single message.
>
> The two parts of the protocol can, and should, be split - many 
> existing websites use a cookie as the result of authentication, and 
> having a more secure variant of this alone would be extremely useful.
>
> Note that the key portion of this - embedded SASL - is not really HTTP 
> auth at all, but a Web Application Auth - since that's really the 
> other party to the authentication, it seems quite obvious to me that 
> this should be the authenticating entity.
>
>
>> - It has to be secure against phishing - if the attacker gets you to 
>> authenticate, they can't later use that authentication to connect to 
>> the real server
>> - If the authentication succeeded, then (a) you typed your password 
>> correctly, and (b) this is really the server
>>
>> EAP has some methods that do this. SASL can probably be made to do 
>> this, but with an extra layer.
>>
>>
> SASL also has methods that will do this, I think - I'm not sure what 
> additional layer you're referring to here.
>
> Dave.

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com