## 6 Limitations and Challenges in Passkeys
### Improvements
#### 6.2.1 Technical Improvements  
From a technical perspective, passkeys bring numerous improvements, both for individual users and for users in the context of enterprise environments [16]. First, because passkeys are based on public-key cryptography, they are considered more secure than classical passwords as they do not rely on the user choosing a secure and long password [4; 14]. Instead, the generation of a secure and randomized private-public key pair is performed on the device that generates the passkey without any user choices involved in the key pair generation. This is much more secure than any password authentication, as long as the private key is kept secret [16]. It has been proven that using public-key cryptography (in this case, with passkeys) is a very secure form of authentication [93]. Current research has also already started the process of developing and standardizing FIDO2 implementations that use public-key cryptography that is quantum-secure and thus future-proof [97]. Since a corresponding website or service that wants to authenticate a user only obtains the public key, a user needs to put less trust in the respective service. A leak of this public key gives an adversary no kind of information and does not allow for retrieving any information about the private key counterpart [29]. Furthermore, current password authentication methods store hashed passwords, which are still vulnerable to cracking given enough computing power [56]. Users often choose weak or reused passwords, making this hash cracking more trivial [2; 83]. Salting, peppering, or using slow hash functions provide some protection but do not fully address the trust issues with password-based authentication [98; 99]. Using passkeys removes the need to trust the service provider completely. Furthermore, passkeys allow for the generation of a new unique key pair for every service that requires authentication, further strengthening passkey authentication [6]. Another critical point is that passkey authentication is achieved without sending the private key anywhere. The service sends a challenge to the user who wants to authenticate, which the user then solves and signs using the private key on the local device [8]. The challenge is then sent back to the service, which can then confirm the user's authenticity using the corresponding public key. No private or secret information regarding the key pair is therefore leaked in a correctly implemented process [29]. Similarly to the previous point, this allows a user to put less trust in the service, as there is no need for trusting the service of handling secret information securely during the authentication process. For passwords, this is entirely different. While different protocols exist that do not require sending the password to the service, like, for example, Password-Authenticated Key Agreement (PAKE) in Ref. [100], the majority of corresponding services do not implement this [101]. Additionally, the user cannot quickly check if the service utilizes this form of password authentication or whether it was implemented correctly, etc. [102]. Passkeys bring another technical advantage from a user perspective as follows: since the authentication does not involve sharing the private key, phishing a user's authentication credentials becomes a lot harder [39]. We note that there exist potential phishing attacks, for example, presented in [77; 82] or [30], and a compromised device will still allow the private key pair to be stolen, but this involves a lot more technical steps from the attacker's perspective [16]. Most importantly, however, it is no longer possible to set up a fake website that resembles a legitimate website and then attempt to trick users into entering theirpassword, for example, by sending them a fraudulent email as the passkey is different for each website [82].