As you probably know, Loader is a hosted service that allows you to load test web apps. We support HTTP Basic Authentication for servers under test that are password protected, so we allow a user to input a username and password that will be sent when the test is run. You might also know that HTTP Basic Auth is itself not secure – it is a base64-encoded version of the username and password, and can be easily decoded. We don’t take any additional measures to protect these fields, and as such, we don’t recommend users use production credentials in load tests.
Until recently, the password field was a plain text input, reflecting that this is not a secure place to put passwords. In our recent site-wide redesign of Loader.io, we changed the input type to “password.”
We recently got a support request from a customer, saying that Chrome was auto-completing the Basic Auth fields of the test with their Loader login credentials! This was a surprise, since we had set
autocomplete="off" HTML attribute on those fields which we thought would be sufficient to avoid precisely this issue. We quickly learned that Google Chrome ignores the
autocomplete attribute on password fields and autofills the fields anyway. Firefox will soon do the same. This is the Chrome security team’s reasoning:
This seems like a solid line of reasoning, and it is certainly good to encourage the use of unique and complex passwords. But, as we see in this situation the Chrome password manager’s insistence on autofilling everything backfired when we used a password field that was not intended for login credentials. “Change password” forms and a few other cases have similar problems. Additionally because that portion of the UI was hidden, it wasn’t apparent to the user that their password was being submitted, which definitely did not help!
Impact to Loader Users
When we audited the Loader database, we found that (presumably Chrome) had indeed auto-filled the “Basic Authentication” username and password fields with the Loader login credentials of about 200 users, including a few of the SendGrid Developer Services team! This had the following implications:
- While there was no compromise of our database or backups, it meant we were inadvertently storing Loader login credentials in plaintext.
- Users who were affected were unknowingly sending their Loader credentials in a Basic Auth header to those servers.
- While all of the Loader UI uses HTTPS, users may have been testing insecure (HTTP) websites, hence requests with Loader credentials could theoretically have been intercepted by third-parties.
Upon discovering this and realizing the impact, we immediately started rolling out a solution:
- Change the basic auth password field back to
type="text", so passwords are not autofilled by Chrome
- Remove user credentials from any test that had them in our database and backups
- Notify users who were affected to change their passwords
To prevent Chrome from autofilling the password field, we considered several options such as this one on StackOverflow, but ultimately we decided these solutions are probably not reliable. By simply not using a password field, we’re making it clear to the user that the contents of that field are not encrypted in our database and sensitive info should not be used there.
- Lesson 1: Don’t use
<input type="password">if you don’t intend to capture sensitive information and handle it securely
- Lesson 2: Don’t depend on autocomplete=off to keep browsers from using auto-complete
- Lesson 3: As always, don’t use the same password on any two sites!
Again, while we have no evidence of nefarious action as a result of this event, we’re taking every possible precaution by purging the sensitive information and encouraging affected users to change their passwords. If you were one of the Loader users affected by this issue, you should have received an email from us. As always, please feel free to contact us if you have additional questions or concerns.