0

I want to make an application which simplifies the use of a certain command line program which can ask for a username and password.

I would like to store the password but then later be able to decrypt it and use it to execute the cli app.

I have looked at lots of information but a lot of them say "use a salt / passphrase" but I would like it to act like (as an example) SQL Server Management Studio where you put in your details and save the profile for later use.

An example I found was the following:

Encrypting & Decrypting a String in C#

However this would be weird for a password since you would then need the user to enter two of them. Likewise if you store the salt hard-coded then surely someone can reverse engineer the application.

Community
  • 1
  • 1
Dwiea
  • 107
  • 2
  • 8
  • You could use certificates to do the encryption/decryption which would mean they need to have access to the certificate to be able to decrypt. – JanR Mar 03 '16 at 01:11
  • Salt is not a secret - otherwise there would be no way to protect it without creating a new secret to protect. It does prevent certain kinds of attacks. I dunno about a "passphrase" but your app would create the salt. – Ňɏssa Pøngjǣrdenlarp Mar 03 '16 at 01:19
  • @JanR so I would generate a certificate (and store it in the app root or in a certificate store?) and then use the string in the certificate as the salt? Do you know of any examples using this method? – Dwiea Mar 03 '16 at 01:20
  • @Plutonix but then if I generate the salt I need to store it somewhere. Doesn't that mean that the salt can then be taken and used to reverse the encryption? – Dwiea Mar 03 '16 at 01:21
  • You would store the certificate in a store on the server, so that only that server could decrypt the passwords. – JanR Mar 03 '16 at 01:23
  • @JanR Ah this would be on a 'user' computer if that makes a difference – Dwiea Mar 03 '16 at 01:30
  • https://crackstation.net/hashing-security.htm - your use case is a little different. Most posts you will see (and the link) are about *hashing* a login password - since you are acting as the PW repository, it would be a little different and more dangerous – Ňɏssa Pøngjǣrdenlarp Mar 03 '16 at 01:31
  • then it won't work, as ever user will have the certificate to decrypt every other user's passwords. – JanR Mar 03 '16 at 01:34
  • @JanR isn't there a CurrentUser store that could be used? – Dwiea Mar 03 '16 at 01:37
  • @Plutonix yes this is the trouble I was having searching for info. Most was about hashing without caring about being able un-encrypt :( – Dwiea Mar 03 '16 at 01:38
  • I have never tried, only ever used it in a server configuration where only the server had the ability to access the certs. – JanR Mar 03 '16 at 01:38
  • The term is `decrypt`. I gritted my teeth thru an entire network TV episode where they constantly asked if Something Important was "de-encrypted" yet for 41 mins. You could store the components separately. but the mere act of storing them means they could be decrypted by Bad Guys. The user should know the risk as pointed out in the answer you should upvote – Ňɏssa Pøngjǣrdenlarp Mar 03 '16 at 01:44
  • If I can generate a certificate and there is a CurrentUser certificate store then using the certificate to seed sounds like it should be quite flexible and a reasonable way to proceed forward. – Dwiea Mar 03 '16 at 01:45
  • @Plutonix I think my problem was thinking that there would be a nice packaged / correct way of storing a password and retrieving it. I have used the mercurial_keyring extension for TortoiseHg before however I am guessing this would suffer from the same problems as we are discussing here – Dwiea Mar 03 '16 at 01:48

1 Answers1

2

Likewise if you store the salt hard-coded then surely someone can reverse engineer the application.

Yes, so don't make false promises. Applications like database management and FTP software offer to store passwords, but warn about the security risks of doing so,and allow the user to opt out of that feature. As such you could generate a key and store it somewhere other than were the encrypted passwords are stored, and while it won't be secure enough for all uses it will for some. Also, if users might have more than one credential then make this decision one where refusal can be global but not acceptance. (Consider eg a user who appreciates the convenience for test cases but won't accept the risk for other csses).

If there are a great many passwords then a master password might be reasonable, as some browsers and mail clients offer.

Jon Hanna
  • 110,372
  • 10
  • 146
  • 251
  • In my case each 'profile' would need the username / password entered each time one is created and any preferences regarding the storage of password would be per profile. – Dwiea Mar 03 '16 at 01:26