- From: Mikko Rantalainen <mikko.rantalainen@peda.net>
- Date: Mon, 10 May 2010 12:34:49 +0300
Juuso Hukkanen wrote: > I was expecting criticism; as is unavoidable with all crypto issues. > > You asked many questions, and unfortunately all you missed the > auth="verisign" argument, which _is_ enough to prevent all practical > (,even if they are all theoretical!,) man-in-the-middle attacks. You keep referring to the source code excerpt you posted. How about explaining what those attributes do, WHY would you want to use those and what are allowed values for each attribute. Also note that because the attribute 'auth="verisign"' is sent without encryption, it cannot be used for preventing MitM attack. This is because MitM attacker would be able to strip out that attribute or replace it with any other value he prefers. > the above 'page' using the meta-encrypt tag, which is enough for a > client browser to submit to site > a) a salted password > b) and a user name transported in encrypted form; over the internet I understand that you believe that this is important. Could you explain to us, why do you think so? You referred to "alypaa.com" case in your original post. Could you explain why do you think this would prevent from similar information leak in the future? As you haven't explained why your proposed scheme really works, I can only guess that you intent that the server never gets the original password, only the salted version. Are you trying to suggest an user agent implementation of something similar to this: http://angel.net/~nic/passwdlet.html ? > I am not suggesting replacing https with anything, government and > business sites can and should keep on using it. I am suggesting a small > easy to use mini-encryption which would be enough for those 90% of sites > should salt their passwords and encrypt sensitive data and but who > currently aren't. What is the attack you're trying to avoid? > Obviously you people will keep complaining, so what do you want to > complain next > 1) Man-in-the-middle problem; which doesn't exists because > a) those are just academic mind games Huh? What is the attack you're trying to avoid? (I'm repeating myself...) > b) if auth="verisign" is used as external CA This cannot be used for authentication because it's part of the non-encrypted and unsigned content. See above. > 2) HTTPS = good (even if it is typically NOT used with forms ?? (Are you trying to make some point? Please, elaborate.) > 3) password salting = webmasters duty to do it (which 50% forget), after > using the HTTPS (which 90% forget) Is this the problem you're trying to fix? You don't like the fact that if the server software is able to know your password, it's able to store it encrypted? Why do you think your proposed feature would fix this? > 4) Declaring encrypt action doesn't fit into HTML (; then why is there a > form method get/post) ?? (Are you trying to make some point? Please, elaborate.) -- Mikko -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100510/82bb6c59/attachment-0001.pgp>
Received on Monday, 10 May 2010 02:34:49 UTC