For a system currently being constructed, the user will need to log in to multiple systems with the same password. One system (A) is always leading, and the user can only change the password on system A. The new hash is then copied to system B and on. Each system B only has a subset of the credentials of system A.

For technical (deployment and connectivity) reasons we cannot use a single sign-on technology like OAuth to transfer trust. The systems B are rarely connected, so while we can push information from A to B, we cannot allow B to rely on a connection to A for its user validation. Of course we correctly salt and hash the passwords.

Now I wonder: is it bad practice for these systems, all of them under our control, to share the same password hash for a user?

  • Why not use a shared database?
    – Mr. E
    Sep 8, 2017 at 13:05
  • Technical reasons :) I'm just wondering whether this solution is bad practice, without getting into different solutions. Sep 8, 2017 at 13:06
  • Doing this you increase the attack surface of your system. I'm wondering what technical reasons let you send an updated hash over the network from system A to system B but does not allow you to connect from system B to system A. Just for curiosity is a valid reason too
    – Mr. E
    Sep 8, 2017 at 13:22
  • Updated question. Sep 8, 2017 at 13:23
  • you could salt/derive them more after duping, to prevent an insta-fail should one get owned. the password will still work as long as you repeat the whole chain.
    – dandavis
    Sep 8, 2017 at 14:35

2 Answers 2


The issue with this design is that there are now multiple points of failure. A compromise of the database for application A now compromises the security of application B. You also have more transport security to worry about. An attacker can theoretically get a MITM for the password copy from application A to application B. A traditionally designed application does not suffer from this flaw.


As you know, this means that if someone compromises any one of the systems, they have compromised all of them.

Such a system is vulnerable to "pass the hash" attacks, where someone who can get into the network can view a hash on the network, copy it, and replay it to gain access elsewhere.

If your security efforts are being audited, such as if you're in scope for the PCI DSS, you'll likely have to spend a lot of extra effort compensating for them.

Are you sure you can't use a known and respected authentication solution like Kerberos, instead of rolling your own? Are you sure that the reasons you've giving (network connectivity and deployment) are valid, that your failure scenarios aren't already handled by existing products (for example, Active Directory can handle many forms of offline authentication) and that any potential disruptions actually outweigh the risks you're introducing with this system?

It's not so much a question of "is it bad practice"; it's up to your organization to decide if they're willing to accept those risks and costs.

  • 1
    Agreed, the attack surface is increased. Could you explain how this is vulnerable to a pass-the-hash attack? Systems B still validate using the password, not the hash. Sep 8, 2017 at 13:27
  • Let's say when the victim logs in to webpage A, the page hashes the password and sends it to the server, which approves it and returns a cookie. Now attacker copies the hash, and goes to system B. Instead of going to the page, he emulates the response of a login and transmits the hash. System B approves it and returns a cookie. You'd want to mitigate this by inventing your own challenge-response protocol; reinventing another thing that already exists. Will your home-grown system be vulnerable to the same flaws as all the other security systems, that have been broken and patched many times? Sep 8, 2017 at 14:15
  • @JohnDeters Why are you assuming the hashing happens client side? If System A and System B both validate the password independently, only using the same hash, I don't see how pass-the-hash applies. Sep 8, 2017 at 14:23
  • Hashing does not happen client side, it always happens server-side for both A and B. Sep 8, 2017 at 15:01
  • If you use a shared database, and that one database is compromised, then all systems are compromised too. Perhaps the rebuttal to this is: instead of spending resources protecting multiple systems, you can double your efforts protecting just one system, which (in theory) would make that one system harder to infiltrate.
    – TTT
    Sep 8, 2017 at 16:19

You must log in to answer this question.

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