1

Despite best efforts it is pretty clear that most users reuse their credentials, especially for what they consider non-critical sites such as forums. While TFA does mitigate the potential damage of this a bit (aside from its other benefits of course), a compromised database of one providing using TFA can still lead to another not-TFA-protected account's credentials to become cracked.

This problem would be voided by users "simply" using public key authentication instead of passwords, but let's be honest, most users won't bother with maintaining a secret key (and password authentication reset usually still means they need to access their emails which out of laziness might be protected by the same private key or still a mere password) and if they have to use Software to store their secret key they might just as well finally use a password manager...

So, what if instead of the server saltedly hashing the password to authenticate the user a client-side function would use the password to derive a PKA pair (salted and/or peppered individually per server and/or user) and the server only stores the public key (plus salt, which does not become part of the public key but part of information the user needs to recreate their private key) for use with e.g. SSH2's authentication (i.e. request a non-replayable message to be signed by the private key)?

Users would hence still need to remember only one password, but since each server's salt/pepper differs the stored public key becomes unique, as does the generated private key.

Tobias Kienzler
  • 7,658
  • 11
  • 43
  • 68
  • I was also thinking about ECC's key addition property, but that's basically just another kind of "salt" on first thought – Tobias Kienzler Jul 03 '20 at 08:41
  • Authentication by PAKE and SRP offer a number of advantages over sending the user's plaintext password over an TLS connection. See https://security.stackexchange.com/questions/242811/alternatives-for-sending-plaintext-password-while-login/242824#242824 for more info. Although, I'm not sure if brute-forcing the password from the material stored by the server is any more/less difficult than modern salted hashing methods. – mti2935 Mar 23 '21 at 12:00

1 Answers1

0

That would have been too easy, wouldn't it? While obtaining the private key from the public key itself is still nigh impossible, the method to obtain it from the too-simple password is trivial, thus all this method does is replacing the purely server-side hashing by a hash-like algorithm that puts more of the workload to client-side. The only potential benefit might thus be slowing down online attacks, but existing methods such as limit-rating are probably still better-suited and more notably already well-established...

Tobias Kienzler
  • 7,658
  • 11
  • 43
  • 68
  • Good old [rubberducking](https://en.wikipedia.org/wiki/Rubber_duck_debugging) at work... – Tobias Kienzler Jul 03 '20 at 08:43
  • 1
    was just wondering how you could post your question _and answer_ in the very same minute. Your comment explains it :) – lab9 Jul 03 '20 at 09:22
  • Using PK authentication would provide some level of protection in the event of a server compromise where the password is intercepted before being hashed. A client-side hash can protect against compromise of plaintext passwords. – Matthew Mitchell Jul 02 '21 at 14:51