2

I'm using a web service which needs a username and password to login to. The web service will be used by a desktop application. What should I do about storing the passwords, and for that matter the usernames? Normally it seems you would store the passwords with a salt in a database, but in this case, the library I'm using to access the web service accepts a username and password in plain text (and not the encrypted version), but uses an SSL connection to the actual web service.

This is not my area of expertise at all, how should I decrypt the password before passing it to the methods in the library?

user9993
  • 5,833
  • 11
  • 56
  • 117
  • 2
    You can't. You need to store it in a form which gives you the plaintext password. – Lasse V. Karlsen Apr 09 '15 at 15:56
  • 1
    That seems incredibly insecure... – user9993 Apr 09 '15 at 15:59
  • Perhaps I'm not understanding the scenario but if your web service requires the credentials in plain text. You can store it encrypted in a config file, when you need to invoke the web service, decrypt the credentials from the config and call it. – kdtong Apr 09 '15 at 15:59
  • 1
    Yes, that is what I meant. You can't hash it, you have to encrypt it, in such a way that the desktop application can decrypt it. – Lasse V. Karlsen Apr 09 '15 at 16:00
  • Use a different web service, since it is "incredibly insecure." – Kjata30 Apr 09 '15 at 16:02
  • However, using SSL the transmission of the plaintext password is encrypted and should be safe. But the webservice does sound insecure: the password should not be stored unhashed; receiving it unhashed over SSL is OK, but not storing it. – simon at rcl Apr 09 '15 at 16:16
  • Are you sure the web service doesn't provide something like OAuth? As mentioned, your best bet is keeping the credentials encrypted and minimizing access to it (e.g. open it, read it, close the file, free memory, etc). – Fisher Apr 09 '15 at 17:37
  • Sending a plaintext password over SSL is the usual way, the password will then hopefully be hashed server-side by the service before storing to the database. Why do you want to store the password (client-side) at all, couldn't the user enter the password when necessary? Did i misunderstood your question? – martinstoeckli Apr 10 '15 at 06:51
  • It's an automated type program, run at scheduled times. It would be impractical to have someone enter the password all the time, – user9993 Apr 10 '15 at 11:10

2 Answers2

0

You neglected to mention whether this is just for you or if you're distributing the software to others.

What is the threat you're worried about?

If it's just for you:

Write it down on a piece of paper and keep that paper in your wallet. Prompt for the password when required.

The password variable should be a SecureString not a string, so that it doesn't get interned.

If you don't want to store it in your wallet, encrypt the password with a public key, and keep the private key in a smart card, and decrypt the password using the smart card.

If you don't want to use a smart card then use DPAPI.

Neil McGuigan
  • 46,580
  • 12
  • 123
  • 152
0

One thing that I found worked well for me in a similar situation was the encryption of the username and password using AES so that the credentials were modifiable in a file but not readable by naked eyes.

To make it more complicated you could run it through multiple passes with different keys and vectors.

I used this guy here: SO: SimpleAES encryption

Of course it can be reversed if the user gets a hold of the key and vector and runs it through their own decryption but at least in this situation you could store the encrypted byte array as base64 or write it to file.

Community
  • 1
  • 1
wmb
  • 58
  • 1
  • 5