1

I am writing a tool that connects to a server using a login and password. The tool's user has to provide at runtime the login and password for the tool to be able to connect to a server to fetch some information.

However, I am putting in place some integration tests for my tool, hence the tests should be able to connect to the server. I can use a generic server's account to do so.
But I would like to automate those integration tests, so I would need to have the generic credentials stored encrypted somewhere and the integration tests to decrypt them when they get executed (even though they are generic, they are still credentials so I'm not comfortable in storing them un-encrypted).

What would be the way to work this out? If the tool is able to decrypt the password, then it means that it would hold some master key, and I do suppose this is wrong.
Should I expose some external service to which I am sending the encrypted value to get it decrypted so the encryption/decryption would be processed outside the tool?

Thanks

Xendar
  • 466
  • 1
  • 6
  • 15
  • What is it that you want to test? That the Internet is Still There? Or that your client still speaks the correct protocol? Or that the password is still valid? This is the question you should find an answer for first. – wallenborn Mar 09 '17 at 17:12
  • 1
    Maybe you could explain the scenario you envisage where a bad guy would steal the credentials, because it's not clear why you're protecting these test credentials, or who from. Surely the credentials wouldn't ship in a production version of the software? So are you protecting them from other developers? And if so, could they not simply put a breakpoint somewhere to see the decrypted credentials? – PaulG Mar 09 '17 at 17:13
  • @wallenborn I am testing that the tool is behaving correctly in front of a live system (compared to the unit tests where I stub the server). – Xendar Mar 09 '17 at 17:28
  • @PaulG I am maybe indeed pushing a bit the security here as this is a generic credentials, that would not be shipped to production. Still I found the security question behind interesting to be covered. – Xendar Mar 09 '17 at 17:29

1 Answers1

0

I think there is no real solution for the problem. In the end somewhere has to be the algorithm or key to decrypt the password anyway. So I would maybe go with a encryption key + obfuscation or key + code in a language that cant be reverse engineered

Ocean15
  • 135
  • 9
  • This is why I thought about separating the encryption and decryption from the tool – Xendar Mar 09 '17 at 17:30
  • Speration would be just useful because java is quite easy reveresed. But a good obfuscation is strong too – Ocean15 Mar 09 '17 at 17:31
  • Obfuscation is only hidding the value to me (like replacing the characters by *), hence not possible to get back the original value. Maybe I did not fully understood your answer then? – Xendar Mar 09 '17 at 17:43
  • Okay again: You encrypt the password with a key(salt) via any common encryption and store the key as algorithm(some fancy stuff) in the code. Then you obfuscate your whole code so no one can reverse engineer your java code. That way your key(salt) is imo as safe as possible (in pure java) – Ocean15 Mar 09 '17 at 17:47
  • There is no such thing as security through obscurity... – Luke Joshua Park Mar 09 '17 at 21:02