I work with an organization that uses some very poor practices such as using default user accounts, default passwords (or passwords the same as user accounts), sharing password information between users, ect.

I've tried to keep my parts of our codebase/ect secure, my programs use proper database logins and permissions, strong passwords ect. But my programs are vulnerable to the greater organization's flaws. If, for example, someone could get ahold of certain account information, the security in my applications is meaningless.

Can I help here and there to change this company's security practices or are my efforts doomed because of the "weakest links"? For the most part my security practices are only as safe as theirs.

  • 1
    I'd be curious to know how much time (total) is lost due to password-related issues in a company with strong password policies vs weak ones. In my entire life I've never had to spend time to deal with a lack of stringent password enforcement on internal systems (ones that require physical access), but I spend an increasing amount of time dealing with password issues as the password requirements become more stringent. This also spends the help-desk's time. External passwords are a different issue, of course.
    – Bill K
    Feb 29, 2012 at 20:46

3 Answers 3


I recently came across this article written by Ross Anderson. Apart from pointing out to your colleagues how quickly bad passwords can be broken, it is worth noting that their research showed some benefits in just reminding people some good rules for passwords and having a basic induction into password choice.


If possible, look for why people are choosing default passwords or sharing accounts and see if there is a way around this. Consider the example of ssh-ing into multiple servers and allowing some of the support staff to do the same. Rather than having a single password that everyone knows, you can use keys here so that they don't need to remember anything. They just log in with the key. If you need to revoke the key, remove it from the server (this is obviously just an example).

Education is the key as well as ensuring people can still easily get on with their jobs. Just demanding everyone chooses a length 16+ password, with multiple cases & special chars which they then have to type in 25+ times a day is not an acceptable solution. They simply won't do it and will fall back to using a 6 character password they use everywhere else as it is easier.

  • 3
    +1. People will do things they don't understand, or they will put up with things that are annoying. They will rarely do both at once. Longer passwords are more annoying, so you'll have to make them understand via some demonstration other than "I told you so."
    – Jeff Ferland
    Feb 29, 2012 at 15:43
  • There is no perceived gain in better passwords; only increased inconvenience. Linking better password policies to an even greater inconvenience, or a perceived gain greater than the inconvenience can work. It's not about the policy, it's about the framing of the situation.
    – schroeder
    Feb 29, 2012 at 17:09
  • Bad SSL certs on that website, there.
    – Iszi
    Feb 29, 2012 at 17:46

Ask if they have a security policy. If not, find out if anyone would be responsible for creating one. If not... consider proposing a policy, something like this, but tweak it... it's got some problems : http://www.sans.org/security-resources/policies/Password_Policy.pdf

Throw in a caveat that when the policy is in conflict with an existing policy, such as PCI, the stronger policy wins. Add a review clause (e.g., annually) a questions-directed-to notice, an exception process, and versioning with a date. If anyone has questions, suggest they attend your annual meeting.

Introduce it with an announcement and review period, e.g., 3 months. Allow for feedback. Hold your first meeting. Hand it to management and hopefully have it declared a policy.

Then develop a process for your team to manage passwords. Suggest the process as a guideline for other teams to create a policy-compliant process.

Once in place, consider tools to audit password strength.

edit: btw, I agree with @webtoe on this one. This is an area IMHO where the old password policies like the one at SANS need tweaking. E.g., 8 characters, mixed case, alphanumeric, special characters, no dictionary words, blindly requiring 30 day password change policies, forbidding ssh-to-root, demanding no writing of passwords down, etc, is just asking for trouble. OTOH, if you give too much flexibility, people will get sloppy. Every aspect of password management needs a rationale and should be able to be challenged.

One of the stupidest password policies I encountered required an automated scan using a tool which would check for password strength. My automation IDs for SSH got hit repeatedly because password authentication was disabled, only public/private key was permitted. Unfortunately this meant that I had to create a cron job to create a random password every 90 days. It wouldn't communicate it, but the policy effectively reduced the security of the solution.


Don't. Use SSO: https://en.wikipedia.org/wiki/Security_token.

If people have to remember something not directly related to their activity, they will write it down, or even use a single weak and easy password for everything. Forcing them to choose a good password like '!@#aa$ogh443\' will just drive them crazy. If it's your job to care about security, then care about the people. A weak remembered password will always be stronger that a 44 character password written on a note next to the keyboard.

Give them the authentication token, they should carry it always with them so choose a small and good looking one ;). It may require some additional work behind the scene to get everything working with it, but it's not impossible and it makes everything more standardized and easy to manage in the end.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .