3

We have a number of internal development environments that use weak passwords in the Auth and SQL components; particularly using passwords such as "password" or "Password1".

These are obviously changed for UAT and Production environments but how guilty should we feel about relaxing our habits for the sake of ease while developing solutions?

Improve this question
2
  • 5
    What advantage do you get from using weak passwords? Are your developers constantly typing passwords in by hand? If your system design is such that using strong passwords is intolerable to your developers, what hope do your customers have of dealing with them?
    – jjanes
    Aug 26, 2014 at 6:23
  • @jjanes That's the crucial question, I think. There's no advantage other than it's a fairly consistent practice across most client dev environments.
    – Phil.Wheeler
    Aug 26, 2014 at 7:49

2 Answers 2

Reset to default
3

It is all a matter of trust and/or accountability. If your internal environment is completely secure/separated from the internet you can, but it is not generally a good idea.

Example: What happens if an employee is let go? Can you trust that person then? If attached to the internet that is very bad and I have seen it happen in companies I have worked for in the past.

-

Response to comments for clarity:

Stronger than 'password' or 'Password1' does not necessarily mean extremist. For production environments I ask my people to do better than that but not requiring codes bordering on extreme or ridiculous unless it is banking data or there is a high security risk.

Improve this answer
7
  • It is completely divorced. Has its own VPN and domain, so no external access. Purely for internal development.
    – Phil.Wheeler
    Aug 25, 2014 at 23:56
  • This is better, I would still want a good password setup. The old statement 'locks are designed to keep honest people honest' is a good mantra here. If I seem paranoid I have reason to be due to experience, but again it is all up to you and your trust level and need for accountability of each person's work.
    – Jeff Clayton
    Aug 26, 2014 at 0:00
  • 1
    I probably should tell you reasons for my answer. I have seen trusted people delete things upon being fired, other trusted people misrepresent records that translated to large sums of money lost, seen people claim other people's code was their own, and worked where trusted people embezzled. All of these were in situations of supposedly trustworthy coworkers. Much of my job was to attempt to clean up or recover from many of these messes. It taught me to be of a 'safer than sorry' mindset over time.
    – Jeff Clayton
    Aug 26, 2014 at 0:24
  • 2
    One additional thing you will need to take into account is the fact that lower security usually means better usability. Surprisingly, this is not really a good thing in dev because it means the devs aren't always aware of the consequences of their choices for the user - for instance, requesting password multiple times
    – Stephane
    Aug 26, 2014 at 7:33
  • 1
    If you cannot make your employees accountable for their actions on a shared login you're in for issues described by @JeffClayton, But luckily this has little to do with whether the password is weak or strong, so I'd act upon that and leave a basic easy password. Jeff look up The Great Authentication Fatigue, simpler passwords can matter when typed 20 times a day.
    – Steve Dodier-Lazaro
    Aug 26, 2014 at 12:39
1

The other answers have touched on pieces of the puzzle, but the high level view is this: All of security boils down to risk assessment, risk management, and risk mitigation.

Because of this, there is no generic answer for your question. Here are some of the sorts of things you need to look at to determine whether or not this practice is acceptable in your environment.

  1. Do you control who has access to the system? (You do in this case, since you mentioned users need network access.)

  2. Who has access to the system? (Enumerating the users who could potentially access the system will give you a better idea of the exposure.)

  3. Do you trust these people? (This is going to be subjective, rather than objective, but it makes it an easy decision if the answer is "No.")

  4. What damage could be done if the system is abused? (If someone adds, edits, deletes, or steals data from the system, what is the cost? Is the data valuable, and could a salesperson who has access to the system be tempted to take it with him when he leaves the job, for instance? Or perhaps the systems contain nothing of value and can be easily and automatically re-based to a known good state.)

  5. What is the risk of the system being abused? (Still subjective, but based on what you know about the system and the users, what are the chances that someone might try to maliciously access the system?

  6. What is the cost of mitigating the risk? (In this case, mitigation is going to involve implementing a good password policy. Is that going to cause additional work for the developers?)

Once you've analyzed the risks to your systems, you can now make a quality, informed decision about whether there are risks that are worth the bit of extra effort to mitigate. If the risks are extremely low, as is not impossible to imagine for an internal development environment, it may not be worth it to make the developers lives even a little bit harder. If there's sensitive data involved however, or a malicious attack on one of your applications would have a significant cost to recover some and the likelihood of such an attack is non-negligible, than it's likely that the small additional effort required for strong passwords may be worth that cost.

Improve this answer

You must log in to answer this question.

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