Re: [whatwg] Passwords

[Delfi Ramirez]

 

Hi Anne, hi All: 

Here, in EEA I've noticed and see the same reasons that Glenn exposes,
with subtle emphasis on the reasons three , four and five. 

Regards 

---

Delfi Ramirez

My digital signature [1]

+34 633 589231
 del...@segonquart.net [2] 

twitter: delfinramirez

 IRC: segonquart Skype: segonquart [3]

http://segonquart.net [4]

http://delfiramirez.info
 [5]

On 2014-10-19 19:35, Glenn Maynard wrote: 

> On Sat, Oct 18, 2014 at 2:50 PM, Anne van Kesteren 
> wrote:
> 
>> I'd be interested in hearing why sites such as forums have not made the 
>> switch yet. If you're hosting passwords it seems downright irresponsible at 
>> this point to not use TLS.
> 
> The most common reasons I've seen are:
> 
> - People asking "why would this page need encryption?", which is always the
> wrong question. (The right question is "why does this page need to not
> have encryption?")
> - People don't want to jump the hoops to get a certificate and install it.
> I still have to search to find the right OpenSSL magic commands, and it
> still takes fiddling to get TLS enabled on web servers. (It should require
> editing two or three lines to enable it on Apache, not uncommenting dozens
> of lines of sample configuration then figuring out how to sync it up to
> your HTTP configuration. I suspect Apache can do this much more simply,
> and that the sample configurations that come with installations are just
> garbage...)
> - People don't want to pay for a certificate. (There's StartSSL, but when
> I tried it, it was so bad that I prefer to pay GoDaddy. That should say a
> lot given how bad *that* site is...)
> - They don't want the additional latency that TLS causes. I assume this is
> why Amazon puts most of the storefront on HTTP, and only selectively
> switches to HTTPS. (They've put a lot of design behind making this secure,
> but most authors can't do that, and it still has a big privacy cost.) This
> is at least a valid issue.
> - Some web services don't support HTTPS. (There's no excuse for this, but
> saying that doesn't make the problem go away. I don't recall particular
> examples.)
 

Links:
--
[1] http://delfiramirez.info/public/dr_public_key.asc
[2] mail:%20del...@segonquart.net
[3] skype:segonquart
[4] http://segonquart.net
[5] http://delfiramirez.info

Re: [whatwg] Passwords

[Glenn Maynard]

On Sat, Oct 18, 2014 at 2:50 PM, Anne van Kesteren 
wrote:

> I'd be interested in hearing why sites such as forums have not made
> the switch yet. If you're hosting passwords it seems downright
> irresponsible at this point to not use TLS.
>

The most common reasons I've seen are:

- People asking "why would this page need encryption?", which is always the
wrong question.  (The right question is "why does this page need to not
have encryption?")
- People don't want to jump the hoops to get a certificate and install it.
I still have to search to find the right OpenSSL magic commands, and it
still takes fiddling to get TLS enabled on web servers.  (It should require
editing two or three lines to enable it on Apache, not uncommenting dozens
of lines of sample configuration then figuring out how to sync it up to
your HTTP configuration.  I suspect Apache can do this much more simply,
and that the sample configurations that come with installations are just
garbage...)
- People don't want to pay for a certificate.  (There's StartSSL, but when
I tried it, it was so bad that I prefer to pay GoDaddy.  That should say a
lot given how bad *that* site is...)
- They don't want the additional latency that TLS causes.  I assume this is
why Amazon puts most of the storefront on HTTP, and only selectively
switches to HTTPS.  (They've put a lot of design behind making this secure,
but most authors can't do that, and it still has a big privacy cost.)  This
is at least a valid issue.
- Some web services don't support HTTPS.  (There's no excuse for this, but
saying that doesn't make the problem go away.  I don't recall particular
examples.)

-- 
Glenn Maynard

Re: [whatwg] Passwords

[Anne van Kesteren]

On Sat, Oct 18, 2014 at 7:14 PM, Roger Hågensen  wrote:
> This precludes that a site has a certificate, and depite someone like
> StartSSL giving them out free, sites and forums still do not use HTTPS.

We recently started doing this for whatwg.org. It was not a big deal
(though quite a bit of work given the amount of subdomains we have) on
a shared hosting provider. There's a whole bunch of reasons why most
sites ought to switch to using TLS:

  https://wiki.whatwg.org/wiki/TLS

I'd be interested in hearing why sites such as forums have not made
the switch yet. If you're hosting passwords it seems downright
irresponsible at this point to not use TLS.


-- 
https://annevankesteren.nl/

Re: [whatwg] Passwords

[Roger Hågensen]

On 2014-10-17 17:09, Nils Dagsson Moskopp wrote:

Roger Hågensen  writes:


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.

Note that Basic Auth + HTTPS provides reliable transport security.


This precludes that a site has a certificate, and depite someone like 
StartSSL giving them out free, sites and forums still do not use HTTPS.

Also, Basic Auth is also plaintext so the server is not Zero Knowledge.




Hashing the password (or passphrase) in the client is the right way to
go, but currently javascript is needed to make that possible.

Do you know about HTTP digest authentication?


Yes, and it's why I said "Basic HTTP Authentication", Digest is the 
better method of HTTP Authentication.
And I know that very well and it's very underdeveloped, there is no 
logout possible (you stay logged in until the browser session is ended 
by the user),
and styling the login is not possible and it's not as easy to implement 
with AJAX methods.



--
Roger "Rescator" Hågensen.
Freelancer - http://www.EmSai.net/

Re: [whatwg] Passwords

[Nils Dagsson Moskopp]

Roger Hågensen  writes:

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

Note that Basic Auth + HTTPS provides reliable transport security.

> Hashing the password (or passphrase) in the client is the right way to 
> go, but currently javascript is needed to make that possible.

Do you know about HTTP digest authentication?


-- 
Nils Dagsson Moskopp // erlehmann

[whatwg] Passwords

[Roger Hågensen]

Was "Re: [whatwg] Proposal: Write-only submittable form-associated 
controls."


On 2014-10-16 01:31, Eduardo' Vela"  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.  or 
something similar perhaps a comma to separate method and number of 
rounds, alternatively just  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/