Recipe 11.19 Transmitting Data Securely

11.19.1 Problem

You want to transmit data, such as credit card numbers, securely.

11.19.2 Solution

Use HTTPS to send the data over a secure channel or, if that is not possible, use a third-party encryption library for one-way data encryption.

11.19.3 Discussion

Flash can use the same protocols for data transmission—HTTP or HTTPS—as HTML pages. A great many servers are set up to accept communication over the insecure HTTP protocol only. Transmitting unencrypted data over HTTP is not secure and should be used only when the data is not sensitive. For example, if you are sending survey responses to the server, you might not care if that information can be seen by others. But insecure transmission compromises credit card numbers and other sensitive financial or personal information. Although a complete discussion of security is beyond the scope of this book, there are many good resources on security.

If you are not using an off-the-shelf solution, such as SSL, there are many non-obvious pitfalls that can leave your data vulnerable. Leave the protocol design to the experts or consult a book that addresses secure cryptographic protocol design: Secure Programming Cookbook for C and C++ by Viega and Messier (O'Reilly) or Practical Cryptography (not Applied Cryptography) by Schneier and Ferguson (Wiley).

Be aware that various encryption algorithms deemed secure today may be considered insecure in the near future due to advances in cryptanalysis and computer processor performance increases.

So what should you, as a Flash developer, do? First, you should recognize that Flash data transmission isn't secure if you are sending it over HTTP. Not only can your unsecured data be intercepted and decoded, but more nefariously, unauthenticated data can be forged. You should make sure that your e-commerce page doesn't accept bogus transactions, for example. There are two basic strategies you can use to secure Flash data transmissions. You can rely on the secure HTTPS protocol for transmission, or you can manually encrypt data (one-way encryption) with a third-party encryption library. If available, HTTPS is the simplest, fastest, and often the most secure to implement. So let's tackle that approach first.

When data is sent over HTTP, it is normally not encrypted in any way. This means that people with the known-how and resources can tap into that transmitted data and read it. However, when you use HTTPS, although the data sent between client and server might be intercepted, it likely cannot be decrypted by the eavesdropper. To use HTTPS from Flash, specify the https protocol as part of the URL when calling LoadVars or XML methods, or similar methods that accept a URL parameter. For example:

myLoadVars.send("https://www.myserver.com");

However, for this to work, two things have to be true:

• Your server has to actually support HTTPS. Otherwise, the URL will be unavailable. For your sever to support HTTPS it will need an SSL (Secure Socket Layer) certificate. If you use a shared host, contact the webmaster to see whether she already has something available for you. If you administer your own server, you will need to get a certificate from a certificate authority such as Verisign (http://www.verisign.com). You'll need to get a certificate to match the level of encryption (128-bit, 256-bit, etc.) that you want. Generally, the more bits, the stronger the encryption.

• The Flash movie needs to be playing in a web browser that supports encryption that matches the level of SSL encryption in use. For example, if using an encryption algorithm that requires 128-bit encryption (strong encryption), then you'll need to require that all users have a 128-bit-encryption-capable browser.

How does HTTPS/SSL work within Flash? When the Flash movie wants to send data to the server, it uses the browser's built-in HTTPS/SSL capabilities to request a public key from the server. A public key is exposed publicly by the server so the client-side data can be encrypted. Once the server returns the public key (and the key is validated), the data from Flash is encrypted in the browser and sent to the server. The data is then decrypted on the server (using a corresponding private key) before it is sent to any server-side scripts.

So how secure are HTTPS transactions? The answer depends on the level of security you demand and the capabilities of the browser. For example, modern browsers support at least 128-bit encryption, which is more secure than older 56-bit encryption. Although 56-bit encryption might appear better than nothing, a false sense of security is worse than no security; 56-bit encryption is considered vulnerable by modern standards and should not be used when true security is necessary. Many companies require 128-bit security because it is considerably less likely to be decrypted by a third party. Financial institutions, for example, almost always require 128-bit encryption. Although HTTPS/SSL is an industry standard for transmitting data securely, no encryption is perfect. That said, 256-bit encryption, when implemented on a properly secured system, is considered unbreakable by today's standards.

There is at least one additional issue of which you should be aware when working with HTTPS/SSL. Although data transmitted via HTTPS is encrypted during transmission, once the data has been received and decrypted by the server, it is again vulnerable to espionage. You must take precautions to secure the server and data sources. Implementing security measures to protect your server from crackers is arguably even more important than securing the data transmission. After all, you don't want to go to all the trouble to secure the data transmission but offer the cracker the convenience of being able to grab your entire database of credit card and social security numbers!

If you cannot use HTTPS/SSL (for example, if you don't have an SSL certificate or if your Flash movie plays as a Projector or is embedded in a Director application), you'll need another solution. Let's examine the third-party encryption options that are available.

There are three types of encryption we'll touch on: public key, symmetric, and one-way hash encryption. Each of these types of encryption is best suited to different types of scenarios. We've already seen an example of public key encryption when we looked at SSL. SSL certificates grant a server a public and private key. When a client wants to encrypt data to send to the server, it must first request the public key. It uses the public key to encrypt the data and then sends it to the server. The corresponding private key, which can be used to decrypt the data, is available only on the server with the SSL certificate. (Interestingly, data encrypted with the private key can be decrypted with the public key. What purpose does it serve to encrypt data that can be decrypted with a widely available public key? Although it doesn't offer privacy, encrypting data with a private key offers so-called authentication. If the public key can successfully decrypt the data, you are reasonably sure that it was encrypted by the entity to whom the corresponding private key belongs. Furthermore, you are assured that the data wasn't modified in transit.)

Symmetric encryption uses one key for both encryption and decryption. This means that the key must be known to both the encrypting and decrypting client and/or server (but not known to other parties). For this reason, symmetric encryption is best suited for scenarios in which the data is sent to the server in encrypted format for storage in encrypted format. The same client can later retrieve the data and decrypt it client-side with the same key.

One-way hash algorithms provide only one-way encryption—the data cannot be decrypted. This may seem like a strange idea. Why would you want to encrypt data if you can never decrypt it? The answer is that, in many cases, you would not. For example, you would not want to one-way encrypt text data such as an address or a name because chances are you'll want that data to be human-readable at some point. But one-way encryption is a great for things such as passwords. The data can be encrypted and stored on the server in encrypted format. When the user tries to log in, the password he enters is encrypted using the same algorithm, and the two encrypted passwords are compared. Since both values were encrypted using the same algorithm, the encrypted values match if the original, unencrypted values matched.

There are several third-party ActionScript libraries available for encrypting data. Most implement one-way encryption algorithms. So we'll look at those first.

Gerrit E.G. Hobbelt has ported a JavaScript MD5 encryption algorithm to ActionScript, and you can download the code from http://flashexperiments.insh-allah.com/md5.zip. Once you've downloaded the .zip file, extract the md5.as file using WinZip or another utility program. Save the md5.as file to your Flash Include directory. Once you extract the .as file, you can include it in any Flash movie and use the calcMD5( ) function to encrypt a string before sending it to the server.

When you use Hobbelt's MD5 library, you need to include the md5.as file in the scope where you want to invoke the calcMD5( ) function or provide a target path when invoking the function, as shown in the following example.

#include "md5.as"

send_btn.onRelease = function (  ) {

  // Encode the value that the user enters into a text field.
  var encodedPasswordStr = _root.calcMD5(_root.password_txt.text);

  var lv = new LoadVars(  );
  lv.password = encodedPasswordStr;
  lv.send("loginScript.cgi");
}

Branden Hall also has a port of the MD5 algorithm as well as the SHA1 algorithm. These libraries are available for download at http://www.waxpraxis.org/encryption/md5 and http://www.waxpraxis.org/encryption/sha1.

What if you need two-way encryption? The ActionCrypt project is an open source library that wraps well-known encryption library functions. So if you need additional encryption algorithms, consider ActionCrypt. At the time of this writing, ActionCrypt provides two-way encryption with the 56-bit blowfish algorithm. ActionCrypt also promises additional encryption algorithms, including other two-way as well as one-way and public key encryption. You can download ActionCrypt from http://actioncrypt.sourceforge.net.

11.19.4 See Also

For two good books on security, see the warning note earlier in this recipe. For more information on encryption, see http://governmentsecurity.org/articles/AnOverviewofCryptography.php. Also see http://www.rsasecurity.com for information related to Internet security in general. See http://www.macromedia.com/devnet/mx/flash/whitepapers/security.pdf for more information regarding security in Flash. See http://flashexperiments.insh-allah.com/#MD5 for information on Hobbelt's MD5 port. See http://www.waxpraxis.org/encryption/md5 and http://www.waxpraxis.org/encryption/sha1 for information on Branden Hall's MD5 and SHA1 ports. See http://actioncrypt.sourceforge.net for more information regarding the ActionCrypt project. Also refer to Recipe 8.6.