当前位置:  开发笔记 > 数据库 > 正文

保持密码可配置的最佳方法是什么,而不会让随意的人类读者容易使用它们?

如何解决《保持密码可配置的最佳方法是什么,而不会让随意的人类读者容易使用它们?》经验,为你挑选了2个好方法。

我有一个数据库,许多不同的客户端应用程序(一些Web服务,一些Java应用程序和一些点网应用程序)连接到.并非所有这些都在Windows上运行(遗憾的是,否则只需启用数据库连接的Windows身份验证就可以解决这个问题).目前,密码存储在系统周围的各种配置/属性文件中.理想情况下,只有支持人员才能访问运行文件的服务器,但如果其他人获得对其中一个服务器的访问权限,他们将拥有足够的数据库权限,以便立即获得公平的数据查询.

那么我的问题是,保持密码可配置的最佳方法是什么,而不会让随意的人类读者轻易获得?

编辑只是为了澄清,DB服务器是Windows Server 2003,运行MSSQL 2005.

PS:我没有看到任何重复的问题,但如果有,请随时关闭这个.



1> WW...:

我假设您想隐藏临时观察者的密码.如果他们是邪恶的,钢铁般的观察者可以访问其中一台连接的机器上的所有源代码,那么他们可以通过一些逆向工程获得密码.

请记住,您不需要为每个不同的客户端使用相同的保护.几步: -

    为访问数据库的不同系统创建不同的数据库帐户

    使用内置数据库GRANT限制对数据库的访问权限

    在数据库的密码管理器类中存储三重DES(或其他)密钥.使用此选项可解密属性文件中的加密值.

我们还考虑过在启动时提供通行短语的应用程序提示,但是没有实现它,因为它似乎很痛苦,然后您的操作人员需要知道密码.它可能不太安全.



2> neesh..:

让我们假设以下常见场景:

您对所有环境使用相同的代码库,并且您的代码库具有每个环境的数据库密码.

可以访问生产应用程序服务器的人员(系统管理员,配置管理员)可以知道生产数据库密码,而不知道其他人.

您不希望任何有权访问源代码的人知道生产密码是什么.

在这种情况下,您可以将生产密码加密并存储在应用程序的属性文件中.在应用程序中,您可以包含一个类,该类从属性文件中读取密码并在将其传递给数据库驱动程序之前对其进行解密.但是,用于解密密码的密钥和算法不是源代码的一部分,而是在运行时作为系统属性传递给应用程序.这将密钥的知识与应用程序源代码分离,只有应用程序源代码访问权限的任何人将无法再解密密码,因为他们无法访问应用程序的运行时环境(应用程序服务器).

如果您使用的是Java看看这对于更具体的例子.该示例使用Spring和Jasypt.我相信这样的事情可以推断到像.Net这样的其他环境

推荐阅读
pan2502851807
这个屌丝很懒,什么也没留下!
DevBox开发工具箱 | 专业的在线开发工具网站    京公网安备 11010802040832号  |  京ICP备19059560号-6
Copyright © 1998 - 2020 DevBox.CN. All Rights Reserved devBox.cn 开发工具箱 版权所有