如何在应用程序配置中管理密码

好的安全是很难的。

尽管安全性很难,但您可以做一些事情。

2) 默默无闻的安全不是真正的安全,但它有助于防止偶然的窥探。例如,将您的文件命名为“passwords.txt”不是一个非常好的主意,但是加密您的密码,然后使用隐写术在某些图像文件中隐藏用户/密码会更好。

3) 查找强加密/解密算法。其中一些已经在大多数语言中实现,您只需导入一个库即可。这可能是坏的,也可能是好的,这取决于你认为你想要这些东西有多安全。

但老实说,这个系统在安全方面确实很糟糕。理想情况下,你有一个两方认证,然后可信的中间人做所有的轮转和交易。例如,当您登录到您的计算机时,您告诉计算机您是授权用户。从那里你可以运行你所有的程序,他们不会询问或关心你的用户/通行证组合-只是你是一个授权用户。他们从操作系统(中间人)那里得到这些信息。见鬼,即便如此,使用openID来确定你是一个受信任的用户-他们不关心你的凭据在其他站点上是什么,只关心其他站点说“是的,这是一个有效的用户。”

关于真实的实例,web服务器将数据库登录详细信息以纯文本形式存储在服务器上。如果有人能访问你的服务器,你就完蛋了。但是保护这些密码不受不想要的机会主义入侵者的攻击,我个人喜欢额外的一层让我感觉更安全。安全总比抱歉好,对吧?

由于这些密码是用于外部系统的,因此谨慎的做法是使用另一层(加密)来保护这些密码。是的,通过默默无闻的安全是不好的,但你不认为它作为一个极好的威慑作用 如果 总得有人无意中发现了这些密码——纯文本密码只是乞求被拿走。

我建议使用1024位加密 a couple good algorhytms random salt 对于您加密的每个条目,这样即使一个条目的密码是强制的,解决方案也不会对其他条目起作用。随机盐渍防止彩虹表攻击,这迫使你的饼干使用蛮力,更耗时。

是的,这些防范措施似乎有些偏执,但如果我尝试破解自己的密码(当然是为了研究目的),我可以想象一些恶意的人会尝试什么。

An example of how the salt makes encryption more secure, even if the encryption key is known.

有些服务器需要在启动时加载对称加密的证书。为了解决这个问题,他们要求在启动时输入密码。所以它只存储在内存中。

赞成的意见:

• 无法从中提取主密码 ps fax

欺骗:

• 在没有用户干预的情况下,无法自动重新启动进程。这可能是为什么没有更多的人选择这个选项的最大原因。幸运的是,Web服务器很少崩溃。