New `TEP-0012`: One-Sided Passkey Authentication

[da2ce7]

This document proposes the use of asymmetric cryptography for user accounts and their authentication.

View Here: https://github.com/da2ce7/torrust-teps/blob/tep-asymmetric_key_client_authentication/TEP-0012.md

Resolves #8

[da2ce7]

I assign the TEP Number: 12.

[josecelano]

hi @da2ce7

If I'm not wrong the two key points in your proposal are:

1. Using bitcoin-like key pairs to authenticate a user in a webapp.
2. User authentication would be like API authentication with a token where you can create different tokens with different permissions.

Questions

• Shouldn't the user provide the original "seed" or the "private key" at the end instead of the password? In terms of UX, I think it's more or less the same, although it allows the user to define different access levels. In terms of security, it's safer, and I suppose passwordless authentication is becoming a standard. Although I do not know if this method is considered passwordless.
• Could you provide some links where I can learn more about how to use asymmetric key encryption for authentication? I've added one below.
• Are the generated keys valid bitcoin addresses? If so, do you think that could be useful for other features in the future?
• Is there already a similar implementation?

Links

• Article/demo: https://medium.com/digital-banking-labs/how-to-implement-password-less-authentication-using-cryptography-in-bitcoin-443785023264

[da2ce7]

Hey @josecelano

Thanks for the questions:

1. Using bitcoin-like key pairs to authenticate a user in a webapp.

Yes, I have specified the same elliptical-curve as is used in bitcoin: secp256k1.

--

2. User authentication would be like API authentication with a token where you can create different tokens with different permissions.

The client sends the server URI it observes to the server, and includes this value in the "Client Authentication Token" that it generates.

• The server compares the URI to be something that it expects (i.e. not "servername.scam.com"). If good:
• The server also generates the "Client Authentication Token" and compares it to the one the client provides. If the same. Authentication is successful.

I suppose after the successful authentication, the server can decide to issue a normal token as per usual.

--

Questions

• Shouldn't the user provide the original "seed" or the "private key" at the end instead of the password? In terms of UX, I think it's more or less the same, although it allows the user to define different access levels. In terms of security, it's safer, and I suppose passwordless authentication is becoming a standard. Although I do not know if this method is considered passwordless.

The client doesn't store or need the seed by default. The seed is the account "recovery phrase". This is by design:

1. Gives another chance for the user to recover their credentials.
2. It gives some forward security:

• The user may wish to rotate their keys when they move to a new computer.
• If the seed was stored by the client, then there is no possibility of reusing the new seed on a new computer.
• However, the client just stores a Public-Secret Key-Pair (in the form similar to the username-password), so when the user moves to a new computer, it can re-enter the seed and generate a new key-pair, and then the seed gets deleted again, (for when the user needs to rotate keys again).

--

• Could you provide some links where I can learn more about how to use asymmetric key encryption for authentication? I've added one below.

This protocol uses ECDH, in a very simple format:

1. Derive a common ephemeral (temporary) key.
2. Derive a common authentication key.
3. Client send URI to server, server checks URI.
4. Derive a common client token.
5. Client sends token to server, server checks token.
6. Server looks up client public key in database, and finishes authentication.

I would love for somebody who is better at crypto than me to review the protocol and confirm that it is indeed secure.

--

• Are the generated keys valid bitcoin addresses? If so, do you think that could be useful for other features in the future?

You could turn a key-pair into bitcoin addresses, however we don't use them as bitcoin-addresses. Having some sort of asymmetric key infrastructure could be leverages for many other aspects in the future: such as the previously proposed signed-invitations.

--

• Is there already a similar implementation?

I'm sure there is, however the common ones are far-more complex than what we use here, (such as getting a CA involved with the authentication). We just use implicit proof of key ownership when deriving a common key.

--

Links

• Article/demo: https://medium.com/digital-banking-labs/how-to-implement-password-less-authentication-using-cryptography-in-bitcoin-443785023264

This article uses bitauth, a different algorithm for authentication: the server receives cryptographic signed requests sent by the client.

The protocol proposed here uses a mutual derivation of a client authentication token, that is used once.

[da2ce7]

@josecelano based upon your questions I have updated the TEP to clarify: 018f5518544893a86ea996fb63a3ba1ecb685e98

[mickvandijke]

Maybe instead of generating a private key for the client, we could instead add a public key field to the signup form. So that clients can use their own existing public key. We could even make this field a list so that a client can submit multiple public keys.

A client would then be able to signup using a normal password and/or a public key. I do not like the idea of only allowing authentication with public keys, as it might be too confusing to set up for some users. Keeping the option for a traditional password would be a nice fallback for these users.

[josecelano]

@josecelano based upon your questions I have updated the TEP to clarify: 018f551

Thank you for the clarification @da2ce7 . I have some more concrete questions above.

I think I got the "purpose" wrong. I thought it was a way to authenticate with different access permissions. But I suppose other purposes could be more like what you said: the admin can permit some public keys to generate invitations.

I have also found this proposal https://github.com/bitid/bitid/blob/master/BIP_draft.md.

[da2ce7]

Hello @WarmBeer

Maybe instead of generating a private key for the client, we could instead add a public key field to the signup form. So that clients can use their own existing public key. We could even make this field a list so that a client can submit multiple public keys.

I don't like the idea of users generating their own public keys interdependently of our client. At least initially:

1. I expect almost all users are familiar with backup-seeds, and be happy to write one down. They are now used for many services.
2. Having users export a derived private key from one application and import it into another application is something that we really should avoid.
3. In the future we could add the option to authenticate with a hardware device (such as a trezor), in this way a user could use the same backup codes with many different services at the same time.

A client would then be able to signup using a normal password and/or a public key. I do not like the idea of only allowing authentication with public keys, as it might be too confusing to set up for some users. Keeping the option for a traditional password would be a nice fallback for these users.

For many users passwords could be easier, I think that providing this fallback is heading in the wrong direction:

1. It stores user secret data on the sever.
2. If public keys associated with an account is a core feature, it give us the freedom to implement other features that require user-public-keys.

[da2ce7]

@WarmBeer https://github.com/rust-bitcoin/rust-secp256k1 supports compiling to wasm :)

[da2ce7]

@josecelano

The standard: Web Authentication: An API for accessing Public Key Credentials, is probability the closest standard in intention to what this one provides.

https://www.w3.org/TR/webauthn/

[da2ce7]

I think that this document is ready for review. :)

[da2ce7]

ACK 90fb11d43fa9d89276ffb35c3e6e177ea6c6aaff