W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2014

[whatwg] Passwords

From: Roger Hågensen <rescator@emsai.net>
Date: Thu, 16 Oct 2014 05:41:15 +0200
Message-ID: <543F3E5B.9020609@emsai.net>
To: whatwg@lists.whatwg.org
Was "Re: [whatwg] Proposal: Write-only submittable form-associated 
controls."

On 2014-10-16 01:31, Eduardo' Vela" <Nava> wrote:
> If we have a password manager and are gonna ask authors to modify their
> site, we should just use it to transfer real credentials, not passwords..
> Passwords need to die anyway.

And use what instead? At some point a password or passphrase (aka 
sentence) is needed.
Password managers need a password to lock their vault as well.

Password/phrases are "free", all other methods requires something with a 
cost.
Biometrics requires scanners, and good ones (that can't be fooled by by 
breathing on a printed out fingerprint) are expensive.
There are USB sticks, and Smart cards (which require a card reader)
Audio require a microphone (and can be heard by others) "my voice is my 
passport verify me".
You could use a app but this means you need a smart phone (which I don't 
have and probably do not plan to get any time soon, no need for one).
There is SMS but a phpBB based forum site isn't going to shell out cash 
for SMS based login or similar.
Biometrics have other issues, the voice may change (your voice changes 
throughout the day), your fingerprints change based on moisture, and you 
can damage them, there are diseases and medicines that can affect them. 
The retina may change as you get older, even your DNA may get damaged 
over time.

Also credentials (certificates) are not free if you want your name in 
them. (you can get free email/identity ones from StartSSL.com and a few 
other places but they are tied to your email only).
Installing certificates are not always easy either, and then there is 
the yearly or so renewals, and you can throw away old certs or you will 
b unable to decode encrypted emails you got archived.

A regular user will feel that all this is too much noise to deal with.
They could use something like Windows Live as a single sign on and tie 
that to the Windows OS account, but only sites that support signon with 
Live can take advantage of that.
And a password (or a portable certificate store, or biometric of sorts) 
is still needed for the Windows OS on that machine anyway.

I mentioned StartSSL above, the cool thing they do is they hand out 
domain only verified certificates, so any website can have "free" https, 
why the heck this isn't a "thing" more than it is I don't understand, 
each time I see a login to a site or forum that is http only I always 
ponder why the heck they aren't using HTTPS to secure their login. But I 
digress.

Single word passwords need to go away, if a attacker finds out/guesses 
it in for one site, changes are the same pass is used on multiple sites 
as is or with minor variations. Passphrases is the solution to some of 
this problem as it will make dictionary attacks much more expensive. 
There are still sites that enforce a 8 character password which is 
insane, people should be allowed to enter any password they are able to 
enter on their keyboard, be it one character or long sentences, with or 
without numbers or odd characters, the more restrictions there are on 
the password input the easier it is to guess/crack. The only 
restrictions that does no harm would be to ask for passphrases instead.

Also http logins with plaintext transmission of passwords/passphrases 
need to go away, and is a pet peeve of mine, I detest Basic 
HTTP-Authentication which is plaintext.
Hashing the password (or passphrase) in the client is the right way to 
go, but currently javascript is needed to make that possible.
If a password field could have a hash attribute that would be progress 
in the right direction. <input type="password" hash="bcrypt"> or 
something similar perhaps a comma to separate method and number of 
rounds, alternatively just <input type="password" hash> and use a 
browser default instead (in this case the server side need to support 
multiple methods of hashing and the hashed password need a prefix to 
indicate method, salt and rounds if any.

There is some new crypt stuff, but again that needs javascript to be 
utilized, having a password be hashable by the browser without the need 
for any scripts to do so would be the best of both worlds in my opinion.
For example if a hostile script had access to the form and hte password 
field, the password would have been hashed before it was put in the 
password field anyway, sure they might be able to snoop the hash but the 
hash could be using a unique salt (or should rather) and would be 
useless to re-use.

-- 
Roger "Rescator" Hågensen.
Freelancer - http://www.EmSai.net/
Received on Thursday, 16 October 2014 03:41:40 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:24 UTC