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
