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]