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
t*t
4 楼
要盖一个甚至印章再签名, 不然总觉得缺点什么.
a*a
5 楼
What the commercial is for? In general, how about 'Secure the moment, future success in hand'?
【在 J*****w 的大作中提到】 : 广告词“把握精彩,印证未来”怎么翻译比较好? : thanks in advance.
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
【在 J*****w 的大作中提到】 : 广告词“把握精彩,印证未来”怎么翻译比较好? : thanks in advance.
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
【在 J*****w 的大作中提到】 : 广告词“把握精彩,印证未来”怎么翻译比较好? : thanks in advance.
r*l
12 楼
Hash is not going to work since it can only verify.
【在 m****r 的大作中提到】 : you can use an one way hash. : : read
x*u
13 楼
大概也是押旧韵罢。:) 不过我是指他的三不足。
【在 s********a 的大作中提到】 : 荆公作诗还是挺讲究格律的
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
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
s*x
17 楼
不用来挡油烟吗?
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.
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
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
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
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
m*r
23 楼
apparently, i mis-understood the question.
【在 r*****l 的大作中提到】 : Hash is not going to work since it can only verify.
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.
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.
【在 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.
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.
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
B*g
29 楼
sys admin既不会deploy更看不懂code,要不谁做sys admin
application 是明
【在 m****r 的大作中提到】 : responsible admins will never deploy it to their evn.
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.
s*e
34 楼
这种东西都是防不胜防的,原来我们做的system, 各种安全措施,SOP, Compliance数 都数不清,理论上讲每个Project都是billion dollar at stake。其实我要想看还是可 以看。绝大多数的东西,对公司很重要,对个人没一点用,你看了也没什么好处,所以 没人会risk 自己的career。如果你看一看就能相对安全地挣几个million,那肯定很多 人偷看。
【在 r*****l 的大作中提到】 : 是呀,记得看过报道,内部人员是极大安全隐患。
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
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
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
r*l
38 楼
Hash is not going to work since it can only verify.
【在 m****r 的大作中提到】 : you can use an one way hash. : : read
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
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
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.
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
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
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
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
m*r
46 楼
apparently, i mis-understood the question.
【在 r*****l 的大作中提到】 : Hash is not going to work since it can only verify.
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.
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.
【在 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.
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.
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
B*g
52 楼
sys admin既不会deploy更看不懂code,要不谁做sys admin
application 是明
【在 m****r 的大作中提到】 : responsible admins will never deploy it to their evn.
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.
s*e
57 楼
这种东西都是防不胜防的,原来我们做的system, 各种安全措施,SOP, Compliance数 都数不清,理论上讲每个Project都是billion dollar at stake。其实我要想看还是可 以看。绝大多数的东西,对公司很重要,对个人没一点用,你看了也没什么好处,所以 没人会risk 自己的career。如果你看一看就能相对安全地挣几个million,那肯定很多 人偷看。
【在 r*****l 的大作中提到】 : 是呀,记得看过报道,内部人员是极大安全隐患。
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.