你们的应用是如何存储数据库密码的 (转载) - 未名空间MITBBS历史存档

国际科技财经博客移民网络热点娱乐民生时事公众号

Redian新闻

>未名空间

>Java - 爪哇娇娃

你们的应用是如何存储数据库密码的 (转载)

你们的应用是如何存储数据库密码的 (转载)# Java - 爪哇娇娃

m*k2009-09-04 07:09

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*g2009-09-04 07:09

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*e2009-09-04 07:09

3 楼

再顺便加个密就行了

【在 g*****g 的大作中提到】

: Usually in a properties file for configuration.

k*r2009-09-04 07:09

4 楼

i always have a security concern.

【在 g*****g 的大作中提到】

: Usually in a properties file for configuration.

g*g2009-09-04 07:09

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*o2009-09-04 07:09

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*k2009-09-04 07:09

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*e2009-09-04 07:09

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*n2009-09-04 07:09

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*g2009-09-04 07:09

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*g2009-09-04 07:09

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 的大作中提到】

c*c2009-09-04 07:09

12 楼

好一点的app server可以加密啦，然后在connection pool里面用password alias.
jboss tomcat什么的好像不行

b*y2009-09-04 07:09

13 楼

Yes, keep it simple吧。不过jdbc里面也应该可以加密。但没必要。把操作系统搞的
secure一些就行啦.

【在 g*****g 的大作中提到】

: Usually in a properties file for configuration.

m*t2009-09-04 07:09

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 的大作中提到】

F*n2009-09-04 07:09

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*t2009-09-04 07:09

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).