Tag: security token

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?

Articles

It is being proven that the use of a hardware security key is making the login experience phish-proof

Google Employees’ Secret to Never Getting Phished Is Using Physical Security Keys | Gizmodo

U2F Security Keys Show Extreme Effectiveness Against Phishing | Tom’s Hardware

Google: Security Keys Neutralized Employee Phishing | Krebs On Security

My Comments

An issue that is being raised regarding SMS-driven two-factor authentication is that it can be used to facilitate phishing and other fraud against the user’s account. Here, it relies on the user receiving an SMS or voice call with a key value to enter in to the login user interface and this is totally dependent on the SMS or call being received at a particular phone number.

The area of risk being highlighted is that the user could be subjected to social engineering to “steer” their phone number to a mobile device under the hacker’s control. Or the IT infrastructure maintained by your mobile telephony provider could be hacked to “steer” your phone number somewhere else. The ease of “steering” your mobile phone number between devices is brought about thanks to a competitive-telephony requirement to “port” mobile or local numbers between competing telephony-service providers if a subscriber wishes to “jump ship” and use a different provider.

Google have proven that the use of hardware security keys that are part of the FIDO Allance’s U2F (Universal Second Factor) ecosystem are more secure than the SMS-based second-factor arrangement used by most online services. This is a “follow-on” from the traditional card-size or fob-size security token used by some banking services to verify their customers during the login process or when instantiating certain transactions.

Here, Google issued all their employees with a U2F-compliant security key and made it mandatory that their work accounts are secured with this key rather than passwords and one-time codes.

Most of these keys are connected to the host computer via plugging them in to a vacant USB port on that host. But there are or can be those that use Bluetooth and / or NFC “touch-and-go” technology to work with mobile devices.

Why are these U2F security keys more secure than the SMS-based two-factor authentication or app-based two-factor authentication? The main reason is that the U2F security key is a separate dedicated hardware device that works on an isolated system, rather than a backbone system dependent on mobile-telephony infrastructure or software that runs on a computer device that can be exposed to security exploits.

For most users, the concept of using a U2F-compliant security key for their data relates it to being the equivalent of the traditional key that you use to gain access to your home or car as in something you possess for that purpose. Most U2F-compliant security keys that use USB or Bluetooth would also require you to press a button to complete the authentication process. Again this is similar to actually turning that key in the lock to open that door.

This has underscored the “phish-proof” claim because a person who uses social engineering to make an attempt on the user’s credentials would also need to have the user’s security key to achieve a successful login. It is something that is similar to what happens when you use an ATM to withdraw cash from your bank account because you need to insert your account card in the machine and enter your PIN to commence the transaction.

What kind of support exists out there for U2F authentication? At the browser level, currently Chrome, Opera and Firefox provide native support but Firefox users would need to enable it manually. At the moment, there isn’t much production-level support for this technology at the operating-system level and a handful of applications, namely password-vault applications, provide native support for U2F authentication.

The issue of providing support for U2F authentication at the operating-system level is a real issue thanks to operating systems having an increased amount of native client-level support for online services “out of the box”. It also includes the use of Web browsers that are developed by the operating system’s vendor like Edge (Microsoft Windows) and Safari (Apple MacOS and iOS) with the operating system set up “out of the box” to use these browsers as the default Web browser. As well, Microsoft, Google and Apple implement their own platform-wide account systems for all of the services they provide.

Other questions that will end up being raised would be the use of hardware-key authentication in the context of single-sign-on arrangements including social-sign-on, along with the 10-foot lean-back user experience involving the TV set. The former situation is underscored through the popularity of Google, Facebook and Microsoft as user credential pools for other online and mobile services. This is while the latter situation would underscore console-based online gaming, interactive TV and video-on-demand services which are account-driven, with the idea of being able to support simplified or “other-device” user authentication experiences.

What has been proven is that easy-to-use dedicated security keys are a surefire means of achieving account security especially where the main attack vector is through social engineering.