Silverlight, Flash, PDF and other Online Form Techniques

[Target Audience: Developers and System Administrators]

There seems to be growing interest for an online form service allowing customers to collect input from users and send it back as structured information to organizations, while preserving confidentiality including input, transmission, archive, access, and auditing functions.

The ability to enable customers to style online forms, for different server scenarios including absence of server-SSL input protection, should also be part of the available customer-design process. Further, the online form service should allow customers to use web forms, email forms, SMS forms, storage file forms, and any other communication process.

ZSentry is currently beta-testing such a Secure Online Form service that meets these considerations.

This work has led us to think more deeply about the pros and cons of Silverlight, Flash, PDF and other methods used to provide online form functions, as well as security and usability, which are the motivations for this posting and feedback.

In many cases of interest, the online form service must assure full HIPAA compliance. Safe Harbor compliance (even without HIPAA) is also coming to the foreground given the high profile and costs of recent breaches such as with Epsilon and Sony.

From the security viewpoint, and contrary to ZSentry for Google Apps (where both the need for HIPAA and Safe Harbor compliance can be satisfied by ZSentry), online forms as enabled by Google Docs cannot at this time be used by ZSentry as a basis for such secure service. The recent security breaches caused by phishing attacks against Google Apps and Gmail further highlight the concerns of storing plaintext information in online services such as Google Docs.

Our usability starting point is that online form functions are "critical" and, thus, in principle should be usable without asking the user to download or do anything else.

Usability is also necessary to ensure security, as we mention elsewhere (Usability is a system's #1 Security Property). In short, a secure online form service that is secure but not usable will not be used and, therefore, will actually fail to be secure. If security is too difficult or annoying, users may give up on it altogether.

Therefore, while it is OK for an information or help document to be available in PDF (with all the PDF requirements/problems to be met and solved at the user side), users can either view the PDF using any quick view software/service (including Google) or just move on to something else. Not so with an online form that needs to be entered.

We also see that many users are just that -- users -- and have no admin privilege in their devices. Increasingly, devices are locked (also by manufacturers -- see iPad vs Flash) for installation.

These concerns go against Silverlight. It could be better to use Flash (more widely available) but still many users would be left out as new Flash versions come out quite frequently and many users cannot update or do not like to bothered by yet another update. Silverlight also suffers from frequent updates.

How about JavaScript? It is commonly available. However, even JavaScript should only be used to provide added usability, while the online form itself should be functional without JavaScript. This is important not just because some devices have problems with JavaScript; some networks and services also block JavaScript.

In comparison, even though Silverlight or Flash based online forms may look more usable for corporate intranets and other special subsets of users, for public Internet users they are actually not as usable as HTML/CSS with optional JavaScript.

ADA and accessibility requirements also point to HTML/CSS with optional JavaScript.

In conclusion:

1. Knowing the target-user comes first, as it defines how the message needs to be delivered. Silverlight, Flash, PDF forms, and other non-HTML solutions can be used well in an intranet (internal services in a hospital, for example) where the organization can control the server, the network, the filters, all the clients, and what is installed and updated at any moment in those clients. Lacking that inclusive control, it is bound to fail in the public Internet for the same reasons.
2. From the user's viewpoint, HTML/CSS with optional JavaScript should be the best practice for online forms using the public Internet, as providing the needed functions while not standing in the way of using the online form -- which is the user's goal.
3. The ZSentry API for secure online forms is designed so that it can be used with any desired method, including HTML/CSS with optional JavaScript, Silverlight, Flash, PDF forms, and other interfaces. It is up to the developer to make the best use of it.

Comments are welcome. ZSentry for secure online forms is currently in beta test. Please submit a Support Ticket if you are interested in participating now or when the service is launched.

Cheers,
Ed Gerck

NMA ZSentry API -- Frequent Questions

[Target Audience: Developers and System Administrators]

The NMA ZSentry API is a secure software service that works in your environment. You can use the API both in a server as well as in a client context. There is no plugin or installation. With the ZSentry API you can readily connect, send, and store information securely, for example as a secure email, enabling secure communications in desktop, cloud, and mobile platforms, anywhere.

What is the NMA ZSentry API?
An SMTPS (SMTP over SSL, also called implicit SSL) service. You use the ZSentry API to connect your system to the ZSentry engine using TCP port 465 for encryption and decryption directly or through a message service or application. The resulting secure emails are encrypted per message and can be sent using ZSentry's own SMTP server, without requiring SSL, or can use another resource as a mail relay with or without SSL.

Why port 465?
With port 465 there is no ZSentry data exchange without SSL, including the ZSentry Usercode and Password data. Contrary to the submission port 587 with STARTTLS where the connection changes from non-SSL into SSL, port 465 has SSL-at-connect required. We prefer port 465 because every connection is encrypted from the start, preventing problems such as the SSL bridge attack (a well-known problem also for web browsers).

What server-side applications and servers are compatible?
The ZSentry API complies with IETF standards. ZSentry tested the API using servers with the dovecot/postfix Debian implementation and other Linux flavors. Customers have tested the API with a variety of Linux and Windows technology, including System.Net.Mail, CDOSYS (Collaborative Data Objects, Cdosys.dll), VB6, PHP, Java, and Sybase PowerBuilder.

Do users need to use ZSentry App (the web interface)?
No, not necessarily. The ZSentry API sends secure email that can be read and decrypted using the ZSentry App as well as leading Mail clients without any plug-in. This means that with the ZSentry API there is no web browser security and usability limitation for users, and users do not need to use the ZSentry App for reading, sending and saving secure messages. However, the ZSentry App can be used in a webmail environment.

How about Google Apps and Gmail?
Web mail services including Google Apps and Gmail can be set up to send HIPAA-compliant secure email using the ZSentry API directly, as a cloud Mail client with Single-Sign-On. This can be done by users, without an add-on or installation. Reading and saving secure email can also be done through Google Apps and Gmail,
using ZSentry App in the webmail environment or a Mail client.

How are Mail clients used?
Mail clients can be set up to send, read, and save HIPAA-compliant secure email using the ZSentry API directly, with Single-Sign-On. The user only sees the Mail client GUI for sending, reading and saving messages. This can be setup by users, without a plug-in or installation. A web browser is still used on the client side, but it is used transparently as a middleware and not as a GUI.

What clients are compatible?
The ZSentry API complies with IETF standards. Compatible clients include any major web browser, Outlook, Outlook Express, Windows Mail, Apple Mail, Entourage, Thunderbird, iPhone, Android, and iPad, on Windows XP, Vista, Windows 7, Linux, Mac OS X and iOS.

What applications can be used at the client side?
Clients can use several applications including webmail, email, IM, SMS, and file storage services.

Can I debug the SSL/SMTP flow?
Yes. This is a typical SSL/SMTP trace enabled by the API and which you can also capture in normal use to log delivery evidence for your service:
--------------
SMTP -> FROM SERVER:220 mail.example.com ESMTP Postfix
SMTP -> FROM SERVER: 250-mail.example.com 250-PIPELINING 250-SIZE 20480000 250-VRFY 250-ETRN 250-
AUTH PLAIN LOGIN 250-AUTH=PLAIN LOGIN 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN
SMTP -> FROM SERVER:250 2.1.0 Ok
SMTP -> FROM SERVER:250 2.1.5 Ok
SMTP -> FROM SERVER:354 End data with .
SMTP -> FROM SERVER:250 2.0.0 Ok: queued as E519A5801F4
-------------------------

More Information:
http://zsentry.com/zapi.htm

How about password security?

Password security may look like yet another oxymoron, as two intrinsically contradictory terms. If it is a password, how can it be secure?

Indeed, there are many and valid security arguments not to use passwords. You can find a summary in the paper Take Five In Internet Security where, in a five-minute appraisal, we present and discuss a typical dialogue with someone claiming that they have a secure server while using username/password authentication.

However, not all passwords are created equal. ZSentry, for example, uses two-factor, strong authentication without passwords -- even though, for familiarity, the second-factor is called ZSentry Password.

This is important for usability, as passwords are easy to use.

The security difference is that ZSentry does not store your Usercode or Password, not even encrypted. This technology, called ZSentry Sans-Target, solves the vulnerability problems of common passwords, including dictionary attacks and password files, as described in the study Take Five In Internet Security.

The ZSentry technology eliminates common online targets such as username/password lists, names, email addresses, plain text user data, meta-data, and even the encryption/decryption keys themselves, while adding two-factor mutual authentication, adaptive security, and password-hardening.

The critical point is that ZSentry Sans-Target provides the best defense possible against data theft -- the best defense against data theft is to not have the data in the first place.

Another important point is that ZSentry is not as dependent on password quality for security, as conventional systems are. With ZSentry technology, passwords are paired with an unpredictable ZSentry Usercode, and both are not at risk anywhere.

Nonetheless, it is recommended that ZSentry passwords should include at least one control or punctuation character. All of the characters !@#$%^&*()_-+=[]|\;:"?/,.< >`~' and space can be used in ZSentry passwords (space cannot be used at the beginning or end of a password).

For advanced password use, for maximum protection, you can use ANSI codes from #32 to #255 (keyboard ALT-number, no space at the start or end of a password). This simple strategy enables more than 132 bits of entropy with just 13 ZSentry Password characters (and the Usercode).

The conventional difficulty for using ANSI codes in passwords is solved by the ZSentry function Password Peek (during signup and login). You can easily see and verify what you typed before you submit, even for ANSI CODES such as ALT-0159 for Ÿ (Latin Capital Letter Y With Diaeresis).

With ZSentry, you can now use passwords as securely as you want.