m*****k
发帖数: 731 | 1 【 以下文字转载自 Working 讨论区 】
发信人: madmonk (madmonk), 信区: Working
标 题: 你们的应用是如何存储数据库密码的
发信站: BBS 未名空间站 (Fri Sep 4 09:58:56 2009, 美东)
你们的应用是如何存储数据库密码的。不会是像如下hardcode在程序里吧？
Class.forName(“oracle.jdbc.driver.OracleDriver”);
String url = jdbc:oracle:thin:@hostname:1526:myDB;
Connection myConnection = DriverManager.getConnection(url, “username”, “
password”); |
g*****g
发帖数: 34805 | 2 Usually in a properties file for configuration.
【在 m*****k 的大作中提到】
: 【 以下文字转载自 Working 讨论区 】
: 发信人: madmonk (madmonk), 信区: Working
: 标 题: 你们的应用是如何存储数据库密码的
: 发信站: BBS 未名空间站 (Fri Sep 4 09:58:56 2009, 美东)
: 你们的应用是如何存储数据库密码的。不会是像如下hardcode在程序里吧？
: Class.forName(“oracle.jdbc.driver.OracleDriver”);
: String url = jdbc:oracle:thin:@hostname:1526:myDB;
: Connection myConnection = DriverManager.getConnection(url, “username”, “
: password”);
|
g**e
发帖数: 6127 | 3 再顺便加个密就行了
【在 g*****g 的大作中提到】
: Usually in a properties file for configuration.
|
k***r
发帖数: 4260 | 4 i always have a security concern.
【在 g*****g 的大作中提到】
: Usually in a properties file for configuration.
|
g*****g
发帖数: 34805 | 5 If someone cracks into your application server, you are screwed anyway.
You may use simple masking to hide the password, but that doesn't really
help much.
【在 k***r 的大作中提到】
: i always have a security concern.
|
A**o
发帖数: 1550 | 6 agreed. in op's case, better put in a properties file so that
dev and prod can be different.
【在 g*****g 的大作中提到】
: If someone cracks into your application server, you are screwed anyway.
: You may use simple masking to hide the password, but that doesn't really
: help much.
|
m*****k
发帖数: 731 | 7 then where do you store the key?
for us now,
we store the db user/password in a xml after AES encrypted.
each time app starts with reading that file then init the DB connection.
while the key we use for AES is hardcoded in our app, now the question is,
if we want to have different key for different customer, how to store the
key. for the same DB, not only j2EE App, we also have Client/Server App,
and Web Service. Now all hardcode the key internally.
【在 g**e 的大作中提到】
: 再顺便加个密就行了
|
g**e
发帖数: 6127 | 8 俺们也是这样。不过目前还没有遇到需要换key的问题
【在 m*****k 的大作中提到】
: then where do you store the key?
: for us now,
: we store the db user/password in a xml after AES encrypted.
: each time app starts with reading that file then init the DB connection.
: while the key we use for AES is hardcoded in our app, now the question is,
: if we want to have different key for different customer, how to store the
: key. for the same DB, not only j2EE App, we also have Client/Server App,
: and Web Service. Now all hardcode the key internally.
|
F****n
发帖数: 3271 | 9 Agree, there no reason to encrypt password stored in the application server.
If the server is physically hacked, you basically have no way to protect it
. You only need to avoid exposing the password directly it in the source
code.
【在 g*****g 的大作中提到】
: If someone cracks into your application server, you are screwed anyway.
: You may use simple masking to hide the password, but that doesn't really
: help much.
|
B*****g
发帖数: 34098 | 10 ding
server.
it
【在 F****n 的大作中提到】
: Agree, there no reason to encrypt password stored in the application server.
: If the server is physically hacked, you basically have no way to protect it
: . You only need to avoid exposing the password directly it in the source
: code.
|
|
|
g*****g
发帖数: 34805 | 11 Back up the DB in daily base is the common practice I believe.
Application server, make sure you have all the right firewall
and security setup, but that's about it.
server.
it
【在 F****n 的大作中提到】
: Agree, there no reason to encrypt password stored in the application server.
: If the server is physically hacked, you basically have no way to protect it
: . You only need to avoid exposing the password directly it in the source
: code.
|
c*c
发帖数: 447 | 12 好一点的app server可以加密啦，然后在connection pool里面用password alias.
jboss tomcat什么的好像不行 |
b******y
发帖数: 9224 | 13
Yes, keep it simple吧。不过jdbc里面也应该可以加密。但没必要。把操作系统搞的
secure一些就行啦.
【在 g*****g 的大作中提到】
: Usually in a properties file for configuration.
|
m******t
发帖数: 2416 | 14
server.
it
I respectfully disagree with all of you. 8-)
An encrypted (e.g. gpg) password still offers
some protection even when the server is
physically hacked.
Also from a legal standpoint, encrypting passwords
is considered part of the "due diligence" effort
in protecting customer data. I believe both SOX and
PCI compliances require it (which my client is
currently painfully going through).
【在 F****n 的大作中提到】
: Agree, there no reason to encrypt password stored in the application server.
: If the server is physically hacked, you basically have no way to protect it
: . You only need to avoid exposing the password directly it in the source
: code.
|
F****n
发帖数: 3271 | 15 You are completely right if its "customer data". But the application server
is not customer data. You only need to keep the password in a property file
and make sure all parties visit the files are secured. In this case, all
parties include programs on the server. The communications between those
programs and the files are internal because they are all "inside the wall".
Encrypting data among them is technically unnecessary (although may be
politically required).
【在 m******t 的大作中提到】
:
: server.
: it
: I respectfully disagree with all of you. 8-)
: An encrypted (e.g. gpg) password still offers
: some protection even when the server is
: physically hacked.
: Also from a legal standpoint, encrypting passwords
: is considered part of the "due diligence" effort
: in protecting customer data. I believe both SOX and
|
m******t
发帖数: 2416 | 16
server
file
.
The idea (of SOX and PCI and other security auditing measures) is that
we can't simply trust everybody just because they are all "inside the wall".
Very much so.
【在 F****n 的大作中提到】
: You are completely right if its "customer data". But the application server
: is not customer data. You only need to keep the password in a property file
: and make sure all parties visit the files are secured. In this case, all
: parties include programs on the server. The communications between those
: programs and the files are internal because they are all "inside the wall".
: Encrypting data among them is technically unnecessary (although may be
: politically required).
|
t*******e
发帖数: 684 | 17 Developers should have no exposure to the db credentials for the production
environment. And that is the intent of JNDI datasource lookup. |
