2

I am trying do something similar to this or this.

I have managed to break the second post down into two jar files. I want to be able to use a command line, pass a password to it, and generate and encrypted password. This is step one (which I have successfully done). My output now is two things:

1) An encrypted password

2) a key, who's output is something like: javax.crypto.spec.SecretKeySpec@######

My problem is now the second part. I want to have another program that decrypts those into a password that can then be sent to log into an application.

My issue is that I cannot seem to set the key in the decrypt program manually. I really only have code to generate it.

Like it would be great to do something like

SecretKeySpec key = args[1]

But that is impossible because SecretKeySpec is not a string and that output is also not the key, but fully-qualified-class-name@hashcode

I guess my issue really boils down to this: I need to store an encrypted password in a config file that was created by program1. I need another program (program2) to be able to decrypt it. But how do I do that if program2 does not have the key that used to encrypt the password in program1?

I feel like I am going to a totally wrong path here, any guidance to get back on track would be greatly appreciated.

David Horvath
  • 21
  • 2
  • do you need to decrypt it, or do you just need to make sure it's correct? if the later, you can use some sort of hash/hmac to validate the key w/o ever knowing the key, – dandavis Jan 05 '18 at 20:31

1 Answers1

1

At the high level, it sounds like you're trying to get both programs to agree to use the same password. You might then be muddying the issue by adding a second constraint to this, which is "how do I move the password securely from program 1 to program 2?"

This is the classic problem that Secrets Management solutions were developed to handle. Have you considered using a secure storage program, like Hashicorp Vault? You can give both programs 1 and 2 access to the same vault instance. Then, your secrets are always stored in the vault, and only taken out by the programs as needed.

John Deters
  • 33,650
  • 3
  • 57
  • 110
  • No I have not tried using anything like Hashicorp Vault...In a way, I think I might be making this too complicated. I mostly have experience with java writing basic programs that run from command line, or are called from batch files. They really are not too complicated. Our company has been trying to get more serious with security, and wanted to get rid of passwords stored in plain text in config files. So I thought I could make a program to encrypt a password (which I did). Then put that encrypted password in the config file. Now the second program needs to decrypt that. But – David Horvath Jan 05 '18 at 19:19
  • that is where the problem lies. I am wondering if I should take a much simpler approach or something. This doesn't need to make the password impervious to hackers or something. Just more secure than having a password stored in plain text. – David Horvath Jan 05 '18 at 19:21
  • If its available to the application its available to anyone that has the access the application does. There is little point encrypting config files unless you are willing to manually have to enter the passwords on boot and store either the password or the config in memory from there on out. Unless taking that approach leave the password in the config in plaintext, set the permissions so that only the user running the app can read the config and lock down whatever service that password is used for to only allow those credentials to be used for required actions. – Hector Jan 05 '18 at 21:16
  • @DavidHorvath - one other alternative is to have a script running under a different user to the application start it and pass the password to it then. That way the file with the password can be stored only readable to that second user account - if the application is exploited but no privilege escalation occurs the password is still safe unless read out of memory (which is possible). – Hector Jan 05 '18 at 21:18