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

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 <mkwst@google.com> wrote:

> On Thu, Oct 16, 2014 at 11:43 AM, John Mellor <johnme@google.com> wrote:
>
> > On 16 October 2014 08:52, Mike West <mkwst@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
>

Received on Thursday, 16 October 2014 12:22:36 UTC