Encrypting/Decrypting Password from a Config File

  • Thread starter michael.santamaria
  • Start date
M

michael.santamaria

Hello,
I am looking for a way to encrypt a password in a configuration file
that is being read by a Java program. Currently, I read-in the
password from the text file, but that leaves the password sitting right
out in the open if someone were to look at the config file.

I was thinking of building a simple class where user could type in
their desired password, get an encrypted version of the password, then
paste the encrypted version into the configuration text file. Then the
application would read encrypted password, decrypt the password back
into a string, and move on.

I am having trouble with the string-->encrytped bytes-->string
conversions.

I am using the built-in java security classes to implement this code.
Here is some sample test code:

// Reads password from config file
String password = ScriptConfig.getString( "password" );

// Generate Key
KeyGenerator kg = KeyGenerator.getInstance("DES");
Key key = kg.generateKey();

// Create Encryption cipher
Cipher cipher = Cipher.getInstance( "DES" );
cipher.init( Cipher.ENCRYPT_MODE, key );

// Encrypt password
byte[] encrypted = cipher.doFinal( password.getBytes() );

// Create decryption cipher
cipher.init( Cipher.DECRYPT_MODE, key );
byte[] decrypted = cipher.doFinal( encrypted );

// Convert byte[] to String
String decryptedString = new String(decrypted);

System.out.println("password: " + password);
System.out.println("encrypted: " + encrypted);
System.out.println("decrypted: " + decryptedString);

// Read encrypted string from config file
String encryptedPassword = ScriptConfig.getString( "encryptedPassword"
);

// Convert encryptedPassword string into byte[]
byte[] encryptedPasswordBytes = new byte[1024];
encryptedPasswordBytes = encryptedPassword.getBytes();

// Decrypt encrypted password from config file
byte[] decryptedPassword = cipher.doFinal( encryptedPasswordBytes );

System.out.println("encryptedPassword: " + encryptedPassword);
System.out.println("decryptedPassword: " + decryptedPassword);


The config file has the following variables:
password=password
encryptedPassword=[B@2a4983


When I run the code, I get the following output:
password: passwd
encrypted: [B@2a4983
decrypted: passwd
javax.crypto.IllegalBlockSizeException: Input length must be multiple
of 8 when decrypting with padded cipher
at com.sun.crypto.provider.SunJCE_h.b(DashoA12275)
at com.sun.crypto.provider.SunJCE_h.b(DashoA12275)
at com.sun.crypto.provider.DESCipher.engineDoFinal(DashoA12275)
at javax.crypto.Cipher.doFinal(DashoA12275)
at com.sapient.fbi.uid.TestEncryption.main(TestEncryption.java:48)


Any help on the error, structure, or process I am using to do this
would be great. Thanks.
 
O

Oliver Wong

Hello,
I am looking for a way to encrypt a password in a configuration file
that is being read by a Java program. Currently, I read-in the
password from the text file, but that leaves the password sitting right
out in the open if someone were to look at the config file.

I was thinking of building a simple class where user could type in
their desired password, get an encrypted version of the password, then
paste the encrypted version into the configuration text file. Then the
application would read encrypted password, decrypt the password back
into a string, and move on.

I am having trouble with the string-->encrytped bytes-->string
conversions.

I am using the built-in java security classes to implement this code.
Here is some sample test code:

// Reads password from config file
String password = ScriptConfig.getString( "password" );

// Generate Key
KeyGenerator kg = KeyGenerator.getInstance("DES");
Key key = kg.generateKey();

// Create Encryption cipher
Cipher cipher = Cipher.getInstance( "DES" );
cipher.init( Cipher.ENCRYPT_MODE, key );

// Encrypt password
byte[] encrypted = cipher.doFinal( password.getBytes() );

// Create decryption cipher
cipher.init( Cipher.DECRYPT_MODE, key );
byte[] decrypted = cipher.doFinal( encrypted );

// Convert byte[] to String
String decryptedString = new String(decrypted);

System.out.println("password: " + password);
System.out.println("encrypted: " + encrypted);
System.out.println("decrypted: " + decryptedString);

// Read encrypted string from config file
String encryptedPassword = ScriptConfig.getString( "encryptedPassword"
);

// Convert encryptedPassword string into byte[]
byte[] encryptedPasswordBytes = new byte[1024];
encryptedPasswordBytes = encryptedPassword.getBytes();

// Decrypt encrypted password from config file
byte[] decryptedPassword = cipher.doFinal( encryptedPasswordBytes );

System.out.println("encryptedPassword: " + encryptedPassword);
System.out.println("decryptedPassword: " + decryptedPassword);


The config file has the following variables:
password=password
encryptedPassword=[B@2a4983


When I run the code, I get the following output:
password: passwd
encrypted: [B@2a4983
decrypted: passwd
javax.crypto.IllegalBlockSizeException: Input length must be multiple
of 8 when decrypting with padded cipher
at com.sun.crypto.provider.SunJCE_h.b(DashoA12275)
at com.sun.crypto.provider.SunJCE_h.b(DashoA12275)
at com.sun.crypto.provider.DESCipher.engineDoFinal(DashoA12275)
at javax.crypto.Cipher.doFinal(DashoA12275)
at com.sapient.fbi.uid.TestEncryption.main(TestEncryption.java:48)
Click to expand...

If you actually included an SSCCE, I could find out which line is line
48, and it'd be easier for me to help you.

SSCCE: http://www.physci.org/codes/sscce.jsp

My guess is it has something to do with not padding the results
correctly. As the message implies, the decryption algorithm expects the
length to be a multile of 8, and "[B@2a4983" is of length 9.

- Oliver
 
J

Jack

I was thinking of building a simple class where user could type in
their desired password, get an encrypted version of the password, then
paste the encrypted version into the configuration text file. Then the
application would read encrypted password, decrypt the password back
into a string, and move on.
Click to expand...

but any bad guy who has access to the config file would also have
access to the decryption routine, yes?

so you might instead do this: once the user creates their password,
the software creates something like an MD5 hash of it and stores the
hash. Thereafter, whenever the user wants to logon again, the software
converts his entered pwd to MD5 and compares that to the list of
stored, hashed pwds. That way, no one but the user ever can know the
actual password.

You probably have seen websites where, if you've forgotten your pwd,
they can send you a new one - that's because they are using a scheme
like that.
 
L

Luc The Perverse

Jack said:
but any bad guy who has access to the config file would also have
access to the decryption routine, yes?

so you might instead do this: once the user creates their password,
the software creates something like an MD5 hash of it and stores the
hash. Thereafter, whenever the user wants to logon again, the software
converts his entered pwd to MD5 and compares that to the list of
stored, hashed pwds. That way, no one but the user ever can know the
actual password.

You probably have seen websites where, if you've forgotten your pwd,
they can send you a new one - that's because they are using a scheme
like that.
Click to expand...

You may want to use SHA-256 though, since MD5 is considered broken.
 
L

Luc The Perverse

Jack said:
can you elaborate? :)
Click to expand...

Sure.

The purpose of a hash is ideally to create a number from an input that
cannot be reversed and cannot be forged. (Reversed means an attacker with
the hash output can "go backwards" and get the input.) (Forged means an
attacker with the output can make up another made up pass phrase which
generated the same hash.) Of course, asking just for the hash, is not good,
because someone not knowing the passphrase could easily just send the same
hash along.

Most of these problems (except reversing) can be fixed by adding a
negotiated preamble (IE random number) to the passphrase before hashing.
But this only works if the server is seperate from the user and knows the
passphrase. (For a local file on a local machine, this is an
impossibility)

MD5 has been broken, in that it is now known how to generate an input which
will cause a certain hashed output.

It just depends on how hard you want to make it. Every system has a
weakness. A very tech savvy person could reverse engineer your program,
find out your encryption, remake a new hash from a new password and drop it
into your file, effectively changing the password without ever knowing what
your old password was.

You need to decide what your threat model is. The dilema that you will
always come back to is this: If the computer is not secure then the
password is not secure. If the computer is secure, then what are you
worried about?

So if the only thing you are trying to do, is keep it from exceptionally
amateur hack attempts, then a simple file encoding would work (maybe a
simple XOR bit mask on every byte.)

If you don't want to compromise the users password to slightly more advanced
attacks, (since you know people are using the same password for everything)
then using a hash is a good idea. And in this model MD5 or SHA-256 would be
fine. I prefer SHA-256 because it feels 1337er to me. Same reason I use
Serpent instead of Rijndael ;)

Just remember that there is always a way around security. Even the
infallible Compusec HSM (http://www.ce-infosys.com.sg/CeiProducts_HSM.asp)
can be easily taken over with a simple hardware keylogger, fingerprint
forgery and simple mugging (for the smart card) or just walk in while the
person is going pee.
 
O

Oliver Wong

Luc The Perverse said:
MD5 has been broken, in that it is now known how to generate an input
which will cause a certain hashed output.
Click to expand...

A technique was always "known": Brute force.

But I guess what you're referring to is some mathematical flaw in the
MD5 algorithm being discovered. I had read an article on that too, but from
my recollection, the weakness was rather theoretical and had little
practical impact. E.g. instead of using pure brute force and expecting to
crack the password in 20 billion years, you could use the weakness they
discovered and crack the password in 10 billion years. (Those were just
numbers off the top of my head, but they illustrate what I meant by 'little
practical impact').

In other words, if you're just doing amateur level security for local
programs, don't worry too much about "MD5 being broken" yet. As Luc alluded
to, suceptibility to reverse engineering is probably a far bigger risk for
you at this point.

- Oliver
 
D

Dag Sunde

Oliver Wong said:
1337er = leeter = more leet = more elite.
Click to expand...

Yeah... And there is nothing more removed from being
elite that using that 14-year old "WaReZ kIdZ" speak...

LOL...
 
D

Daniel Dyer

message


A technique was always "known": Brute force.

But I guess what you're referring to is some mathematical flaw in the
MD5 algorithm being discovered. I had read an article on that too, but
from
my recollection, the weakness was rather theoretical and had little
practical impact. E.g. instead of using pure brute force and expecting to
crack the password in 20 billion years, you could use the weakness they
discovered and crack the password in 10 billion years. (Those were just
numbers off the top of my head, but they illustrate what I meant by
'little
practical impact').

In other words, if you're just doing amateur level security for local
programs, don't worry too much about "MD5 being broken" yet. As Luc
alluded
to, suceptibility to reverse engineering is probably a far bigger risk
for
you at this point.
Click to expand...

"In 1996, a flaw was found with the design of MD5; while it was not a
clearly fatal weakness, cryptographers began to recommend using other
algorithms, such as SHA-1 (recent claims suggest that SHA-1 was broken,
however). In 2004, more serious flaws were discovered making further use
of the algorithm for security purposes questionable."

[From http://en.wikipedia.org/wiki/Md5]

Collisions can be found in a matter of hours with a modest PC.

Or you can look up a hash in an online database such as this one:

http://www.md5lookup.com/

Dan.
 
M

Monique Y. Mudama

Yeah... And there is nothing more removed from being elite that
using that 14-year old "WaReZ kIdZ" speak...

LOL...
Click to expand...

It's a form of humor. Using "1337" in otherwise well-formed and
comprehensible text is a way of both mocking the script kiddies and
yourself, just a bit, at the same time. Obviously Luc is mocking
himself when the only reason he gives for using one over the other is
"it feels 1337er". He's acknowledging that he doesn't have a better
reason.

As with all jokes, it's not funny if you have to explain it.

In short, if every third word you type uses numbers in place of
letters, etc, then you look dumb. If you very rarely use a select
l33tspeak word for emphasis, you are identifying yourself as part of a
particular community.
 
J

Juha Laiho

Daniel Dyer said:
Collisions can be found in a matter of hours with a modest PC.
Click to expand...

Hmm.. was this "free-form" collisions, as in I give you just any hash,
and you provide data matching that hash within hours, or cases where
you first generate the data and hash yourself, and then manipulate the
initial data in such ways that you have another piece of data which
produces the same hash as the first one?

I know the latter can be done, but I'm still unclear whether the former
has been successfully demonstrated. For some uses even the latter case
is enough to not use md5, and of course it does take some credibility
from the algorithm, but mostly I wouldn't panic - yet.
 
D

Dag Sunde

Monique Y. Mudama said:
It's a form of humor. Using "1337" in otherwise well-formed and
comprehensible text is a way of both mocking the script kiddies and
yourself, just a bit, at the same time. Obviously Luc is mocking
himself when the only reason he gives for using one over the other is
"it feels 1337er". He's acknowledging that he doesn't have a better
reason.

As with all jokes, it's not funny if you have to explain it.

In short, if every third word you type uses numbers in place of
letters, etc, then you look dumb. If you very rarely use a select
l33tspeak word for emphasis, you are identifying yourself as part of a
particular community.
Click to expand...

Oh, I got it... I've got two kids at 11 and 16 that speak the lingo...
:)
 
M

Monique Y. Mudama

Oh, I got it... I've got two kids at 11 and 16 that speak the
lingo...
:)
Click to expand...

Okay, then I won't comment on the irony of someone using "LOL" to
laugh at l33tspeak =)
 
D

Dag Sunde

Monique Y. Mudama said:
Okay, then I won't comment on the irony of someone using "LOL" to
laugh at l33tspeak =)
Click to expand...

Context? Usenet/NG vs. chatrooms/IRC? Social culture in the one
vs. the other? ...and where we communicate now?

LOL belongs here (together with AFAIK, YMMV, IANAL et.c.)
1337, 1am3r et.c does not?

I don't see the irony...
:)
 
O

Oliver Wong

Daniel Dyer said:
"In 1996, a flaw was found with the design of MD5; while it was not a
clearly fatal weakness, cryptographers began to recommend using other
algorithms, such as SHA-1 (recent claims suggest that SHA-1 was broken,
however). In 2004, more serious flaws were discovered making further use
of the algorithm for security purposes questionable."

[From http://en.wikipedia.org/wiki/Md5]

Collisions can be found in a matter of hours with a modest PC.

Or you can look up a hash in an online database such as this one:

http://www.md5lookup.com/
Click to expand...

This is not to say that I doubt your claims, but I found it amusing that
md5lookup.com reports that the database is down for maitenance and will be
back up on October 31st ("now" being November 3rd, 2005). I guess it isn't
exactly a lie, as they haven't specified October 31st of what year!

I then proceeded to go down the list of "MD5 Crackers" listed on
Wikipedia and none of them worked. http://md5.crysm.net/ kept timing out for
me, http://gdataonline.com/ reported the password as being "?????" for every
hash I tried (which is either a stunning coincidence, or this is their way
of saying they don't know the password), and
http://passcracking.ru/index.php I couldn't figure out how to use, as it was
in Russian (no matter what hashes I tried, it would return a blank page).
http://passcracking.com/ was the most promising of the bunch, but apparently
there was a queue of 31504 hashes to crack before me (I was too impatient to
wait).

Conclusion: Cracking MD5s isn't as easy as some people make it sound,
sometimes for as pragmatic reasons as the fact that the webservers are being
overloaded with work and cannot respond in time.

- Oliver
 
L

Luc The Perverse

Monique Y. Mudama said:
It's a form of humor. Using "1337" in otherwise well-formed and
comprehensible text is a way of both mocking the script kiddies and
yourself, just a bit, at the same time. Obviously Luc is mocking
himself when the only reason he gives for using one over the other is
"it feels 1337er". He's acknowledging that he doesn't have a better
reason.

As with all jokes, it's not funny if you have to explain it.

In short, if every third word you type uses numbers in place of
letters, etc, then you look dumb. If you very rarely use a select
l33tspeak word for emphasis, you are identifying yourself as part of a
particular community.
Click to expand...

Thank you! I couldn't have described it better myself.
 
J

Joan

Dag Sunde said:
Context? Usenet/NG vs. chatrooms/IRC? Social culture in the one
vs. the other? ...and where we communicate now?

LOL belongs here (together with AFAIK, YMMV, IANAL et.c.)
Click to expand...

shouldn't this be "iANAL"
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

Decrypting in Javascript 8
Decrypting using Javascript 0
Crypting and decrypting with key public and private 0
using CipherInputStream 6
Encrypting passwords using Java 8
Encrypt and Decrypt 3
Encripting with PBE key 3
PBE 3

Members online

No members online now.
Total: 36 (members: 0, guests: 36)
Robots: 204

Forum statistics

Threads
473,766
Messages
2,569,569
Members
45,042
Latest member
icassiem

Latest Threads

Top