Passwords in 2022

It’s time to talk about something important: the security of user accounts in your application. At Google I/O 2022, Eiji Kitamura gave multiple solutions to protect user accounts. He also talked about passwordless logins. Making your application more secure without passwords. But how does that work exactly?

Why are passwords insecure?

Passwords alone are no longer a safe way to protect user accounts. Phishing attacks make passwords less efficient. In phishing attacks, your users land on fake websites where they might leave sensitive account information. But it is not only phishing that is dangerous for user accounts. Many people do not realise that they themselves are handling their own data dangerously. People tend to use the same passwords over and over again. If their password is leaked somewhere, it will be possible for an intruder to use that password in all applications. Even if your application is 100% safe, there’s still a possibility that your users get hacked because of their own password security.

Tips for your users to help them use better passwords:

• Never use the same password for multiple websites/apps.
• Do not use a logical system - For example: Including (a part of) the name of the application in your password.
• Do not use personal information - For example: A user named Phil, born on 02/04/1993, uses password Phill_02041993
• Use randomly generated passwords
• Use long passwords with random characters

Ok, these tips may make these passwords extremely difficult to remember. Many people won't like that either... Fortunately, there are some solutions for this problem!

Keep track of all your passwords with password managers

The best tip we can give to everyone is to start using a password manager. Such password manager stores all your passwords in a secure, encrypted vault and allows you to access this vault on different devices.

However password managers do not always work across all platforms and devices. So perhaps it is time to find a solution that is not solely the responsibility of your end user. A solution that you yourself can participate in.

Web authentication

Web authentication or WebAuthn tries to address these issues and uses the combination of biometrics (faceID, fingerprint scan etc.) and your device to log you in. This specification is written by W3C and FIDO, and is already widely adopted by the major companies like Google, Mozilla, Microsoft and others.

The application integrates with the strong authenticators (biometrics) of the device. Instead of a password, a keypair is generated. The private key gets stored on the device, while the public key is returned to the application. The public key is used to prove the user’s identity, but it is also useless without the private key. This means that public keys aren’t interesting for hackers, because they can't login without the private key on the device.

Pros

• Extremely safe
• No (unsafe) password needed (*)
• Also possible to provide an extra security layer for sensitive operations within your application (for example changing account information, making a payment…).

*: only possible if all of your users have devices with biometric access.

Cons

• Users need a device with biometric authentication.
• A username/email needs to be provided, before the login can take place.
• A good onboarding flow needs to be implemented, because users need to onboard to their account for each device.

Discoverable credentials

As stated in the second con above, we still need a username to login using WebAuthn. This can be skipped with 'discoverable credentials'. Thereby the username is stored in the authenticator on onboarding (registration). When a user logs in with WebAuthn (by clicking a single login button), the user sees a pop-up which allows them to select the account they want to sign in with.

Google Accounts uses this method, where you can see the previous accounts you have logged in with.

Onboarding new devices to an existing account

WebAuthn completely removes the need for passwords, but there’s also a downside to that. With this implementation, the user is only allowed to login with a certain device, on a certain application with their own biometrics.

When you use another device, or a new device, we need to implement an onboarding flow to register the device to the user account. This can be done by implementing a verification system via email and/or text message. However, this is still not fully secure, because email and/or text messages also can be hacked.

An even better solution is to use the other device authenticated to onboard the new device, this is where passkeys come in.

Passkeys

Passkeys are a replacement for passwords, but they are actually FIDO-credentials.

These passkeys can be shared across devices on the same platform. For example, when both devices are logged in with a Google Account, they can use the shared passkeys.

Passkeys can also be used cross-platform. Suppose we have a phone and a web application and we want to log into the web app for the first time. When the user clicks the login button, he must scan a QR code with his phone. Then the user can select an account locally and log in on their phone. When this is completed, the user is logged into the web application.

Scanning the QR code is only necessary when logging in for the first time. Next time, the user can simply select the name of the phone from the list of discoverable credentials. This skips the step of scanning the QR-code, but you still need to sign on with your phone.

Passkeys will be available on Android devices later this year, stated by Google in their Google I/O talk.

Two-factor authentication

Besides web authentication, there is also a more well-known solution: two-factor authentication.

The general idea of two-factor authentication is using a one-time password that can be generated via an app or delivered via sms or email. Sometimes it uses a FIDO-authenticator such as a security key, which can implement passkeys (from above).

SMS-based two-factor authentication is also a good solution, but there are already cases where phone numbers get recycled and hijacked. To prevent that, there’s SMS-based one-time password (OTP).

SMS-based OTP will send an SMS, which includes an option to directly confirm the message. When you do this, the user will be automatically authenticated in the web application. This is done without having to enter the received one-time login code. Because the SMS includes the target origin, it will not work on a phishing website.

Identity federation

Another secure option is 'identity federation', which consists of standard protocols like OpenID Connect, OAuth or SAML.

In this case, a 'relying party' authenticates itself at an external identity provider (IdP), such as Google, Facebook or others.

It's a great solution for users that don’t want to create a username or password for the application they want to use.

Despite the advantage, some people fear that identity providers know exactly which applications they are using. This raises the question of whether their third-party cookie can be used for tracking. The evolution of digital privacy teaches us that companies are increasingly trying to track their users.

This is why Google is working on a new browser API dedicated for identity federation, which is called Federated Credential Management.

Federated credential management

Federated credential management (FedCM) makes the integration of identity providers more privacy-preserving. With this functionality, the user will click on a sign-in button. Then all identity providers are shown where they are logged in (for example your Google account). After selecting an identity provider, the user is logged in.

The user information is not shared with the identity provider until the user agrees to sign in. The browser forms the bridge between the identity provider and the application being used.

FedCM is designed without the use of a third-party cookie, which could allow user tracking.

FedCM is currently still at an early stage and works on Chrome and is coming to Android soon. The WebKit team has expressed interest in working on FedCM.

Do you still need a password?

Passwords aren't a thing of the past yet. However, with the rise of various systems such as web authentication, two-factor authentication and identity federation, great strides are being made to make user accounts as secure as possible. We are moving towards a future where your password will become obsolete and it won't be an absolute disaster if someone knows your password.

At Endare, security always comes first. For example, the financial app of Carrefour Finance had a huge need for high-quality security. Discover here how we ensured that the security of the end user could be guaranteed.