On Sun, Jul 3, 2022 at 11:11 AM Petr Pisar via curl-library <curl-library@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
