Hiding FTP Credentials

Is there a way to hide the ftp login credentials from the users using wyUpdate? We have a ftp server that we are using to download new updates, but don't see any other way to provide the login credentials other than imbed it in the target url. We are unable to provide these updates anonymously which forces us into this scenario.

The reason why I ask is if the wyUpdate client fails to download the media successfully it will display the full connection url in the message which exposes our login credentials. We do plan on moving to sftp, but I could only guess that the same will apply here.

Thank you for your time and I am really enjoying your product!

Jim

Hey Jim,

There's no way to hide the FTP credentials. Even if we hid them in the user interface in wyupdate, they would still be visible in the client.wyc file, and they would also be visible in a program like WireShark when your user connects to your FTP server.

The way to handle this is to give that user read-only access to your FTP.

Or use HTTP (which we recommend). Using HTTP you have full control over who has access to your servers without having to use a "global password". See: How to prevent or limit updates.

Thank you for the fast feedback!

It totally understand about the wireshark issue which is why we were trying to move to sftp (I stood this solution quickly for testing). I mentioned the HTTP solution, but this will be over the internet and our management is requiring a method that will allow only authorized users (Not referring to just the wyUpdate application) to download the media.

Based on your solution how does this prevent anyone (non-Customers) from simply downloading the wyu/wys files using any simple download method? Perhaps, I misunderstood the article, but it appears that this solution is only for preventing downloads using the wyUpdate application. Our concern goes beyond this to people checking out a site for vulnerabilities. We chose SFTP as our ideal solution to force someone to authenticate first before attempting to download anything.

If someone was able to download the wyu/wys files (Without your wyUpdate client), how difficult would it be to unpack? I'm working with the premise that downloading these files is the same thing as someone having our intellectual property.

You guys have helped me change expectations already for the better so perhaps this could be another one of those situations.

Jim

It totally understand about the wireshark issue which is why we were trying to move to sftp (I stood this solution quickly for testing).

Well, wyUpdate only supports downloading from ftp://, file:///, http://, and https://. We don't support downloading updates from sftp:// (a.k.a. SSH FTP) nor ftps:// (a.k.a. FTP with SSL slapped on).

wyBuild does support uploading updates to SFTP (a.k.a SSH FTP) sites, but that's another matter.

Based on your solution how does this prevent anyone (non-Customers) from simply downloading the wyu/wys files using any simple download method? Perhaps, I misunderstood the article, but it appears that this solution is only for preventing downloads using the wyUpdate application. Our concern goes beyond this to people checking out a site for vulnerabilities. We chose SFTP as our ideal solution to force someone to authenticate first before attempting to download anything.

In the limit or prevent updates article we talk about how you can limit access of your updates to only users with a valid product key. The actual verifying of the key is done server-side. And if you do everything on HTTPS then the product key is encrypted on the way to the server and the update is encrypted on the way back to the client.

This sounds like it solves all your problems:

  1. Encrypted details
  2. Encrypted updates
  3. Verification done on the server (not wyUpdate).
If someone was able to download the wyu/wys files (Without your wyUpdate client), how difficult would it be to unpack?

It depends on what's inside the update. Sometimes updates only contain patches (that is, the info to get from "old file" to "new file"). Sometimes updates contain full files. Sometimes updates contain a mix of both.

Using the article I linked to solves the problem of users without permission to your app getting updates.

Does that make sense?

Thank you for the feedback. This does make sense.

Jim