Missing Ccs? Forwarding: ---------- Forwarded message ---------- From: David S. Misell MBCS CISSP <07710380...@o2.co.uk> Date: 2011/6/15 Subject: RE: [saag] [websec] [http-auth] re-call for IETF http-auth BoF To: "KIHARA, Boku" <bkihar...@gmail.com>
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" <bkihar...@gmail.com> Date: 15/06/2011 10:45 am 2011/6/14 Peter Gutmann <pgut...@cs.auckland.ac.nz>: > Phillip Hallam-Baker <hal...@gmail.com> 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 <pgut...@cs.auckland.ac.nz>: > Phillip Hallam-Baker <hal...@gmail.com> 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 > s...@ietf.org > https://www.ietf.org/mailman/listinfo/saag > _______________________________________________ saag mailing list s...@ietf.org https://www.ietf.org/mailman/listinfo/saag _______________________________________________ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
