Score:2

Is it safe to use ECDH shared secret as a simple authentication cookie?

co flag

The protocol would look like this:

  1. User creates account and provides username, static public key
  2. User logs in by sending username
  3. Server responds by sending an ephemeral public key
  4. For the duration of the user's session, all requests must be accompanied by the ECDH shared secret between user-static and server-ephemeral keys

So the shared secret is used as a raw token or cookie. Assuming the communication is otherwise encrypted by TLS, are there any drawbacks to this? The benefit is "passwordless" authentication without any extra encryption.

Maarten Bodewes avatar
in flag
"User logs in by sending username"... 'xcuse me, what?
Score:2
es flag

You're essentially using knowledge of an ECDH shared secret to prove knowledge of the private key associated with your static public key, thus authenticating yourself to the server.

If you use the same public key to authenticate yourself both to server A and server B, then this would allow either server to impersonate you.

For example, you would log in to server A, and server A would provide your username to server B and request an ephemeral public key from server B. Server A would provide server B's ephemeral public key to the client, as if it had come from server A. The client now provides the ECDH secret as a cookie to server A, and then server A can impersonate you with server B.

Your approach requires the server to keep a copy of every ephemeral public key issued. This would not be necessary if you had provided a signature, which is the normal approach to proving knowledge of your private key. Such a signature would need to be bound to the server you're contacting, to prevent it being used elsewhere. It would ideally also be bound to a server challenge and an expiry date, to prevent a replay attack from anyone that does not know your private key but happens to be able to gain knowledge of one of the signatures.

You can avoid reinventing the wheel by using a TLS client certificate for registration and authentication.

samuel-lucas6 avatar
bs flag
Additionally, [with X25519/X448](https://www.rfc-editor.org/rfc/rfc7748#section-7), multiple different public keys produce the same shared secret. You need to include both the sender/recipient public keys in the key derivation.
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.