Automatic Strong Passwords and Security Code AutoFill 

[ Music ]

[ Applause ]

Good morning.

Welcome to Session 204, Automatic Strong Passwords and Security Code Autofill.

My name is Chelsea.

You may have seen Automatic Strong Passwords and Security Code Autofill in the State of the Union, yesterday.

I’m really excited to tell you more about these features, today.

These new features and other features in iOS 12 will help users log into and create accounts with ease in your app.

If you have a login screen or an account creation screen in your app, this session is for you.

A major pain point for users is dealing with passwords.

They can be a pain point, even for people that use the best practice, which is to use a password manager to create and fill passwords for them.

For everyone else it can be tempting to do something easy but insecure, like reuse a password they’re already using on another service or use an easy to guess password that they can memorize.

We know that the most private secure thing for your users is to use strong unique passwords for each service that they use.

We’ve all heard of breaches in services that result in users’ passwords being exposed.

Users then need to go and change their password on every service where they were using it.

The features that we’ll discuss today will help users choose strong unique passwords for your apps.

This way, you both help users that are trying to consciously use best password practices, as well as your users that would rather not think about passwords.

Many of your users use the iCloud Keychain.

The features that we’re going to talk about today are built on top of the Keychain.

It has best in class security and it protects users’ passwords behind biometric authentication.

Apple does not have access to the credentials stored in Keychain, so users’ privacy is preserved, as well.

The iCloud Password Keychain Manager can help users log into and create accounts in your app.

We’ve added some new features on iOS 12 to help make account creation and login even easier.

I’m really excited to show you these features with a demo.

So, I’m going to go to the Shiny app.

This is my favorite demo app for creating an account and logging back into it.

So, I’m going to go ahead and create and tap create account.

I’ll focus the email field and you’ll see that I’ve been given a suggested username.

This is a new feature on iOS 12.

These suggested usernames are based on credentials that the user already has stored in the Keychain.

Since I always use [email protected], I’m going to select that as my username.

Without another tap, the password field is focused for me and a strong unique password has been provided.

I’m also told that I can go and look up this password in Settings at any time.

So, if I need to go and type it onto another device where iCloud Keychain is available, it’s available to me.

So, I’m going to go ahead and use this strong password and sign up.

So, with just a couple of taps I’m logged back into the Shiny, or I’m signed up for the Shine app.

Now, let’s fast forward through all of the other account setup.

I’ve turned on second factor authentication.

And let’s look at what logging back into Shiny looks like.

So, I’m going to go ahead and tap the email field.

As you can see, the credential I just created is suggested right on the QuickType bar.

Going to select that.

And then, after Face ID, my password and username are filled and I can log in.

Now, I’ve set up second factor authentication.

Normally, I’d need to try to memorize this code or go back to Messages.

But as you can see, the code that I just received for second factor authentication is right on the QuickType bar.

So, with one tap I can fill the code.

Yeah. It’s really awesome.

[ Applause ]

So, I can fill that code, submit, and again, with a minimal number of taps I’m logged back into Shiny.

Back to the slides.

So, as you saw, creating an account with Automatic Strong Passwords is quick and easy.

I didn’t think about the password, since one was provided for me and inserted into the password field.

I also didn’t think about the password when logging back into Shiny.

Passwords have truly become an implementation detail to logging into my app with Automatic Strong Passwords and Password Autofill.

Here’s today’s agenda.

First, we’re going to do a quick recap of Password Autofill, since many of the features that we’ll talk about today are built upon that feature.

Next, we’ll talk about how to ensure that Automatic Strong Passwords works in your app.

Then, we’ll talk about Security Code Autofill.

Next, we’ll talk about federated authentication with a third-party service.

And finally, we’ll discuss some new password management features that the iCloud Password Keychain Manager provides.

In iOS 11, we introduced Password Autofill for apps.

Some of the new features that we’re going to discuss today are built upon the same adoption you may have done for that feature.

Password Autofill helps users log into your app by surfacing credentials right on the QuickType bar.

Here’s a quick recap of how to ensure that it works in your app.

Passwords in the iCloud Keychain Password Manager are stored based on domains on the Web.

Like Apple.com.

Thus, it’s important to have an association between your app and the domain on the Web.

This way, we’re able to confidently surface credentials on the QuickType bar.

You already have this association if you’ve adopted Universal Links or Handoff.

The process of adding this association is pretty simple.

You’ll have a small change to your apps Entitlements file and you’ll serve a file from your domain on the Web.

If you’d like to see an in-depth look at how to set this up, see Introducing Password Autofill for Apps from WWDC 2017.

It’s important to always tag your fields with text content type, so that Autofill can be offered at the right place.

Tag your username fields with the username content type.

Tag fields where users are going to be filling, or passwords for existing accounts with a password content type.

If you’ve chosen not to use Secure Text Entry for your password fields, it’s particularly important that you tag your fields with the password content type.

This way, we know we’re in a password context.

Now, that we’ve discussed how to get Password Autofill working in your app, let’s talk about some improvements that it has.

Since, iOS 11.3, WKWebView supports Password Autofill.

This helps your users if your login screen is implemented using Web technologies.

New to iOS 12, password managers from the app store can provide information to Autofill.

This means that any work you do to support the iCloud Keychain Password Manager filling credentials in your app, also, helps users of these other password managers, as well.

If you’re a developer of a password manager, see Implementing Autofill Credential Provider Extensions.

On iOS 12, we now offer to save credentials when a user logs into your app with a new account.

This way, users can then use these credentials in your app and website on all of their devices.

Let’s talk about how to ensure users are prompted to save and update passwords in your app.

Here’s how saving works.

First, Autofill infers that we’re in a login scenario.

Then, Autofill checks the eligibility of your app based on if there’s an association between your app and the domain on the Web.

Without this association saving passwords will not be offered.

Next, it finds the username and password fields so that it knows which data to save in the new credential.

Then, it detects that a sign in action has occurred.

And finally, Autofill decided whether to prompt to save or update the password based on if this is as brand new credential that’s not yet in the Keychain.

Or if the user is updating an existing credential.

Now, this may work with no changes to your app on iOS12.

But let’s talk about some steps you can take to ensure that it works.

First, make sure to tag your fields with the username and password content types, like, with filling passwords.

Make sure to remove your username and password fields from the view hierarchy when a sign in occurs.

This way, Autofill can detect that a sign in is occurring.

You could do this by dismissing the view controller that your sign in fields are in.

Make sure to only clear the username and password fields after they’ve been removed from the view hierarchy.

This way, we can read out the data and save it into credential.

Make sure the Autofill saves the credential to the correct domain.

You can do this by saving a password in your app, and then going to Settings to check where the credential is saved.

If you notice that Autofill is not saving to the correct domain, you can override where it’s saving using the Web credentials associated domain service.

Finally, you may have previously been using SecAddSharedWebCredential to manually save credentials when a user logs into your app.

However, now that Autofill automatically prompts users to save passwords you may no longer need this.

You will still want to use this if your app has a web view for its login screen because saving is not supported there.

So, here are some of the key steps that we’ve discussed so far to make sure that filling and saving passwords in your app works.

Make sure to associate your app with the domain on the Web.

Tag your fields with the username and password content type.

And for saving passwords, ensure that login is detected by making sure that the saving prompt appears when you sign into your app.

By ensuring that Password Autofill works in your app, you help your users log in with ease.

For new users, one of the first encounters they’ll have with your app is creating an account.

In my demo you saw how Automatic Strong Passwords made this process super easy.

I’d like to invite Reza to the stage to discuss how to ensure Automatic Strong Passwords works in your app.

Thank you.

[ Applause ]

Thank you, Chelsea.

Hi, everyone.

This is Reza and I’m really excited to tell you all about Automatic Strong Passwords.

Account creation is a point of frustration for many users.

They might even leave your app and never come back, or as many of them do, decide to use a weak password or keep reusing the same one.

This significantly reduces their security.

Although, it might be an alternative to account creation, some of you might have concerns about allowing social media to be used to sign into your apps.

Automatic Strong Passwords makes account creation just as easy.

It brings convenience and security to the signup process.

Users no longer need to think about or worry about passwords.

Autofill even suggests usernames to ease the signup process.

With Automatic Strong Passwords, account creation is only a few taps away.

So, users are more likely to sign up and user your services.

Now, I’d like to talk about how Automatic Strong Passwords works.

Similar to what Chelsea explained in a login scenario, when your app presents a view controller Autofill infers its type.

In this case, it’s a signup view controller.

It will then check the eligibility of your it will then check the eligibility of your app based on the associated domains to figure out if it can save passwords.

If that’s the case, Autofill will then detect relevant signup form elements; the username and the password.

Once the username field become first responder Autofill suggests usernames.

This is a new feature we’re adding in iOS 12.

The user proceeds with the suggested username.

And eventually, the password field becomes first responder.

Autofill automatically inserts a strong password into the password field.

At this point, the user only needs to proceed with the suggested password and sign up.

Autofill takes care of saving the password.

In many cases, this happens automatically without any adoption requirements in your apps.

However, in order to ensure your app’s compatibility with Automatic Strong Passwords there are a certain number of steps you should take.

Many of these steps are identical to those Chelsea explained to make your apps compatible with saving.

Make sure to tag your username field with UI textContentType username.

New in iOS 12, make sure to tag your new password and confirm new password fields with UI textContentType newPassword.

If you’re using a UI table view to represent your signup form make sure to use unique instances of UITextField for the username and the password field.

This is important, because once Autofill detects username and password fields, it expects to be able to reliably read their values later on.

Some of you might have changed password forms in your apps.

Automatic Strong Passwords is compatible with change password forms if Autofill is able to detect username and password fields on the same screen.

Note that the username field can be Read Only.

Best practices that we discussed for signup forms, also, apply to change password forms.

Now, let’s take a moment and talk about the format of these generated passwords.

The generated passwords are 20 characters long.

They contain uppercase, digits, hyphen, and lowercase characters.

This gives you a strong password with more than 71 bits of entropy.

We designed this to be a strong, yet compatible with most services.

It is, of course, possible for your apps to define their own custom password rules.

As I mentioned before, in most cases, you don’t need to do this because the default format of Automatic Strong Passwords should be compatible.

However, if your app’s backend requires a separate set of rules that are not compatible with the default format of Automatic Strong Passwords, you could define your own rules.

To do so, use the new password rules language in iOS 12.

Following the format of the password rules language, create a rulesDescriptor.

Using the rulesDescriptor create an instance of UITextInputPasswordRules and assign it to the password rules property of UITextField.

Once you do this, Automatic Strong Passwords will generate passwords based on these rules.

We have also created a new web-based Password Rules Validation Tool.

Use this tool to ensure the rules that you specify are correct and produce the type of passwords that you expect.

I’ll talk more about this, shortly.

Now, that we talked about the steps it would take to make your apps compatible with Automatic Strong Passwords, I’d like to show you a demo.

I’m the developer of the Shiny app and I want to make sure that Shiny is compatible with Automatic Strong Passwords in iOS 12.

So, the first thing to do is to run Shiny using the iOS 12 SDK and try it out.

So, in Xcode I’ll click on Run.

And here is Shiny.

I’ll tap on Create Account.

Tap on Email.

And I don’t see any suggested username.

When I tap on the Password field I don’t see any Automatic Strong Passwords suggestion, either.

So, let’s go back to Xcode and investigate this, further.

The first thing to make sure of is associated domains for your apps.

In this case, I’ve already ensure that Shiny has an associated domain.

In fact, earlier today I was able to get Autofill suggestions when I wanted to logging into Shiny.

Next, you should take a look.

You should take a closer look at your signup view controller.

I’ll click on the Email field.

And here, under Text Input Traits, Content Type, I see that I’m correctly setting the content type to username.

And because I want the format of this username to be of type email address, I’m also correctly setting the Keyboard Type to Email Address.

So, this is good.

Let’s take a closer look at the Password field.

I see that the Content Type is set to Unspecified.

This should, actually, be set to New Password.

So, I’ll select New Password, here.

And because this is a password field, I’m going to mark it as Secure Text Entry.

All right.

Let’s run Shiny again and try it out.

:15 Okay. Tap on Create Account.

Tap on Email.

Here, I see I’m getting suggested username, now.

I’m going to go ahead and proceed with the suggested username.

I also, see Automatic Strong Passwords.

So, in most cases, this should be enough and you should be done.

Let’s proceed with the signup process.

For the purpose of this demo, I’m requiring Shiny passwords to contain a dollar sign.

This means that we need to specify our own custom password rules for Automatic Strong Passwords.

And actually, the best way to do so is using the new Password Rules Validation Tool.

Using the tool, I will be able to specify correct password rules, and also, ensure the rule will produce the type of password that I expect.

So, let’s jump right in.

This is the new Password Rules Validation Tool that you can have access from developer.apple.com.

For the purpose of this demo, I’m allowing uppercase, lowercase, digit, and requiring at least a dollar sign to be present in my password.

At the bottom of the page I see some examples of the password generated.

I also, have the option to download a number of these passwords in case I need to run some tests in my app’s backend.

Once I’m happy with the formatting of the passwords I have two options.

If I’m making a native app for UIKit, I can go ahead and copy the rules formatter for UIKit.

Or if I’m making a webpage I can copy the HTML formatted rules.

For this demo, since we are making a native app for UIKit, I’m going to go ahead and copy the UIKit version.

And once I’ve copied it, all I need to do is go back in Xcode, select the password, and paste in the rule in the Password Rule text field.

Now, let’s run Shiny, again.

Okay. I’ll tap on Create Account.

Tap on. I’m going to go ahead and proceed with the suggested username.

And at this point, the password should be compatible with the rules that I just specified.

Let’s proceed with the signup.

And just like that, I’m in.

[ Applause ]

Thank you.

We just saw how easy it is to make your apps compatible with Automatic Strong Passwords.

Than you, Reza.

As Reza showed you, these are some steps you can take to ensure that Automatic Strong Passwords works in your app.

Make sure to associate your app with the domain on the Web, just like filling and saving passwords.

Make sure to tag your fields with the username and new password content types.

Ensure that signup is detected by checking that when you sign up for your app the password is saved.

Most of you will be done after doing these three things.

However, if your service is not compatible with Apple’s password generation format you may want to use some password rules on your password text field.

To ensure that Automatic Strong Passwords generates a compatible password.

By ensuring that Automatic Strong Passwords works well in your app, you’re setting your users up for success by encouraging them to use a strong unique password in your app.

Some of your apps and services may use SMS, or security code sent via SMS to your users.

I’d like to invite Harris to the stage to discuss how you can service these codes right in your app.

[ Applause ]

Awesome.

Thank you, very much, Chelsea.

Hello, everyone.

My name is Harris and I am super stoked to talk to you about Security Code Autofill.

But first, this section needs a little bit of audience participation.

So, show of hands, how many of you have ever gotten a text message that looks something like this?

All right.

I think it’s fair to say that most of us have to deal with these codes on a fairly regular basis, these days.

All right.

Question of the second, after getting one of these text messages how many of you go through a process like this?

Where you think you have the code memorized, you type it in, you switch the last two digits around, and then you have to do it all over, again.

Let me see those hands.

All right.

Final question.

After going through this process, how many of you feel something like this?

All right.

So, let me tell you it doesn’t have to be this way.

Because starting in iOS 12 and macOS Mojave, we’re introducing Security Code Autofill.

A brand new feature which takes all the pain and frustration out of message based second factor flows.

Now, it is important to note that Security Code Autofill does not alter the calculus around the security of second factor methods.

What it merely does is remove the indignity out of having to type the code in yourselves in the age of computers.

Nothing more, nothing less.

[ Applause ]

So, starting in the new iOS and macOS, instead of exercising your memorizing skills you get to do something like this.

Just one tap, right on the QuickType bar, and you’re signed in.

And hopefully, at the end of this process, you feel a little bit more like this.

All right.

So, let’s talk about some technical details.

As with other Autofill features, Security Code Autofill will work in your apps right out of the box, most of the time.

Still, you can do just a tiny bit of work to ensure that Security Code Autofill works every single time.

We’ve told you this before but tag your fields.

In iOS 12 we’re introducing a new UITextContentType with the value oneTimeCode.

Tag your security code fields with this and Security Code Autofill will work every time.

Additionally, it is very important that you allow usage of the system keyboard for inputting these codes.

Tempting as it may be, you should refrain from building Bespoke keyboard UI’s within your view hierarchy or setting custom input views in your controls.

Because if you do so you are preventing iOS from surfacing the necessary UI or injecting the appropriate events to type the code in on behalf of your users.

And additionally, you may be hampering the experience of folks that leverage accessibility technologies like voiceover.

So, bottom line is let the system keyboard do the heavy lifting for you and Security Code Autofill will work every time.

Another step that you can take to ensure that Security Code Autofill works great with your service is to craft your text message, accordingly.

iOS and macOS use data detector heuristics to infer that an incoming message carries a security code.

Specifically, our heuristics are looking for words like code or passcode in proximity to the actual code string.

And you can see a few sample text messages in different languages in the slide behind me.

Now, verifying that your specially crafted message properly triggers the iOS and macOS heuristics is super simple.

You can be your own best friends and simply text yourselves.

Then, when you go into the message transcript and you see the code being underlined and tapping the code offers you a Copy Code option, you know you have it right.

Security Code Autofill is available in all supported locales of iOS and macOS.

And if after following these best practices you find that you cannot get Security Code Autofill to trigger appropriately inside of your app or website, please let us know by filing a bug report.

We’ll be looking out for them.

So, so far, we’ve talked about getting Security Code Autofill to work within your native iOS apps.

Security Code Autofill is also available in iOS Safari on websites and, and this is pretty cool, if your users are signing into your service in Safari on their Mac, text message forwarding securely pushes incoming messages from their iPhone to their Mac.

Now, what this means is that they can fill in a security code with a single click in Safari’s completion UI.

You no longer have to switch back to Messages to copy the code out or, you know, go find your iPhone all the way across your home.

It’s really cool.

[ Applause ]

To support Security Code Autofill in Safari, we are introducing a new input autocomplete attribute value one-time-code.

In fact, all of the UI Text Content Types that you heard about today have web platform equivalents that you can leverage to ensure a smooth seamless autofill experience in your websites, just as well as in your apps.

You’ve heard this before but tag your form fields this time and Autofill will work great every time.

So, this was a brief introduction to Security Code Autofill, a brand new addition to iOS 12 and macOS Mojave that takes all the pain and all the frustration out of message based second factor flows.

Now, with the Autofill features that we’ve introduced today, it becomes super simple for you to build a relationship with your users while safeguarding their security and respecting their privacy.

Still, some of you may find that you have to support federated authentication flows with third party providers, such as popular social networks.

For those of you among the audience, we are introducing in iOS 12 a new API to support such flows.

We call it ASWebAuthenticationSession and I would like to show you how it works.

Now, here I am back in the Shiny app.

And this time I will choose to log in with example.com, a super popular social network.

Now, as soon as I tap the button the app under the hood calls in to the new ASWebAuthenticationSession API.

Now, one of the ways in which ASWebAuthenticationSession makes logins faster is by sharing its underlying cookie storage with Safari.

Now, of course, before we do any of this, iOS asks for explicit user consent.

Upon consenting, the user is presented with a secure view controller and guided through the third party’s federated authentication flow.

In this case, I’m already signed into example.com in Safari on my iPhone, so all I have to do is tap Allow.

There we go.

And with just two taps I’ve gone through a full federated authentication flow with a third-party service.

So, in the past you may have used one of the other iOS platform technologies to implement federated authentication inside of your apps.

Starting with iOS 12, ASWebAuthenticationSession is the go-to way to implement such flows.

As we mentioned, already, ASWebAuthenticationSession makes login flows faster by sharing its underlying cookie storage with Safari upon explicit user consent.

Now, what this means is that depending on the implementation of the federated authentication flow by the third party.

If your user is already signed into that service in Safari on their device, they may not even have to see a login form, at all.

If they do have to see a login form ASWebAuthenticationSession supports Password Autofill and Security Code Autofill to make the experience as painless as possible.

And for you developers, ASWebAuthenticationSession offers a straightforward block-based API that makes adoption super simple.

So, let’s take a look at it.

Now, let’s see how simple it is to implement federated authentication using ASWebAuthenticationSession.

You’re going to start off by importing the brand new AuthenticationServices framework.

And then, you simply define the oauthURL as it’s described to you by your third-party authentication provider.

Now, following this you will create an ASWebAuthenticationSession object.

You’re passing the oauthURL and a callback handler that gets involved at the end of the authentication session.

Now, it is crucial that you hold onto a strong reference to the authentication session object while the session is in flight.

And by doing so, you also have the ability to cancel an ongoing session should you choose to do so.

Finally, you call the nonblocking start method.

Upon doing so, first iOS will ask for user consent to share the underlying Safari, the underlying cookie storage that Safari has with your session.

And then, the user is presented with a secure view controller and guided through the authentication flow.

When the user completes the authentication flow or if they cancel out of the authentication session, your completion handler gets involved and you can handle the result.

And that’s how simple it is to implement federated authentication in iOS 12, using ASWebAuthenticationSession.

It only takes a few lines of code.

Starting with iOS 12 this new API is the go-to way to implement federated authentication and it replaces SFAuthenticationSession.

If you find that you have to support federated authentication inside of your apps, we strongly encourage you to adopt this new API.

And with that, I’ll turn things over back to Chelsea, to talk to you about a number of super cool new password management features that we built right into iOS 12 and macOS Mojave.

Thank you, very much.

[ Applause ]

Thanks, Harris.

I’m really excited to tell you about some of the new features that the iCloud Keychain Password Manager gives you in iOS 12 and macOS Mojave.

You may have seen some of these in the State of the Union, yesterday.

What we’ve talked about, so far, is how you can help users log into and create accounts in your app.

However, there are some cases when users will be interacting with accounts for your app when they’re outside of the context of your app.

For these cases we’ve added some features to the iCloud Keychain Password Manager to make managing and interacting with these accounts a breeze.

If a user needs to look up a password, they can now simply ask Siri.

They’ll be taken right to their password after authentication.

This way, they can read off their password to type into another device that doesn’t have iCloud Keychain.

Some users may share account information for services like utilities.

In order to share this information, users can now AirDrop passwords to their contacts.

On iOS 12 the password list UI is redesigned so it’s more scannable and delightful to interact with.

The password list UI in macOS has been redesigned, as well.

And it looks great.

Another new feature of the iCloud Keychain Password Manager is it now warns users if they’re reusing passwords across multiple websites.

When the user taps on one of these passwords they’ll be given the option to change their password on the website.

Automatic Strong Passwords on the web can help them update to using a strong unique password for that service.

The Password Reuse Auditing feature is built right into the Safari Passwords List on macOS, as well.

Last but not least, your tvOS apps can now offer to autofill from a nearby iOS device.

[ Applause ]

In order, to learn more about this incredibly convenient feature see the Password Autofill section of the What’s New in tvOS 12 session.

In summary, Autofill is a powerful platform feature that helps users interact with accounts in your apps.

As we discussed, the features that we talked about today may work with no changes to your app, however, it’s important that you test your app with these new features.

Apply the recommendations that we discussed today.

If after applying these recommendations, Autofill is not working as you’d expect, please file a bug report.

We’d love to hear from you.

To use the Password Rules Validation Tool that Reza showed you during his demo, you can visit the URL listed here.

Here are some related sessions you might be interested in.

If you’re a developer of a password manager, see Implementing Autofill Credential Provider Extensions.

If you’d like to learn more about Password Autofill for apps, see Introducing Password Autofill for Apps from WWDC 2017.

And if you’d like to talk to us or you have questions about any of the content we’ve covered today, come to the Safari, WebKit, and Password Autofill Lab after this session.

We’ve also got a couple more, later in the week.

Thank you, so much, for attending and have a great WWDC 2018.

[ Applause ]