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

[Dave Cridland <[e-mail]>]

On Mon Dec 13 10:55:11 2010, Adrien de Croy wrote:
> for instance what would you propose for non-browsers, which perform  
> a large proportion of all HTTP transactions.
> 
> 
I agree a solution is needed for non-browsers (including IPP, for  
example). I disagree this needs to be, or should be, the same as a  
solution for web apps. I disagree that non-browser security is even a  
major priority at this point in time - it's adequately served by TLS  
and client certificates and/or Basic auth, depending on the security  
model desired - this latter I appreciate is a personal opinion.

However there is no doubt at all that current webapp deployments are  
in need of a serious improvement in security, given that these  
generally use TLS only during authentication itself, and use  
plaintext usernames and passwords for the authentication itself.

> 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.

Yet every webapp currently uses a form, and it's so close a standard  
that browsers can, and do, spot login forms and allow the credentials  
to be cached. As such, I fail to see why we wouldn't want to place  
better authentication at that layer, where it's quite likely to be  
actually used.

> 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.

Right, that's fair enough.

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

Yes, but the problem is that existing, deployed, webapps could use  
Basic right now - they all just ask for a username and password after  
all. Yet none of them do, in part because of integration issues, but  
mostly I suspect due to usability and branding issues.

We could deploy some more advanced mechanisms in HTTP auth tomorrow,  
and nobody would use those either.

Dave.
-- 
Dave Cridland - mailto:[e-mail] - xmpp:[e-mail]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade