⚠️: please send a pull request if you find any security risks that are not listed here

In the context of public key cryptography, the user's public key is registered and stored on a service's database. When a user logs in, they must answer a challenge that is generated by the service for the private key that corresponds to the stored public key.

If the user were to lose their private key, they would no longer be able to answer the challenge which means that they would no longer be able to prove that they are the owner of the public key that is stored on the service's database.

On top of losing the ability to prove that they are the owner of the public key, the user would also lose the ability to access all the services tied to the public key.

Saving the private key is the simplest solution to this problem. The actual implementation of this solution is not very important. as it can be done in many different ways (e.g. saving key file, printing key on paper, etc). This solution depends on the user's ability to store the key properly and in a secure location.

On the other hand, if user's private key were to be stolen, the attacker would be able to answer the challenge and gain access to the user's account.

On top of losing the ability to prove that they are the owner of the public key, the user would also lose the ability to access all the services tied to the public key.

It is important to educate the user on the importance of keeping their private key safe. This includes diffrientiating between the public key and the private key and explaining the consequences of losing the private key. Another important point to make is that the private key is the only thing that is needed to gain access to the user's account. This means that the user should not share their private key with anyone, not even with the service that they are registering with.

A good starting point would be to gather some learning points from other projects that also use public key cryptography - the blockchain space is a great place to start.

Assuming that this project is secure, the only way that the key could be stolen would be if the user were to store a backup of their key in a insecure manner (e.g. on a cloud storage service).

To mitigate this, the user should download their private key in an encrypted format using a password that they provide. This way, if the key were to be stolen, the attacker would not be able to decrypt the key and gain access to the user's account.

Another option would be break the key into multiple pieces and store each piece in a different location. This way, if the key were to be stolen, the attacker would not be able to gain access to the user's account (see the Horcrux Protocol).

note: this security risk is address with the help of the friendship bracelet

Let's assume that:

• verifier - example.com is a web shop service that allows registered users to purchase items from the shops list of products.
• claimant - Alice is interested in purchasing some items from the web shop.

During the login process in a legitimate service, Alice performs the challenge-response which allows the service to verify that she is who she is claiming to be (a registered user) but it does not allow Alice to verify that she has 'registered' to the service and established terms of engagement prior to the current login interaction.

This means that Alice can engage with an illegitimate service (one that she hasn't registered to) without ever knowing. This can lead to a number of security.

The goal of ssasy is to provide a usable and secure user authentication experience. This comes with some constraints:

• verifiers have the potential to accumulate and store information. This is achieved by storing user information in databases, for example.
• claimants do not have the potential to accumulate and store information. This is because of multiple reasons.
  • users my have the authenticator on multiple devices and synchronizing over cloud brings it's own security risks
  • tracking the number of registered services increases the cognitive effort of the user which can negatively impact the security of their authenticator

When registering with a service, claimants provide their public key to the service and once they successfully conduct the challenge-response ritual, they are registered with the service. Afterwards, all they have to do when logging is hand over their public key and answer the challenge.

However, the way things are set, the claimant is not able to store any information other than their private key. This means that they are not able to keep track of all the services that they have registered with which has some potential security implications.

Note: this is a very simple example of a phishing attack that could be carried out by a malicious actor

Let's look at a potential phishing attack that could be carried out by a malicious actor.

1. Alice registers to example.com with her public key
2. example.com generates a challenge to verify that Alice is in control of her public
3. Alice solves the challenge
4. example.com verifies the challenge and registers Alice if the solution is valid

1. Alice provides her public key to example.com
2. example.com verifies that the public key provided by Alice has been registered
3. example.com generates a challenge and sends it to Alice
4. Alice solves the challenge and returns the solution to example.com
5. example.com verifies the solution and returns a confirmation if the solution is valid
6. Alice selects some items and then purchases them
7. example.com accepts Alice's payment and fulfills the order

1. Bob creates a phishing website, exampl3.com, that is identical to example.com
2. Alice lands on exampl3.com, assuming that it is example.com
3. Alice provides her public key to exampl3.com for the purpose of logging in
4. exampl3.com conducts the challenge-response as though Alice is a registered user and logs her in successfully
5. Alice does not know that she has successfully logged into a service that she has never registered to
6. Alice selects some items and then purchases them
7. exampl3.com accepts Alice's payments but does not fulfill the order

The user sets up a file with a list of public keys belonging to all the services that they have registred to. Although this is the simplest solution to this problem, it has some implications:

• This is not a very good solution because it is not very user friendly and it is not very secure. The user has to manage another piece of information on top of their private key.
• Also, if the claimant has ssasy installed on multiple devices, they have to keep track of all the services that they have registered with on all of their devices (preferably without cloud storage which has its own set of security risks).

This was decided to be the best solution to this problem. Find out more about the conrete implementation here

The user creates a 'friendship bracelet' that is unique to the claimant and the service. The bracelet is verifiable by the claimant and it is stored with the user's public key during the registration phase.

Whenever, the user logs into the service, they can demand that the service provide the friendship bracelet. If the bracelet is not provided or not valid, the user can assume that they never registered with the service in the first place and that they are probably being phished.

This solution is more user friendly and it is more secure than the previous solution because it does not require the user to manage another piece of information on top of their private key. However, it does have some implications:

• if the service is compromised, an attacker could potentially steal the friendship bracelets and use it to impersonate the service and phish the claimant.

The digital signature needs to meet the following requirements:

• unique to the claimant and the service
• protected from tampering
• verifiable by the claimant

In order to meet these requirements, the following steps need to be taken:

1. verifier generates a challenge for the claimant
2. claimant generates a response to the challenge and then signs it with their private key
3. verifier verifies the signature and the solution to the challenge, confirming that the claimant is the owner of the public key that they have provided

Once the steps above are completed, the verifier can provide the claimant's signature along with future challenges. This way, the claimant can verify they have registered with the service in the past which means that they are not being phished.