Innovative authentication methods

Limits of password authentication

According to the survey 2023 Password Decisions Survey led by Bitwarden, traditional email/password authentication mechanisms are no longer sufficient to ensure the security of mobile applications. Here are some key findings from the survey that highlight the limitations and risks associated with password-based authentication:

  1. Password habits at work : 84% of respondents use password management software, but risky practices such as saving passwords on documents on their computer (54%) or relying on memory (45%).
  2. Ways to share passwords : Although 66% of IT decision makers share passwords through a password manager, a significant number also share passwords via emails and online documents.
  3. Reusing passwords : It is important to note that almost all respondents (90%) reuse passwords across multiple sites, which increases the risk if one of the sites is compromised.
  4. Two-factor authentication (2FA) : Although 92% of respondents use 2FA in the workplace, 48% feel that people who are reluctant to use 2FA are not aware of its benefits.
  5. Cyber attacks : The percentage of respondents reporting cyberattacks increased to 60% this year, up from 54% last year.

Mobile applications continue to handle more sensitive data, so taking steps to improve security is crucial. In the rest of this newsletter, we present you with some possible solutions with their advantages and disadvantages!

One Time Passcode (OTP)

A One-Time Passcode, or single-use pass code in French, is a security code that is valid for a single session or a single transaction. This code is often used in 2FA or MFA authentication systems to add an extra layer of security by combining something you know (a password) and something you have (a phone). If the password is compromised, receiving a one-time password via text message can protect the account.

Here is how it works in general:

  • OTP code request : The user is trying to connect to an account or complete a transaction that requires additional authentication. After entering his basic credentials (like a username and password), he asks for an OTP code.
  • OTP code generation : The server generates a unique OTP code. Generating this code is often based on an algorithm that can take into account the current time, date, or other information that is unique to the transaction or session.
  • Sending the OTP code : The OTP code is then sent to the user via a separate communication channel, usually an SMS message on the user's mobile phone, an email, or via an authentication application.
  • OTP code entry : The user receives the OTP code and enters it into the interface that requests it.
  • OTP code verification : The server checks that the OTP code entered by the user corresponds to the OTP code that it generated. If this is the case, the user is authenticated and the transaction or session can continue.


  1. Enhanced security : OTPs provide an extra layer of security over a simple password. Even if an attacker gets your password, they would also need to access your OTP to connect to your account.
  2. Single use : As the name suggests, OTPs are designed to be used only once. This means that a stolen or intercepted OTP becomes useless once it has been used.
  3. Validity limited in time : OTPs generally have a limited validity period, which means that an unused OTP will expire after a certain period of time. This further reduces the risk that a stolen or intercepted OTP could be misused.


  • OTP verification does not offer optimal UX. Indeed, the user must enter their phone number, wait for the SMS to arrive, retype the code, and only then can they continue to use the application. This can be facilitated with the autofill feature that has been available since iOS 12 and Android 8.
  • Vulnerabilities in mobile networks, such as breaches in the SS7 network, can allow attackers to intercept SMS messages containing OTPs.
  • Phishing attacks : While OTPs can help protect against many forms of attacks, they are not effective against phishing attacks. If a user is tricked into entering their OTP on a phishing site, the attacker can then use the OTP to access the user's account.
  • SMS Pumping Attacks : A form of attack where hackers exploit SMS systems connected to online forms or web applications. They use bots to automatically enter premium phone numbers, which can be expensive for businesses that send OTPs. Twitter removed their 2FA because of an annual bill of 60 million.

The NIST (National Institute of Standards and Technology) has also proposed to deprecate the use of SMS as an authentication factor.

Questions... and buzz surrounding draft NIST Special Publication 800-63-3

Time Based One Time Password (TOTP)

The major disadvantage of OTP is the need to send the single-use code via SMS, which is an important attack vector. With TOTP, we can use an authentication application (like Google Authenticator or Duo Mobile) to generate an OTP directly from our phone with a very limited lifespan that changes after a certain period of time (usually every 30 seconds or 1 minute).

Here is how it works in general:

  • Initialization : When TOPT is set up, a shared secret is generated. This secret is then stored both by the service that requires authentication (for example, your application server) and by the user's phone via an authentication application. This shared secret can be transferred via a QR code that the user scans with their device.
  • TOPT Generation : Whenever a TOPT is required, the authentication application uses the shared secret and the current time to generate an OTP.
  • TOPT check : The user enters the TOPT into the service that requires authentication. This service also generates a TOPT based on the shared secret and the current time, and then compares this generated TOPT with the one entered by the user. If the two match, the authentication is successful.
  • Expiry of the TOPT : The TOPT changes with each new time step. This means that a given TOPT is only valid for a short period of time. If a TOPT is intercepted by an attacker, it will be useless after the time has passed.


  • Enhanced security: TOTP's are generated using a shared secret and the current time, making it difficult for an attacker to predict the next password. Additionally, unlike SMS-based OTPs, TOTPs do not rely on the mobile phone network, eliminating the risks associated with SMS interception.
  • Offline: TOTP can be generated even when the device is not connected to the Internet.
  • Pricing : Since we do not depend on a mobile operator, the costs are lower.


  • Third-party application dependency: This can add an extra layer of complexity and be seen as a barrier, especially for less tech-savvy users. Additionally, having to switch between the authentication application and the application or service for which authentication is required can result in a less smooth user experience.
  • Time sync: TOTP's depend on the synchronization of time between the server and the client device. If the clocks are not synchronized correctly, the generated OTP may not be valid.
  • Device loss: If the user loses the device on which the TOTP is generated, he may have difficulty regaining access to his accounts
  • Phishing: Like the OTP, the TOTP is not immune to phishing attacks. If a user is tricked into revealing their OTP to an attacker, the attacker can use the OTP to access the account.

Silent Network Authentication (SNA)

Silent authentication validates that the user's SIM is both actively connected to the mobile network and is not cloned. SNA technology is based on the GSM authentication standard.

Here is how it works in general:

Step 1: The mobile network (also called operator) activates a SIM card with a unique authentication key (known as Ki). This happens when the user receives a new SIM card. Both parties have the unique key, but it is never shared on the network.

Step 2: SNA initiates an authentication challenge. The mobile network sends a 128-bit random number (known as RAND) on the network to the SIM card. From that moment on, the mobile network and the SIM card both know the authentication key (Ki) and the random number (RAND).

Step 3: Both the SIM card and the mobile network use Ki and RAND as entries to a *oDoesn' t function*. The output of the one-way function is a “signed response” (SRES).

Step 4: The SIM card sends its SRES to the mobile network.

Step 5: The mobile network verifies that both SRES match. If they match, the user is authenticated. This form of symmetric key cryptography makes it very difficult for an attacker to tamper with the SRES, making this authentication method both secure and deterministic. SNA has a similar level of security with authentication applications (TOTP) like Authy or Google Authenticator.

Note that a user does not have to do anything or provide input for the SIM card to be authenticated - everything happens in the background.


  • Reduce the friction and complexity of using an SMS or CAPTCHA-based authentication process for customers
  • Don't require users to download an authentication app like Google or Microsoft Authenticator
  • Eliminate form entries that can be used to capture user information


  • Not usable in WiFi mode
  • Only available in some countries
  • Additional configuration is required for dual SIM phones

Push authentication

Push authentication is a two-factor authentication method that uses a trusted device, typically a smartphone, to validate attempts to connect to an account or application. It is an increasingly popular approach that offers both a high level of security and a good user experience.

During the first authentication on the mobile application, you canRegister your device as trusted.

For future connections, the experience varies depending on the device you're using to connect.

  1. Your device: If you connect to the app from your trusted device, there's no need for two-factor authentication. The app recognizes your device and allows you to connect directly.
  2. Another mobile device or website: If you attempt to connect to the app from another mobile device, a push notification is sent to your trusted device. You must accept this notification on your trusted device to allow the connection.

Here is how it works in general:

  1. Authentication request: When a user attempts to log in, an authentication request is sent to the user's mobile device.
  2. Push notification: The user receives a push notification on their mobile device. This notification indicates that someone (hopefully the user himself) is trying to sign in to their account.
  3. Verification: The user verifies the request by pressing a button in the notification, usually marked as “Approve” or “Reject.” The user may also be asked to provide another authentication factor, such as a fingerprint or PIN, to approve the request.
  4. Confirmation: If the user approves the request, a signal is sent back to the service requesting authentication to confirm that the user is who they say they are.

Using a push notification service (FCM, APNS) is not mandatory. A pulling system can be set up. The user must then open the application himself. It is the application that then determines whether it should display a modal to validate a connection or not. This flow is implemented for example by Google through the YouTube or Gmail application.


  1. Increased safety: Phishing attacks are more difficult because authentication is based on an exchange of messages between the authentication server and the mobile application, not on entering a password or a unique code.
  2. Better UX: The user receives a notification and only has to approve or reject the authentication request. This eliminates the need to enter passwords or unique codes.
  3. Fraud detection: Users are immediately alerted to unauthorized access attempts to their account, as they receive a notification every time they request authentication. A click on the refused button should alert more than an incorrect OTP that could be due to a typo.
  4. Pricing : Since we do not depend on a mobile operator, the costs are lower.


  1. Notification risks: Notifications are not delivered in 100% of cases. On the other hand, the user may not see them, either due to inattention or because of the configuration of the phone. The authentication may then fail. The implementation of the pulling system is therefore recommended in addition to the push notification system.
  2. Lower coverage of supported use cases compared to the OTP:

WebAuthn (iOS PassKey - Android FIDO2)

Web authentication (WebAuthn) is a web standard published by the World Wide Web Consortium (W3C). The aim of the project is to standardize an interface for authenticating users to web-based applications and services using public key cryptography.

This standard has been implemented on the mobile side:

  • For Android applications, developers can use the Android FIDO2 API, which offers WebAuthn methods for generating and attesting public key identifiers, as well as for authenticating themselves with these identifiers.
  • For iOS applications, Apple developed the PassKey feature, which can be accessed from iOS 16

Let's pass the technical jargons and see how Payfit uses this tool on iOS to allow us to connect to their application:

  1. The user navigates the site and enter his email
  2. Instead of entering their password, the user is invited to use their FaceID or TouchID to confirm their identity

Thanks to FaceID, the user retrieves their PassKey and uses it to connect to Payfit.

This PassKey was created when the user's account was created, or during post-login onboarding when the feature was deployed in production as was the case for Payfit.The PassKey is either saved locally or on another Apple device synchronized with iCloud and is used by the OS to confirm the identity of the user.

The passkey is accessible and shareable in settings > password.

The way WebAuthn works is complex. To avoid extending this newsletter, which is already (let's face it) too long, we invite more curious people to consult:


  1. Enhanced security thanks to the use of asymmetric cryptography algorithms.
  2. Phishing resistance: Since WebAuthn does not require the sharing of secret identification data and ensures that the website is the same during registration and authentication, it is resistant to such attacks.
  3. Passwordless authentication: WebAuthn allows users to authenticate using biometrics, mobile devices, or FIDO security keys, eliminating the need for passwords.
  4. Interoperability: WebAuthn is a web standard, which means it provides a standard that different platforms comply with.


  1. If your user loses their phone, which they use for WebAuthn authentication (biometrics, security key, etc.), they will not be able to authenticate themselves on your platform until they regain access to their device. This is a potential downside to strong two-factor authentication, but there are several ways to handle such situations:
  2. Emergency codes: During the initial setup of two-factor authentication, you can provide users with backup codes. These codes can be printed or written and stored securely offline. If a user loses their device, they can use one of these codes to authenticate themselves.
  3. Backup authentication method: Allow your users to configure more than one authentication method such as OTP or magic links.
  4. Account recovery process: Have a robust account recovery process in place. This could involve contacting customer support, verifying identity by other means (like email or security questions), or even verifying personal identity documents in some cases.
  5. Implementation complexity: Implementing WebAuthn can be complex and requires a good understanding of public key cryptography and the standard.
  6. “Too” innovative : This system is not adapted to all personas. It will be better received by early adopters and techies.
  7. OS compatibility : This technology is still very young, and only available as of iOS 16. It may be adopted on a larger scale in the years to come.

Magic Link

Magic Link authentication is an authentication method that allows users to connect to an account or application by clicking on a link generated and sent by email or text message. When a user clicks on the Magic Link, they are automatically authenticated and accesses their account by entering only their email.

General operation

The operation is quite similar to that of OTP authentication:

  1. The user requests a connection to the application by entering his email
  2. The application generates a MagicLink and transmits it to the email or SMS service.
  3. The email or SMS service sends the magic link to the user.
  4. The user clicks on the magic link.
  5. The application validates the magic link and authenticates the user.


  • Simplicity and usability for users.
  • Fast and effortless login experience.
  • Eliminates the need to remember and reset passwords
  • Easy to implement and integrate with existing applications.


  • Depends on the security of the email or phone number used to send the magic link.
  • Security risks if Magic Links are intercepted.
  • Unauthorized access may occur if the email or phone number is compromised.
  • May not be suitable for all scenarios, especially when higher levels of security are required or where specific regulatory constraints are in place.

Best Practices

  1. Expiration: MagicLinks should expire after a certain period of time and should only be used once to minimize the attack window
  2. Threshold: to prevent an attacker from sending bulk Magic Link requests.
  3. Two-factor authentication (2FA): Consider adding an additional layer of security, such as 2FA, especially for sensitive actions in the application.

What would that look like applied to a BAM project? The Younited example

Last year, BAM helped Younited Credit launch its mobile application.

As a reminder, Younited Credit is a start-up that simplifies the credit application experience and helps its users to borrow very quickly. For example, if you have just dropped your latest iPhone in the water and it is burnt out or if you want to buy a car because you are expecting 2 babies, Younited promises you an answer to your credit request almost immediately!

Obviously, as soon as we talk about bank accounts and loans, we expect a very thorough authentication. Beyond a moral duty, it is a “marketing” obligation of Younited.

I won't mention my favorite stat: “On average, a user manages 100 different passwords and spends 13 minutes PER WEEK resetting them” (White Paper: 7 Things You Need to Know About Passwordless Authentication - Auth0, 2021). But it does illustrate the need for businesses to simplify authentication.

One could imagine that Younited Credit decides to detach itself from the password, and for its log-in, only asks for the email address of the user's account. To authenticate it, he could send an email with a link that expires at the end of the user's session.

Thus, when arriving on the app, the user enters his email address (an identifier that he is not likely to forget). This triggers the sending of an email. In 3 clicks, there is access on your device. When the link is clicked, the user is redirected to the app via a clever magic link. It opens and it is automatically authenticated. When he finishes his session on the app, he is automatically “disconnected”. And the link is deactivated.

The user benefits from a secure experience (apparently thanks to an “ephemeral” link and in reality), while avoiding the friction of log-in with a complicated password.


We encourage you to go beyond simple password authentication and to consider these methods as ways to explore in your future projects. By seeking innovative solutions, we will be able to offer our users a secure and seamless experience, while strengthening the trust they place in our applications.

Let's not forget that security is a crucial issue in the development of mobile applications, and that it is our responsibility to stay up to date with market standards.

Product Owner ?

Rejoins nos équipes