---
3ip: 6
title: Authentication Methods
author: oed@3box.io
discussions-to: https://chat.3box.io
status: Draft
created: 2019-05-10
requires: [3](./3ip-3.md)
---
Currently authentication in 3Box is done by signing a message with an Externally Owned Account (EOA). This 3IP describes how additional authentication methods can be added to a users 3Box.
Signing a message with an EOA is great a great way to do authentication with a simple ethereum wallet. However, as more wallets are starting to use contract wallets this authentication method will not be as simple anymore. Moreover 3Box should enable a 3Box account to have multiple authentication methods, for example a user might want to be able to authenticate with two different ethereum addresses on two different devices. To enable this we add a standard way of storing an encrypted secret in a users 3Box. Decrypting this secret gives the user access to the seed used to generate the 3ID used to control the users 3Box.
Adding multiple ways of authenticating to a 3Box is crucial to make the 3Box protocol more usable. The way new authentication methods are added needs to be standardized in a way where it's easy to extend with new ones.
Currently a 3Box is authenticated by signing a message and using the entropy of this message to generate the seed of the users 3ID. It's not possible therefore to have signatures of multiple different keys end up with the same 3ID seed. However, we can encrypt a users seed to an encryption key derived from a signature. If we do this for multiple different signatures from different keys we can in this way add multiple authentication methods. A problem arises with spaces. Right now spaces requires the user to sign a new message for each space that they are opening. This would be troublesome since a new authentication method would need to sign a new message for every space, in addition if a new space is added using one auth method it would need to be migrated to the other authentication methods which can quickly escalate to a lot of signatures. Instead this 3IP assumes that we use 3IP 3 already. In 3IP 3 we specify how to derive space specific keys using a single seed, which solves the issue described above.
Here we provide an example of how to derive an encryption key from a signature. Different authentication methods might use different ways of deriving the encryption key.
Below is some pseudo-code describing the process
signature = getSignature()
entropy = sha256(signature)
encryptionKey = Uint8Array(entropy)
The encryption key can now be used in with the tweetnacl library to encrypt data.
A new authentication method can be added by encrypting the secret seed of the 3ID to an encryption key. This encrypted data is then stored in a users rootstore using the format below.
{
type: 'auth-data',
ciphertext: <the ciphertext of the encrypted seed>,
nonce: <the nonce>
}To authenticate a user to a 3Box first derive the encryption key using the preferred authentication method. Now get all entries in the rootstore and filter by type = 'auth-data', this will give us an array of encrypted seeds. Using the encryption key simply try to decrypt each entry in the array until the correct one is found.
The main design choice here is storing the authentication data as encrypted blobs in the rootstore. This makes sense because the rootstore is the first DB that is fetched when opening a users 3Box, so it makes the data available quickly. There is a small drawback that if there are multiple authentication data blobs one needs to decrypt all of them when authenticating. This could be fixed by adding an additional property that specifies the auth method. However, this would leak some information about the user, and testing decryption on multiple blobs is cheap.
This shouldn't need any additional work to be backwards compatible.
No implementation is yet available for this 3IP.
Copyright and related rights waived via CC0.