1
$\begingroup$

This is a question about standard every day web authentication.

I have the following assumptions:

  • one of the reasons public key user authentication is not used as bread and butter on the web is that it is expensive for the server to verify signatures (the other is that it is not convenient for the client, but let's ignore that for now and in practice server operators have bigger role in decision making)
  • on the other hand massive password breaches in the last years and quickly growing computing power available for cracking hashed passwords pushes the state of the art towards more and more expensive KDFs - more rounds of PBKDF2, argon2 with high parameters etc
  • established public key schemes are secure against direct cracking

My question is: what is the proportion of computational cost (burden) on the server for verifying signatures on a supposed challenge (say, with ed25519) versus the cost of stretching passwords according to the up to date standards.

$\endgroup$
4
  • 1
    $\begingroup$ The standard recommendation for server-side password hashing is "100ms". Verifying an ECDSA signature made using P-521 (arguably the most expensive public key verification you will encounter) takes about 185k cycles on a Kaby Lake, which amounts to 92ms if your CPU runs at 2GHz. Now most server CPUs won't run at "only" 2GHz and more often than not you will not use the slowest signature scheme that is still somewhat practical. $\endgroup$ – SEJPM Aug 21 '18 at 14:38
  • $\begingroup$ side note: An impediment towards using asymmetric keypairs and not passwords for client-server authentication is that it changes the proof from "something you know" to "something you have". Supposing that the user loses the device(s) that have their private key(s), then they can no longer authenticate to the server. Not related to your specific question about cost, but possibly useful just the same. $\endgroup$ – Ella Rose Aug 21 '18 at 14:58
  • $\begingroup$ I intentionally ignored the client side. I can be handled in different ways that boil down to 'something you know' but this is not important here. $\endgroup$ – Petar Donchev Aug 21 '18 at 15:19
  • $\begingroup$ It may be one of the reasons, but the requirements for the browser / client PC to have special software / hardware or storage is a much bigger issue. Extensions for each browser / operating system, correct drivers for smart cards etc. This kind of stuff is hard to get right (read: user friendly) and secure (not all browsers support extensions anymore, notably browsers on mobile and such). I've never heard about the verification issue yet; especially for RSA the cost would be pretty minimal. The other issues above OTOH I've experienced for 16 years. $\endgroup$ – Maarten Bodewes Aug 22 '18 at 15:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.