Cloud storage considerations

I was recently asked this question by a client:

If you were considering using a cloud solution for client data, which includes personally identifiable information, what would you require, at a minimum, for data security?

Great question. First off, how much personally identifiable information and what kind?

Worst acceptable case

I don't consider names and addresses and even phone numbers very important. I sync my contact list, calendar and tasks to a host which will accept some insecure protocols. So if someone was still using Windows XP and IE version 6, it could use a handshake that is no longer secure in order to be compatible with them. I am OK with this flaw, but I don't store more important information like passwords with them. Furthermore, SSL Labs gives them a B grade so they don't even consider this flaw horribly significant.

Best Practice: The gold standard.

For the highest level of security, what I require for client data, is everything is encrypted on your own computer in a state of the art fashion with gigantic random passphrases. It is uploaded to shockingly secure servers that get an A or A+ rating from SSL Labs. You hold the encryption keys so the people you are sending it to cannot access the data under any circumstance. This is critical. It is nearly impossible to be completely secure if they are holding the keys to get into your data.

The quality of the encryption on your computer meets these criteria. Note: I've written two good articles on password encryption here and here. These will give you more background and explanation. If you don't understand these criteria, read these two background articles.

The password is NOT stored, but rather a hash of the password. So, passwords can use any characters, and be essentially any length. They may put a 40 or 50 character limit, or even refuse to accept a few characters the programmer doesn't like because they can be confusing. People can mistake the small L for the numeral 1 for example, or spaces, which can be difficult to see if the password is printed, particularly trailing spaces! Further restrictions are almost always a sign of insecure procedures.
Detailed explanation of the hashing algorithm. If it is proprietary, run away. Top cryptographers have created solid algorithms. Programmers cannot do better. You cannot depend on secrecy. Depend on the math.
Individualized salting. They should explain how they salt the password. The salting should have variation from one person to another.
Iterations. They should do thousands of iterations of the hashing algorithm before storage. Hopefully the number is controlled by the user to some extent, forcing a hacker to attack each client individually, instead of breaking everything with the same attack. In other words, a hacking program could not be setup to run against every instance of the software, since each installation would have a different salt and a different number of iterations.

What if you don't hold the keys?

Once you violate the Trust No One (TNO) standard above, you need to balance three factors:

How useful is the program / System. For example, I don't think my doctor or hospital or insurance company secures my data properly. But, I'd rather they have it, than kill me by giving me the wrong medicine in an emergency.
The degree to which they meet some or most of the standards above.
Exactly what data is stored on the system. For example, I don't worry much about names and phone numbers or my appointment schedule. I worry totally, and require the gold standard above, for client passwords, access to client data backups and similar data.

If they hold the keys, then a corrupt or corrupted employee, or compromised system will compromise your data.

Compromise?

If some service adds a lot of value, but makes you a little nervous about their security standards, then perhaps you can pull some data out, and handle it locally, while still using the service for most of your data.

Local Encryption

If you encrypt your critical data locally, then you can backup or store that encrypted information on an insecure server (or local backup drive) and not be compromised. For example, Keepass can be used to store your passwords with a good passphrase and then that file could be stored on a less secure server because it is already encrypted.

Veracrypt seems to be the best successor to TrueCrypt and can be used to securely store files, spreadsheets, Quickbooks and so forth. A Veracrypt volume can be deeply encrypted to a gold standard above, and saved on your local computer. Then backed up to a cloud backup location which doesn't need to be highly secure because the volume is locked down securely before being uploaded.

Date: June 2016

This article is licensed under a Creative Commons Attribution-NoDerivs 3.0 Unported License.

Keeping clients' computers safe and profitable for over 30 years

Home Forms About Current Newsletter subscribe Search All Articles Browse by Category Security Internet Mobile Business Hardware Fun		Cloud storage considerations I was recently asked this question by a client: If you were considering using a cloud solution for client data, which includes personally identifiable information, what would you require, at a minimum, for data security? Great question. First off, how much personally identifiable information and what kind? Worst acceptable case I don't consider names and addresses and even phone numbers very important. I sync my contact list, calendar and tasks to a host which will accept some insecure protocols. So if someone was still using Windows XP and IE version 6, it could use a handshake that is no longer secure in order to be compatible with them. I am OK with this flaw, but I don't store more important information like passwords with them. Furthermore, SSL Labs gives them a B grade so they don't even consider this flaw horribly significant. Best Practice: The gold standard. For the highest level of security, what I require for client data, is everything is encrypted on your own computer in a state of the art fashion with gigantic random passphrases. It is uploaded to shockingly secure servers that get an A or A+ rating from SSL Labs. You hold the encryption keys so the people you are sending it to cannot access the data under any circumstance. This is critical. It is nearly impossible to be completely secure if they are holding the keys to get into your data. The quality of the encryption on your computer meets these criteria. Note: I've written two good articles on password encryption here and here. These will give you more background and explanation. If you don't understand these criteria, read these two background articles. The password is NOT stored, but rather a hash of the password. So, passwords can use any characters, and be essentially any length. They may put a 40 or 50 character limit, or even refuse to accept a few characters the programmer doesn't like because they can be confusing. People can mistake the small L for the numeral 1 for example, or spaces, which can be difficult to see if the password is printed, particularly trailing spaces! Further restrictions are almost always a sign of insecure procedures. Detailed explanation of the hashing algorithm. If it is proprietary, run away. Top cryptographers have created solid algorithms. Programmers cannot do better. You cannot depend on secrecy. Depend on the math. Individualized salting. They should explain how they salt the password. The salting should have variation from one person to another. Iterations. They should do thousands of iterations of the hashing algorithm before storage. Hopefully the number is controlled by the user to some extent, forcing a hacker to attack each client individually, instead of breaking everything with the same attack. In other words, a hacking program could not be setup to run against every instance of the software, since each installation would have a different salt and a different number of iterations. What if you don't hold the keys? Once you violate the Trust No One (TNO) standard above, you need to balance three factors: How useful is the program / System. For example, I don't think my doctor or hospital or insurance company secures my data properly. But, I'd rather they have it, than kill me by giving me the wrong medicine in an emergency. The degree to which they meet some or most of the standards above. Exactly what data is stored on the system. For example, I don't worry much about names and phone numbers or my appointment schedule. I worry totally, and require the gold standard above, for client passwords, access to client data backups and similar data. If they hold the keys, then a corrupt or corrupted employee, or compromised system will compromise your data. Compromise? If some service adds a lot of value, but makes you a little nervous about their security standards, then perhaps you can pull some data out, and handle it locally, while still using the service for most of your data. Local Encryption If you encrypt your critical data locally, then you can backup or store that encrypted information on an insecure server (or local backup drive) and not be compromised. For example, Keepass can be used to store your passwords with a good passphrase and then that file could be stored on a less secure server because it is already encrypted. Veracrypt seems to be the best successor to TrueCrypt and can be used to securely store files, spreadsheets, Quickbooks and so forth. A Veracrypt volume can be deeply encrypted to a gold standard above, and saved on your local computer. Then backed up to a cloud backup location which doesn't need to be highly secure because the volume is locked down securely before being uploaded. Date: June 2016 This article is licensed under a Creative Commons Attribution-NoDerivs 3.0 Unported License.
		I attempt to provide reliable information, but make no warranty as to the accuracy or safety of these articles. I disclaim all legal responsibility for what following these instructions may do. Follow my advice at your own risk