ECDSA or DSA in general was to sign a message or data using private key and verify it using public key, if the attacker/imposter doesn't have the private key then they couldn't sign the message properly.

If ECDSA private key was kept private, can the signature verification of ECDSA be used for user to login into a system ? Rather than a password hashed based login approach ?

  • $\begingroup$ SSH already does this. I'll leave room for new members to provide more thorough answers. $\endgroup$ – DannyNiu Jan 18 at 6:54

Yes, this is secure provided the message to be signed is unique on each login to prevent replay attacks. Usually that's done with either a random challenge or the signature over a shared secret.

In fact, SSH does this already with ECDSA keys: the two sides agree on a shared secret, which is hashed, and the client signs the hashed secret and some other data to verify that it's allowed to log in. MariaDB also does a similar thing by deriving an Ed25519 key (which isn't exactly ECDSA, but is similar) and using that to sign a random challenge (although it doesn't necessarily derive this key in a secure way).

Similarly, most FIDO2 and WebAuthn two-factor authentication devices, such as YubiKeys, use this approach. You could also use TLS client certs that are ECDSA, which is another approach used in some environments.

This could be used for any type of login, including websites, but it is less common there because people don't expect to carry a key around with them everywhere and frequently log into websites from different computers, so it's practically inconvenient. But ignoring the practical problems, this is secure if implemented correctly.

  • $\begingroup$ I recently think of user keep requesting random data/message to be signed with .. but what do you mean by "random challenge" ? I am using a CA signed RSA 4096 bits key certificate(from a source it stated it's equivalent to 128 bits of AES key in terms of strength). $\endgroup$ – Hern Jan 18 at 15:53
  • $\begingroup$ I would like to know given in such case: cuz right now what i have in my mind was to create an ephemeral shared secret[combination of client ECDSA/ED25519 + ECDH(X25519) through libsodium every web api session] with 1 built in TLS/SSL + Libsodium ephemeral session upon registering/login/other activities $\endgroup$ – Hern Jan 18 at 15:59
  • $\begingroup$ is this necessary or too much of a work ? $\endgroup$ – Hern Jan 18 at 15:59
  • $\begingroup$ By "random challenge", I mean something like a 128-bit random value presented by the server on login that the client must sign to log in. I would say unless you have a specific threat model that requires a key-based approach, sending a plaintext password over TLS is probably fine. $\endgroup$ – bk2204 Jan 18 at 16:16
  • $\begingroup$ Is the random challenge necessary needs to be 128 bit random value ? or it can be more than 128 bit ? Do I need to have passwords hashed based login mechanism too ? $\endgroup$ – Hern Jan 18 at 16:21

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.