Browser side form encryption

[Guru Partap Khalsa]

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.

[Patrick H. Lauke]

Post by Guru Partap Khalsa
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

[Mike Samuel]

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.

Post by Patrick H. Lauke

Post by Guru Partap Khalsa
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
www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com

[Guru Partap Khalsa]

It is a shame that if you changed your domain you would have to force users
to reset their passwords. I did mean hash and not encrypt, that was my
mistake; the salt (which could optionally have a server generated salt on
top of that) was intended to prevent the server from being able to replay
your password to other servers. I'm glad this area of the internet is more
insightful and understanding toward security analysis than the rest of the
general public spaces such as stack exchange, where this inquiry and many
others are met with random hostility and ignorance.

[Terence Eden]

I wrote about this a few years ago.
https://shkspr.mobi/blog/2016/11/password-hashing-in-the-browser/

For example, using something like
`input type="password" encrypt="bcrypt" salt="abc..." rounds="4"
pattern=".{6,}">`

There is discussion in the comments about the disadvantages and
practicalities of this approach.

I still think it would be an interesting idea - but I'm sit sure if it
solves the problem.

Post by Guru Partap Khalsa
It is a shame that if you changed your domain you would have to force
users to reset their passwords. I did mean hash and not encrypt, that was
my mistake; the salt (which could optionally have a server generated salt
on top of that) was intended to prevent the server from being able to
replay your password to other servers. I'm glad this area of the internet
is more insightful and understanding toward security analysis than the rest
of the general public spaces such as stack exchange, where this inquiry and
many others are met with random hostility and ignorance.