保护数据库中的敏感数据，使用 H2 值得吗？
我目前正在设计一个 Web 应用程序，其中一项要求是保护用户凭据及其角色。现在 ofc 除了通常的 pwd 哈希 + salt +.... 我正在考虑将这些特定表放入加密的 H2 数据库中，并将其余数据放入 MySQL 数据库中。就我而言，H2 的优点是：内存存储，因此意味着访问速度更快；加密数据库，这样就可以在服务器受到威胁时提供额外的安全层。
我的问题：当需要额外的安全层时，这是一种常见做法吗？这意味着将登录信息（在我的例子中是敏感数据）与其他数据分开是个好主意吗？
谢谢
I am designing a web application at the moment, and one of the requirements is to secure the user credentials as well as their roles. Now ofc besides the usual pwd hashing + salt +....
I was thinking of putting those specific tables in an encrypted H2 database, and the rest of the data ina MySQL db. the advantages of H2 in my case are: in-memory storage, so means faster access; encrypted db so an additional layer of security in case the server gets compromised.
My question: is this a common practice when an additional security layer is demanded? meaning is it a good idea to seperate the login info (in my case, it is the sensitive data) from the other data?
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
好的，我在安全论坛上得到了答案，对于那些感兴趣的人，这是链接 https://security.stackexchange.com/questions/7062/securing-sensitive-data-in-a-db-is-using-h2-worth-it
Ok I got my answer at the security forum, for those interested this is the link https://security.stackexchange.com/questions/7062/securing-sensitive-data-in-a-db-is-using-h2-worth-it
我认为这并没有真正增加相关的安全层。
如果您的服务器遭到破坏并且您的服务器可以验证用户的凭据，那么无论谁破坏了您的服务器，也都拥有必要的数据来验证它（例如：您需要在服务器上存储加密密钥/密码来解密数据库，除非您在每次启动时输入它）。
而且：它使您的设置变得相当复杂，这本身可能会导致很多安全问题（“为什么组件 A 不能读取这个文件？哦，我会让它成为世界可读的”）。简单可能有利于安全。
I don't think that this really adds a relevant layer of security.
If your server is compromised and your server can verify the credentials of users, then whoever compromised your server has the necessary data to verify it as well (for example: you'd need to store the encryption key/password on the server to decrypt the DB, unless you enter it on each startup).
And: it complicates your setup quite a bit, which in itself can lead to lots of security problems ("Why can't component A read this file? Oh, I'll just make it world-readable"). Simplicity can be good for security.
如果应用程序非常简单我认为你可以只使用一种类型的数据库，例如MySql。您可以在将密码存储到数据库之前对密码进行哈希处理。请注意，散列与加密不同，您无法从散列密码中获取实际密码。当用户尝试登录时，您将散列用户输入的密码并比较已存储在数据库中的散列值。如果使用盐值，那么即使黑客可以访问散列密码，也很难获得实际密码。
对于更复杂的应用程序，我建议使用其中一台 ldap 服务器（例如 openladp）。然后您可以免费获得密码策略和哈希。
If the application is very simple I think you can use only one type of database, e.g. MySql. You can hash the password before storing in the database. Note that hashing is different from encryption in that you cannot get the actual password from the hashed password. When a user tries logging in you hash the user entered password and compare the hash value that is already stored in the database. If a salt value is used then it would be extremely difficult for a hacker to get the actual password even if she has access to the hashed password.
For a more complex application I suggest using one of the ldap servers (e.g. openladp). Then you get the password policies and hashing for free.