Overview Passwords are not a very good form of authentication. They are easy to use but they are trivial to steal, either through phishing, malware, or a malicious/incompetent site owner. Furthermore, since people are so apt to reuse passwords losing one password leaks a substantial amount of your internet identity. Chrome's long term solution to this problem is browser sign in plus OpenID. While implementing browser sign in is something that we can control, getting most sites on the internet to use OpenID will take a while. In the meantime it would be nice to have a way to achieve the same affect of having the browser control authentication. Currently you can mostly achieve this goal through Password Manager and Browser Sync, but users still know their passwords so they are still susceptible to phishing. By having Chrome generate passwords for users, we can remove this problem. Design Generating and Updating Passwords Detecting when we are on a page that is meant for account sign up will be most of the technical challenge. This will likely be accomplished via heuristics (i.e. there is an account name field and two password fields). If we determine that this is a signup page, then we will add a small UI element to the password field.   If the user clicks on this element, we will pop up a small dialogue box next to field which is prepopulated with what we think is an acceptable random password. The reason we don't just choose a password for them is that many sites have requirements (e.g. must have one digit, must be alphanumeric, must be between 6 and 20 characters) some of which may be contradictory between sites. So we will choose a default generator that will work on most sites, but users may need to change our password if it doesn't work. We can skip this for sites that have "pattern" set on the password field. Long term we can hopefully also gather some aggregate information from users who opt-in to help improve Google Chrome about the form of passwords they generated so that this whole process can be skipped for the vast majority of sites.   After accepting the password, both password fields are populated, and normal password management handles the rest. TODO(gcasto): Figure out what to do about cases login page has autocomplete=off, but the signup page doesn't. This could leave users in a bad situation. Determining if a page is meant for changing passwords should use approximately the same heuristics as for signup pages. We can probably distinguish between the two cases by simply knowing if the users is currently logged into this site. When the user actually goes to update their password, we can either autofill their old password on page load or when the box is selected and the user clicks on a UI element (assuming that this feature is used for the currently signed in account). Which we choose is a matter of usability and how low our false positive rate is for detecting the correct password field. The password field to enter their new password will show the same UI as during account signup. Retrieving Passwords While generally it's good that users don't know their passwords, there are times when they will need them such as when they aren't able to use Chrome. For these cases, we will have a secure password storage web site where users can sign in and view (and possibly export?) their passwords. Since it should be relatively rare that users need this, and since this information is valuable, having users solve a Captcha before getting this information seems wise. We may also want to prompt users to enroll in StrongAuth when they first start using this feature. Implementation The UI for this feature is split across the browser and the renderer. The key icon is done in the renderer so that it correctly follows the text field that it is attached to. The bubble is displayed by the browser because we want it to look like Chrome not content. A more detailed description follows. Renderer PasswordGenerationManager is responsible for showing the key icon using the WebKit API defined in TextFieldDecoratorClient. This attaches a shadow DOM element to every password input field in the page, but with styling so that it isn't visible (display:none). Once the page is fully parsed, we iterate over all the forms and try and determine if the form corresponds to account creation. If we believe that a form does, we make decoration visible. Clicks on this icon are forwarded to the browser to show the bubble. If the password is accepted in the bubble, we fill in the associated password field(s). Browser AutofillManager takes messages from the renderer and makes an OS specific bubble. These bubbles use a PasswordGenerator to create a reasonable password for this site (tries to take in account maxlength attribute, pattern attribute, etc.). If the password is accepted, it is sent back to the renderer. Caveats Users must have password sync enabled Since users are not going to know their passwords, we need to be able to retrieve it for them no matter which computer they are using. Not all websites can be protected Any website that has autocomplete turned off will not be able to be protected. Going by current phishing attacks, this means that 40-70% of phishing pages can't be protected against. Once this feature is rolled out we probably want to see if we can get around this problem. Maybe we can get users to re-authenticate to the browser before logging into such sites. Users are only protected for new passwords We will not force users to use this feature, we simply suggest it when they sign up or change their password. After it's been running for long enough, it might be reasonable to prompt users to change their passwords when they login, but this is likely to annoy some users. Feature makes Google a higher value hijacking target Google is already a high value target so this shouldn't changes much. Moreover it's easier for us to make logging into Google more secure via StrongAUTH than have every site on the internet secure itself. At some point in the future it might also be possible for us to automatically change all of a users passwords when we realize that their account is hijacked. |
|
For Developers > Design Documents >
Password Generation |
