存储数据库密码 [英] Store database password
问题描述
我们陷入两难境地。我们将数据库密码存储在位于Web根目录之外的include
文件中。密码是普通的
文本。因此，没有人可以获得该密码，因为它无法通过Web服务器提供
。到目前为止，这么好。
客户想要加密我们所有的密码。那么，我如何安全地加密密码？
？如果我使用mcrypt，我必须
存储一个密钥和一个IV的某个地方...如果这些是明文的话，我
也可能只是存储密码用明文。也就是说，我用
可以用给定的密钥和IV加密密码，然后硬编码
将密钥和IV放入我的应用程序并将加密密码放入
数据库。但是，那里真的没有安全感。
还有其他人做过这样的事吗？
谢谢。
Pat
>我们陷入两难境地。我们将数据库密码存储在驻留在Web根目录之外的include文件中。密码是简单的
文本。因此，没有人可以获得该密码，因为它不能由Web服务器提供。到目前为止，非常好。
客户想要加密所有密码。那么，我该如何安全地加密该密码呢？如果我使用mcrypt，我必须在某个地方存储一个密钥和一个IV ...如果这些是明文的话，我也可以只用明文存储密码。也就是说，我可以使用给定的密钥和IV加密密码，然后将密钥和IV硬编码到我的应用程序中并将加密的密码放入
数据库。但是，真的没有安全性。
你必须存储< something>这会让你进入数据库。
无论如何< something>是的，它也可能是纯文本，
因为根据定义它可以让你进入数据库，虽然你可以把它分开并分散它周围的部分（这是安全的
默默无闻，这通常意味着安全性不高）。如果你进一步加密，那么解密的密钥就会成为访问数据库的< something>
的一部分。
基本上，你被搞砸了，虽然有一些安全性来自
默默无闻。技术并非百分之百无用（必须计算
真实密码比在某个文件中使用它更困难。
某处）。
Gordon L. Burditt
我有坏消息。有些方法可以混淆你正在做的事情，
但最终你会向数据库发送一个明文密码。
这就是它所需要的。这意味着任何能够查看您的DB
交互代码的人都能够破译您的应用程序
密码是什么。
这就是为什么你限制你的web数据库用户访问本地主机（所以
来自外面的人不能使用那个用户名/密码，即使你告诉
它给他们）。有一个单独的用户名/密码用于外部数据库访问。
我还建议你限制你的网络数据库用户的权限所以
它不能改变/创建/ drop / etc如果你的应用程序不需要
就这样做了。
你可以将MD5 / base64编码成一些密码，并使用那个
文本作为你的申请密码。当他们问，说这是一个MD5
哈希值。它是明文，但至少它基本上是随机的
明文。这有点不诚实，但他们已经要求你做
不可能。
如果你将db交互用户限制在localhost（因为它是访问数据库的localhost上的
网络服务器，并且在某个文件中有你的
用户名/密码，那么唯一的方法就是
用户名/密码是进入你的系统，他们可以在你的系统中读取你的来源。如果他们能做到这一点，那就太晚了。
~D
Pat A写道：
我们陷入两难境地。我们将数据库密码存储在驻留在Web根目录之外的include
文件中。密码是简单的
文本。因此，没有人可以获得该密码，因为它不能由Web服务器提供。到目前为止，非常好。
客户想要加密所有密码。那么，我该如何安全地加密该密码呢？如果我使用mcrypt，我必须在某个地方存储一个密钥和一个IV ...如果这些是明文的话，我也可以只用明文存储密码。也就是说，我可以使用给定的密钥和IV加密密码，然后将密钥和IV硬编码到我的应用程序中并将加密的密码放入
数据库。但是，真的没有安全性。
有没有其他人做过这样的事情？
我去购买了ionCube编码器正是出于这个原因。我没有找到
任何其他方法在不到一两天的时间内无法解决的时间 - 当然是其他人的。 ;）
当然，使用ionCube还有一些额外的好处
有助于说服我的购买。 ;）
-
Justin Koivisto - ju **** @ koivi.com
http://koivi.com
We have a dilemma. We are storing our database password in an include
file that resides outside of the web root. The password is in plain
text. So, no one can get that password because it can''t be served up
by the web server. So far, so good.
The customer wants all of our passwords encrypted. So, how do I go
about securely encrypting that password? If I use mcrypt, I have to
store a key and an IV somewhere...and if those are in clear text, I
might as well just store the password in clear text. That is to say, I
could encrypt the password with a given key and IV, and then hard code
that key and IV into my app and put the encrypted password into the
database. But, there''s really no security in that.
Has anyone else done anything like this?
Thanks.
Pat
>We have a dilemma. We are storing our database password in an includefile that resides outside of the web root. The password is in plain
text. So, no one can get that password because it can''t be served up
by the web server. So far, so good.
The customer wants all of our passwords encrypted. So, how do I go
about securely encrypting that password? If I use mcrypt, I have to
store a key and an IV somewhere...and if those are in clear text, I
might as well just store the password in clear text. That is to say, I
could encrypt the password with a given key and IV, and then hard code
that key and IV into my app and put the encrypted password into the
database. But, there''s really no security in that.
You have to store <something> that will get you into the database.
Whatever that <something> is, it might as well be in plain text,
since by definition it gets you into the database, although you can
divide it up and scatter pieces of it around (which is security by
obscurity, which generally means not much security). If you further
encrypt, then the key to decrypt becomes part of the <something>
that HAS to be there to access the database.
Essentially, you''re screwed, although some of the "security by
obscurity" techniques aren''t 100% useless (having to calculate the
real password is a LITTLE harder than having it around in a file
somewhere).
Gordon L. Burditt
I have bad news. There are ways you could obfuscate what you''re doing,
but ultimately you are sending the database a cleartext password.
That''s what it requires. This means that anyone who can look at your DB
interaction code will be able to decipher what your application
password is.
That is why you limit access to your web db user to the localhost (So
someone from outside can''t use that username/password, even if you tell
it to them). Have a separate username/password for external DB access.
I also recommend that you limit the permissions on your web DB user so
it can''t alter/create/drop/etc if your application doesn''t require that
it do so.
You could MD5 / base64 encode some text into a password, and use that
text as your application password. When they ask, say that it''s a MD5
hashed value. It is cleartext, but at least it''s basically random
cleartext. It''s slightly dishonest, but they''ve asked you to do the
impossible.
If you limit your db interaction user to the localhost (since it''s the
webserver on the localhost accessing the db), and have your
username/password in a file somewhere, then the only way to get at your
username/password is to get into your system at a level where they can
read your source. If they can do that, it''s too late.
~D
Pat A wrote:
We have a dilemma. We are storing our database password in an include
file that resides outside of the web root. The password is in plain
text. So, no one can get that password because it can''t be served up
by the web server. So far, so good.
The customer wants all of our passwords encrypted. So, how do I go
about securely encrypting that password? If I use mcrypt, I have to
store a key and an IV somewhere...and if those are in clear text, I
might as well just store the password in clear text. That is to say, I
could encrypt the password with a given key and IV, and then hard code
that key and IV into my app and put the encrypted password into the
database. But, there''s really no security in that.
Has anyone else done anything like this?
I went and purchased ionCube Encoder just for that reason. I didn''t find
any other method that couldn''t be cracked in less than a couple day''s
time - by someone else of course. ;)
Of course, then there are some added benefits to using ionCube as well
that helped persuade my purchase. ;)
--
Justin Koivisto - ju****@koivi.com
http://koivi.com
这篇关于存储数据库密码的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
