Impact Infrastructure is very concerned with safeguarding your information when using AutoCASE. We follow generally accepted industry standards to protect the information submitted to us, both during transmission and once we receive it, and where applicable use the highest appropriate level of encryption or security available to us at the time. No method of transmission over the Internet, or method of electronic storage, is entirely secure, however. Therefore, we cannot guarantee its absolute security.
For those interested in our security protocols the following outlines the approach we have taken to user, transmission, and data security.
User Security
All user authentication is validated using one way encryption algorithms. What this means is your password is stored in a format that is completely distinguished from its plain text format. This makes your password unreadable to any individual and cannot be decrypted from its encrypted state to reveal its true plain text format. When users attempt to log in to AutoCASE their typed password is encrypted and compared against the encrypted state of the password set on registration. If the encryption results match the user is considered to have authenticated and successfully logged in to their account. AutoCASE uses different encryption parameters that are unique to each user so no two users passwords are encrypted the same way. In the event that a users account becomes compromised for any reason, it will not affect any other users account.
There is no way to prevent all attacks but we use techniques to make it difficult and time consuming1. We do this by increasing the default rounds of encryption that is recommended and also by randomizing each encryption2.
Transmission (Internet) Security
Transmission of data between server and client (the user) is sent over SSL (Secure Socket Layers). This protocol utilize two way encryption methods to encrypt and decrypt data at the browser and server endpoints such that data intercepted between those two points remains private and unreadable. AutoCASE only uses authorized certificate providers to ensure the highest standard of reliable encryption.
For the connection to the server, where a web browser needs to establish a secure connection over the Internet to access AutoCASE, we use servers that all require RSA encryption3 for access. RSA creates a public key based on the two large prime numbers that are secret. Multiplying two large primes is easy. Factoring the result, that is determining the two original prime numbers from the product, is effectively infeasible4.
AutoCASE goes even a step further by having the user generate their own RSA signature on their personal computer which is also saved on the server. This means even if someone knows the password to get on the server they won’t be able to access AutoCASE and the data stored by the user because the password wasn’t encrypted with the RSA encryption from the user’s computer.
Server Security
Access to the server is authorized with 64-bit RSA encrypted keys. These keys are generated and signed off by a user’s personal computer. Therefore only users who have been authorized to connect to the server and whose accepted keys are referenced on the server can access it. With this approach even if a user’s password or key is stolen, a connection not established by the individual’s personal computer will be rejected. Only the AutoCASE lead developers have access to computers that contain the aforementioned keys.
Data Security
For the data itself, the data are stored in the database that has scheduled backups.
In addition, we store the data backups on secured cloud storage services. Only Impact Infrastructure has access to the storage repositories used by AutoCASE. We always securely upload/download data to these repositories via SSL endpoints using the HTTPS protocol. For extra security we use either Server Side Encryption (SSE) or Server Side Encryption with Customer-Provide Keys (SSE-C) to further encrypt AutoCASE’s data.
AutoCASE does have a point of entry for outside users to access the data through the AutoCASE API (Application Programming Interface). Access through the API is controlled with token-based authentication, so only users that have been granted an access token from Impact Infrastructure can access the API. The API is not a direct link to the database, Impact Infrastructure controls the flow of information with its API functions. AutoCASE’s API is designed so that only limited data can be accessed and only controlled data is accepted from third party applications through the API.
1 For example randomization and successive rounds of encryption make it impossible to use certain cracking techniques that attempt to speed up attacks such as lookup, reverse lookup, and rainbow tables. These approaches work if each password is hashed the same way. If two users have the same password, they’ll have the same password hashes.
2 Randomizing the process means that when the same password is hashed twice, the hashes are not the same. We do this by adding a random string, called a salt, to the password before hashing. A new random string is generated and added to the password encryption each time a new user creates an account or a user changes their password. Also, to make it impossible for an attacker to create a lookup table for every possible salt, the salt is used is long.
3 The Rivest-Shamir-Adleman cryptosystem for public-key encryption.
4 “As of 2010, the largest factored RSA number was 768 bits long … Its factorization, by a state-of-the-art distributed implementation, took around fifteen hundred CPU years (two years of real time, on many hundreds of computers). This means that, at this date, no larger RSA key has been factored.” RSA (cryptosystem) From Wikipedia, the free encyclopedia http://en.wikipedia.org/wiki/RSA_%28cryptosystem%29. AutoCASE’s RSA keys are 2048 bits long making it infeasible to decode the AutoCASE connection.
0 Comments