18

I have read the following question: Storing password in Java application but I don't find the answers useful for my case.

So here is my question somehow related to that. I have a Java Web application with a back end DataBase secured access with username and password.

Right now the username/password sits in a .properties file on the web server. The server is secure, but having it like that in plain text kinda bothers me.

Tried at some point to use secure stores to encrypt/decrypt the username and password but the stores are themselves protected by a password so where do I store that? I'm back to square one.

So? What is the best way to store username/passwords for connecting to other systems (database, web service etc)

Community
  • 1
johnD
  • 183
  • 1
  • 1
  • 4
  • Have you looked at the answers here: http://security.stackexchange.com/questions/22817/how-to-encrypt-database-connection-credentials-on-a-web-server/22858#22858 ? – iivel Nov 02 '12 at 15:09
  • I often see passwords like this encrypted, in some belief that it protects it. Of course, if the software needs the password, then the password is decryptable, which means it can be read by anybody with the decryption key. If the software boots up automatically, then the decryption key is usually sitting right there, readable. This is often required in some shops because even though it's security through obscurity, it's better than no security at all. – Brandon Aug 04 '14 at 15:09
  • Personally, I would avoid such an encryption/decryption process unless I was forced to do it. It just adds complexity with very little benefit. – Brandon Aug 04 '14 at 15:10

2 Answers2

13

The server needs to be able to access some resource R. If an attacker has full control of the server then that attacker can by definition now access any resource the server can access. There is absolutely nothing you can do about this except secure the server.

If the attacker doesn't have full control of the server but has access to the server's file system then the question is if the server needs to boot autonomously (without any external help). If the server needs to boot autonomously then all the data required to access resource R must reside somewhere in the server's file system and are thus available to the attacker. The best you could do is to try and obfuscate the password - good luck with that.

If the server can use external help to boot then the best option would be to require an administrator to enter the password during boot (and keeping the password stored in RAM). If that's not a practical option (it usually isn't) then you could secure the password using a USB token (e.g. store an encrypted password and use the USB token to decrypt it).

TL;DR: Assuming you can't manually enter the password every time you boot the server there's not much you can do except protect the server itself.

David Wachtfogel
  • 5,512
  • 21
  • 35
-3

The answers about encryption are not wrong, but the approach is wrong. You should not encrypt. You should use a one way hash function. This means that you do a NON-reversible mathematical operation on the password, and store the result.

When someone wants to log in, you perform the operation again on the password they supply, and compare it to the result on record.

LOADS more detail here.

https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet

Toy Trumpet
  • 1
  • 4
    Please take a closer look at the question. It's not about logging on, it's about the server connecting to other resources on behalf of the user. – S.L. Barth Aug 09 '15 at 19:30
  • 3
    Hashing is worse than useless here: the question is about password storage as the *actor* in a login situation, not about password storage as the verifier. – Mark Aug 09 '15 at 19:59