Re: [whatwg] Hashing autofilled data (was Re: Proposal: Write-only submittable form-associated controls.)

2014-10-16 Thread John Mellor
On 16 October 2014 08:52, Mike West mk...@google.com wrote:

 * Server stores credentials as `sha512(password + username)`.


It might be better to require PBKDF2/bcrypt/scrypt.


Re: [whatwg] Hashing autofilled data (was Re: Proposal: Write-only submittable form-associated controls.)

2014-10-16 Thread Mike West
On Thu, Oct 16, 2014 at 11:43 AM, John Mellor joh...@google.com wrote:

 On 16 October 2014 08:52, Mike West mk...@google.com wrote:

 * Server stores credentials as `sha512(password + username)`.


 It might be better to require PBKDF2/bcrypt/scrypt.


Yeah, that certainly makes sense.

-mike


Re: [whatwg] Hashing autofilled data (was Re: Proposal: Write-only submittable form-associated controls.)

2014-10-16 Thread Ben Maurer
Hey,

I think it'd be worth supporting encrypting the password. There are a
number of reasons why a site might have trouble using a hash:

1) It is unlikely that whatever standard format the browser supports will
be exactly how passwords are hashed today. It is possible to migrate hashes
(if the user doesn't use the new hash format, on the first login, take
their plain text password and re-hash it. alternatively, you can make your
new format an extra hash on top of the old format). Both of these require
either an unhashed password or a password hashed in some custom format.

2) Some sites may take measures to handle typos. For example, if your
password is MyPassword and you log in with the password mYpASSWORD,
Facebook lets you log in. The password does not need to be stored in plain
text. You can simply do the reverse-all-caps transform and re-hash the
password to verify. In theory a site could solve this by storing multiple
hashes.

3) A user might have multiple username formats (eg, you can log in with
email, phone# or username)

4) This functionality could be useful for credit card numbers, which
obviously can't be hashed.

Even though encryption doesn't prevent deriving the original password (like
hashing would), it could still be very valuable. For example, it would
prevent a 3rd party from seeing the users plain text password (even if they
are able to replay it). It reduces the number of systems which are exposed
to the password.

-b


On Thu, Oct 16, 2014 at 11:46 AM, Mike West mk...@google.com wrote:

 On Thu, Oct 16, 2014 at 11:43 AM, John Mellor joh...@google.com wrote:

  On 16 October 2014 08:52, Mike West mk...@google.com wrote:
 
  * Server stores credentials as `sha512(password + username)`.
 
 
  It might be better to require PBKDF2/bcrypt/scrypt.
 

 Yeah, that certainly makes sense.

 -mike



Re: [whatwg] Hashing autofilled data (was Re: Proposal: Write-only submittable form-associated controls.)

2014-10-16 Thread Anne van Kesteren
On Thu, Oct 16, 2014 at 2:22 PM, Ben Maurer ben.mau...@gmail.com wrote:
 It reduces the number of systems which are exposed
 to the password.

You mean after the password arrives at the server? Because for
transfer we should advocate TLS.


-- 
https://annevankesteren.nl/


Re: [whatwg] Hashing autofilled data (was Re: Proposal: Write-only submittable form-associated controls.)

2014-10-16 Thread Ben Maurer
Correct. For example, if you used CloudFlare to terminate your SSL traffic,
this measure would prevent CloudFlare from ever seeing your passwords. The
key to decrypt the password (or CC#) can be limited to the absolute minimal
surface area necessary.

On Thu, Oct 16, 2014 at 2:27 PM, Anne van Kesteren ann...@annevk.nl wrote:

 On Thu, Oct 16, 2014 at 2:22 PM, Ben Maurer ben.mau...@gmail.com wrote:
  It reduces the number of systems which are exposed
  to the password.

 You mean after the password arrives at the server? Because for
 transfer we should advocate TLS.


 --
 https://annevankesteren.nl/