2

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 '17 at 13:05
  • Technical reasons :) I'm just wondering whether this solution is bad practice, without getting into different solutions. – Angelo van der Sijpt Sep 8 '17 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 '17 at 13:22
  • Updated question. – Angelo van der Sijpt Sep 8 '17 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 '17 at 14:35
1

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.

| improve this answer | |
1

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.

| improve this answer | |
  • 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. – Angelo van der Sijpt Sep 8 '17 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? – John Deters Sep 8 '17 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. – AndrolGenhald Sep 8 '17 at 14:23
  • Hashing does not happen client side, it always happens server-side for both A and B. – Angelo van der Sijpt Sep 8 '17 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 '17 at 16:19

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.