Phishing Is No Longer Relevant With Passkey! Really?

Ronghwa included in Authentication Cybersecurity

2023-06-11 1870 words 9 minutes

Contents

TLDR

Passkey promises to be a more secure and usable replacement for passwords. Google and Apple have provided their support to eliminate passwords via passkeys. While passkeys are more secure compared to passwords, life isn’t a bed of roses. We should not be mistaken by the marketing hype that (all) cyber problems will disappear with passkeys.

As the cybersecurity landscape evolves with better tools, attackers will continue to innovate and pose new cyber challenges. However, a clearer understanding of passkeys’ opportunities and limitations can help create a safer cyberspace by reducing the dependency on passwords.

If you are already familiar with the impetus of passkey, start from section #3 to understand what marketing materials don’t tell you, i.e. cyber challenges and considerations.

1. From Password & Passphrase to Passkey

Digital Identity is the cornerstone of trust for digital services. Passwords and their hashes are shared secrets between digital users and websites (sometimes known as Relying Parties) to help verify users. However, passwords are susceptible to cyber-attacks such as password guessing, credential phishing, and password-hash cracking.

As the number of digital services exploded over the past two decades, using passwords as users’ credentials has become untenable.

Firstly, users were advised to use complex passwords to protect against password guessing. When users find it hard to remember many complex passwords, they reuse or create “special conventions” for them.

Secondly, the impact of one cyber incident is often beyond one website. The credentials stolen from one website can often be used in another when users reuse their passwords.

Without solving the fundamental issue that using passwords is not scalable, more “solutions” such as password managers and slow hashes were born until we have decided to replace passwords with passkeys.

2. The Promise of the Future

Thanks to FIDO’s passwordless vision, they have created FIDO2 standards that leverage PKI to shift from knowledge-based credentialing (e.g. passwords) to possession-based credentialing (e.g. Yubikeys). The dependency on something you know is gradually reduced.

With Passkey, it is more secure, more usable, and cheaper…

Extracted from Google

Passkeys are easier:

Users can select an account to sign in with. Typing the username is not required.

Users can authenticate using the device’s screen lock, such as a fingerprint sensor, facial recognition or PIN.

Once a passkey is created and registered, the user can seamlessly switch to a new device and immediately use it without needing to re-enrol (unlike traditional biometric auth, which requires setup on each device).

Passkeys are safer:

Developers only save a public key to the server instead of a password, meaning there’s far less value for a bad actor to hack into servers and far less cleanup to do in the event of a breach.

Passkeys protect users from phishing attacks. Passkeys work only on their registered websites and apps; a user cannot be tricked into authenticating on a deceptive site because the browser or OS handles verification.

Passkeys reduce costs for sending SMS, making them a safer and more cost-effective means for two-factor authentication.

Does it mean that Passkey is totally invulnerable?

3. Life Isn’t a Bed of Roses

Sharing secrets with many users is a bad idea! This is even when Apple claims that sharing passwords or passkeys can be securely performed. Multiple users sharing the same credential could lead to accountability and audibility issues.

Furthermore, sharing of passkeys could be an avenue for social engineering. With a suitable pretext, an attacker can convince their targeted victim to save the their contact into their victim’s contact list. Doing this will meet the pre-requisite of sharing a passkey.

2. Phishing is Not Going Away

By eliminating passwords, credential phishing is no longer effective.

However, Hackers WILL NOT Stop Phishing! Human is always the weakest link. Hackers and scammers will continue phishing to steal passkeys, deliver malware, and scam. While each passkey is scoped to be bounded against a specific website, scammers can ask victims to log into the website voluntarily or use convincing spoofed websites to tell their stories.

After seeing many scammers’ success stories, people will continue to fall prey.

IMPORTANT: Phishing is still a relevant threat even when your organisation has removed the use of passwords.

3. Google Password Manager and Apple’s iCloud Keychain

Being able to use the same passkeys across devices seems like great news. However, the private keys of the passkeys are not stored in hardware enclaves.

Is this a cybersecurity problem?

IMHO, not really. Suppose you are using a passkey as a pure replacement for a password. We are not going to have a worse-off situation.

However, if your business requires more assurance, your passkeys should be bound to a specific hardware (device or token) where their private keys cannot be extracted. It is noted that more stringent cybersecurity measures may come with different additional considerations, e.g., cost, usability, availability, etc.

For example, high-risk business applications such as banking apps and high-risk users such as systems administrators may want more assurance for their users’ digital identities through additional security measures such as using hardware-backed tokens, approval workflows, and multi-device authorisation.

Extracted from Google

Google Password Manager stores, serves and synchronises passkeys on Android and Chrome. Passkeys from Google Password Manager are available to all Android apps, including Chrome and other browsers. When the user creates a passkey on an Android device, it’s stored and synchronised with their other Android devices, and their passkey secrets are encrypted end-to-end. This makes passkeys available to users across all Android devices that use Google Password Manager and are signed in with the same Google account.

While Google generally supports syncing passkeys to different devices, not all platforms are equally supported.

Image Reference: https://developers.google.com/identity/passkeys/supported-environments

On Apple’s iCloud implementation, will it result in a platform lock-in? Probably, to some extent.

You can use a passkey on your iPhone if you want to sign in to an account on non-Apple devices. Hence, you would minimally need to have an iPhone.

Separately, regarding the recoverability of iCloud Keychain. You can recover a keychain with an iCloud account, password, and SMS. This seems like passwords are not going to be entirely eliminated as what is marketed for practical reasons. Well, it at least solves password scalability issues.

Extracted from Apple

To recover a keychain, a user must authenticate with their iCloud account and password and respond to an SMS sent to their registered phone number. After they authenticate and respond, the user must enter their device passcode. iOS, iPadOS, and macOS allow only 10 attempts to authenticate. After several failed attempts, the record is locked and the user must call Apple Support to be granted more attempts. After the tenth failed attempt, the escrow record is destroyed.

Optionally, a user can set up an account recovery contact to make sure that they always have access to their account, even if they forget their Apple ID password or device passcode.

4. Application Security of Websites has to Step Up

For passwordless to work well, relying parties implementing WebAuthn are expected to code securely. Application developers need to ensure considerations such as the following:

Ensuring that the Challenge generated is a secure random to prevent replay attack, i.e. it must not be a hardcoded value, it must not be repeated across sessions, and it must be generated in a secure and trusted environment (e.g. server side).
Ensuring the Challenge is at least 16 bytes to mitigate against brute-force attacks.
Verify the returned Challenge to ensure it matches the generated Challenge for the session. This is to prevent an Authentication bypass.

These are measures on top of standard application security practices to reduce attack surfaces such as code injections, broken authentications such as IDOR, 3rd party script management, etc.

5. Security of Endpoint Devices Remain Relevant

Your device has become your identity!

If the attacker knows your password/PIN and can access your device, he can be you! Guessing or knowing someone’s password/PIN is not impossible.

Furthermore, passkey does not protect against malware siphoning everything from an infected device, including session cookies and access tokens, to gain access to services.

Important: This implies that devices should not be shared.

4. Is Passkey a Replacement for Multi-Factor Authentication?

Many believe that with Passkey, they will no longer require Multi-Factor Authentication (MFA).

Technically, passkey does not replace MFA. Instead, password/PIN (something you know) or biometrics (something you are) are used as an authorisation gesture to access the passkey on the trusted device (something you have). This effectively resulted in using at least two factors.

FIDO defines two types of gestures, i.e. User Presence (UP) and User Verification (UV). UV is typically used as the first factor for passwordless authentication.

UP is a simple form of authorisation gesture where a user interacts with an authenticator to prove human presence (e.g. touch a button or shake the device)
UV is an authorisation gesture where a user is verified through various authorisation gestures modalities (e.g. password/PIN or biometric)

Image Credit: FIDO 2

Is Passkey Good Enough?

“Good enough” is subjective. It depends on your risk appetite!

As an application system owner, are there higher-risk activities that you want to protect? If there is, what additional level of protection would you like to take?

These additional protection measures depend on the assumptions you want to address. Below outlines examples of assumptions which you may wish to address. Different assumptions require more effort from the attacker which affects the likelihood of an attack.

The application may want to authenticate the user again using a passkey when performing higher-risk activities.

Assumption #2: Attackers have gained full control of their victim’s device through malware.

If the attacker can gain complete control of the device, they may be able to extract the private key and authenticate with the application without the victim’s knowledge. Hence, the application may want to authenticate the user again using a hardware token, e.g. Yubi key, that is segregated from the device.

Assumption #3: The user is the attacker

If the user (e.g. administrator) is the attacker, passkey and additional tokens will not help. The application may want to authenticate multiple users via a workflow to approve a higher-risk activity.

5. Conclusion

Passkey is an excellent replacement for the password! It helps solve password-related vulnerabilities, e.g., password reuse, password hash cracking and password phishing.

That said, passwords will not disappear in a year or two. It takes time for web applications to upgrade to support passwordless authentication.

Additionally, we need to exercise our assessments on various implementations of passkeys! Not all features are secure, and not all threat scenarios are irrelevant. For example, Phishing will not go away just because of passkeys. Passkey is only one part of the puzzle to developing a secure application!

Lastly, step-up verifications for higher-risk activities are still relevant to create friction for attackers. However, the implementation choice would depend on the application owner’s risk appetite.

Special thanks to my wife and son for giving me time to work on this project.

If you like this post, please share it to reach a wider LinkedIn community.