Authentication today: Based on usernames and passwords - Familiar - Most folks know what to do when presented with a username and password blank Lessons learned over the years - Protecting secrets is hard - Phishing is very common - Weak / reused passwords make the problem worse Most authentication today relies on the user and server sharing a secret when the account is created - This is usually a password - Secret is reshared during every successful authentication Every time that secret is shared, there is a non-zero risk that the secret can learned by a third party Phishing is the most common way for a third party to learn a secret they shouldn't have access to. Phishing methods: - Misleading or fake emails - Misleading or fake phone calls - Misleading or fake websites If a secret does get out, the following can quickly compound the problem: - Weak passwords - Same password shared across multiple accounts When studied by the 2020 Verizon Data Breach Investigation, 80% of breaches involved weak or stolen credentials (secrets). - Weak credentials could be learned by brute-force attacks - Stolen credentials could be used as-is by malicious third parties Meanwhile, authentication methods have continued to evolve to try to mitigate these risks: - Memorized passwords - Passwords are stored only in your head - People are not good at devising or remembering strong and unique passwords for every account - Password managers - Password managers can generate strong and unique passwords for every account - May be able to assist with detecting phishing attempts - Password + one-time codes (OTP) - Password by itself is not enough - A one-time verification code must also be entered as part of the login process - macOS Monterey and iOS 15 both have OTP code generators built into the iCloud Keychain password manager (more information on this topic is available in the "Secure login with iCloud Keychain verification codes" session.) - Federated authentication - Authentication is outsourced to a trusted third party - Examples include Sign In with Apple - People can focus on trusting a small number of highly protected accounts which grant access to numerous systems This session is going to focus on non-federated authentication options. - Memorized passwords - Password managers - Password + one-time codes (OTP) All methods listed above: Easy to use Works on all Apple devices Works on non-Apple devices Always with you However, they each have varying levels of security issues: Memorized passwords - Probably are not strong and unique passwords for every account - Password managers - Can generate strong and unique passwords for every account - Protection for those password is only as strong as the password (along with potentially other factors) used to protect it - Password + one-time codes (OTP) - Offer the best protection of all three - Secrets protected this way are still subject to many of the same problems as passwords - Typeable - Phishable - Sharable Also, if passwords are in your head, you can forget them: - Must be a separate recovery flow for apps and websites for forgotten passwords which need to be reset - Usually a link in an email - This reduces the account's security level to the level of security of the email provider - Generally something out of your control Some password managers and second-factor solutions can help with recovery, but the overall problems described above remain with these recovery workflows as well. Phishing: - Remembered passwords also don't offer any kind of phishing resistance. - Password managers can assist with detecting phishing - Password manager may not offer to fill a password blank on a known phishing site - The person can still manually enter the password themselves - OTP has similar problems though there are modern mitigations However, whenever you are sharing a secret, that secret is only as well protected as the weakest protection for that shared secret. Replacing passwords: - Replacement solution needs to be secure by design - Replacement solution needs to be easy to use - Replacement solution needs to work everywhere - The recovery process should be a first-class feature of the replacement solution Any friction involved in the authentication process is going to hurt adoption of the replacement solution. One of the strongest security solutions currently available are security keys - Based on the web authentication open standard (WebAuthn standard) - Generally easy to use (may be a learning curve) - More secure than passwords - Usable on a wide variety of devices macOS has supported USB, NFC and Lightning security keys for a while now. - Most security keys also support more than one connection method - Single hardware key can be used on many devices A comparison between WebAuthn and passwords can be seen at 7:35 in the session video. A WebAuthn account creation demonstration can be seen at 8:16 in the session video. WebAuthn - WebAuthn account creation creates two pairs of encryption keys - One of these keys is public (like a username) - Public key can be shared with anyone and everyone without compromising the account's security - One of these keys is private (like a password) - This private key is secret and protected by your device - This private key is never shared with anyone else When authenticating: - Public key is shared with the service you want to authenticate to. - Service now has a copy of your public key, which is public information and not a secret - Private key stays on the device - Only that device is responsible for protecting that secret The service you're authenticating to is never sent anything secret. Instead, you prove that the account used to log in is legitimate by proving that your device knows the private key associated with your account's public key. A WebAuthn authentication workflow demonstration can be seen at 9:23 in the session video. WebAuthn - Public / private key pairs - Trust comes from the web browser and the OS - Trust is not placed with the human - No server-side secrets - only public information is shared with the server - Server breach will not reveal secrets because the server never has them - Less work on the server side to protect secrets - Less attractive to attackers because no secrets are available to be stolen Security keys: - Easy to use - Works on all Apple devices - Works on many non-Apple devices - May not always be with you - Security level is very good - Not recoverable (backup system MUST be in place) - Very strong phishing resistance - Does not require shared secrets In iOS 14.5, Apple extended security key support to work in all browsers on iOS. Security keys in apps As of macOS Monterey and iOS 15, the following is available for security keys: - Security key API available for all macOS and iOS apps - API is being added to the ASAuthorization API family in the AuthenticationServices framework - Native equivalent to the WebAuthn API on the web - ASAuthorization API is your one-stop shop for getting signed in with whatever mechanisms the system supports - Passwords - Sign in with Apple - Security keys Passwordless authentication using key pairs is the next big thing in authentication technology Apple's contribution to a post-password world: Passkeys in iCloud Keychain - Stores a new type of credential, called a passkey, in an iCloud keychain - Passkeys are WebAuthn credentials - Storing them in iCloud Keychain means they are backed up to iCloud and synced with all your devices - Storing them in iCloud Keychain also means that they're stored in an end-to-end encrypted solution - Not even Apple can read the contents of an iCloud Keychain - Easy to use - Because of the combination of WedAuthn and iCloud Keychain's security, this is a stronger solution than most password and second factor solutions available today Right now, this solution works on all devices which support macOS Monterey and iOS 15. It is not available at this time for non-Apple devices. - Easy to use - Works on all Apple devices - Does not work on non-Apple devices - Always with you - Security level is very good - Recoverable via iCloud Keychain - Very strong phishing resistance - Does not require shared secrets A passkey demonstration can be seen at 17:34 in the session video. For more details on how passkeys are passed to apps and to browsers, see the "Introducing Password AutoFill for Apps" session from WWDC 2017: https://developer.apple.com/videos/play/wwdc2017/206/ To see how to write the code to register an account, please reference 20:20 in the session video. Transitioning away from passwords is going to take time In macOS Monterey and iOS 15, passkeys in iCloud Keychain is being released as a technology preview. - Off by default On iOS 15, there's a new setting in Settings: Developer. It's called Syncing Platform Authenticator (under the "Authentication Services Testing" section) and will allow you to use synced passkeys in both apps and in web browsers. On macOS Monterey, the setting is found in Safari's Develop menu. - First, the "Show Develop menu in menu bar" setting needs to be enabled in Safari's preferences under the Advanced settings. - Next, select "Enable Syncing Platform Authenticator" in the Develop menu. Passkeys are only meant for testing in macOS Monterey and iOS 15. They should not ever be used for production work. Please test this out with your apps and in your environment to see how it fits into your existing workflows.