I use Lastpass and I'm testing out other password managers in order to set policy for organizational use. Depending on settings, I've found that these programs can automatically send your password out to unexpected places. For example:

Password Safe: The "browse to URL and autotype" feature of Password safe opens the default browser, enters username and password and generates a carriage return! In IE and Chrome, this results in a web search with my password as the search term, broadcasting my password to an unexpected place.

LastPass: Lastpass sometimes has trouble differentiating between "hr.company.com" and "testing-apps.hr.company.com". I enabled auto-login for hr.company.com. Lastpass then tried to auto-login to testing.hr.company.com and failed. Since we are testing, this generated a log file entry containing my credentials for hr.company.com. Forced me to quickly change my password and re-evaluate my use of auto-login settings.

My question is this: These can't be the only examples of unsafe use of password managers. What other gotchas are out there? Can anyone recommend guidelines for safe use of password managers in an organization?

  • Password Safe: Good, because no "cloud" storage." Browse to URL: Bad! I wasn't aware of the vulnerability you point out, but I still want to get to the URL myself. – Bob Brown Dec 16 '14 at 0:39

The hostnames hr.company.com and testing-apps.hr.company.com will not cause proper browser security model segregation - it is possible for hr.company.com to set cookies than can be read by testing-apps.hr.company.com and testing-apps.hr.company.com will be able to set cookies on the hr.company.com domain. So you have to trust both hr.company.com and testing-apps.hr.company.com in order to use either, so it could be argued that LastPass accidentally completing the password details on one application is not that big of a flaw - the testing environment should be on a completely separate domain to prevent any vulnerabilities found from exposing the live domain. Additionally, passwords should never be stored in log files so while it could be considered a small bug (maybe it should prompt before filling a form on a different subdomain), it is not a huge security weakness in itself - the underlying web application needs to be trusted, which includes considering the browser security model. It could be that testing-apps.hr.company.com is only available internally. however this could allow a local attacker to compromise another employee's live account using a flaw on the test version.

In this case you can make this particular password manager more secure by configuration. e.g. disabling auto fill, and there is also an option in settings called URL Rules. Here you can set whether the hostname has to be an exact match. You cannot stop people using software in an insecure fashion, you can only guide and educate them, as you have pointed out.

My question is this: These can't be the only examples of unsafe use of password managers. What other gotchas are out there? Can anyone recommend guidelines for safe use of password managers in an organization?

There will be flaws in all applications, whether at enterprise level or not. The advantage of browser based password managers is that is can protect against phishing attacks. The URL is validated and as default only the credentials saved for that URL will be completed. If this is something you want to protect against then you will pretty much need to use a browser based password manager. If using something browser based is too much of a risk then you can use a separate application, but you must accept that an unwitting user may accidentally log into a wrong website, whether a malicious one or not, potentially exposing their login credentials to a 3rd party.

The specific guidelines will differ depending on the software used and how passwords are used within the organisation, as well as the organisation itself. For example. does the organisation trust the cloud, or is everything done in house? Storing password data on trusted internal servers might be better, however the organisation is then taking on the extra work of making sure the infrastructure is properly secured and ensuring that the data is properly encrypted and encryption keys are securely stored.


Password management tools like Lastpass are storing your data on their servers which is what lead to their huge vulnerability earlier this year. While Lastpass may be great to use for home based machines, enterprise password managers do exist, and should reside in your infrastructure. There will be some who will debate: "the cloud is just as safe" to which I will state: "networks go down... if your cloud provider goes down... so too do your passwords." In either event, NIST has SP800-118: Guide to Enterprise Password Management it's in draft form, but should give some guidance

  • 1
    "There is no cloud; there's just a bunch of disks you don't own run by people you don't know." (That's not original, but I don't know to whom to give credit.) – Bob Brown Dec 16 '14 at 0:43
  • "Enterprise Password Managers do exist", like LastPass...? It's software. All software is going to have bugs. I've never heard of the PW Manager you linked to is the opposite of a service I would purchase to reduce my company's risk (hiring Sales in USA and engineering in India).... "Networks go down" so do internal networks and internal services. AFAIK, all of the big name commercial cloud PW managers cache locally, so this is not an issue for them. – user11869 Dec 23 '14 at 14:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.