Password security recommendations
The Password AutoFill passwords list in iOS, iPadOS and macOS indicates which of a user’s saved passwords will be reused with other websites, passwords that are considered weak, and passwords that have been compromised by a data leak.
Overview
Using the same password for more than one service may leave those accounts vulnerable to a credential-stuffing attack. If a service is breached and passwords are leaked, attackers may try the same credentials on other services to compromise additional accounts.
Passwords are marked reused if the same password is seen used for more than one saved password across different domains.
Passwords are marked weak if they may be easily guessed by an attacker; iOS, iPadOS and macOS detect common patterns used to create memorable passwords such as using words found in a dictionary, common character substitutions (such as using “p4ssw0rd” instead of “password”), patterns found on a keyboard (such as “q12we34r” from a QWERTY keyboard) or repeated sequences (such as “123123”). These patterns are often used to create passwords that satisfy minimum password requirements for services but are also commonly used by attackers attempting to obtain a password using brute force.
Because many services specifically require a four- or six-digit PIN code, these short passcodes are evaluated with different rules. PIN codes are considered weak if they are one of the most common PIN codes, if they are an increasing or decreasing sequence such as “1234” or “8765” or if they follow a repetition pattern, such as “123123” or “123321”.
Passwords are marked leaked if the Password Monitoring feature can claim they have been present in a data leak. For more information, see Password Monitoring.
Weak, reused and leaked passwords are either indicated in the list of passwords (macOS) or present in the dedicated Security Recommendations interface (iOS and iPadOS). If the user logs into a website in Safari using a previously saved password that’s very weak or that’s been compromised by a data leak, they’re shown an alert strongly encouraging them to upgrade to an automatic strong password.
Upgrading account authentication security in iOS and iPadOS
Apps that implement an Account Authentication Modification Extension (in the Authentication Services framework) can provide easy, tap-of-a-button upgrades for password-based accounts — namely, they can switch to using Sign in with Apple or an automatic strong password. This extension point is available in iOS and iPadOS.
If an app has implemented the extension point and is installed on device, users see extension upgrade options when viewing Security Recommendations for credentials associated with the app in the iCloud Keychain password manager in Settings. The upgrades are also offered when users sign in to the app with the at-risk credential. Apps have the ability to tell the system not to prompt users with upgrade options after signing in. Using new AuthenticationServices API, apps can also invoke their extensions and perform upgrades themselves, ideally from an account settings or account management screen in the app.
Apps can choose to support strong password upgrades, Sign in with Apple upgrades or both. In a strong password upgrade, the system generates an automatic strong password for the user. If necessary, the app can provide custom password rules to follow when generating the new password. When a user switches an account from using a password to using Sign in with Apple, the system provides a new Sign in with Apple credential to the extension to associate the account with. The user’s Apple ID email isn’t provided as part of the credential. After a successful Sign in with Apple upgrade, the system deletes the previously used password credential from the user’s keychain if it’s saved there.
Account Authentication Modification Extensions have the opportunity to perform additional user authentication before performing an upgrade. For upgrades initiated within the password manager or after signing in to an app, the extension provides the user name and password for the account to upgrade. For in-app upgrades, only the username is provided. If the extension requires further user authentication, it can request to show a custom user interface before moving on with the upgrade. The intended use case for showing this user interface is to have the user enter a second factor of authentication to authorise the upgrade.