That is not a fair assumption. The reason being that you know nothing about the type of vulnerability that they are exploiting. For example, if the site has a S

That is not a fair assumption. The reason being that you know nothing about the type of vulnerability that they are exploiting. For example, if the site has a SQL injection attack, user separation in the database would prove quite useful. > but I don't think you necessarily want it as the linchpin of your encryption strategy. Its not about having one thing at "the linchpin". In fact, you should not rely on any singular thing, but rather separate out pieces of information so that no part has more than it needs. The test user should not have access to the production database and vice versa. In sum, you should use multiple things to defend yourself, not just one.