0

Currently i am dealing with a conceptional issue in my Java - SFTP Client/Server - Setup.

Basically i got a client who sends files to a remote server and stores them there. BUT: You trigger the upload via a jar file on your computer, so anyone could decrypt the jar file and read the clear java file and obtain the credentials for my sftp.

Is there any technology to solve this issue or some workaround you can advise?

Greetings and Thanks!

Creative crypter
  • 1,348
  • 6
  • 30
  • 67
  • I didn't quite get your issue. You're worried that the users who use the jar file would be capable of decrypting and seeing what they're doing? Or did you hard-code your user/password in the source code? – oBit91 Dec 24 '17 at 23:22

2 Answers2

2

  1. It is inadvisable to put credentials into a common / shared JAR file. It can't be done securely, and if you need to get the user to replace them they need to download and install a new JAR.

  2. There is no way that you can keep the credentials private from the user. If your credentials need to be used on the user's machine, then it will be possible for the user to extract them, somehow. No matter what you try. (Assuming that they control their machine ....)

  3. Saving credentials encrypted does not protect them from the user. The application needs the decryption key. The user can find / extract that and then recover the credentials.

  4. It is better to issue distinct upload credentials for each user. That way, if one user loses or abuses his credentials you can invalidate them without affecting other users.

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
  • can you please explain what you mean by **issue distinct upload credentials for each user** , when i still want the user to use the jar file? – Creative crypter Dec 25 '17 at 01:02
  • You provide each user with their own username + password or key, *separately from the JAR file*. You could provide this as a config file ... separately from the JAR file, you could require them to copy it off a dynamic web page, etcetera, – Stephen C Dec 25 '17 at 11:33
-1

If I'm understanding your issue correctly, it is rooted at the fact that your java sources contain your credentials.

First, I highly recommend using jSch library for a great implementation of SSH2.

Regarding your credentials, you can find your answer here. In short - save your credentials encrypted.

oBit91
  • 398
  • 1
  • 12
  • The linked solution does not solve the OPs problem. Storing server credentials and API keys client side is something you should never do, encrypted or otherwise. – Luke Joshua Park Dec 25 '17 at 08:22
  • I wouldn't recommend doing it, however the OP specifically asked to store his credentials in thr source. Other than encryption I don't see any other option. Stephen's answer is more thorough but it simply doesn't deal with the issue, instead he's saying that it's an insecure design (rightfully). Either way I believe the OP has enough information to deduce an intelligent solution. – oBit91 Dec 25 '17 at 09:39
  • And when i write a application for c++? Can i then somehow hide the credentials from the user? As is is not possible with java.. – Creative crypter Dec 25 '17 at 12:45
  • In a word, No. If the user controls the platform he / she can reverse engineer / extract any credentials embedded in any program ... irrespective of the programming language. (The only assumption is that the program itself is *able* to use the credentials itself. But if it can't, that defeats *your* purpose in embedding them!) – Stephen C Dec 25 '17 at 14:01
  • ehm but in g++ documentation they say, if you compile your app like "g++ main.cpp -o main", the output file "main" can not be reverse engineered back to original c++ code, what about that? – Creative crypter Dec 25 '17 at 14:14
  • @Creativecrypter Technically speaking you can always revert the binary opcode to assembly instructions and from there deduce the logic. Although highly unlikely, it all boils down to the level of security you seek. – oBit91 Dec 25 '17 at 15:37