iOS 12 Password Tools: Improving User Security and Experience

Customizing iOS Password AutoFill Rules

You’re almost there. Before taking on the final steps, you need to take a final quick detour to learn about iOS Password AutoFill rules.

Apple’s default suggested passwords are 20 characters long and must contain all of the following character types: uppercase, lowercase, digits and hyphens. This produces a strong password that’s compatible with most web services.

In some cases, though, you may need or want to set custom rules for the suggested iOS password. You can add these custom rules to the Password Rule property of any field in which Content Type is set to New Password.

iOS Password AutoFill rules require the following format:

required: (<identifier> | <character-class>), ..., (<identifier> | <character-class>); 
allowed: (<identifier> | <character-class>), ..., (<identifier> | <character-class>); 
max-consecutive: <non-negative-integer>

They use these keywords:

• required: Use “required” if the generated password must contain at least one member of the specified character class. To combine character classes, separate them with commas. For example, required: X, Y is equivalent to required: [XY] where X and Y represent character classes.
• allowed: Use “allowed” if the restrictions specify a subset of allowed characters. If you don’t include the allowed property, and just include required, the password can only contain the required characters. If you only specify allowed and not required, then the password can only contain the characters that you’ve explicitly allowed. If you specify neither required or allowed, then your password can contain any ASCII printable characters.
• max-consecutive: Follow “max-consecutive” with a positive integer to limit the number of times a character can appear consecutively.
• minlength: Follow the “minlength” keyword with a positive integer to specify the minimum password length.
• maxlength: Follow the “maxlength” keyword with a positive integer to specify the maximum password length.

You must use “allowed” and “required” alongside these permitted character classes:

• upper: Represents uppercase letters A – Z.
• lower: Represents lowercase letters a – z.
• digit: Represents digits 0 – 9.
• special: Includes -().&@?’#,/”+ and Space.
• ascii-printable: Includes all ASCII characters.
• unicode: Includes all unicode characters.
• Or specify a custom character class by listing whichever ASCII characters that you’d like to include within square brackets. For example, “allowed: [a1,-]” allows characters “a”, “1”, “,” and “-“.

A Super Fun Happy Quiz? Oh, Boy!!

Think you get the gist? Try your hand at the following exercise. For each password rule, determine whether Password AutoFill can generate A, B, C and/or D. Each answer may consist of none|any|all of the multiple-choice options:

A. JEMSP
B. 43jKL
C. 39LS2
D. 92JJK

[spoiler title=”Answer #2″]Password rule #1 can generate passwords A and C.[/spoiler]

A. jsoeebd1re
B. Ys2jUJaaauREV
C. js13&Lk2ja
D. 29mn$#ki@nd

[spoiler title=”Answer #1″]Password rule #2 can generate passwords A and D.[/spoiler]

A. I❤️U
B. aJEK24
C. 30 👩‍💻3420
D. 3 0 4 2

[spoiler title=”Answer #1″]Password rule #3 can generate passwords B, C and D.[/spoiler]

1. required: upper, digit; maxlength: 5; max-consecutive: 1;
2. required: lower; required: digit, [$#@]; allowed: upper; minlength: 9; max-consecutive: 2;
3. required: lower, special; required: digit, upper; allowed: unicode;

Congrats on getting through that exercise! That said, according to Apple:

The more restrictions you have on a password, the higher the likelihood that it can be guessed. The hardest-to-guess password rule is allowed: unicode. No password rule at all creates the second most-difficult-to-guess passwords.

So remember those complicated password rules you just painstakingly analyzed? As a general rule, you’ll usually want to avoid them when you can!

Putting Custom Password Rules to Use

That said, you took this quick detour for a very good reason. Whenever you’re integrating with a back end web service, chances are good that you’ll need to use iOS password rules to sync with any specific password requirements that service may impose.

For the sake of testing, imagine that your web back end:

1. Doesn’t accept special characters.
2. Needs to be at least 12 characters long.
3. Requires an uppercase character.

To meet those requirements, open Main.storyboard, select the New Password field in the Signup View Controller Scene, then copy and paste this password rule into New Password Field’s Password Rule field:

required: upper;
allowed: lower, digit;
minlength: 12; 
maxlength: 20;
max-consecutive: 3;

This rule requires at least one uppercase character; it also allows lowercase characters and digits; it generates a password 12 to 20 characters long, and it prevents any character from appearing more than three times consecutively.

As you go forward implementing your own iOS Password AutoFill rules, you can confirm that they work as intended by entering them into Apple’s Password Rules Validation Tool. There, you can review a few a hundred, or even ten thousand, generated passwords to make sure your rules produce the results you need.

Taking It for a Spin

You’ve now set up authentication, strong password autofill, security code autofill and custom iOS password rules. Build and run your iOS app to test it all on a physical iOS device — iOS Password AutoFill won’t work on a simulator.

Tap Sign Up on the bottom-right of the login page to navigate to the sign-up view.

The username field Keyboard Type is “E-mail Address”; so, while the Username field is the first responder, the QuickType bar may suggest email addresses that you’ve used to log in to other services. This is because iOS recognizes this particular username field as a sign-up username field.

After entering a username, select the Password field. It should autofill with a strong password that conforms to the rules that you specified in the field’s Password Rule. Tap Use Strong Password to use the autofill-provided suggestion, then tap Sign Up. An alert will pop up to let you know if you’ve registered successfully.

If you see the above alert, congrats! You’ve registered a new account. Tap OK and the sign-up view will dismiss itself to return to the login view.

Saving Your Passwords

There’s just one last piece of the puzzle: automatically saving your newly created credentials. As it turns out, for iOS to recognize that it needs to save a new set of credentials, you must:

1. Remove the Username and Password fields from the View hierarchy after sign up occurs.
2. Only clear the Username and Password fields after they’re no longer in the View hierarchy.

Since your app dismisses the sign-up view completely without deleting any fields, it already meets these requirements. Great! But how do you prevent your keychain from saving the credentials of a failed or incomplete sign-in attempt? Good question!

Open SignupViewController.swift, scroll down to viewWillDisappear(_:) and find this code snippet:

if API.token == nil {
  usernameField.text = nil
  passwordField.text = nil
} else {
  API.logout()
}

Here’s what this code does:

When a user signs up successfully, the server returns a token. UltraMotivator’s API.swift class stores this in the variable API.token.

If API.token is nil when the user navigates back to the login view, the sign-up action was not completed. In this case, you set the text fields to nil before leaving the View hierarchy, i.e., in viewWillDisappear(_:). This prevents these invalid credentials from being saved to the user’s keychain.

If API.token is not nil, the sign-up action has been completed successfully. In this case, you log out, leaving the fields’ text intact. iOS will then automatically save those credentials to the user’s keychain.