Hashed userpass authentication?

[surma]

I’d like to not store my userpass/basicauth password in plaintext, so I am wondering if there’s any interest in a hasheduserpass authenticator?

I’d envision it would look something like this:

{
  "//": "...",
  "auth": "hasheduserpass:<username>:<sha224’d password>-<hex salt>[:vivify=<sha224’d vivify password>-<hex salt>][:+localhost]"
}

The password would still be transferred from the browser in plaintext and would be hashed on the server-side. In combination with HTTPS, this should be fine and avoid storing the password in plaintext.

I’d love to implement this, but wanted to check first that there’s interest and I’m not missing something.

[zenhack]

We should probably use an algorithm designed for password hashing (probably Argon2?) instead of sha224.

...But that gets a bit weird, since currently the basic auth gets used for every request, whereas normally with a password scheme you'd use it once to get a session token and thereafter use that. Early on in my career I made the mistake of using a good password hash directly in an API and woke up to CI taking 45 minutes to run. So it seems like there's kindof two bad ways to do this:

• Use a not-great password hash, giving users a somewhat-false sense of security (it's not nothing, but not "best practices")
• Use a best-practice password hash, introducing a performance footgun for users. We'd at a minimum want to clearly document the pitfall.

An auth option that allowed for some sort of token exchange e.g. with a cookie would be more ideal, but also obviously much more work to implement.

What do others think? (Since you're specifically fishing for maintainers' thoughts, I should point out that I am some rando whose involvement is somewhat limited these days).

[brainwave]

@zenhack How about implementing an API first in Perkeep then? Would there be any interest for this feature?