.wyu is just a zip file (?)

We've added [url=http://wyday.com/wybuild/help/encrypt-updates.php]password encryption to wyBuild[/url] 2.6.18.

Thanks! I created a registered forum account and will e-mail you.

Actually we had some questions about how this feature would work best for you (some implementation details), but we didn't have your email so we held off on the feature. I can't remember the question off the top of my head, but it's in my notes so I'll find it later today.

Just send me a ping at support@wyday.com.

Just wondering... did you ever get around to implementing this? 2.6.16.4 is out, but I didn't see it mentioned in the release notes.

Looking at the source code, I noticed that your zip library already has support for EncryptionAlgorithm.WinZipAes256 which should be pretty reliable encryption. But the AESCRYPTO constant is apparently disabled in your configuration.

THANK YOU! :D

[quote]I think actually the most natural place to store this password would be inside the client.wyc data file.
[/quote]

Ok, that can work. We'll add it to wyBuild 2.6.15.

A command line switch would work fine for us. In your model, I think actually the most natural place to store this password would be inside the client.wyc data file.

The idea of prompting the user to manually enter a password during the update process sounds interesting, but it would need some design work. Can the installation be temporarily aborted if they don't know the password? Can we display custom instructions telling them where to obtain the password? Can there be different passwords for each version? We don't need this, but I'm sure someone would want it.

If you did the simplistic approach, I think people could implement the prompting functionality themselves by modifying your open source code for wyUpdate and AutomaticUpdater. In your file format, you could allow for this possibility by providing a wyBuild option to encrypt the server files with a password, but not write the password to client.wyc.

Thanks for considering our suggestion.

[quote]However, your scenario seems to assume that the product is being sold to strangers on the internet. Our scenario is slightly different [...]
[/quote]

You're right, I did make that assumption.


[quote]We have talked about deploying application updates by copying the .wyu files to a shared drive using a Remote Desktop connection. I believe the wyUpdate software supports file URL's like this "file:///N:/Public/Updates/%file%".
[/quote]

That's possible, but it could be a bit of a hassle for you & your customers.


If we added AES256 password protection for the update files, would a simple commandline switch for wyUpdate work for you? That is, could you pass the password to wyUpdate something like this:

[code]wyUpdate.exe -upass="your password here"[/code]

Or would you require the user manually enters the password when they run your program?

Thanks for the explanation Sam. However, your scenario seems to assume that the product is being sold to strangers on the internet. Our scenario is slightly different:

- There is exactly one customer for this application

- The application is installed by us on PC's at the customer's physical office building

- These PC's already have access to a LAN file server with the full database, so we can assume they are secure (i.e. if not, our application is not the weak link). They do use BitLocker to protect against stolen hardware.

- Confidential data is transmitted over the internet, but it is always manual action that can be tracked, e.g. e-mailing a report, copying files over a secure Remote Desktop session, etc.

We have talked about deploying application updates by copying the .wyu files to a shared drive using a Remote Desktop connection. I believe the wyUpdate software supports file URL's like this "file:///N:/Public/Updates/%file%".

The disadvantage of this approach is that it won't work unless every PC has this "N:" drive mapped correctly, and for laptops they need to be connected to the LAN. Also, the Remote Desktop deployment method is less convenient than an FTP server. So we are interested in the idea of using our FTP server.

Although we "trust" the FTP server hosting provider, we don't really know who has access to this machine. It's not physically located in our building or the customer's building. Our IT staff doesn't have root access to the machine. Obviously there are a lot of points of failure here, so we're not looking for Fort Knox security. The files currently on our FTP server are encrypted with AES-256 using a strong password, which was accepted as reasonable due diligence: If a hacker gained access to the FTP server, they could not trivially extract our files, since like I said the zip password never leaves the office. But with wyUpdate, the objection was "hold on a sec, there is no password at all?" That's putting a lot of trust in this FTP server.

Hopefully this gives a little more background on where we're coming from. It sounds like we're not your typical scenario, but I still think wyUpdate will meet our needs.

[quote]Our current approach of using encrypted zip files does not require this trust.[/quote]

Encrypted zip files [i]do[/i] require trust; it's a different trust that you've chosen to ignore. Unfortunately there's no magic solutions. You will have to maintain security on your servers no matter what method you choose.

If your servers are insecure, fix that first. Then switch to a hosting company that you can trust.


[quote]Even if a hacker gains full control of the server, they cannot decrypt the archives without the password.[/quote]

Yes, but that makes the assumption that they can never obtain a copy of your program that uses the password. Once they get the program the password is visible in-memory. So every customer that has your app installed has access to the password. Thus the security of the password protected archives is illusory when applied to updating.

One customer buying your app with a stolen credit card (or using a computer with the app installed) has the "keys to the castle" so to speak.

Once a single user has access to the password, all security is out the window.


[quote]The password is always used locally and never transmitted across the internet.[/quote]

How do they get the password?

Telephone call? What if the line is tapped?
Snail mail? What if a neighbor opens the mail?
Email? Very very insecure.
Embedded in the app? Every customer downloading your app can read the password.
Etc., etc.


In other words using password protected archives is fine if the person developing the app is the [i]only[/i] person to ever attempt to open to open the archive. In every other case password protected archives are perhaps the weakest security you could implement.


[size=150][b]Why you should use licensing to limit updates[/b][/size]

Now I'm going to cover why you should use licensing and address any other points you've raised.

[b]Step 1: Use HTTPS and buy a secure server[/b]

First of all, if you're limiting updates then you need to use HTTPS (a.k.a. encrypted HTTP) and your servers must be secure. If you don't know how to secure your website then you need to hire someone. If your servers are on shared servers then buy proper colocated servers.

[b][i]Advantages over password protected archives:[/i][/b] The data will be secure when transmitted to/from your servers. Your server's security is in your hands. With password protected archives the password is spread across your entire user base (i.e. absolutely no security).


[b]Step 2: Use licenses to request updates[/b]

When you pass licenses to your (now secure) server you can verify that the license is valid before transmitting the update file. If it's not valid you can just show an error.

See [b][url=http://wyday.com/limelm/help/saas-and-time-limited-licensing/]SaaS and time-limited licensing[/url][/b] for a fully built example.


[b][i]Advantages over password protected archives:[/i][/b] Every customer will have their own license. And if you're using hardware-locked licensing like [url=http://wyday.com/limelm/]LimeLM[/url] you can block the customer on both the client-side and the server-side.

If a customer shares their product key across an organization (or with friends) then you can revoke their product key remotely and it will immediately be useless.