1. Introduction

2. Related Work

3. Methods

3.2. Implementation

3.2.1. Pre-Installation

To prevent an adversary-in-the-middle attack, SSL/TLS certificates are generated from an open-source certificate authority - letsencrypt.org[9] on the BE, and the certificate’s public key is hardcoded on the FE. This ensures that the communication between the FE and BE is always authenticated. The BE then generates a separate 4096-bit RSA key pair using the native Nodejs crypto module[10] to be used for encrypted communication.

3.2.2. Installation

At the initial download of the SA app on either an Android or iOS device, the RN library “react-native-RSA-native”[11] is used to generate a 2048-bit RSA key pair. In addition, the “crypto-es” library[12] is also used to generate a 256-bit symmetric key. Further, a device notification ID (DN-ID) is generated using functionality provided by the RN library [13]; DN-ID is used to identify a specific device during authentication requests. To overcome the failings of shared secrets in authentication systems, the keys are stored securely on the user’s device. React Native provides the app with an encrypted storage area on the device, such that the cryptographic keys cannot be extracted [14,15].

As shown in Figure 2, public keys are exchanged in the first connection of the app to the BE, as well as the DN-ID; the app’s public key and DN-ID is saved to the database as the unique ID for that app, while the server-generated public key is saved to local storage on the app. Private keys are never exchanged during this process. All requests from the app to the server are identified using the app’s public key. The server also generates a unique ID to be associated with the user’s typing pattern (TP), encrypts it with the app’s public key, and sends it to the app.

3.2.3. Post-Installation

• SA User registration (SAUR)

• The user is presented with the typing behaviour capture screen, where their TP is recorded by the TypingDNA library implemented on the page. Before this data is sent to the server, biometric authentication is requested on the user’s device by prompting for either a fingerprint or face ID, depending on that which was previously set up by the user. The SA app is designed to work only on devices with biometric authentication capability. Once the user’s biometric information is confirmed, along with the unique ID received during the installation stage, the TP is encrypted with the server’s public key, and sent to the server for onward transmission to TypingDNA’s API to be recorded. The TP is then identified for that user via the unique ID. The user is prompted to enter a predefined text (their email address) a minimum of three times to ensure that enough patterns are captured to be able to create a model for the user[16].
  As depicted in Figure 3, once a response from the API signals that enough patterns have been received to verify the user, the unique ID is then saved as the user’s typing ID along with the app public key in the database. The user is subsequently routed to ALS.

  

  Figure 3. SA User typing behaviour capture

  Figure 3. SA User typing behaviour capture

  

• Account registration (e.g. an e-commerce website - "Ecom") Before a user can add an account to the app, the service (hereafter referred to as “Ecom”) they wish to add must have implemented the SA scheme. This is achieved by Ecom creating authenticated API endpoints on their server to receive requests from the SA server. With this implementation, usernames are associated with public keys rather than passwords. This ensures that if Ecom is breached, they hold a database of public keys rather than passwords or hashes, and usernames. The registration flow for new Ecom users differs from that of existing password-based users migrating to passwordless authentication and is described below.
  • New Ecom User Registration (NEUR)

    −

    User visits the Ecom website, creates an account according to Ecom’s process and selects the passwordless authentication option.

    −

    The username is sent from Ecom to SA server, through Ecom’s server as shown in Figure 4; requests from Ecom’s website to SA server are rejected by default. The communication between Ecom’s server and SA server are always authenticated.

    

    Figure 4. Ecom new user passwordless authentication registration flow

    Figure 4. Ecom new user passwordless authentication registration flow

    

    −

    SA server generates a unique registration ID for the username and serves it as a response to the Ecom server’s request.

    −

    Ecom delivers the unique registration ID to the user embedded in a download link of the SA app.

    −

    When the user downloads and launches the app; the process described in Section 3.2.2 occurs. In addition, a 2048-bit RSA key pair is generated for the account. Each account on the SA app has a key pair separate from the key pair of the app.

    −

    The user is automatically routed to the NAS with the service name (Ecom) and username pre-filled. The user then needs to upload an image where the public key for that account and their typing ID will be embedded. When they click on the option to add the account, biometric authentication is requested by prompting the user for their fingerprint or face-ID.

    −

    On successful biometric authentication, the SA app sends the app public key, account public key, registration ID, and image file to the SA server. The server extracts the typing ID previously saved to the app public key (as described in section 3.2.3 - SAUR), encrypts it with the server private key, and embeds the encrypted typing ID and account public key in the image provided using steganography. The stego image is then sent to the user with a prompt to save it off the device for account retrieval purposes. The stego image is not saved in the database.

    −

    The SA app updates the accounts list with an entry for that service and username.

    −

    The SA server saves the account public key and username in the database, and it is matched to the public key for the app. The database has a mapping of accounts to an app, such that an app public key can hold multiple account public keys.

    −

    The SA server delivers the account public key and username to the Ecom server.

  • Existing Ecom User Registration - services that have implemented SA is listed as an option that can be selected on the NAS in the app. An existing user registers an account following the steps described below:

    −

    The user selects Ecom from a dropdown list on the NAS.

    −

    They provide their Ecom username and image in the input fields; when the user clicks the option to add the account, biometric authentication is requested by prompting the user for their fingerprint or face-ID.

    −

    On successful biometric authentication, a 2048-bit RSA key pair is generated for the account.

    −

    The process from item 7 of the NEUR section then occurs. Since this is an existing Ecom user, as shown in Figure 5, no registration ID is included as part of the data sent to the SA server.

    

    Figure 5. Ecom existing user passwordless authentication registration flow

    Figure 5. Ecom existing user passwordless authentication registration flow

    

3.2.4. Image Steganography

Steganography provides the ability to hide data such that the existence of the data is unobvious[17]. The image uploaded during account creation by the user is the medium where the credentials for that particular account are stored, to be provided by the user via upload when there is a need to restore that account. The JavaScript code excerpts shown in Figure 6 describe the logic and process of embedding the credentials of an account in the image provided by the user for that account using Nodejs:

• The image is converted into its binary format using the Jimp library[18].
• The user’s typing ID (associated with their typing pattern) is encrypted using the server’s public key. The public key for that account and the encrypted typing ID are then converted to their binary format. Each data is then joined into a long string of bits, as conversion to their binary format produces an array of bytes.
• Each bit from the string of bits from each group is then embedded into the image bytes using the least significant bit (LSB) steganography method. LSB involves replacing the right-most bit of each image byte with another bit from the data to be hidden[19]. The implication of this is that the number of bytes in the image must be at least the sum of all bits to be embedded.
• Once all the bits have been embedded in the LSB of the image, the new image is then reconstructed using the Jimp library; the new and original image will have no visual difference at the end of this process.

Figure 6. Embedding Account Public Key In Image Using LSB Steganography

Figure 6. Embedding Account Public Key In Image Using LSB Steganography

Considering that the LSB method can be detected if an adversary is aware that steganography was employed, the goal of this method is not detection prevention, as the public key is not a secret and the typing ID is encrypted; it is intended to offer ease of account recoverability. While users are allowed to reuse the same image for different accounts, only the original image is allowed; images pre-embedded with account details cannot be reused for another account. If a user uses the same image for all accounts, each image will be named differently. Users are also allowed to change the image name, provided they are able to identify which image belongs to which account.

4. Results

5. Evaluation and Discussion

As evident in Tables 1 to 4, SA presents a notable advancement over memory-based passwords; however, it falls short of some of the framework’s criteria. Realistically, achieving an ideal state may prove challenging in certain aspects, given that passwords themselves, as well as other existing passwordless alternatives (e.g. FIDO2) lack several of the benefits outlined in the framework. On the contrary, we submit that the benefits offered by the system are adequate to position it as a feasible passwordless authentication system.

Table 1. Evaluating SA using Bonneau et al. Usability Framework.[2]

Table 1. Evaluating SA using Bonneau et al. Usability Framework.[2]

Framework Benefit	Sesame Auth (SA)
Memory Wise-Effortless	Account credentials are stored on the device and the user does not have to remember secrets.
Scalable-for-Users	SA can handle hundreds of accounts without any cognitive load on the user.
Nothing-to-Carry	SA depends on an existing owned device and does not require the purchase of new hardware.
Physically-Effortless	The authentication process requires typing in a challenge code, ranking it low on this benefit.
Easy-to-Learn	Users can quickly learn to use SA as it is designed to work as a regular mobile app.
Efficient-to-Use	Account creation and authentication times aggregated are under 4 seconds, making it acceptably short.
Infrequent-Errors	Login is dependent on supplying the exact challenge code generated by the SA server and providing biometric authentication on the device. Therefore, there are no errors if these criteria are satisfied.
Easy-Recovery-from-Loss	Account recovery simply involves uploading an image and typing in an email address, making it this benefit high.

Table 2. Evaluating SA using Bonneau et al. Deployability Framework.[2]

Table 2. Evaluating SA using Bonneau et al. Deployability Framework.[2]

Framework Benefit	Sesame Auth (SA)
Accessible,	A user who can use passwords can also use SA.
Negligible-Cost-per-User	There is some negligible-fixed cost incurred in implementing SA.
Server-Compatible	SA is compatible with text-based passwords; the server simply swaps out the authentication logic.
Browser-Compatible	SA is browser-agnostic as users do not need to install any browser plugins/software for it to be compatible.
Mature	SA is a proof-of-concept; it has not yet been deployed on a large scale. Therefore, it is low on this benefit.
Non-Proprietary	SA is proprietary, as implementers have to pay some negligible royalty.

Table 3. Evaluating SA using Bonneau et al. Security Framework.(a)[2]

Table 3. Evaluating SA using Bonneau et al. Security Framework.(a)[2]

Framework Benefit	Sesame Auth (SA)
Resilient-to-Physical-Observation,	An attacker cannot impersonate the user by physically observing them during authentication using SA.
Resilient-to-Targeted-Impersonation	An attacker cannot impersonate the user on SA by having any knowledge of the user’s personal data.
Resilient-to-Throttled-Guessing	In a rate-limited scenario, an attacker cannot guess the 2048-bit RSA private keys for SA. Further, the challenge code is a cryptographic pseudo-random number that has a 1:1000,000 relationship.
Resilient-to-Unthrottled-Guessing	Constrained only by computing resources, it is computationally infeasible to guess 2048-bit RSA keys. Further, the attacker would need physical access to the user’s device, making SA high on this benefit.

Table 4. Evaluating SA using Bonneau et al. Security Framework.(b)[2]

Table 4. Evaluating SA using Bonneau et al. Security Framework.(b)[2]

Framework Benefit	Sesame Auth (SA)
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.
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.
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.
Resilient-to-Theft	Where the user’s device is stolen, an attacker cannot access the account as biometric authentication is required to complete login.
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.
Requiring-Explicit-Consent	Authentication cannot be done without the user’s consent and knowledge, making it resistant to MFA fatigue.
Unlinkable	The user’s privacy is preserved as each account has a unique keypair, making this benefit high.

6. Conclusions

References

1. Oduguwa, T.; Arabo, A. A Review of Password-less User Authentication Schemes, 2023, [arxiv:cs/2312.02845]. Comment: 6 pages, submitted to Internet Technology Letters, 6: Comment. [CrossRef]
2. Bonneau, J.; Herley, C.; van Oorschot, P.C.; Stajano, F. The Quest to Replace Passwords: A Framework for Comparative Evaluation of Web Authentication Schemes. 2012 IEEE Symposium on Security and Privacy, 2012, pp. 553–567. [CrossRef]
3. Jadhav, C.; Kulkarni, S.; Shelar, S.; Shinde, K.; Dharwadkar, N.V. Biometric Authentication Using Keystroke Dynamics. 2017 International Conference on I-SMAC (IoT in Social, Mobile, Analytics and Cloud) (I-SMAC). IEEE: Palladam, India, 2017. [Google Scholar]
4. Conners, J.; Devenport, C.; Derbidge, S.; Farnsworth, N.; Gates, K.; Lambert, S.; McClain, C.; Nichols, P.; Zappala, D. Let’s Authenticate: Automated Certificates for User Authentication. Proceedings 2022 Network and Distributed System Security Symposium. Internet Society: San Diego, CA, USA, 2022. [Google Scholar] [CrossRef]
5. Eisenman, B. Learning React Native : Building Mobile Applications with JavaScript., first edition. ed.; Beijing, China : O’Reilly, 2016.
6. Teh, P.S.; Teoh, A.B.J.; Yue, S. A Survey of Keystroke Dynamics Biometrics. The Scientific World Journal 2013, 2013, e408280. [Google Scholar] [CrossRef] [PubMed]
7. TypingDNA. About Us - TypingDNA. https://www.typingdna.com/about.
8. Node.Js — About Node.Js®. https://nodejs.org/en/about.
9. Encrypt, L. Let’s Encrypt. https://letsencrypt.org/.
10. Node.js. Crypto | Node.Js V21.2.0 Documentation. https://nodejs.org/api/crypto.html.
11. amitaymolko. React-Native-Rsa-Native, 2017.
12. entronad. CryptoES. https://www.npmjs.com/package/crypto-es, 2022.
13. Expo. Send Notifications with FCM & APNs. https://docs.expo.dev/push-notifications/sending-notifications-custom.
14. Google. Android Keystore System | App Quality. https://developer.android.com/privacy-and-security/keystore.
15. Apple. Keychain Services. https://developer.apple.com/documentation/security/keychain_services.
16. TypingDNA. API Documentation - TypingDNA. https://api.typingdna.com/docs/index.html#api-API_Services-Advanced-saveUserPattern.
17. Taha, M.S.; Rahim, M.S.M.; Lafta, S.A.; Hashim, M.M.; Hassanain, M.A. Combination of Steganography and Cryptography: A Short Survey. IOP Conference Series. Materials Science and Engineering 2019, 518. [Google Scholar] [CrossRef]
18. Jimp. Jimp. https://www.npmjs.com/package/jimp, 2023.
19. Jebur, S.A.; Nawar, A.K.; Kadhim, L.E.; Jahefer, M.M. Hiding Information in Digital Images Using LSB Steganography Technique. International Journal of Interactive Mobile Technologies (iJIM) 2023, 17, 167–178. [Google Scholar] [CrossRef]
20. Tran, D.; Zepernick, H.J.; Chu, T. LSB Data Hiding in Digital Media: A Survey. EAI Endorsed Transactions on Industrial Networks and Intelligent Systems 2022, p. 173783. [CrossRef]
21. Stark, E.; Hamburg, M.; Boneh, D. Symmetric Cryptography in Javascript. 2009 Annual Computer Security Applications Conference; IEEE: Honolulu, Hawaii, USA, 2009; pp. 373–381. [CrossRef]