• 0

[C#] Best encryption method for ftp password


Question

I'm building a class that manages ftp connections. I just realized when making a private string for the password that anyone could just load the program in a hex program or something and grab the password can't they? Or aren't there ways to obtain that string? It seems kind of a bad idea to just have an ftp password sitting there in plain text. But I can do a one way encryption b/c I'd have no way of decrypting it for them. Any ideas to this solution? Or is it not even a problem if it's set to private?

8 answers to this question

Recommended Posts

  • 0

If you're using standard FTP the password isn't sent encrypted during authentication. If someone wanted it they could just sniff their own network traffic and read the plain text after your program has done whatever it is it needed to do in order de-obfuscate it.

  • 0
  G0NADS said:
if you wanted to keep someone from locally reading it, consider md5 hashing the password, it wont get sent encrypted and they could sniff it if theyw anted to, but if its md5'd in the proggy then its pretty secure

How do you propose turning that hash back into the source password so that it can be used when authenticating with the FTP server?

  • 0

Really the only way to not store the password in some readable form would be to have user interaction. In other words, have someone enter the password into a dialog box or something (obviously not what you want).

Here are some things you could do (none of which are fool-proof):

1) Encode the password locally with Base64 or something, then decode it when it needs to be sent to the FTP server. At least the password wouldn't be stored in plain sight.

2) Encrypt the password with AES locally and decrypt it before sending to the FTP server. This technically is no more secure then #1, because you'd have to store your AES key somewhere, which someone could read and then use to decrypt your FTP password.

3) Store the password in an encrypted database, such as SQLite. Again, same problem as above.

These methods all add steps that would prevent the casual person browsing your code or disassembling your program from seeing the plaintext password. But I think the bottom line is that in any system where someone has access to the machine running your code, the password could be compromised. It would be important to consider who has access to that code, and what their level of computer knowledge is. If it's a casual user, then the above methods should be fine. But if it's a knowledgeable programmer, I think you're out of luck.

Also, don't forget what "the evn show" said above: if you're using the plain FTP protocol, any ol' idiot can simply sniff the password from the network traffic, which would obviate the need to encrypt the password in your code.

  • 0
  Express said:
The recommended way is to use DPAPI

See http://msdn.microsoft.com/en-us/library/ms995355.aspx

Use ProtectedData class in System.Security.Cryptography if code is in .net

Thanks for pointing that out, but doesn't it inherently suffer from the same problem (that someone with access to the code could run the same protection routines to decrypt the password)?. Also, the protected FTP passwords could not be transferred to another machine because the ProtectedData class locks it to the current computer or user.
  • 0
  boogerjones said:
that someone with access to the code could run the same protection routines to decrypt the password

Only if someone knows your username & password+has access to your system. <= Equivalent to no password!

Just Code access doesn't give away your credentials.

  boogerjones said:
the protected FTP passwords could not be transferred to another machine because the ProtectedData class locks it to the current computer or user

I consider that as a plus point from a security perspective.

This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Posts

    • Idiotic Teams strickes again. "Teams, Teams, I was not joking when I said I'd like to smash every tooth in your head Oh Teams Teams, I was not joking when I said By rights you should be bludgeoned in your bed"
    • KB5060829: Microsoft confirms new upcoming Windows 11 24H2 feature is triggering Firewall by Sayan Sen At the end of June, Microsoft released Windows 11 setup and recovery updates (KB5062233/ KB5060843/ KB5062197/ KB5061090) following the month's non-security previews for 24H2 (KB5060829) and 23H2/22H2 (KB5060826). Today, the company has confirmed that KB5060829 is causing some troubles for systems in regards to Firewall. Microsoft says that IT admins and system admins may notice a recurring error entry in the Security event log related to Windows Firewall With Advanced Security wherein the Event Viewer records event ID 2042, labeled “Config Read Failed” with the message “More data is available” each time the device restarts. Although logged as an error, the tech giant notes that this entry does not indicate a malfunction of the Windows Firewall and as such it can be "safely ignored and disregarded," and that Windows Firewall continues to enforce rules and filter network traffic normally as intended. Microsoft assures that "there is no impact to Windows processes associated to this event." IT support teams and even general users often rely on error-level event entries to detect misconfiguration and other issues (Microsoft itself recommends you do so), so unexpected log noise can trigger unnecessary alerts like these. Interestingly, in this case, the logged event stems from an upcoming feature as Microsoft notes that the "event is related to a feature that is currently under development and not fully implemented." No additional information regarding this new feature has been provided at this time. For those who prefer a cleaner log, administrators can filter out event 2042 in Event Viewer or via PowerShell. In Event Viewer, create a custom view filtering out ID 2042 under the Security log and in PowerShell, use the Get-WinEvent -FilterHashtable parameter. Microsoft says that the team is currently working on a fix and an update will be released later. However, no ETA has been shared today. You can find the issue entry here on Microsoft's official Windows Health dashboard website.
    • Concerning the situation at XBOX (title cancellations, studio closures and firing employees): The management at MS gaming division (Booty, Spencer etc.) has to go. Money and time has been wasted in such amounts that those people have to be held accountable and better managers can take the lead. In most other businesses this would have happened ten years or so ago.
    • Why, because different bothers you? You aren’t using the OS per your own admission so why is it a shame? It’s a great way to focus imo.
    • People often hate on what they don’t understand. It’s not stupid, it’s different. That said, ignorance more often than not rules the roost, so it is seen as stupid instead. How much time have you spent learning how to use macOS as intended before making your proclamation?
  • Recent Achievements

    • Reacting Well
      SteveJaye earned a badge
      Reacting Well
    • One Month Later
      MadMung0 earned a badge
      One Month Later
    • One Month Later
      Uranus_enjoyer earned a badge
      One Month Later
    • Week One Done
      Philsl earned a badge
      Week One Done
    • Week One Done
      Jaclidio hoy earned a badge
      Week One Done
  • Popular Contributors

    1. 1
      +primortal
      433
    2. 2
      ATLien_0
      158
    3. 3
      +FloatingFatMan
      146
    4. 4
      Nick H.
      65
    5. 5
      +thexfile
      62
  • Tell a friend

    Love Neowin? Tell a friend!