Tag: FIDO2 standard

Apple to support security keys as a means to protect your Apple ID

Articles

You can use security keys as a second factor for authenticating with Apple ID on your iPhone

iOS 16.3 Lets You Use a Physical Key for Added Security When Logging Into Your Apple Account (gizmodo.com.au)

Apple iOS 16.3 arrives with support for hardware security keys (bleepingcomputer.com)

Security Keys Are Now the Best Way to Protect Your Apple ID (lifehacker.com.au)

From the horse’s mouth

Apple

Apple advances user security with powerful new data protections (Press Release)

About Security Keys for Apple ID (Support article)

Use security keys to sign in to your Apple ID account on iPhone (Support article)

My Comments

Apple is making it feasible to use hardware security keys in iOS as an authentication factor for their Apple ID logon.

This is being desired as a “phish-proof” approach for secondary authentication or sole authentication due to a physical device not being easily coerced or fooled. As well, this “machine-to-machine” approach allows for stronger passkeys.

It is even seen as a preferred secondary authentication factor for online services used by journalists, human-rights defenders, the public service within democracies and others working with high-stakes information. This avoids such users being fooled in to releasing their online accounts to highly-targeted spear-phishing attacks.

Apple supports this on iPhones and iPads through the iOS/iPadOS 16.3 major feature update. This is also being written in to MacOS Ventura 13.2 for the Apple Mac regular computers whereupon you just use the security key as the secondary authentication factor. They primarily implement this as an alternative secondary authentication means to transcribing a six-digit number shown on your iPhone when it comes to two-factor authentication for your Apple ID.

In the context of the Apple Watch, Apple TV and HomePod devices, you use your iPhone that you set up with the security key authentication to provide the secondary authentication factor when you set these up for your Apple ID. Here, this is easier for limited-interface devices because another device is managing some of the authentication work with your Apple ID.

FIDO-compliant hardware security keys are supported with this update but they have to have an MFi Lightning plug or NFC “touch and go” interface to work with the current crop of iPhones in circulation. USB-C is also supported but you would need a USB-C to MFi Lightning adaptor for iOS devices except newer iPads that have this connector. You also may find that newer iPhones that are to come on the market soon will have the USB-C connector due to pressure from the European Union and some other jurisdictions.

There will be a requirement to set up two hardware keys with the same iOS device when you implement this feature. This is so you have a backup key in case the one you lose the one you regularly use or that one is damaged such as being laundered with your clothes.

Add to this that support does exist for app-level or Website-level verification with security keys within iOS. But it may allow Apple to build in and refine the necessary application-programming interfaces for third-party app developers who want to support this form of authentication.

What I see at least is the implementation of hardware security keys in the mobile platform context when it comes to multi-factor or password-free authentication for the user’s primary platform account. Who knows when Google will offer this feature for Android. Could this also be about leading towards the use of hardware security keys as a hardening factor for user account security?

FIDO Alliance closer to password-free authentication

Article

Facebook login page

FIDO Alliance could be having us move off passwords when we use online services

FIDO Alliance says it has finally killed the password • The Register

From the horse’s mouth

FIDO Alliance

Charting an Accelerated Path Forward for Passwordless Authentication Adoption – FIDO Alliance

My Comments

The FIDO Alliance and WebAuthN groups are moving towards a password-free authentication approach for online services. This is based around a device-local private authentication key associated with your username for that online service that is only released when you enter your device PIN / screen-unlock code or scan your fingerprint or face where your device supports it. A corresponding public key is stored in the user’s account record on the online service’s servers and used to “test” the private key to complete the user-verification process.

Samsung Galaxy Tab Active 8" business tablet press picture courtesy of Samsung

The smartphone will end up as a key authentication device especially if you sign in with your fingerprint or face

But there is a problem associated with the reality that most of us own multiple computing devices. This can typically manifest in us owning a smartphone, a mobile-platform tablet like an iPad and/or a regular desktop or laptop computer. There is also the fact that most of us will end up owning “connected-TV” equipment be it a smart TV, set-top device or games console that is a gateway to online video services. Or we may even end up using various smart-home platforms including Amazon Echo or Google Home.

The problem also includes lifecycle issues associated with today’s devices such as acquiring a new device or replacing a broken, lost or stolen device. Or it could include where one is using another device on a temporary basis like using a friend’s computer or a computer at a hotel business centre.

Then there is the issue of phishing even with multifactor authentication because there is no way of identifying whether a user is signing in to the real online service or not.

Solutions

Bluetooth as a means for authentication

Logitech MX Anywhere 3 mouse on glass table near laptop

Or you could authenticate online services from a laptop’s fingerprint reader or your smartphone

One factor being examined is the use of your smartphone as a roaming authentication device. Part of what will be looked at is using Bluetooth LE as a machine-to-machine link between the device you are signing in from and your phone to conditionally release online-service authentication keys.

This avoids you entering a one-time-password in to a phishing site for example because you are not transcribing information in to a site. The Bluetooth functionality is also about device proximity – your smartphone is close to the device you want to sign in from.

I also see the Bluetooth link appealing to client devices that have limited user interfaces like connected-TV devices, printers and the Internet Of Things. It avoids the need to log in to your online service to transcribe a “binding code” to use it with connected-TV devices or, at worst, “hunt and peck” a username and password to associate it an online service.

It will also support bare-bones provisioning to new devices irrespective of the platform such as when you, as an iOS or Android mobile-platform user, want to set up you Windows laptop to work with your online services.

As well, it could come in to its own with temporary-use scenarios like shared computers or equipment installed in places like hotels. It could even include adding one’s online video service account to smart TVs or set-top devices installed in hotels, holiday home or common rooms for temporary use.  I could even see this earn its keep as an alternative to cards for authentication at kiosk-type setups like ATMs.

Multi-device authentication

The multi-device approach would be on the likes of Apple, Google and Microsoft coming to the party. This is because it would be based on device operating systems and associated cloud-driven account services like Apple ID (MacOS, iOS, tvOS), Google Account (Android, ChromeOS) and Microsoft Account (Windows, XBox).

In some cases, it may extend to device vendors or other entities who run their own cloud-driven account services and want them as the login of choice for your online world. Even account services typically managed by businesses or education establishments could become “primary” account services typically for large fleets of organisation-owned devices.

Amazon Echo Show 10 press image courtesy of Amazon

Even smart displays like the Amazon Echo Show 10 could be in on the action

This approach would have the operating system create and use the authentication key and store these with your account on the cloud-driven account service. It would come in to its own if you are adding a device that works with the same platform as what you were using, for example onboarding an iPad to the same Apple ID as your iPhone.

The system can distinguish between an extant device and a newer device through another device-bound authentication key that underscores that you are authorised to use the service with that physical device. Here, it can be about deeming that particular new device as trusted and under your control or some corporate setups may use it as a way to constrain use of the service to devices they have control over.

Online services would have to support a number of authentication keys for the same username with these associated with different computing platforms an end-user is likely to use. As well, another requirement that would be expected is to have one authentication key able to work across a vendor’s different operating systems such as a mobile OS and a desktop OS. This is due to vendors architecting their mobile operating systems for battery efficiency while the desktop operating systems are maintained for performance.

Situations

Moving between devices or platforms

Apple TV 4th Generation press picture courtesy of Apple

.. as could the likes of connected-TV and set-top-box setups like the Apple TV

If you are moving your online life between devices of the same platform, the multi-device authentication would  have all the platform-level authentication keys moved across similar to what happens with a password vault app.

The Bluetooth authentication approach will come in to play if you have devices of a different platform. But you have to have one of the devices still alive and in your possession for this to work properly.

What really may happen is that you may use Bluetooth authentication to “enrol” other computing devices and have them seen as trusted devices once one or more of your devices support the necessary standards. Then, whichever one of them that is “alive” like, per se, your regular computer or your mobile-platform tablet would be used to authenticate your replacement smartphone to your secure online circle even if this was to replace a lost, stolen or damaged phone.

If you intend to completely move off a platform, you can simply delete from your online services all the credentials associated with that particular platform. This may be through account management options offered by the online service where you revise what platforms you are logged in from.

Multiple-platform setups

Most of us are likely to operate a multiple-platform setup for our online lives. This will typically range from an iPhone and a Windows or Macintosh computer through an Android phone, an iPad and a Windows computer.

Online services will be likely to keep with your username, multiple sets of access credentials for each computing platform you are using. There will still be the ability to keep a platform-specific authentication key for your devices that operate a particular platform along with another for a different platform.

Gaps yet to be filled

One gap that needs to be filled is software-to-software authentication like what is expected for email or document-contribution setups or even the Internet of Everything. Such setups typically rely on stored credentials to authenticate the user with their account on that service along with client software like email clients having continual access to that service.

This may have to be about adapting protocols like IMAP4 or XML-RPC to device-generated authentication credentials and supporting multiple sets of these credentials for one user account. This would be important where multiple client devices are being used for the same online service such as a smartphone and a laptop for an email service.

Conclusion

Even the common reality of users operating multiple devices or using a highly-portable device like a smartphone as an authentication device will not escape the goal of a password-free online-service future. Here it would primarily be about authenticating with a device-local PIN or your fingerprint

What will passwordless authentication be about?

Facebook login page

You soon may not need to remember those passwords to log in to the likes of Facebook

The traditional password that you use to authenticate with an online service is in the throes of losing this role.

This is coming about due to a lot of security risks associated with server-based passwords. One of these is for us to use the same password across many online services, leading towards credential reuse and “stuffing” attacks involving “known” username/password or email/password pairs. As well, the password is also subject to brute-force attacks including dictionary attacks where multiple passwords are tried against the same account. It also includes phishing and social-engineering attacks where end-users are tricked in to supplying their passwords to miscreants, something I had to rectify when an email account belonging to a friend of mine fell victim to phishing. This is facilitated by users creating passwords based on personal facts that work as aide-memoires. Passwords can also be stolen through the use of keyloggers or compromised network setups.

Managing multiple passwords can become a very user-unfriendly experience with people ending up using password-vault software or recording their passwords on a paper ore electronic document. As well, some applications can make password entry very difficult. Examples of these include connected-TV or games-console applications where you pick each character out using your remote control’s or game controller’s D-pad to enter the password.

You will be able to set your computer up to log you in to your online services with a PIN, fingerprint or other method

The new direction is to implement passwordless authentication where a client device or another device performs the authentication role itself and sends an encrypted token to the server. This token is then used to grant access to the account or facilitate the transaction.

It may be similar to multifactor authentication where you do something like enable a mobile authenticator app after you key in your online service’s password. But it also is very similar to how a single-sign-on or social-sign-on arrangement works with the emphasis on an authenticated-session token rather than your username and password as credentials.

The PIN will be authenticated locally nd used to enable the creation of a session token for your online service

There will be two key approaches which are centred around the exchange of an asymmetric key pair between the client and server devices.

The first of these will be the primary client device like your laptop computer or a smartphone that you are using the online service on. Or it can be a secondary client device like your smartphone that is holding the private key. You authenticate with that device using a device-local PIN or password or a biometric factor like your fingerprint or face.

Android security menu

The same holds true for your Android or other smartphone

The second will involve the use of a hardware token like a FIDO2-compliant USB or Bluetooth access key or an NFC-compliant smart card. Here, you activate this key to pass on the credentials including the private key to the client computer for your online session.

It is being facilitated through the use of FIDO2, WebAuthN and CTAP standards that allow compliant Web browsers and online services to implement advanced authentication methods. At the moment, Windows 10 is facilitating this kind of login through the use of the Windows Hello user-authentication functionality, but Android is in the process of implementing it in the mobile context.

There is effectively the use of a form of multifactor authentication to enable the cryptographic key pair between the client and server devices. This is based around the device you are using and the fact you are there to log in.

HP Elitebook 2560p business notebook fingerprint reader

The fingerprint reader on this HP Elitebook and similar laptops will become more important here

If the authentication is to take place on the primary client device like a laptop or smartphone, the device’s secure element like a TPM module in a laptop or the SIM card in a smartphone would be involved in creating the private key. The user would enter the device-local PIN or use the fingerprint reader to enable this key which creates the necessary session token peculiar to that device.

On the other hand, if it is to take place on a secondary device like a smartphone, the authentication and session-token generation occurs on that device. This is typically with the user notified to continue the authentication on the secondary device, which continues the workflow on its user interface. Typically this will use a Bluetooth link with the primary device or a synchronous Internet link with the online service.

The online service has no knowledge of these device-local authentication factors, which makes them less likely to be compromised. For most users, this could be the same PIN or biometric factor used to unlock the device when they switch it on and they could use the same PIN across multiple devices like their smartphone or laptop. But the physical device in combination with the PIN, fingerprint or facial recognition of that user would be both the factors required to enable that device’s keypair and create the session token to validate the session.

A hardware token can be in the form of a USB or Bluetooth security key or a NFC smart card. But this device manages the authentication routines and has private keys kept in its secure storage.

There will be the emphasis around multiple trusted devices for each service account as well as the same trusted device supporting multiple services. Some devices like hardware tokens will have the ability to be “roaming” devices in order to do things like enabling a new device to have access to your online services or allow ad-hoc use of your services on shared equipment such as the public-use computers installed at your local library. They will also work as a complementary path of verification if your client device such as a desktop PC doesn’t have all the authentication functionality.

Similarly, when you create a new account with an online service, you will be given the option to “bind” your account with your computer or smartphone. Those of us who run online services that implement legacy-based sign-in but are enabled for passwordless operation will have the option in the account-management dashboard to bind the account with whatever we use to authenticate it with and have it as a “preferred” authentication path.

Some of the passwordless authentication setups will allow use with older operating systems and browsers not supporting the new authentication standards by using time-limited or one-use passwords created by the authentication setup.

Questions that will arise regarding the new passwordless Web direction is how email and similar client-server setups that implement native clients will authenticate their sessions. Here, they may have to evolve towards having the various protocols that they work with move towards key-pair-driven session tokens associated with the particular service accounts and client devices.

There will also be the issue of implementing this technology in to dedicated-purpose devices, whether as a server or client device. Here, it is about securing access to the management dashboards that these devices offer, which has become a strong security issue thanks to attacks on routers and similar devices.

IT WILL TAKE TIME TO EVOLVE TO PASSWORDLESS