avatar
how do u store secrets?# Java - 爪哇娇娃
c*1
1
最近忙于私事,很少上来玩,今天发现这里有很多古诗的课要好好上,正在拿着本本记
记记,顺便奔个家的一角,呵呵。那也算是我的座右铭。以前我父亲说我不应该拿这个
当自己的座右铭,因为我本来就够糊涂的,呵呵,以后要改成难得聪明,嘿嘿。
avatar
J*w
2
广告词“把握精彩,印证未来”怎么翻译比较好?
thanks in advance.
avatar
c*n
3
like db password,
if the code is able to read it, then that means every intruder can also read
it. so storing them in a file exposes a security risk.
but otherwise you have to let people manually type in keys every time
avatar
t*t
4
要盖一个甚至印章再签名, 不然总觉得缺点什么.
avatar
a*a
5
What the commercial is for?
In general, how about 'Secure the moment, future success in hand'?

【在 J*****w 的大作中提到】
: 广告词“把握精彩,印证未来”怎么翻译比较好?
: thanks in advance.

avatar
B*g
6
一般来说写在纸上,哈哈

read

【在 c******n 的大作中提到】
: like db password,
: if the code is able to read it, then that means every intruder can also read
: it. so storing them in a file exposes a security risk.
: but otherwise you have to let people manually type in keys every time

avatar
x*u
7
哈哈,俺来题诗:
祖宗之法犹可变,能无小如旧韵诗?昨日糊涂不糊涂,至今老思王安石。

【在 c**********1 的大作中提到】
: 最近忙于私事,很少上来玩,今天发现这里有很多古诗的课要好好上,正在拿着本本记
: 记记,顺便奔个家的一角,呵呵。那也算是我的座右铭。以前我父亲说我不应该拿这个
: 当自己的座右铭,因为我本来就够糊涂的,呵呵,以后要改成难得聪明,嘿嘿。

avatar
f*k
8
control the brilliance, confirm the future

【在 J*****w 的大作中提到】
: 广告词“把握精彩,印证未来”怎么翻译比较好?
: thanks in advance.

avatar
m*r
9
you can use an one way hash.

read

【在 c******n 的大作中提到】
: like db password,
: if the code is able to read it, then that means every intruder can also read
: it. so storing them in a file exposes a security risk.
: but otherwise you have to let people manually type in keys every time

avatar
s*a
10
荆公作诗还是挺讲究格律的

【在 x*****u 的大作中提到】
: 哈哈,俺来题诗:
: 祖宗之法犹可变,能无小如旧韵诗?昨日糊涂不糊涂,至今老思王安石。

avatar
F*r
11
Passion/Excitement in hand, future in sight.

【在 J*****w 的大作中提到】
: 广告词“把握精彩,印证未来”怎么翻译比较好?
: thanks in advance.

avatar
r*l
12
Hash is not going to work since it can only verify.

【在 m****r 的大作中提到】
: you can use an one way hash.
:
: read

avatar
x*u
13
大概也是押旧韵罢。:)
不过我是指他的三不足。

【在 s********a 的大作中提到】
: 荆公作诗还是挺讲究格律的
avatar
g*g
14
If someone is able to get your configuration file and reverse engineer
your code without being noticed, yes, you are fucked.

read

【在 c******n 的大作中提到】
: like db password,
: if the code is able to read it, then that means every intruder can also read
: it. so storing them in a file exposes a security risk.
: but otherwise you have to let people manually type in keys every time

avatar
O*s
15
haha,zan

【在 c**********1 的大作中提到】
: 最近忙于私事,很少上来玩,今天发现这里有很多古诗的课要好好上,正在拿着本本记
: 记记,顺便奔个家的一角,呵呵。那也算是我的座右铭。以前我父亲说我不应该拿这个
: 当自己的座右铭,因为我本来就够糊涂的,呵呵,以后要改成难得聪明,嘿嘿。

avatar
r*l
16
My JavaOne topic is about security :)
DBAs have to know the password to perform DB operations. This is no easy way
to go around DB passwords. If you really need security, you can split the
password to two or more parts and give each part to one or more person. No
one knows the complete password.
The general rule is: never store the encryption key/password with the
application and DB. The key should be stored in an isolated environment. You
only need to expose it when you start the application and then clean it.
For encryption keys, store an encrypted form of it and keep the key to
encrypt the encryption keys secret. This works for DB password too.
There will always a plain text key you need to provide when you start up the
application, Typing it or use other means to provide it is equivalent.

read

【在 c******n 的大作中提到】
: like db password,
: if the code is able to read it, then that means every intruder can also read
: it. so storing them in a file exposes a security risk.
: but otherwise you have to let people manually type in keys every time

avatar
s*x
17
不用来挡油烟吗?
avatar
c*n
18
but the problem is like:
I want my box to boot up, upon start up , /etc/init.d/myapplication should
start, and launch my app
my application should talk to db. now when it boots up, without human
intervention, it has to read the db passwd from some files.
so passwd has to be stored on the local box. if my application can read it,
then anyone can read it once he gets into the box ( file permission is the
only defense then)

way
You

【在 r*****l 的大作中提到】
: My JavaOne topic is about security :)
: DBAs have to know the password to perform DB operations. This is no easy way
: to go around DB passwords. If you really need security, you can split the
: password to two or more parts and give each part to one or more person. No
: one knows the complete password.
: The general rule is: never store the encryption key/password with the
: application and DB. The key should be stored in an isolated environment. You
: only need to expose it when you start the application and then clean it.
: For encryption keys, store an encrypted form of it and keep the key to
: encrypt the encryption keys secret. This works for DB password too.

avatar
g*g
19
As I said, password masking (2 way hash) is a standard practice here.
If someone is able to get the configuration file and reverse engineer
the code, there's nothing you can do.

should

【在 c******n 的大作中提到】
: but the problem is like:
: I want my box to boot up, upon start up , /etc/init.d/myapplication should
: start, and launch my app
: my application should talk to db. now when it boots up, without human
: intervention, it has to read the db passwd from some files.
: so passwd has to be stored on the local box. if my application can read it,
: then anyone can read it once he gets into the box ( file permission is the
: only defense then)
:
: way

avatar
r*l
20
You need to balance security and usability. If you want automatic restart,
then the only way you can protect your password is to use access control.
However, root can get everything. If you make sure that you are the root and
make the password file only readable by root and your application user,
then you are ok. I am not a *nix guru though. Weblogic is using similar
approach. Look at its SerializedSystemIni.dat file. However, if someone can
read that file, he/she can decrypt the password with very simple Java
program.
Or you can try to do something like this (not simple):
1, Store password in a separate box, make the password file mountable and
disable the mount by default.
2, Right before you start up application, enable the mount.
3, Start application since it can ready the password file now.
4, After the application confirms it got the password, disable the mount
again.
The mount control should be on the server with password file.

should

【在 c******n 的大作中提到】
: but the problem is like:
: I want my box to boot up, upon start up , /etc/init.d/myapplication should
: start, and launch my app
: my application should talk to db. now when it boots up, without human
: intervention, it has to read the db passwd from some files.
: so passwd has to be stored on the local box. if my application can read it,
: then anyone can read it once he gets into the box ( file permission is the
: only defense then)
:
: way

avatar
c*n
21
but I believe all that "tempmount" approach and 2-way hash/obfuscation
methods are just security through obscurity, which just gives you a false
sense of security.
for the mount method, if a poser gains control to the application box, and
poses as your application code , simulating a legit startup sequence, then
he can mount and read the temp mount just the same way as
my application.
I think the only substantial difference it's possible to achieve is to let
the holder of secret **initiate** the process, for example, you don't let
the application start automatically, instead, you let the operator invoke
the startup script. other than this period, there is no source to obtain the
secret. the other approaches have the source of secrets readily available
as a server (mount) or file sitting there. in this way no secret exists at
all to be obtained, so it's safe.

and
can

【在 r*****l 的大作中提到】
: You need to balance security and usability. If you want automatic restart,
: then the only way you can protect your password is to use access control.
: However, root can get everything. If you make sure that you are the root and
: make the password file only readable by root and your application user,
: then you are ok. I am not a *nix guru though. Weblogic is using similar
: approach. Look at its SerializedSystemIni.dat file. However, if someone can
: read that file, he/she can decrypt the password with very simple Java
: program.
: Or you can try to do something like this (not simple):
: 1, Store password in a separate box, make the password file mountable and

avatar
g*g
22
If a hacker can gain root access to production server without being noticed,
it's fairly easy to print out end user password/credit number etc. when it
runs. Whatever you try to achieve is not gonna help much.

【在 c******n 的大作中提到】
: but I believe all that "tempmount" approach and 2-way hash/obfuscation
: methods are just security through obscurity, which just gives you a false
: sense of security.
: for the mount method, if a poser gains control to the application box, and
: poses as your application code , simulating a legit startup sequence, then
: he can mount and read the temp mount just the same way as
: my application.
: I think the only substantial difference it's possible to achieve is to let
: the holder of secret **initiate** the process, for example, you don't let
: the application start automatically, instead, you let the operator invoke

avatar
m*r
23
apparently, i mis-understood the question.

【在 r*****l 的大作中提到】
: Hash is not going to work since it can only verify.
avatar
r*l
24
I do believe based on your knowledge, minunderstanding is the only reason.
Anyway, nothing to lose.

【在 m****r 的大作中提到】
: apparently, i mis-understood the question.
avatar
r*l
25
True. There is no total prevention but making bad guys job more difficult.
They have their ultimate weapon: dump.

noticed,

【在 g*****g 的大作中提到】
: If a hacker can gain root access to production server without being noticed,
: it's fairly easy to print out end user password/credit number etc. when it
: runs. Whatever you try to achieve is not gonna help much.

avatar
B*g
26
就数据库来说大部分除了密码认证还要ip认证,除了application server其他ip用
application server上的user/pd一般是连不上去的。不过如果人家能上application
server或db server,那基本上是没办法防的。不过俺从来不担心,俺们的密码都是明
码存在application server上,反正出了事担责任的事system admin,哈哈。

noticed,
false
and
then
let
let
invoke

【在 g*****g 的大作中提到】
: If a hacker can gain root access to production server without being noticed,
: it's fairly easy to print out end user password/credit number etc. when it
: runs. Whatever you try to achieve is not gonna help much.

avatar
m*r
27
i think alot of it has to do with my pre-occupation with trying to store
username/passwords in cassandra, which only needs verification.

【在 r*****l 的大作中提到】
: I do believe based on your knowledge, minunderstanding is the only reason.
: Anyway, nothing to lose.

avatar
m*r
28
responsible admins will never deploy it to their evn.

【在 B*****g 的大作中提到】
: 就数据库来说大部分除了密码认证还要ip认证,除了application server其他ip用
: application server上的user/pd一般是连不上去的。不过如果人家能上application
: server或db server,那基本上是没办法防的。不过俺从来不担心,俺们的密码都是明
: 码存在application server上,反正出了事担责任的事system admin,哈哈。
:
: noticed,
: false
: and
: then
: let

avatar
B*g
29
sys admin既不会deploy更看不懂code,要不谁做sys admin

application
是明

【在 m****r 的大作中提到】
: responsible admins will never deploy it to their evn.
avatar
r*l
30
对安全要求高的公司还要求所有知道key的人签liability form。很少有人拿自己的
career开玩笑。更别说其它的连带责任了。
这点上developer最安全。

【在 B*****g 的大作中提到】
: sys admin既不会deploy更看不懂code,要不谁做sys admin
:
: application
: 是明

avatar
B*g
31
我就觉得其实公司搞了半天主要是防公司自己人,嘿嘿

【在 r*****l 的大作中提到】
: 对安全要求高的公司还要求所有知道key的人签liability form。很少有人拿自己的
: career开玩笑。更别说其它的连带责任了。
: 这点上developer最安全。

avatar
r*l
32
是呀,记得看过报道,内部人员是极大安全隐患。

【在 B*****g 的大作中提到】
: 我就觉得其实公司搞了半天主要是防公司自己人,嘿嘿
avatar
a*n
33
A common practice in some of the projects would be encrypting with SHA-1
plus SALT. However, it is more of a trap-door function. That is, not easy to
revert back. So, if you want keep your secrets temporarily till finding a
new encrypting method, then maybe using Triple-DES.
avatar
s*e
34
这种东西都是防不胜防的,原来我们做的system, 各种安全措施,SOP, Compliance数
都数不清,理论上讲每个Project都是billion dollar at stake。其实我要想看还是可
以看。绝大多数的东西,对公司很重要,对个人没一点用,你看了也没什么好处,所以
没人会risk 自己的career。如果你看一看就能相对安全地挣几个million,那肯定很多
人偷看。

【在 r*****l 的大作中提到】
: 是呀,记得看过报道,内部人员是极大安全隐患。
avatar
c*n
35
like db password,
if the code is able to read it, then that means every intruder can also read
it. so storing them in a file exposes a security risk.
but otherwise you have to let people manually type in keys every time
avatar
B*g
36
一般来说写在纸上,哈哈

read

【在 c******n 的大作中提到】
: like db password,
: if the code is able to read it, then that means every intruder can also read
: it. so storing them in a file exposes a security risk.
: but otherwise you have to let people manually type in keys every time

avatar
m*r
37
you can use an one way hash.

read

【在 c******n 的大作中提到】
: like db password,
: if the code is able to read it, then that means every intruder can also read
: it. so storing them in a file exposes a security risk.
: but otherwise you have to let people manually type in keys every time

avatar
r*l
38
Hash is not going to work since it can only verify.

【在 m****r 的大作中提到】
: you can use an one way hash.
:
: read

avatar
g*g
39
If someone is able to get your configuration file and reverse engineer
your code without being noticed, yes, you are fucked.

read

【在 c******n 的大作中提到】
: like db password,
: if the code is able to read it, then that means every intruder can also read
: it. so storing them in a file exposes a security risk.
: but otherwise you have to let people manually type in keys every time

avatar
r*l
40
My JavaOne topic is about security :)
DBAs have to know the password to perform DB operations. This is no easy way
to go around DB passwords. If you really need security, you can split the
password to two or more parts and give each part to one or more person. No
one knows the complete password.
The general rule is: never store the encryption key/password with the
application and DB. The key should be stored in an isolated environment. You
only need to expose it when you start the application and then clean it.
For encryption keys, store an encrypted form of it and keep the key to
encrypt the encryption keys secret. This works for DB password too.
There will always a plain text key you need to provide when you start up the
application, Typing it or use other means to provide it is equivalent.

read

【在 c******n 的大作中提到】
: like db password,
: if the code is able to read it, then that means every intruder can also read
: it. so storing them in a file exposes a security risk.
: but otherwise you have to let people manually type in keys every time

avatar
c*n
41
but the problem is like:
I want my box to boot up, upon start up , /etc/init.d/myapplication should
start, and launch my app
my application should talk to db. now when it boots up, without human
intervention, it has to read the db passwd from some files.
so passwd has to be stored on the local box. if my application can read it,
then anyone can read it once he gets into the box ( file permission is the
only defense then)

way
You

【在 r*****l 的大作中提到】
: My JavaOne topic is about security :)
: DBAs have to know the password to perform DB operations. This is no easy way
: to go around DB passwords. If you really need security, you can split the
: password to two or more parts and give each part to one or more person. No
: one knows the complete password.
: The general rule is: never store the encryption key/password with the
: application and DB. The key should be stored in an isolated environment. You
: only need to expose it when you start the application and then clean it.
: For encryption keys, store an encrypted form of it and keep the key to
: encrypt the encryption keys secret. This works for DB password too.

avatar
g*g
42
As I said, password masking (2 way hash) is a standard practice here.
If someone is able to get the configuration file and reverse engineer
the code, there's nothing you can do.

should

【在 c******n 的大作中提到】
: but the problem is like:
: I want my box to boot up, upon start up , /etc/init.d/myapplication should
: start, and launch my app
: my application should talk to db. now when it boots up, without human
: intervention, it has to read the db passwd from some files.
: so passwd has to be stored on the local box. if my application can read it,
: then anyone can read it once he gets into the box ( file permission is the
: only defense then)
:
: way

avatar
r*l
43
You need to balance security and usability. If you want automatic restart,
then the only way you can protect your password is to use access control.
However, root can get everything. If you make sure that you are the root and
make the password file only readable by root and your application user,
then you are ok. I am not a *nix guru though. Weblogic is using similar
approach. Look at its SerializedSystemIni.dat file. However, if someone can
read that file, he/she can decrypt the password with very simple Java
program.
Or you can try to do something like this (not simple):
1, Store password in a separate box, make the password file mountable and
disable the mount by default.
2, Right before you start up application, enable the mount.
3, Start application since it can ready the password file now.
4, After the application confirms it got the password, disable the mount
again.
The mount control should be on the server with password file.

should

【在 c******n 的大作中提到】
: but the problem is like:
: I want my box to boot up, upon start up , /etc/init.d/myapplication should
: start, and launch my app
: my application should talk to db. now when it boots up, without human
: intervention, it has to read the db passwd from some files.
: so passwd has to be stored on the local box. if my application can read it,
: then anyone can read it once he gets into the box ( file permission is the
: only defense then)
:
: way

avatar
c*n
44
but I believe all that "tempmount" approach and 2-way hash/obfuscation
methods are just security through obscurity, which just gives you a false
sense of security.
for the mount method, if a poser gains control to the application box, and
poses as your application code , simulating a legit startup sequence, then
he can mount and read the temp mount just the same way as
my application.
I think the only substantial difference it's possible to achieve is to let
the holder of secret **initiate** the process, for example, you don't let
the application start automatically, instead, you let the operator invoke
the startup script. other than this period, there is no source to obtain the
secret. the other approaches have the source of secrets readily available
as a server (mount) or file sitting there. in this way no secret exists at
all to be obtained, so it's safe.

and
can

【在 r*****l 的大作中提到】
: You need to balance security and usability. If you want automatic restart,
: then the only way you can protect your password is to use access control.
: However, root can get everything. If you make sure that you are the root and
: make the password file only readable by root and your application user,
: then you are ok. I am not a *nix guru though. Weblogic is using similar
: approach. Look at its SerializedSystemIni.dat file. However, if someone can
: read that file, he/she can decrypt the password with very simple Java
: program.
: Or you can try to do something like this (not simple):
: 1, Store password in a separate box, make the password file mountable and

avatar
g*g
45
If a hacker can gain root access to production server without being noticed,
it's fairly easy to print out end user password/credit number etc. when it
runs. Whatever you try to achieve is not gonna help much.

【在 c******n 的大作中提到】
: but I believe all that "tempmount" approach and 2-way hash/obfuscation
: methods are just security through obscurity, which just gives you a false
: sense of security.
: for the mount method, if a poser gains control to the application box, and
: poses as your application code , simulating a legit startup sequence, then
: he can mount and read the temp mount just the same way as
: my application.
: I think the only substantial difference it's possible to achieve is to let
: the holder of secret **initiate** the process, for example, you don't let
: the application start automatically, instead, you let the operator invoke

avatar
m*r
46
apparently, i mis-understood the question.

【在 r*****l 的大作中提到】
: Hash is not going to work since it can only verify.
avatar
r*l
47
I do believe based on your knowledge, minunderstanding is the only reason.
Anyway, nothing to lose.

【在 m****r 的大作中提到】
: apparently, i mis-understood the question.
avatar
r*l
48
True. There is no total prevention but making bad guys job more difficult.
They have their ultimate weapon: dump.

noticed,

【在 g*****g 的大作中提到】
: If a hacker can gain root access to production server without being noticed,
: it's fairly easy to print out end user password/credit number etc. when it
: runs. Whatever you try to achieve is not gonna help much.

avatar
B*g
49
就数据库来说大部分除了密码认证还要ip认证,除了application server其他ip用
application server上的user/pd一般是连不上去的。不过如果人家能上application
server或db server,那基本上是没办法防的。不过俺从来不担心,俺们的密码都是明
码存在application server上,反正出了事担责任的事system admin,哈哈。

noticed,
false
and
then
let
let
invoke

【在 g*****g 的大作中提到】
: If a hacker can gain root access to production server without being noticed,
: it's fairly easy to print out end user password/credit number etc. when it
: runs. Whatever you try to achieve is not gonna help much.

avatar
m*r
50
i think alot of it has to do with my pre-occupation with trying to store
username/passwords in cassandra, which only needs verification.

【在 r*****l 的大作中提到】
: I do believe based on your knowledge, minunderstanding is the only reason.
: Anyway, nothing to lose.

avatar
m*r
51
responsible admins will never deploy it to their evn.

【在 B*****g 的大作中提到】
: 就数据库来说大部分除了密码认证还要ip认证,除了application server其他ip用
: application server上的user/pd一般是连不上去的。不过如果人家能上application
: server或db server,那基本上是没办法防的。不过俺从来不担心,俺们的密码都是明
: 码存在application server上,反正出了事担责任的事system admin,哈哈。
:
: noticed,
: false
: and
: then
: let

avatar
B*g
52
sys admin既不会deploy更看不懂code,要不谁做sys admin

application
是明

【在 m****r 的大作中提到】
: responsible admins will never deploy it to their evn.
avatar
r*l
53
对安全要求高的公司还要求所有知道key的人签liability form。很少有人拿自己的
career开玩笑。更别说其它的连带责任了。
这点上developer最安全。

【在 B*****g 的大作中提到】
: sys admin既不会deploy更看不懂code,要不谁做sys admin
:
: application
: 是明

avatar
B*g
54
我就觉得其实公司搞了半天主要是防公司自己人,嘿嘿

【在 r*****l 的大作中提到】
: 对安全要求高的公司还要求所有知道key的人签liability form。很少有人拿自己的
: career开玩笑。更别说其它的连带责任了。
: 这点上developer最安全。

avatar
r*l
55
是呀,记得看过报道,内部人员是极大安全隐患。

【在 B*****g 的大作中提到】
: 我就觉得其实公司搞了半天主要是防公司自己人,嘿嘿
avatar
a*n
56
A common practice in some of the projects would be encrypting with SHA-1
plus SALT. However, it is more of a trap-door function. That is, not easy to
revert back. So, if you want keep your secrets temporarily till finding a
new encrypting method, then maybe using Triple-DES.
avatar
s*e
57
这种东西都是防不胜防的,原来我们做的system, 各种安全措施,SOP, Compliance数
都数不清,理论上讲每个Project都是billion dollar at stake。其实我要想看还是可
以看。绝大多数的东西,对公司很重要,对个人没一点用,你看了也没什么好处,所以
没人会risk 自己的career。如果你看一看就能相对安全地挣几个million,那肯定很多
人偷看。

【在 r*****l 的大作中提到】
: 是呀,记得看过报道,内部人员是极大安全隐患。
avatar
B*g
58
疑似找到这个topic

way
You

【在 r*****l 的大作中提到】
: My JavaOne topic is about security :)
: DBAs have to know the password to perform DB operations. This is no easy way
: to go around DB passwords. If you really need security, you can split the
: password to two or more parts and give each part to one or more person. No
: one knows the complete password.
: The general rule is: never store the encryption key/password with the
: application and DB. The key should be stored in an isolated environment. You
: only need to expose it when you start the application and then clean it.
: For encryption keys, store an encrypted form of it and keep the key to
: encrypt the encryption keys secret. This works for DB password too.

avatar
r*l
59
You can be a detective :)

【在 B*****g 的大作中提到】
: 疑似找到这个topic
:
: way
: You

相关阅读
logo
联系我们隐私协议©2024 redian.news
Redian新闻
Redian.news刊载任何文章,不代表同意其说法或描述,仅为提供更多信息,也不构成任何建议。文章信息的合法性及真实性由其作者负责,与Redian.news及其运营公司无关。欢迎投稿,如发现稿件侵权,或作者不愿在本网发表文章,请版权拥有者通知本网处理。