This section describes the supported authentication methods in detail. We note that the server implements rate limiting for all authentication methods to ensure that malicious strong attackers cannot guess the values by brute-force. Typically, a user is given three attempts per hour to enter the correct code from 2^63 possible values. Transmitted codes also come with an expiration date. If the user re-requests a challenge to be sent, the same challenge may be transmitted (with the three attempts counter not increasing!) for a limited period of time (depending on the authentication method) before the service eventually rotates to a fresh random code with a fresh retry counter. Given the default value range and time intervals (which providers are at liberty to adjust), brute-force attacks against this are expected to succeed with a 50% probability after about 200000 years of attempts at the maximum permissible frequency.
Sends an SMS with a code (prefixed with A-) to the user’s phone, including
a UUID which identifies the challenge the code is for. The user must send
this code back with his request (see $RESPONSE under Managing truth).
If the transmitted code is correct, the server responses with the requested
encrypted key share.
Sends an email with a code (prefixed with A-) to the user’s mail address,
including a UUID which identifies the challenge the code is for. The user
must send this code back with his request (see $RESPONSE under Managing truth).
If the transmitted code is correct, the server responses with the
requested encrypted key share.
Requires the user to identify via video-call. In the video-call, the
user is told the code (prefixed with A-) needed to authenticate.
The user is expected to delete all metadata revealing personal information from the images before uploading them. Since the respective images must be passed on to the video identification service in the event of password recovery, it should be ensured that no further information about the user can be derived from them.
Video identification will typically result in the Anastasis provider requesting the user to be redirected to a Web site (or other URL) for the video-call.
Asks the user a security question. The user sends back a salted hash over the answer. The question-salt is stored encrypted as part of the recovery document and never revealed to the providers. This ensures that providers cannot derive the answer from the hash value. Furthermore, the security question itself is also only in the recovery document and never given to the Anastasis provider. A moderately expensive hash function is used to further limit strong attackers that have obtained the recovery document from brute-forcing the answer.
If the hash value matches with the one the server is expecting, the server answers with the requested encrypted key share. However, unlike other encrypted key shares, the encrypted key share of a security question uses a special variation of the Anastasis encryption: Here, a different hash function over the security answer is used to provide an additional key-salt for the decryption of the (encrypted) key share. This ensures that the key share remains irrecoverable without the answer even if the Anastasis provider storing the security question is malicious.
Sends physical mail (snail mail) with a code (prefixed with A-) to the
user’s mail address, including a UUID which identifies the challenge the code
is for. The user must send this code back with their request (see
$RESPONSE under Managing truth). If the transmitted code is correct,
the server responds with the requested encrypted key share.