8

I've been tasked with writing a module for my company to interface with an external API. This API has a syntax similar to SSH where I have to incorporate the user details as well as the host address of the server I'm trying to connect to.

However, I run into the security issue that in order to pass the user details, I need to have them in plaintext. Even worse is the fact that these user details are actually the user details for the machine that the server is running on. Is there a smart way to do accomplish this task without going overboard and using an external login server? I know there have been similar discussions where the conclusion "Don't do it" was reached, but in this case I really have no control over the way the API works.

TheJulyPlot
  • 7,669
  • 6
  • 30
  • 44
Max
  • 81
  • 2
  • So, the data supplied by the client have to match the data stored on the server? Sounds like the same problem that password has. How is the password model not the same as your situation? Transmit hashes of the data? What about shifting to Asymmetric Keys instead? – schroeder Jul 22 '14 at 21:10
  • Your question is a bit unclear, but maybe the answer is in creating a proxy or bastion of some sort ? – Little Code Jun 10 '16 at 09:54

3 Answers3

1

If you can't change the API, then you need to either store the password or ask for it from the user every time you need to make an API call.

Assuming that asking isn't practical, store the password encrypted. No, it won't stop a serious attacker, but it's better than nothing: storing the password in plaintext won't even stop a script kiddie.

Mark
  • 34,390
  • 9
  • 85
  • 134
0

It's a common problem, and using an external login server just shifts the problem elsewhere.

One (rather elaborate) solution is to encrypt the password using a public key for each authenticated user and using password protection on the users private key, stored on the machine, where the password supplied by the user may also authenticate access to the machine acting as client, or sent across the wire from storage on the client machine (but still protected by the manually entered password). This at least removes the cleartext from the storage.

Certainly you want to make sure there is a restrictive firewall between the client machine and any users.

Community
  • 1
symcbean
  • 18,278
  • 39
  • 73
-1

Well, so you could do the asymmetric key method, but if you think about it, the reason the password is encrypted on the client, is usually the same password is used in other instances, so if you use a separate password for transactions with this api, you'll isolate problems only to this method of access.

mincewind
  • 41
  • 4