Defence in depth - too often I hear "whelp, we had a tiny crack in one of our measures, so it's game over, why even try?".
Imagine the scenario where service A has read-only access to the authentication db/table, whereas service B (which could be maintained/operated by an entirely different person/team that leverages a more stringent code review process, or simply one performed by better eyes) has write access to that same db/table - the credential database could be leaked but due to a variety of measures in place further compromise through that specific avenue is mitigated.
One of the primary goals of "security" is to stop an attacker from accessing things or being able to perform actions that they "shouldn't" be able to access/perform. When dealing with humans it is incredibly difficult to decisively achieve that goal. It could be a zero day, a vulnerability in a code dependency, or otherwise some service dependency or other such software (say an internal analytics system with its own entirely separate models and storage of data) that leads to a breach - the bigger the team/company, the more people involved, the higher the chances that someone makes an inadvertent (or intentional) mistake somewhere.
I do not agree that a compromise of any form should be considered a reason to not attempt to build a secure system resilient to layers and layers of human failure.
Comments
Defence in depth - too often I hear "whelp, we had a tiny crack in one of our measures, so it's game over, why even try?".
Imagine the scenario where service A has read-only access to the authentication db/table, whereas service B (which could be maintained/operated by an entirely different person/team that leverages a more stringent code review process, or simply one performed by better eyes) has write access to that same db/table - the credential database could be leaked but due to a variety of measures in place further compromise through that specific avenue is mitigated.
One of the primary goals of "security" is to stop an attacker from accessing things or being able to perform actions that they "shouldn't" be able to access/perform. When dealing with humans it is incredibly difficult to decisively achieve that goal. It could be a zero day, a vulnerability in a code dependency, or otherwise some service dependency or other such software (say an internal analytics system with its own entirely separate models and storage of data) that leads to a breach - the bigger the team/company, the more people involved, the higher the chances that someone makes an inadvertent (or intentional) mistake somewhere.
I do not agree that a compromise of any form should be considered a reason to not attempt to build a secure system resilient to layers and layers of human failure.