Re: Idea for improving password security in the web

From: Isaac Boukris via curl-library <curl-library_at_lists.haxx.se>
Date: Sun, 3 Jul 2022 16:09:45 +0300

On Sun, Jul 3, 2022 at 11:11 AM Petr Pisar via curl-library
<curl-library_at_lists.haxx.se> wrote:
>
> V Sat, Jun 25, 2022 at 07:12:43PM +0300, Isaac Boukris via curl-library napsal(a):
...
> > Here's a suggested flow to register a new password and how to update
> > it upon server certificate change:
> > - the user submits his registration details except for the password.
> > - the server replies with "401 www-authenticate tls-bound-pwd".
> > - the browser prompts the new secure password UI and the user enters
> > the password, the browser then calculates "HASH(password,
> > server-certificate)" and sends to the server in an "Authorization
> > tls-bound-pwd b64(hash)" header (where HASH could be the hash
> > algorithm used in the server certificate for instance).
>
> This has a race when the server changes a certificate while having an open
> connection to the client. The client should return "Authorization
> tls-bound-pwd b64(certificate) b64(hash)". An established TLS connection
> usually does not need the certificate any more. HTTP is stateless in
> contrast to TLS.

I haven't thought about that, perhaps it would require resetting all
the old connections trying to authenticate while the server changes
certificate.

> > - the server saves the user's password hash, along with the
> > certificate it had used at the time.
>
> Here the server should save a certificate the client sent him.
>
> > - next time when the client tries to access the site, the server
> > replies again with "401 www-authenticate tls-bound-pwd".
> > - the browser prompts again the secure password UI and sends the hash
> > to the server as before.
>
> The client again should send the certificate used for computing the hash.
>
> > - if the server certificate hasn't changed since, then the server is
> > able to verify the credentials.
> > - otherwise, if the server certificate has changed, the hash the
> > client sent using the current certificate won't match the one the
> > server expects,
>
> The server should first check wheter the certificates match. Then it can
> actually distinguish a changed certficate from a bad password and report to
> a client a different status code.
>
> > so in that case, the server sends back "401
> > www-authenticate tls-bound-pwd b64(old-cert) b64(HASH(old-hash,
> > new-cert))" to prove to the client that it knows the old hashes so it
> > is fine to send them.
> > - the browser calculates the old-hash based on the old-cert, and if it
> > matches what the server sent, then the client sends again an
> > "Authorization tls-bound-pwd b64(old-hash) b64(new-hash)" header.
>
> Again the client should also send a certificate used for new-hash.

In order to facilitate the adoption I think it would be better not to
add any requirements on the client, like saving the certificate
somewhere, the client should just remember his password like today,
the server would have to save the certificate along with the password
hashes upon registration, but that feels easier.

btw, the protocol could be improved so that the client only sends the
password-hash at registration time, and then only sends 'hash(rand,
password-hash)' at authentication time like challenge-response
protocols.

> > - the server verifies the old-hash and if it matches, it replaces it
> > with the new hash and the new certificate and successfully
> > authenticates the client.
> >
> > That is roughly the idea, I'd be glad to hear any thoughts and
> > feedback about it.
> >
> That's a good idea in general. However, as you can see the certificate
> entering the hashes can actually be replaced with a nonce randomly genereated
> by a client. Then there is no need too bind the authentication method to TLS.

Here again, adding a requirement for the client to save his nonce
would make adoption much harder, and trusting the server to tell you
the nonce would break the security aspect of it (as it could tell you
some other server's nonce), while the TLS certificate has already been
verified by the client.

> Actually I think that binding it to TLS would be a problem for servers which
> separate TLS and user authentication. E.g. you terminate TLS on a dedicated
> proxy and then route the decapsulated HTTP relation to an application (or
> session) server. in that case the application server does not have access to
> the certificate.

The backend server could simply be made aware of the certificate being
used by the front-end server. This was afair, one of the reasons why
'tls-server-end-point' (RFC 5929, which inspired this idea btw) was
prefered over 'tls-unique' in GSSAPI channel-binding for HTTP and LDAP
protocols.

> I haven't search for various WWW-Authorization mechanisms, but I have a dim
> memories that someting like that already exists.

The main problem with the existing HTTP schemes and form-based auth,
is that the client can't really tell if the password he enters is
going to be sent in clear, so an important part of the idea is a new
distinguished place to enter the password where the browser will
guarantee to not send it in clear.

Thanks for your thoughts.

-- 
Unsubscribe: https://lists.haxx.se/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html

Received on 2022-07-03