Re: Browser side form encryption

I think using a salt tied to the origin is meant to prevent replay attacks
when the user uses the same password for multiple origins, but yeah, salts
should be at least one of (secret, quick to expire).  Also, IIUC
salt+encrypt allows recovery of plain-text even for well-chosen passwords
whereas salt+hash does not.

Allowing the server to putt the salt in a header would allow servers to
scope salts, make password values opaque to injected client-side scripts,
allow security researches to collect stats on salt reuse using their own
accounts, and maybe put us on a path to turning off the https lock icon for
plain text passwords as form inputs.

One outstanding problem is password reset forms that want to enforce
policies like "at least one number and letter" which we could address by
providing a JS API that allows a single regex against the form value per
end-user interaction when there are two password inputs in the form.

This wouldn't address the use case where <input type=text> is used to mimic
a password, but again, security researchers can name and shame by testing
their own accounts.

On Sat, Oct 6, 2018 at 8:48 PM Patrick H. Lauke <>

> On 06/10/2018 23:51, Guru Partap Khalsa wrote:
> > Presently, to encrypt a password type input without javascript, we are
> > forced to trust a server-side script.
> > So that for example, the client is actually required to trust the remote
> > server with their password unnecessarily.
> > If there were some standard which defined a way in which <input
> > type="password"> were automatically encrypted with sha and salted with
> > the present domain, it would mean that the server can't ever see the
> > user's password. That way, we can make login systems which can't be
> > compromised under any circumstances.
> Until a site needs to move/subtly change its domain. Also, salting with
> the domain name means your salt is known to pretty much anybody, so
> rather pointless?
> P
> --
> Patrick H. Lauke
> |
> |
> twitter: @patrick_h_lauke | skype: patrick_h_lauke

Received on Sunday, 7 October 2018 14:35:29 UTC