Allow browsers to save RSA Link username/password

[NathanielWallwo]

RSA has gone out of their way to prevent web browsers from storing their RSA Link username and password.  This promotes poor security practices, so RSA ought to allow us to use the password managers built into our browsers.

The initial login page ( https://auth.rsasecurity.com/IMS-AA-IDP/InitialLogonDispatch.do ) prompts for User ID.  In the HTTP code, the input form includes autocomplete="off".  Since there are no input fields with type="password", browsers honor the autocomplete="off" setting, and they do not store the username.

The next page ( https://auth.rsasecurity.com/IMS-AA-IDP/ProcessUserID.do ) prompts for Password.  In the HTTP code, the input form includes autocomplete="off".  Since there is an input field with type="password", some browsers ignore the autocomplete="off" setting, and store the password.  If there had been other input fields on that page, those would have been stored as well.   IE does not store the password.  Firefox and Chrome do store the password.

When I connect to RSA Link with Firefox, I have to type my username, then the browser knows my password.  That's annoying.

When connect to RSA Link with IE, I have to type my username, open Firefox's password manager, copy my password, close Firefox's password manager, and paste the password to IE.   That's REALLY annoying.

This page ( https://blog.0xbadc0de.be/archives/124 - "The war against autocomplete=off: let my browser remember passwords !") does a good job of addressing the various pros and cons.

The bottom line is that preventing browser storage of username and password forces users to compromise security, either selecting a weak password that they can remember, using the same password on unrelated sites, or recording the password somewhere else.  These are all much worse than just using the browser's password manager.

Recommended solution: Prompt for username and password on the same page.

[jeffshurtliff]

Hi Nathaniel‌,

Thank you for submitting this idea.  We are reviewing the request and performing the discovery phase in order to identify what effort is required to make these changes to the authentication process on RSA Link.

I will provide an update as soon as we have more information.

Thanks again,

Jeff Shurtliff, CISSP, CISM | Team Lead, RSA Link Team | Customer Success | RSA

Working Hours: Mon-Fri, 7am-4pm MST | 800-995-5095 | jeff.shurtliff@rsa.com

[DavidBaldwin1]

Jeff Shurtliff‌ this is a question that should definitely be reviewed carefully. Back in 2012 a colleague and me were working a project for a large web application. We discovered that we could convert a password to "plaintext" when a user chose to have the browser save the password. I then tried to see how many friends I could trick into giving me their Facebook password. 

Exploitation worked simply like this:

1. Ask to use friend's laptop

2. Goto facebook

3. Use browser's developer tool to change the field type from password to text

These screenshots were taken from friends machine literally 15 minutes ago. This form of social engineering can be done on both Chrome, Firefox, and IE. 

Note: User choose weak passwords anyways. So allowing password autocomplete does not increase the security of the password. Back in the day I could uncover most people's windows passwords using Opscrack because they were all under 14 characters in length. Using symbols did not have any effect on my ability to retrieve the password.

Cracking Windows XP passwords

[NathanielWallwo]

I agree that malicious parties who have access to your computer or browser will be able to access your credentials....  There are many attack vectors.

The current login implementation for RSA Link doesn't prevent users from storing their passwords.   It only prevents users from storing their email address, and forces users to type their email address each time they log in.  That's inconvenient for users, but it does nothing to improve security.

[DavidBaldwin1]

Now, I had a random thought that may prove useful. You could use javascript to covert the password to hash using a one-way encryption algorithm. This way its the hash that gets stored in the browser. This could be done as a part of the activities conducted when the user clicks "login" or hits "enter" on their keyboard. But the new hash would require you to employ 2-factor authentication methods -- like the way myfedloans.org, regions.com, Auth0 or some other institutions employs it.

It may even be possible to have the browser update the password hash each time the user logs in or based on some other predetermined frequency -- changing password or the salt each time will prevent the user from using the same encrypted hash to login. 

This way even with my described social engineering example-- the user would only end up with an expired hash. Or hash that can only be used if you know the original password.