5 ms·

I don't see why it would have to be more numbers to type in than in the symmetric case. And yes, the public key would be the secret. Seems like a strict improve

I don't see why it would have to be more numbers to type in than in the symmetric case. And yes, the public key would be the secret. Seems like a strict improvemebt on the way it currently works.

UncleMeat 5y ago
If the public key needs to be a secret then it is the same as it is now. If the attacker obtains either secret they win. The whole point of asymmetric crypto is that the public key doesn’t need to be kept secret.
- BoardsOfCanada 5y ago
  Maybe I didn't express myself very well. The server stores the public key, instead of the current symmetric secret. So the new "secret" is the public key. It could be published of course but there is zero point to do so. So now if the database is exfiltrated by a hacker without anyone noticing, he still couldn't produce tokens to log in as a user.
  - UncleMeat 5y ago
    > So now if the database is exfiltrated by a hacker without anyone noticing, he still couldn't produce tokens to log in as a user. Why not? With TOTP, you type in a short code. The server needs to also be able to generate this code so they can verify that your code is correct. If it only has the public key then it must be able to produce the tokens to login as the user. If you want a more complex setup where the public key can only verify that the code is valid but cannot be used to create valid codes then the codes themselves (and the protocol) become considerably more complex and aren't going to be managed by a "type six digits into a web form" UX. I also don't think this really matters in a major sense. If somebody pwns the credential database then continuing to rely on authentication to prevent further harm is a fool's errand. "The adversary only got to extract the credential database and achieved nothing else" is not an especially common scenario today.
    - BoardsOfCanada 5y ago
      Yeah you're probably right.

I don't see why it would have to be more numbers to type in than in the symmetric case. And yes, the public key would be the secret. Seems like a strict improvemebt on the way it currently works.

UncleMeat 5y ago

If the public key needs to be a secret then it is the same as it is now. If the attacker obtains either secret they win. The whole point of asymmetric crypto is that the public key doesn’t need to be kept secret.

BoardsOfCanada 5y ago
Maybe I didn't express myself very well. The server stores the public key, instead of the current symmetric secret. So the new "secret" is the public key. It could be published of course but there is zero point to do so. So now if the database is exfiltrated by a hacker without anyone noticing, he still couldn't produce tokens to log in as a user.
- UncleMeat 5y ago
  > So now if the database is exfiltrated by a hacker without anyone noticing, he still couldn't produce tokens to log in as a user. Why not? With TOTP, you type in a short code. The server needs to also be able to generate this code so they can verify that your code is correct. If it only has the public key then it must be able to produce the tokens to login as the user. If you want a more complex setup where the public key can only verify that the code is valid but cannot be used to create valid codes then the codes themselves (and the protocol) become considerably more complex and aren't going to be managed by a "type six digits into a web form" UX. I also don't think this really matters in a major sense. If somebody pwns the credential database then continuing to rely on authentication to prevent further harm is a fool's errand. "The adversary only got to extract the credential database and achieved nothing else" is not an especially common scenario today.
  - BoardsOfCanada 5y ago
    Yeah you're probably right.