I connect to the VPN of another company with a company-specific username and password (they aren't giving everyone the same password to every company to access it or anything ridiculous like that.) After one of our employees left, I contacted this company about updating our password. I was told they are unable to change passwords and can only issue new usernames. Doing this would mean about two months of being unable to use their system due to paperwork and bureaucracy, so obviously quite an inconvenience.

Is there any reason besides poor design that their system would not be able to accommodate a password change? Passwords are also recoverable. This is a large company and there are probably a few hundred companies using this system, and as it is government-related there are no alternatives.

I'll go with others and doubt that there's a good reason to prevent a password change (what if the password was compromised?). But there's something weird on your side as well: you mention a “user-specific username and password”, and then you talk of “our password” and of an employee having left. If an employee has left, shouldn't you disable his account, and continue using other employee's accounts?
– Gilles 'SO- stop being evil'Oct 28 '11 at 9:44

@Gilles - That was bad wording on my part. Should have said company-specific.
– John StrakaOct 28 '11 at 10:18

1

If passwords are recoverable, please add this prestigious company to plaintextoffenders.com. (Or maybe you can check if they are already listed there).
– sampathsrisSep 29 '14 at 14:20

3 Answers
3

I agree this must be bad design. You may want to have password stability over certain periods for synchronization across systems or when a new system is integrated into a larger system. Except for those circumstances, you want to be able to change a password whenever a password may have been exposed, which could be anytime.

The only thing I can think of is that the password is used for a secondary purpose, such as making a digital signature of every person who read a particular document. In a case like this where the password is used to keep a record of an individual's action it would be complicated or confusing to change passwords. However the easy solution is to issue a password for authentication and another cryptovariable for digital signatures.

I think the root of it is poor design as you said. Everytime I've seen a system that can't change a password, it has been developed in such a way for various reasons, none of which are for the sake of security, and none of which are where it's the best solution to a problem.

The only design that I can think of that comes remotely close is where you have an identity management system that syncs disaparate accounts across legacy/incompatible systems with a central account store and the only way the passwords can stay in sync is if the password is changed at the central location. I don't think this is the case though, because you say they can't change it at all. Either that or the management system is being controlled by another department and it's just a political thing, etc.

What if a system can handle the scenario where one machine knows a user and his password, but the other doesn't (the machine which knows the password is "right"), but not the situation where two machines both know of an account but the passwords don't match? A properly-designed system should be able to determine which password is "newer", but if a system didn't include such information it might not be easy to retrofit. A requirement that one create a new account when changing the password may be irksome, but wouldn't necessarily imply an insecure design.
– supercatFeb 2 '14 at 20:31