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/
