9

I need to save a db password as an encrypted string and then decrypt before connecting.

Can anyone refer me a good two-way encryption library in Java?

Dan
  • 9,681
  • 14
  • 55
  • 70
  • 3
    If you encrypt your passwords using password-based encryption (a two-way technique) and an attacker gets to know your encryption password, all of your user passwords will be revealed (and, probably, all at a time). If you don't have such encryption password (or key) to be able to decrypt, this risk disappears, and the attacker will have to trust on brute force or similar strategies. Found [HERE](http://www.jasypt.org/howtoencryptuserpasswords.html) – AndroidHustle Nov 02 '11 at 11:42
  • 5
    This is right. Password should always be [_hashed_](http://en.wikipedia.org/wiki/Hash) and not encrypted. – dwalldorf Nov 02 '11 at 11:54
  • 8
    @entek: I think you misunderstand the question, as I read it this is not about storing user passwords, but the password for accessing the Database. You would need the DB user and password to connect. Now, for a web application this should be handled by the app-server through JNDI-resources and storing the passwords securely, but if you are writing a Plain Old Java App, whichs accesses the DB through JDBC, you'll need the password somewhere. And leaving it in plain text is not the way to do it, so encryption a password is definitely a valid use case... – beny23 Nov 02 '11 at 12:04
  • @entek Usually you cannot use an already hashed password to log into a database. Besides, in the named case this would not improve security in any way. – JimmyB Nov 02 '11 at 12:06
  • I got this wrong.. I thought you wanted to save passwords of someone.. In this case hashing is no option of course.. My blame – dwalldorf Nov 02 '11 at 12:11

3 Answers3

4

Dan, take a look at this thread as there is some useful info on how to do that in a property file just via Java's APIs.

Encrypt Password in Configuration Files?

Community
  • 1
  • 1
Mechkov
  • 4,294
  • 1
  • 17
  • 25
1

Usually passwords are kept as hash, so the process of getting the real password is not possible, other than converting it back what we do is we convert the password user entered to a hash and then match them. If you can explain more about your usecase it'll be clear

Imal Hasaranga Perera
  • 9,683
  • 3
  • 51
  • 41
1

In real terms of security Base64 encoding will be almost as good as any "hard" encryption.

(Dispute in comments. :) )

Edit: OK, the recent downvote brought me back here to add some words.

The above statement is meant to remind people that it is impossible to have any automated activity authenticate in a secure way to some other party. If you'd use a password to encrypt and decrypt a stored password, where would you store this new password? Easy! Just make a third password to securely store the second password and so on.

Point is: Any password which is decryptable by some automatic procedure is in fact not encrypted but merely obfuscated. Thus, the encryption is futile in the first place.

JimmyB
  • 12,101
  • 2
  • 28
  • 44
  • 2
    It's not perfect, but still better. You're right that you would have to keep adding password on top of password... but leaving it in plain sight could be worse. Say you were storing passwords for an external service to authenticate on behalf of users. If you stored it in plaintext and your database (only) was breached, they would get the passwords. If you encrypted them and had the key stored in a file (and app memory at runtime) and the database (only) was breached, the attacker would have to brute force the decryption key. Using a salt per record would slow them down even more. – Nick Spacek Nov 10 '15 at 15:33
  • 1
    Of course you're right. Yet, you say "and had the key stored in a file"... And if that file one day takes a trip to the internet it's all gone again. I guess it boils down to the best-effort technique to somewhat split up the required information and hope that no one gets a glimpse at *all* the individual parts. – JimmyB Nov 10 '15 at 16:07
  • Sure thing, totally agree! – Nick Spacek Nov 10 '15 at 18:45