Make that [email protected], not [email protected]. ;) -- Thomas Roessler, W3C <[email protected]> (@roessler)
On 2011-06-15, at 15:42 , KIHARA, Boku wrote: > Missing Ccs? Forwarding: > > ---------- Forwarded message ---------- > From: David S. Misell MBCS CISSP <[email protected]> > Date: 2011/6/15 > Subject: RE: [saag] [websec] [http-auth] re-call for IETF http-auth BoF > To: "KIHARA, Boku" <[email protected]> > > > One time passwords should still be OK for poor auth methods, There is > a series of SecurID based RFCs > Kind Regards > dave > > -original message- > Subject: Re: [saag] [websec] [http-auth] re-call for IETF http-auth BoF > From: "KIHARA, Boku" <[email protected]> > Date: 15/06/2011 10:45 am > > 2011/6/14 Peter Gutmann <[email protected]>: >> Phillip Hallam-Baker <[email protected]> writes: >> >>> what would we want HTTP authentication to look like? >> >> I have a suggestion for what it shouldn't look like: Any method that hands >> over the password (or a password-equivalent like a password in hashed form) >> as >> current browsers do should be banned outright, and anyone who implements >> hand-over-the-password should killed and eaten to prevent them from passing >> on >> the genes. > > +1. > > To make the goal clear, let's list what kind of authentication methods > should be avoided. One item is methods that hand over passwords, > mentioned by Peter. Let me add methods whose UI can be imitated and > the result can be forged by malicious sites. Like a padlock icon that > insists the session is secured by TLS inside content area, Is a _secure_ > authentication method inside content area truly reliable? > > * a method that hands over a password (or a password-equivalent) > * a method whose UI can be imitated by malicious sites. > > Of course there might be more items, please append. > > # Peter, sorry for missing Ccs. > > -- > KIHARA, Boku > > 2011/6/14 Peter Gutmann <[email protected]>: >> Phillip Hallam-Baker <[email protected]> writes: >> >>> what would we want HTTP authentication to look like? >> >> I have a suggestion for what it shouldn't look like: Any method that hands >> over the password (or a password-equivalent like a password in hashed form) >> as >> current browsers do should be banned outright, and anyone who implements >> hand-over-the-password should killed and eaten to prevent them from passing >> on >> the genes. >> >> The only permitted auth.form should be a dynamic, cryptographic mutual auth. >> that authenticates both the client and the server. There are endless designs >> for this sort of thing around so the precise form isn't too important, as >> long >> as it's not hand-over-the-password. >> >> Peter. >> _______________________________________________ >> saag mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/saag >> > _______________________________________________ > saag mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/saag > _______________________________________________ > websec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/websec > _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
