Idea for improving password security in the web

From: Isaac Boukris via curl-library <curl-library_at_lists.haxx.se>
Date: Sat, 25 Jun 2022 19:12:43 +0300

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

Received on 2022-06-25