[whatwg] meta="encrypt" tag is needed

[Juuso Hukkanen]

Thanks Mikko for linking to those passsalt generator tools. And thanks
Maciej for that analysis. Good that you at least see some benefit about
the passsalt parameter ;)

Good to know there are already tools that do the for of salting thing  
locally ( http://supergenpass.com/ ) I'd like nothing more than UAs to  
do the same and be guided to do that by HTML5.01.

Ok so I think passsalt is rather simple one, shouldn't have much complications

and as shown below site could choose to demand plain text passwords. Below

are the allowed values for passsalt. Unfortunately you all maybe right

that authenticated stateless active MITM attacks can't be avoided that  
simply -
Damn you Mallory. So that PKI could only protect against *most* cases  
of passive
listeners who the hell want's such, after all there might be some  
academic person next door playing with newest version PKI sniffing  
tools.


To me passalt is the important one. https can take care of  properly  
authenticated
  encryption,... but it sure would be nice if some PKI encryption

could be baked in HTML forms. help your self if you like that too.


> How about explaining what those attributes do, WHY would you want
> to use those and what are allowed values for each attribute.

PASSSALT:
^^^^^^^^^^
Attributes:
<meta encrypt <=> Identification tag for html 5.01 content for 5.01  
conforming UAs


passsalt="no|domainname"
^^^^^^^^^^^^^^^^^^^^^^^
1) no <=> UAs should send passwords unsalted (e.g. for the sake of  
compatibility)

2) yes <=> (default value, 5.01 conforming UAs will salt passwords  
using domain name)

3) domainname <=> domain(+TLD), if site wants hashes salted using it's  
current or some another domain name

4) in all other cases:
	a) empty string OR
	b) invalid domain name OR
	c) passsalt argument is not given at all
    <=> passwords are to be salted with domainname

5) passsalt argument could also be given as an argument of <form> -tag

how UAs should do the passsalt salting
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1) read the lowercase utf-8 string of domainname (e.g. mydomain.com)
2) read the users given password
3) calculate sha256(password+domainname)
4) take the first 24 chars of hex output and submit those as password

I have no opinion if HTML5.01 should define a minimum lenght to which salted
passwords would be truncated. Or should the password field lengths be as the
form defines them


Why passsalt in html5.xx specification
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1) multi-use of same passwords is a growing security problem. A  
successfull stealing single sites unencrypted real person names +  
passwords can lead to thousands of ID theft cases.
2) Voluntary salting of passwords has failed even on reputable sites.
3) Forcing the passwords salted is one solution. But the UA needs to  
know if it should send password salted or unsalted. Situation where  
one UA would send salted password and another unsalted is unacceptable
4) defining the salting requirement in html5.xx would tell to UAs  
about the sites readiness to accept salted passwords if the page would  
not be marked html5.xx+ (or passsalt="no") UA would send passwords  
unsalted


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


1) Site had stored the it's email addresses and passwords in unsalted format.
And as often is the case, same password had been multi-used on many sites.
If the alypaa.com had only gotten salted passwords from UA, it could not have
leaked out the passwords to peoples email, blog and facebook accounts.

"I did a test around year 2001 when I stumbled upon a small but similar
list (200+) of email addresses and "forgotten passwords". So, I send  
emails to all saying hi email if this is your password change it where  
you use it, because
anyone could find it at the internet. about 70% replied back to me and  
of those about a third said it's a bogus password, only for bogus  
sites. about a third thanked and said to be changing the passwords  
where needed. and about a third were furious and threatening to sue me  
for hacking his/her important password."

2) do you multi-use same passwords? (yes)

3) do you expect all login-requiring internet sites to start using https? (no)

4) do you expect all login-requiring internet sites to start salting  
passwords? (no)


You all had a million good questions, sorry but I will not elaborate anything
anymore as I am already busy and leaving this mailing list now.  
Fortunately, I am sure you all can consider the benefits and risks(?)  
of forcing passwords salted. Nice if that can be somehow applied into  
HTML standard; with or without PKI encryption parameters.

Juuso