- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
There are a few cases where the browser acts as password manager software. It will store your passwords to safely save you time and efforts. Where it sounds like a good plan, there are times when you get an unexpected memo from the headache department. Sometimes Chrome, Firefox and IE will set autocomplete for your password to "on" as a result of passwords being saved for specific instances. We clearly set HTML on the password fields to say "do not auto-complete" but can be ignored.
In Chrome auto-complete for passwords is ON by default. To double check, just open your Chrome settings then go to advanced, and select "auto-complete passwords" ON. After that, to access your settings, go to: chrome://settings/passwords to manage your passwords in Chrome.
If everything works fine, when you login into the instance the first time, Chrome will allow you to save the password.
To see all of your passwords saved on Chrome, navigate to chrome://settings/passwords
This works fine and the next time you try to login, it will auto-complete the password. You can recognize it because the background of the field usually changes to yellow to indicate that autocomplete is working.
When everything goes smoothly, you can efficiently login to your instance and save yourself the hassle of having to remember your password with auto-complete.
When the browser password management changes go wrong
I worship the ground Chrome walks. As painful for me as it is, there are some cases when the password fields are auto-completed even when it should not be. On Chrome, the browser matches the password with the "previous" field (not necessarily the login name). On ServiceNow, password fields could be anywhere in the form and even when the autocomplete="off" is set on them, some browser just ignore them.
Example #1: The User form (sys_user)If you open our sys_user form, change the password and click "update" (similar to form submit), the browser will try to save the password and associate it to the previous field. In this case, it will associate the password value with the 'Department' field. If you open any other user from the same department, the autocomplete will incorrectly auto-complete the password. Saving the record will override the password. It will even ask you to save when leaving the form even if you have not changed anything. To avoid this problem of having the password associated with the wrong user, move the password field below an unique field like User ID or disable auto-complete. Example #2: The X.590 formAnother form with a similar problem is X.509 Certificate (sys_certificate). If auto-complete is enabled and have records, it will set the key store password that can cause problems on some integrations. You can move the password field below an fairly unique field like Name or disable auto-complete to avoid the it from setting the key store password. Example #3: SOAP message formOn the SOAP message (sys_soap_message), the basic authentication fields get auto-completed. These fields can be overwritten when saving the form by the values auto-completed. The problem here is that both fields are initially empty. |
Luckily, the auto-complete password problem will only affect forms with password fields. The complexity of the problem is that it could happen when users are UNAWARE of the auto-complete. Also, the password is saved to the whole domain (service-now.com sometimes) so it will cross into different instances or forms (e.g. passwords set on the sys_user form, then recalled by the browser on sys_soap_message (as showed on example #3). Note that most sophisticated password managers like Lastpass, Keepass, 1password, etc do not have the same problem as IE, Firefox and Chrome have. Also, Opera and Safari seems to work fine as well.
Here are the list of forms that can be affected by the browser password auto-complete:
Table | - | Column name |
digest_properties | - | secret_key |
discovery_credentials | - | privacy_key |
discovery_credentials | - | password |
discovery_credentials | - | ssh_passphrase |
discovery_credentials | - | authentication_key |
instance | - | database_password |
instance | - | admin_password |
ldap_server_config | - | password |
oauth_entity | - | client_secret |
saml2_update1_properties | - | signing_key_password |
sys_certificate | - | key_store_password |
sys_data_source | - | scp_password |
sys_data_source | - | jdbc_password |
sys_email_account | - | password |
sys_rest_message | - | basic_auth_password |
sys_rest_message_fn | - | basic_auth_password |
sys_soap_message | - | basic_auth_password |
sys_soap_message_function | - | key_store_password |
sys_soap_message_function | - | basic_auth_password |
sys_update_set_source | - | password |
sys_user | - | user_password |
sys_wss_profile | - | user_password |
In a nutshell, if you are using auto-complete password on your browser, you need to be extra cautious. If the password fields are NOT next to a non-empty or unique field to allow the password managers to link to the correct value, then it's safer to disable the auto-complete function for good. If you see YELLOW background, then you are in trouble. I personally use most sofisticated password managers like Lastpass, 1password or Keepass.
I have tested this using Chrome 48.0.2564.116 as browser and on Fuji release.
More information here:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.