Hi, First I'd like to say that this isn't something I'm working on or anything, it is just an idea I keep thinking about and wanted to share and see if others find it useful and are willing to work with me to bring it forward. For my part, if it gets traction I could implement a POC for libcurl, hence my email to the list.
Problem statement: While there are many problems with password authentication, the main problem I try to alleviate is password reuse across different sites, which most people do (in the best case with some minor differences). As we know from history, you can't trust servers to only ask for and save the password hashes with salt, and even if the server complies with that, it could still get compromised and then the attacker could simply change the web page to prompt for the password in clear. The current solution pushed by the big tech companies is to drop the use of passwords, and instead use PKI, certificates etc (see WebAuthn). While this is better in most cases, I don't see it happening in practice, and it does have some drawbacks, e.g. private keys are just long passwords in a way, which normal humans cannot remember and so have to be stored on a device, which you then have to physically protect. Proposed improvement: The idea is to add a new HTTP authentication scheme, where the browser will make sure the prompt to enter the password has a distinguish UI which cannot be faked with javascript or anything, Then the browser sends the hash of the entered password concatenated with the server's certificate (thus can only work over TLS), and so the requirement from the user would be, to only ever enter his password in this special UI (or with curl, using a special argument option). 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). - the server saves the user's password hash, along with the certificate it had used at the time. - 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. - 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, 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. - 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. Thanks! -- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
