I am writing a program in Processing (which is basically java), that (amongst other things) downloads files from a FTP Server. To connect to the Server the program needs the correct FTP-password, which is currently saved as plain text in a String in the source code. The program should be given out to other people later, so I'm guessing this is not a very safe way to store the password. What would be a good way to protect the password?
-
1Without the user providing input, and comparing it to a hash I don't think there's a secure way to do what you want. Encrypting the password means you have to store the encryption key in plaintext somewhere, which is as good as storing the password in plaintext. From a security perspective anyway. – RoraΖ Aug 19 '14 at 11:17
4 Answers
I think your effort is broken by design. You want to install a program at someone's machine that connects to an FTP server via password, but you don't want the user to know the password. No matter what you do to protect it, the user can easily intercept the network traffic comming from the program. For example, the user could set up a proxy and just dumping everything that runs through it - the password will be somewhere in this dump. Encrypting the password at the user's side and decrypting it at the server will just delay the problem - the user will just send the encrypted password.
I would rather set up an extra FTP account with an extra directory just for this user. There he cannot hurt anything, because anything he sees is generated by his own actions.
edit It's true that with FTPS the user wouldn't be able to extract the password. But who is setting up the encrypted connection in the first place? The user's machine. So the certificate is sent to the FTP server before the encryption is done, which can be intercepted again and used to decrypt the whole communication.
![](../../users/profiles/47985.webp)
- 381
- 1
- 7
You can't.
FTP is a plain-text protocol. No matter what you do to slow down reverse-engineering the password from the program code, an attacker can always get the password just by using a network sniffer to watch what the program is sending out over the wire.
Edit: In response to your comment, FTPS is a bit harder to break: an attacker can't grab the password with a network sniffer. The password still needs to be present in RAM at some point, so the attacker can look for it with a debugger, or they can still reverse-engineer your program to extract the password.
![](../../users/profiles/37496.webp)
- 34,390
- 9
- 85
- 134
-
1Or if it would be encrypted connection, by using a debugger to trace what the code is doing. No need to analyse all of it, just get to the step where it deobfuscates the password and print it. – domen Aug 19 '14 at 10:43
-
I forgot to mention it's actually a FTPS connection. Is it still possible to just get the pw using a network sniffer with FTPS? – BigAl Aug 19 '14 at 10:56
-
No FTPS is secure. Mark is saying FTP is a plaintext protocol, and you would be able to see the password in network traffic. – RoraΖ Aug 19 '14 at 11:20
-
1@BigAl A network sniffer won't see it. But anybody who's running the application on their own machine can still extract the password. – CodesInChaos Aug 19 '14 at 13:09
Store the password in source code is the worst approach. But the right approach is not easy to define and depends on chosen procedures.
A better approach could be:
- Ask the user to insert the password every time (console/gui interface)
- Save the password to a text (property) file, in this case other users with right permissions could read the file with the cleartexr password. You can still encrypt the password(s) with a master password and an cipher like AES. In this case every time the user needs to insert the master password but you can protect many password with the master one at the same time.
![](../../users/profiles/53372.webp)
- 51
- 3
-
I can't ask the user to insert the password bc the users are not supposed to know it. – BigAl Aug 19 '14 at 11:01
-
@BigAl So you want the user to use a password without knowing it. Sounds pretty impossible... – CodesInChaos Aug 19 '14 at 13:15
-
if the user should not enter the password, because he should not know it, you can only obfuscate it. To do it one option is to encode it in AES with a fixed password. You also need to take the risk that the user discover the password anyway, and it is not that difficult! – DavidC Aug 19 '14 at 13:43
What platform is this being run on?
Ideally, you should use something like an encrypted password store, or a password manager which supports APIs or command line utilities.
On linux, I use a tool called 'pass' which uses gpg encryption to store passwords.
When I want to use a password from my password store in one of my scripts, I simply send the output to a variable and assign that variable as the password.
Here's some documentation for pass:
http://liquidat.wordpress.com/2013/03/27/pass-a-perfect-shell-based-password-manager/
I also make use of Password Manager Pro from ManageEngine - they have a great SSL API for retrieving passwords. XML-RPC is also available. They provide java libraries for doing this. PMP is not free though - but it's probably one of the best password managers I've seen for the price you pay.
![](../../users/profiles/53894.webp)
- 251
- 1
- 2