Download
Hi. I'm Eryn Wells, an engineer on the Authentication Experience Team. If your app or website ever asks someone for a password, then you know that account security is critically important. In this video, I'm gonna talk about how to keep your customer's accounts more secure and how to make signing in with verification codes even easier with the new verification code generator built into iCloud Keychain.
This is a big topic, and I'm gonna break it down into three important parts. First, we'll talk about passwords, some of the security problems they have, and how multistep authentication helps address some of those problems. Second, I'll talk about time-based verification codes, including a brand-new authenticator we've built into iCloud Keychain in iOS 15 and macOS Monterey. Finally, I'll take a step back to discuss the beginning of a big change happening in the world of authentication, as well as some other opportunities to improve how people sign in with verification codes.
OK, let's talk about passwords and multistep authentication.
Passwords are everywhere, and people understand how to use them. However, it turns out they're difficult to use correctly. In fact, it's easier to misuse passwords than to use them correctly. People frequently reuse passwords across multiple websites or choose passwords that are easy to guess. It's also pretty easy for an attacker to convince someone to give up their password. So services are faced with a dilemma: How do we add security to our users' accounts while still making it easy to log in? Many services add steps to their log-in flows. They ask for additional pieces of information to confirm someone's identity. Adding steps like this reduces the chance that an attacker with someone's password will be able to access that person's account. It also means the attacker won't automatically have access to any other accounts where that person used the same password. Verification codes are a common additional step. Services ask for these codes after someone has entered their user name and password. These codes are either delivered over SMS, email, or a push notification, or they're generated by an authenticator app on the person's phone or with a hardware key fob.
An essential feature of these codes is that they're single use. Since they're not intended to be memorized or stored, they're not susceptible to reuse like passwords are. Verification codes do still require a human to enter the code, though, so they're still prone to phishing in the same way that passwords are. The most common way by far that verification codes are delivered is with SMS. Almost everyone who has a cell phone can receive a text message, and people understand sending and receiving texts.
AutoFill made it even easier to use these codes. Just one tap fills a code into any text field. But there are still real problems with verification codes delivered over SMS. For one thing, they're not very secure. They're vulnerable to snooping on carrier networks and SIM-swapping attacks, where an attacker can receive messages meant for someone else.
People tend to take for granted that text messages will come and go without error, but they do require network access. So if someone's on an airplane or away from strong service, it might take a long time for a message to arrive or it may not arrive at all.
Finally, SMS messages have a cost, both to send and to receive. So sending millions of these messages can really add up. Another way verification codes are done is with on-device code generators. The algorithm for doing this is defined in RFC 6238 and is called "Time-Based One-Time Passwords," or "TOTP." It takes a secret key and a time and produces a short numeric code based on those bits of information. Typically, an authenticator app or hardware device generates the codes. It doesn't require any communication with the service. It all happens on the device.
This is a huge benefit in terms of security and user experience. Codes are valid for a short amount of time, typically 30 seconds or so. And it results in lower costs for both services and customers because no one has to send or receive SMS messages.
The challenge with TOTP is that it tends to be a bit more complicated to set up. Services have to share a secret key with their customers, along with several other parameters, so that the customer's device can start generating codes. A typical setup process involves displaying a QR code on one device, downloading an authenticator app on another device, and then scanning the QR code with that app. This is a cumbersome process, and it's difficult to explain to people. Generating codes on-device is a better experience for everyone, but it does still have some pesky issues around setup. We took a careful look at some of those difficulties and developed a new feature of iCloud Keychain that brings a streamlined setup experience together with AutoFill into something really fantastic.
New in iOS 15 and macOS Monterey, we've built time-based verification code generators into iCloud Keychain Password Manager, and I am so excited to show you how this works.
We started with the basics: looking up and copying codes to use on this device or another device. These are important features of any authenticator app.
But AutoFill really makes this shine. Just like with codes delivered over SMS, AutoFill fills generated verification codes with a single tap. Because codes are immediately available, your customers get a more streamlined, reliable sign-in experience, and you get to reduce the costs of sending SMS messages.
One of my favorite parts of this feature is how easy it can be to set up a new verification code. When you add a special link or a button to your TOTP setup pages, someone using iOS 15 or macOS Monterey will be able to set up a new verification code on the same device with just a couple taps. It's really, really easy.
Finally, verification codes are synced across all of a person's devices, and they're securely backed up with iCloud Keychain. So they don't have to pull out their iPhone to fill a verification code when they're signing in to an account on their Mac. This is great for account recovery too. When verification codes are safely backed up in iCloud, losing a device no longer means losing access to accounts. As a reminder, everything in iCloud Keychain is end-to-end encrypted, so no one except the owner of the account-- not Apple or anyone else-- can access them.
Devices with iCloud Keychain enabled are protected by Face ID, Touch ID, or a passcode. And every Apple device has the highest level of security supported by the operating system. So Keychain data is safe, no matter which device a person has in the moment. Apple's Platform Security Guide describes all of this and a lot more in great detail.
There are a few easy things you can do to ensure your customers have the best possible experience setting up and filling codes. For your setup flows, there are two things, and for your log-in flows, there's just one. Let's talk a little about each one.
Being able to set up a new verification code with just a few taps is a big deal. Hundreds of millions of iPhone users are going to be able to do this as soon as they update to iOS 15. You can make it super easy to set up verification codes on their devices by adding a link or a button that does this to your setup screens.
If you already have infrastructure to support logging in with TOTP codes, you might be familiar with otpauth: URLs. These URLs contain all of the information required to set up a code generator, including the base32-encoded secret key, the number of digits in each code, the period of time that each code is valid for, and an issuer field that you should set to your domain name. iCloud Keychain uses this field to suggest an account to add the verification code to.
This is the same URL that you encode into the QR codes that are a common part of the TOTP setup process. You can link directly to the iCloud Keychain Password Manager by prefixing the URL with "apple-".
You can take this apple otpauth: URL and put it in an anchor tag on your web page. And in apps, you have two options. You can create a link by adding the "link" attribute to an NSAttributedString that you assign to a textView's attributedString property, or you can open the URL in response to a button tap with the open API on the window scene. You can check whether the system can open apple otpauth: URLs with an availability check. On previous versions of iOS, you should hide setup buttons and remove setup URLs.
The second thing you can do during setup is to use raster images like JPGs, PNGs, or GIFs for QR codes intended to be scanned by other TOTP apps. Safari uses on-device image analysis to detect QR codes and decode the information they contain. If Safari determines that the QR code contains an otpauth: URL, it will offer to set up the code generator in the context menu for the QR code image.
The last thing to do concerns text fields for entering generated codes. To ensure that AutoFill knows exactly where to fill user names, passwords, and verification codes, annotate those text fields with content types. You can do this in SwiftUI with the textContentType view modifier, in UIKit with the textContentType property on UITextFields, in AppKit apps with the contentType property on NSTextFields, and on the web, you can set the auto-complete attribute to "one-time-code" on input elements. So now, I wanna take a step back. Let's look at the big picture of authentication and talk a little about how to make your existing infrastructure more secure.
Authentication mechanisms exist on a spectrum, increasing in strength and security as you move along. Passwords are the traditional baseline for the industry, and there are a number of ways that services reinforce password-based log-in flows. Two of the most common are Passwords + Codes delivered over SMS and Passwords + Codes generated with TOTP.
An additional decision services make is whether to use a federated sign-in provider that delegates the entire process of authentication to another service. Federated authentication options are based on all the same mechanisms as traditional methods but require people to keep track of fewer passwords. When implemented on robust, secure infrastructure-- as is the case with Sign in with Apple-- they can also be more secure than those traditional mechanisms.
A step beyond any of these is to get rid of passwords altogether. The WebAuthentication standard, or "WebAuthn," does exactly this. Instead, it uses public key cryptography to keep accounts safe. iOS 15 and macOS Monterey contain a preview of this technology that offers a usable replacement for passwords. My teammate Garrett has a video about it that you should definitely check out.
As our whole industry continues to work on building that future without passwords, there is still real value in taking steps to improve the security of the infrastructure you already have and may continue to have for a while. Anything you can do to keep people safer online is good.
One step you can take concerns verification codes delivered over SMS. As you're evaluating adopting time-based verification codes, you might still need to send codes with SMS.
In iOS 14 and macOS Big Sur, we introduced a simple mechanism for making your SMS codes more resistant to phishing by adding domain bindings to your messages. A domain binding is a way of communicating with AutoFill that the code in this message is meant for a particular domain. When the code is bound in this way, AutoFill will only offer the code if the domain it's bound to matches the domain of the web page or one of your app's associated domains. In apps, this works on the same mechanisms as associated domains and universal links. So if you've already configured your apps for those technologies, you're all set to add domain bindings.
You can learn more about this in an article we published about enhancing the security of SMS codes with domain bindings.
Now that you know all about verification codes, go and do these two important things. First, adopt time-based verification codes in your apps and websites. Add support to your back ends, and encourage your customers to use them instead of getting codes over SMS. Second, if you are continuing to support SMS verification codes, add domain bindings to your messages.
Thank you for watching. [music]
