Encrypt / Decrypt text
I created MyClass having the capability update a database. A typical application call is like this.
MyClass newObj = new MyClass("uuuu", "pppp", otherparam );
i = newObj.update();
The first two parameters in the constructor are username and password. It is not good to have them in plain text. Please suggest what I can do in Java.
I am thinking .. if I keep a password key between a small group, and use that key to do encrption and decrption. Where is the resource that can help me?
[516 byte] By [
ykfca] at [2007-11-26 22:48:26]
Can you create a login form for your application?
Can't use a form for the user to type the database password as they are not suppose to know.. I want to save this password in encrypted form, so that although users can see it, they were just funny texts. A java application reads these funny text but is able to convert it back to the unencrypted password text (if it knows the agreed key for decryption). When the database password expires, I just change the plain text to another set of funny texts. I want to allow the same Java codes to be capable of retrieving the new decrypted password without changing any source codes and without the need for re-compilation.
Btw I have compiled and tested the sample codes in http://www.exampledepot.com/egs/javax.crypto/DesString.html
It runs perfectly but I still cannot figure out how it can fit into my wants.
ykfca at 2007-7-10 12:08:13 >
If you just want to ensure that trusted users can't discover this password at a casual glance then you can "encrypt" it using anything you want (ROT13 it if you want to). Write this out somewhere and have the key in the code (write a utility method to encrypt strings with that key so you can update the file that you store your encrypted password in).
If you want to defend against a malicious attacker than you need to step back and ensure such an entity doesn't have read access to your password file, code, or key.
Good Luck
Lee
tsitha at 2007-7-10 12:08:13 >
> If you just want to ensure that trusted users can't
> discover this password at a casual glance then you
> can "encrypt" it using anything you want (ROT13 it
> you want to).
In some vb applications I can "encrypt" password and other sensitive string values using Enigma PRO Encrption (you can find sample VB source easily by google). It seems quite good as it does not "translate" the same char in two different strings to different character.
I am not sure if ROT13 can achieve something similar. I haven't got any luck to find Java source codes (save my time to code it myself) that does Enigma Encrption function. So I try if someone can help here.
ykfca at 2007-7-10 12:08:13 >
The JCE provides implementations for good encryption routines so there is no need to accept toy encryption like rot13 or 2nd World War encryption like Enigma PRO.
> The JCE provides implementations for good encryption> routines so there is no need to accept toy encryption> like rot13 or 2nd World War encryption like Enigma> PRO.My point is that if you leave the key in the file system you might as well ROT13
tsitha at 2007-7-10 12:08:13 >
> > The JCE provides implementations for good
> encryption
> > routines so there is no need to accept toy
> encryption
> > like rot13 or 2nd World War encryption like Enigma
> > PRO.
>
> My point is that if you leave the key in the file
> system you might as well ROT13 it.
Agreed.
> The JCE provides implementations for good encryption
> routines so there is no need to accept toy encryption
> like rot13 or 2nd World War encryption like Enigma
> PRO.
Before I fall back to something i did before (such as Enigma), I also believe Java has good encryption routines. Therefore I did some research and had compiled and tested the sample codes in http://www.exampledepot.com/egs/javax.crypto/DesString.html
It runs perfectly but I still cannot figure out how it can fit into my wants. Can some give me more hints or show me a practical application example.
This is what I need: I know what the database password is today, so I encrypt it and save it. The main java application MMM takes this encrypted password and decrypts it. Use the password to access the database,
Later when the password expires, it is only me who knows how to encrypt the password. I save the encrypted password in the same place as before. The same application MMM will need to decrypt it correctly. Is that possible?
ykfca at 2007-7-10 12:08:13 >
> This is what I need: I know what the database
> password is today, so I encrypt it and save it. The
> main java application MMM takes this encrypted
> password and decrypts it. Use the password to access
> the database,
>
This basic mechanics of this are very easy BUT where do you store you encryption key?
If your application is Client/Server then it is easy because you can place the key in some key repository on your server. On the assumption that only trusted persons can access your server then you only they can have any access to the key. Your system is then as secure as far as you trust the trusted persons.
If your application is 'stand alone' then you can never make the system really secure. In my view the best you can do is to hide/obfiscate the key in your code but then any half competent hacker could find the key. Even if you play games like making the key a function of the users name then a competent hacker would have little difficulty in working out what you have done.
P.S. This applies whether you use DES, AES, Enigma or RSA.
Message was edited by:
sabre150
'c racker' is now a rude word so changed to 'hacker'
Message was edited by:
sabre150
Message was edited by:
sabre150
>
> This basic mechanics of this are very easy BUT where
> do you store you encryption key?
>
Thank you so much for your interest and thank for your time too.
The key will be stored in the server for business application, certainly. For testing, it is in my own laptop. There is some but not a high risk of losing the database password unless a thief is a hacker (usually he is happy getting money by selling it). But we can change password.
For example, I have:
SecretKey key = javax.crypto.KeyGenerator.getInstance("DES").generateKey();
byte[ ] keyArray = new byte[1000];
keyArray = key.getEncoded();
Now I think i know how to store the key ( for example, just hardcoded the value of byte[ ] during initialization )
But I couldn't finger out the method to convert a byte array back SpecialKey key for an application.
For example, the following Encrypter method requires a SecretKey as parameter. How could I make use of the byte[ ] value and convert it to SecretKey key?
DesEncrypter(SecretKey key) {
try {
ecipher = Cipher.getInstance("DES");
dcipher = Cipher.getInstance("DES");
ecipher.init(Cipher.ENCRYPT_MODE, key);
dcipher.init(Cipher.DECRYPT_MODE, key);
}
catch (javax.crypto.NoSuchPaddingException e) {
}
catch (java.security.NoSuchAlgorithmException e) {
}
catch (java.security.InvalidKeyException e) {
}
}
ykfca at 2007-7-10 12:08:13 >
Hey ykfc, I had this same question (sort of) 2 weeks or so ago.
http://forum.java.sun.com/thread.jspa?threadID=5148769
http://forum.java.sun.com/thread.jspa?threadID=5148833
I even used the same example page to learn from.
I can post simple code if you want it.
I wasnt dealing with databases though. I just wanted PBE (password
based encryption) but in my case the password was not being
stored anywhere.
If you want to store the password in your case from what I gather
youre supposed to store the hash of the password and validate
the entered input against it.
[snip]
> If you want to store the password in your case from
> what I gather
> youre supposed to store the hash of the password and
> validate
> the entered input against it.
Except in this case the OP needs to use the password to log in to a DB, so the hash won't help.
tsitha at 2007-7-10 12:08:13 >
> >
> > This basic mechanics of this are very easy BUT
> where
> > do you store you encryption key?
> >
>
> Thank you so much for your interest and thank for
> your time too.
>
> The key will be stored in the server for business
> application, certainly. For testing, it is in my own
> laptop. There is some but not a high risk of losing
> the database password unless a thief is a hacker
> (usually he is happy getting money by selling it).
> But we can change password.
>
So as someone who wants to do something bad to your system you are protecting from the case where they already have access to the code.
So what prevents them from simply putting a replacement code module into your code without replacing your verification routine? So your verification routine runs, and then they collect all of the credit card information (or whatever) anyways.
Additionally standard best practices (actual standards) call for password change rules which require the passwords change no less than every 90 days. And I suspect many places go for less than 30 and will also do it when an employee leaves the company.
So how is that going to work with a hard coded password?
> So how is that going to work with a hard coded
> password?
Yes, I prepared to hardcode the password that is passed from the client side to the server side BUT IT IS ENCRPTED. The secret key is hardcoded in the server side codes. The codes read the encrpted password string, etc. transmitted from the client, and with the SpecialKey kept by by it, the credentials required to access the database can be worked out. After some time (say 30 days) when the database password is changed, all I need is to adjust the encrypted password on the client side software.
Back to my question, what I have to work out is: the method to convert something to the SpecialKey , the server side codes need that. The plan is also to remove the source codes from the server (I don't know if there exists a decompiler). Assuming no one can work out my SpecialKey based on the runtime class, how can they be decoded based on the encrypted password and username strings? I hope it makes sense. In fact I have use this way for so long, but in VB. Now I want it in Java.
ykfca at 2007-7-21 19:15:59 >
> > So how is that going to work with a hard coded
> > password?
>
> Yes, I prepared to hardcode the password that is
> passed from the client side to the server side BUT IT
> IS ENCRPTED. The secret key is hardcoded in the
> server side codes. The codes read the encrpted
> password string, etc. transmitted from the client,
> and with the SpecialKey kept by by it, the
> credentials required to access the database can be
> worked out. After some time (say 30 days) when the
> database password is changed, all I need is to adjust
> the encrypted password on the client side software.
Not to keep picking on your protocol here, but wouldn't it be easier if the only thing that needed the DB password was your server-side process? That way you only need to change your server-side password and don't have to resdistribute keys to all your clients.
>
> Back to my question, what I have to work out is: the
> method to convert something to the SpecialKey , the
> server side codes need that.
I've seen protocols where you simply serialize the key. If you're using
http://java.sun.com/j2se/1.5.0/docs/api/javax/crypto/spec/SecretKeySpec.html
Then you can use the byte[] ctor.
> The plan is also to
> remove the source codes from the server (I don't know
> if there exists a decompiler).
Yes, there exists a decompiler. And making your security dependent upon secrecy is a bad idea anyway. You *have* to prevent the bad guys from having read access to where your code is. If I have read access then you don't care if I decompile your code, as you have bigger problems.
> Assuming no one can
> work out my SpecialKey based on the runtime class,
> how can they be decoded
What is "they"? The DB credentials? You said you are transmitting them to the server from the client and you plan on decrypting it using your key, right?
> based on the encrypted
> password and username strings?
I am assuming you want to encrypt some DB user/password using some key and you will distribute that to your client software. Your client software will transmit this to your server process which will decrypt it and use that to log in to the DB. Is this correct? If so, are you asking how to encrypt/decrypt data in java?
tsitha at 2007-7-21 19:15:59 >
The OP's whole approach looks flawed. As I see it, all the OP needs is a Secret key held only on the server and used to encrypt the data and then the client to use Public Key Cryptography either indirectly using SSL (or HTTPS?) OR directly with all the clients know the server's Public key.
But obviously I am missing something.
> Additionally standard best practices (actual
> standards) call for password change rules which
> require the passwords change no less than every 90
> days. And I suspect many places go for less than 30
> and will also do it when an employee leaves the
> company.
It's interesting that that is best practices, I have read a couple of articles that were calling for an end to the constant password changing. The argument was the more frequent the changes, the more likely a person would be to write it down. I'm pretty sure we can agree that the weakest link in the authentication is users.
> > Additionally standard best practices (actual
> > standards) call for password change rules which
> > require the passwords change no less than every 90
> > days. And I suspect many places go for less than
> 30
> > and will also do it when an employee leaves the
> > company.
>
> It's interesting that that is best practices, I have
> read a couple of articles that were calling for an
> end to the constant password changing. The argument
> was the more frequent the changes, the more likely a
> person would be to write it down.
Depends on what you're trying to defend against. The written down password might still be physically secured (in desk or wallet), but the passwd file or whatever might be more easily compromised - and if you change passwords regularly then yes, it might make the "note" threat more likely, but could still mitigate the "hacker" threat damage.
Or something like that...
tsitha at 2007-7-21 19:15:59 >
> The OP's whole approach looks flawed. As I see it,
> all the OP needs is a Secret key held only on the
> server and used to encrypt the data and then the
> client to use Public Key Cryptography either
> indirectly using SSL (or HTTPS?) OR directly with all
> the clients know the server's Public key.
Agree.
tsitha at 2007-7-21 19:15:59 >
> Depends on what you're trying to defend against. The
> written down password might still be physically
> secured (in desk or wallet), but the passwd file or
> whatever might be more easily compromised - and if
> you change passwords regularly then yes, it might
> make the "note" threat more likely, but could still
> mitigate the "hacker" threat damage.
Agreed, but there is no magic silver bullet for security. You have to take into account the time required to secure a system versus the necessity to protect the data behind the system. It's all about risks and mitigation. It's good that there is no magic bullet or there would not be anything interesting to talk/learn about.
In fact any situation where you're storing and passing the password from the client to the server in plain text is vulnerable. All you have to do is sniff the outgoing traffic.
> > Additionally standard best practices (actual
> > standards) call for password change rules which
> > require the passwords change no less than every 90
> > days. And I suspect many places go for less than 30
> > and will also do it when an employee leaves the
> > company.
>
> It's interesting that that is best practices, I have
> read a couple of articles that were calling for an
> end to the constant password changing. The argument
> was the more frequent the changes, the more likely a
> person would be to write it down. I'm pretty sure we
> can agree that the weakest link in the authentication
> is users.
Of course calling for an end to it obviously means that it is in use.
As for the second that would seem likely conclusion to me.
> Not to keep picking on your protocol here, but
> wouldn't it be easier if the only thing that needed
> the DB password was your server-side process? That
> way you only need to change your server-side password
> and don't have to resdistribute keys to all your
> clients.
> >
> I've seen protocols where you simply serialize the
> key. If you're using
> http://java.sun.com/j2se/1.5.0/docs/api/javax/crypto/s
> pec/SecretKeySpec.html
>
> Then you can use the byte[] ctor.
>
tsith:
From your questions I know you do not fully understand my specific application and therefore a lot of you think my protocol is incorrect. I hadn't explained clearly enough. But your above reply had answered my only question (which is the original purpose of my post). I worked out using SecretKeySpec hinted by you. Thanks a lot.
ykfca at 2007-7-21 19:15:59 >
