# Passwordless Authentication Using a Combination of Cryptography, Steganography, and Biometrics
## 5 Evaluation and Discussion
### Threat Analysis and Mitigation  
This section identifies the risks that may compromise the integrity and security of authentication systems, as well as measures taken by SA to prevent these risks from materializing.  
* Phishing (user visits the fraudulent representation of a listed service)--SA does not involve shared secrets; therefore, users can only provide public usernames, which alone do not provide access to the account.
* Malware on user device--Secret keys are stored in the trusted execution environment (TEE) of the device and are as secure as the strength of the device TEE implementation.
* Physical access to the user device by an attacker --Authentication requires biometric confirmation; therefore, the attacker also requires the user's physiological biometrics. Further, cryptographic keys are prevented from being extracted by the device security measures [24, 25].
* MITM during initial registration--Certificate authorities provide digital signatures for the SA app and server public keys.
* Malicious version of the SA app--The malicious app is unable to communicate with the true SA server and, therefore, cannot impersonate the user.
* SA server database attack--The SA server only stores public keys, while private keys are stored in environment variables; therefore, account impersonation is prevented. However, if the database is modified, it might lead to a denial of service for users.
* Real-time MITM attacks--All communications between the SA app and server, and between SA and the service (e.g., Facebook), are end-to-end encrypted over HTTPS.
* Keylogging--No secrets are entered into the app during its operation; therefore, this does not yield any data for attackers to impersonate the user.  
In our study, we evaluated our proposed SA system against the criteria set forth by [PERSON] et al. These criteria encompass three main factors: usability (Table 1), deployability (Table 2), and security (Table 3). Our analysis provides compelling evidence that SA  
\begin{table}
\begin{tabular}{p{142.3 pt} p{142.3 pt}} \hline \hline
**Framework Benefit** & **Sesame Auth (SA)** \\ \hline Resilient-to-Internal-Observation & All communications are encrypted; therefore, an attacker cannot impersonate a user by observing network traffic. Further, SA cryptographic keys are stored in the devices’ secure area isolated from the rest of the system, making them resistant to malware on the device. \\ \hline Resilient-to-Leaks-from-Other-Verifiers & An attacker cannot impersonate the user due to data breaches at the service, as the service stores usernames and public keys rather than secrets. \\ \hline Resilient-to-Phishing & Since no secrets are shared between the SA server and service, it is resilient to phishing as an attacker can only harvest publicly available data from a phishing campaign. \\ \hline Resilient-to-Theft & Where the user’s device is stolen, an attacker cannot access the account as biometric authentication is required to complete login. \\ \hline No-Trusted-Third-Party & Compromise of the SA server can lead to user impersonation as malicious data is sent to the service; therefore, it is low on this benefit. \\ \hline Requiring-Explicit-Consent & Authentication cannot be carried out without the user’s consent and knowledge, making it resistant to MFA fatigue. \\ \hline Unlinkable & The user’s privacy is preserved as each account has a unique keypair, making this benefit high. \\ \hline \hline \end{tabular}
\end{table}
Table 4: Evaluating SA using Bonneau et al. security framework (b) [2].  
successfully fulfils all the specified criteria. Notably, SA effectively addresses the identified shortcomings associated with passwordless authentication, as outlined in [PERSON] et al.'s framework.