Encryption involves the “scrambling” or encoding of data so that it can only be read via the use of an encryption “key”. From our perspective, there are two flavors of encryption—encryption of the data streams and “encryption at rest”.
Encryption of the data stream prevents “snoopers” from stealing data as it travels through the Internet. This type of encryption is fairly easy to implement. Our formal position on this type of encryption reads as follows:
“TOPAZ uses industry standard cryptographic libraries that are part of the Microsoft Windows operating system and the Microsoft development tools which we use for development.
We recommend our clients use Secure Socket (SSL) transport between the client and server, achieved via industry standard SSL security certificates issued by commercial certificate authorities and generally created with 2048-bit or higher encryption. If TOPAZ provides hosting, these recommendations are used.”
This is a fancy way of saying, “use https”.
Encryption at rest is a little more complicated to implement, as it affects the actual application. This would encrypt the data that sits quietly in the database, and you could only then read that data if it was decrypted within the application. Given that Elements includes things like TOPAZ Reporter and a Web Services based API, this would be very expensive to implement.
It would also make things like troubleshooting and debugging significantly more complicated.
For this reason (and because of the low risk), Elements only encrypts user passwords at rest. This only impacts those customers who use local authentication, which we’ll touch on in more detail later