July 29, 2016

Open Kimono Security

You've probably heard of "security by obscurity", the (old) idea that one should try to prevent the technical details of IT and security solutions from escaping into the wild, to avoid giving the bad guys ammunition. But it's usually much better to assume that all the technical details will leak out and to make sure that your solutions will be secure nonetheless.

Still, when a password file gets stolen and published, it's a big deal, and various parties go to work trying to crack passwords out of it. (Password files don't store passwords in plaintext: they are salted and hashed, so it takes effort to extract them.) Because most people don't choose long, random (and therefore complex), and unique passwords, a large percentage of passwords can be brute-forced.

Is there a better way?

Here is my idea: what if all Internet-connected services went a step further and published everything about their services? Except for their keys, of course.

I haven't thought this through in detail, but the obvious place to start is password files. Every website would make its password file freely available for download.

This probably sounds crazy. Ok, it definitely sounds crazy. But what would happen if we tried it?

It would certainly be a crazy thing to do with the current state of passwords. A password like "Julie94#" would likely take less time to crack than it would take to download the password file. So the amazingly insecure password practices of today would have to go out the window, and fast.

It would force services to (a) force users to choose much more secure passwords and (b) salt and hash those passwords much more securely.

There would be advantages. For instance, when a user of Service A tries to create an account with password X, or to change their password to X, Service A could check the password files of other services B, C, D, etc., (Google, Microsoft, Apple, etc.) to ensure the user isn't presenting a password they currently have on any of those other services.

Since users would be forced to use long, random, and unique passwords for all (or most) of their services, they would need to use a password manager -- which is something they should be doing today anyway.

There is (at least) one disadvantage: because password files need to store plaintext user ids (so that the salt value can be looked up), and because user ids are often email addresses, users whose services started publishing their password files would be immediately hit with spam. But since this would force email providers to improve spam filtering, maybe this is really an advantage in disguise.

Clearly some careful analysis is needed, but I wonder whether my idea would be basically viable if all passwords had to be long (say, at least 64 characters), and complex, and if salts and hashes were long (say, 512 bits long)?

. o O o .

If this post made you curious to know more about password files and how they are protected, check out this great page: Salted Password Hashing - Doing it Right

July 20, 2016

Are your cloud storage and backup services secure enough?

Should you be worried about the security of cloud services such as Internet storage and Internet backup? That's like asking whether you should be worried about cars: it's the kind of question that can't be answered without asking more questions and digging a lot deeper.

Consumers and businesses often choose a product or service based mainly on its obvious functionality -- does it solve a problem for you, is it easy to use, does it look nice, etc. -- and think little about its security and privacy features. This is as true for cloud services as it is for the more traditional computer and mobile software.

So just how secure are those cloud services you're using or looking at? It's often hard to know in any absolute sense, because it depends on so many considerations, many of which you don't control and can perceive only indirectly if at all. As a very simple example, you might choose a unique, high quality password for a cloud service (good) but the service -- unknown and unknowably to you -- might store it in plaintext (bad). In security little is black and white; mostly it's shades of grey.

In this post I'll describe how to understand and evaluate some key security features of cloud services, and then I'll present an analysis of several Internet storage and backup services. In future posts I'll look at other important cloud services -- including password managers and two-factor authentication -- as well as other security issues.

(TL;DR? Skip down to Seven Cloud Services.)

Threat model

In evaluating any system, including a cloud service, it's useful to start with a threat model. At a simple level, this can be a list of assets at risk, vulnerabilities (weaknesses) in the assets, and threats to the assets.

Here assets at risk include account credentials such as userid and password, encryption keys (either independent of or derived from the account credentials), and the data you want to store or back up.

Vulnerabilities can be divided into three main types: those in your computer or device itself, those in the cloud service client running on your computer or device, and those in the cloud service server somewhere on the Internet. Some examples of these vulnerabilities are malware, software bugs, misconfiguration of software and systems, and implementation weaknesses. Implementation weaknesses that are especially worrisome on the server side include passwords stored as plaintext or encrypted (instead of being salted and hashed), and data stored unencrypted. Even storing data encrypted on a server is a vulnerability when the encryption keys are stored there too.

Threats to consider include malevolent insiders in the cloud service provider; a compromise (hack) of the cloud server, the cloud client, or your computer or device; and, if you're paranoid enough, government subpoenas or secrets orders (a la USA PATRIOT Act or similar) to access server data.

That's a lot to think and worry about. Most of these risks are not under your control, but that doesn't mean you can't do anything about them. As much as possible you want to reduce the number of things that can go wrong by reducing your vulnerabilities.

You can make sure your computer and mobile devices are secure -- that's under your control. You want your service provider's service to be secure too -- but that's not really under you control, after you've chosen the service. 

Zero Knowledge

Still, there is a way to insulate yourself to a fair degree from security issues in the service, by choosing services that are colloquially called "zero knowledge".

"Zero knowledge" in the context of a cloud service means that the service provider has no access to your data. In practice this is accomplished by having all encryption and decryption done locally, that is, on your computers and devices, using an encryption key that only you (or your computers and devices) create and hold. The server never sees your unencrypted data and never sees your encryption key.

By contrast, while most non-zero knowledge services do encrypt your data when it's stored on their server, it's the server that creates and holds the encryption key; so they have full access to your data.

(By the way, the SSL/TLS encryption that occurs between your computer or device and the server is unrelated to the above. It's only for transmission over the Internet and has nothing to do how your data is stored on the server.)

The bottom line is that a zero knowledge service, properly implemented, provides you with a fair amount of protection from a number of vulnerabilities. 

In depth

So how do you know whether a particular cloud service is zero knowledge and whether it's properly implemented? Unless you're a security researcher or hacker (the good kind), the only way, imperfect as it is, is to review the service's website in detail, ask questions of the service provider if necessary, and read what others have written, then decide how much you trust each piece of information and form your judgement.

Be aware that when you're evaluating a service, you need to carefully consider all access methods -- computer application, mobile app, web client, etc. -- and all the use cases that the service supports -- such as writing or backup, reading or restore, and sharing with other users, in all its many forms. And of course you also have to consider all the combinations of access methods and use cases.

Even with due diligence in your analysis, if you decide that a particular service is zero knowledge, it's good to keep in mind that you could be wrong or partly wrong:
  • the service provider could incorrectly describe its functionality and security features, accidentally or intentionally; 
  • it could change the service functionality or security features at any time and not publicize this; 
  • the service might have architectural or implementation issues that weaken their security; or 
  • you might have missed an access method or use case in your analysis. 

All you can really do is factor the knowledge that your analysis is never perfect into your decisions. 

Mostly zero knowledge

If you start analyzing cloud services and their security, you'll find that there is also a halfway-point between non-zero knowledge and zero knowledge, what one might call "transiently non-zero knowledge", or maybe "mostly zero knowledge". Such a service works just like a zero knowledge service except that, for one or more access methods and/or use cases, your encryption key (which lives in your client software) is sent to the server, kept in memory (i.e., not written to disk or otherwise stored on the server), used for some operation, and then purged from memory afterward.

One reason for doing this is to move encryption or decryption from the client to the server, where it can be done much faster. This "transiently non-zero knowledge" is more secure than non-zero knowledge but less than zero knowledge as it does introduce additional vulnerabilities, namely possible interception of your encryption key while it's in the server.

Did I mention that little in security is black and white? As with all things, you need to make a risk assessment, balancing the value of the service with the security risks. 

Data sensitivity

Another thing you'll notice when you look around is that only a small fraction of cloud services are zero knowledge. Luckily you don't need to use zero knowledge services for everything.

The key is to classify your data by sensitivity, that is, how much damage would be done if that data were to escape into the wild. You can use these three levels of classification:
  • Low sensitivity: no or minimal damage; for example, most (but not all) of your photos; 
  • Medium sensitivity: some damage but not heavy; for instance, what you'd consider your "personal files"; 
  • High sensitivity: heavy damage: say, a file containing all your accounts with userids and passwords, or a backup of all the files on your computer. 

With this analysis done, you can decide how much each class of data needs to be protected. High sensitivity data should be allocated to a zero knowledge service and low sensitivity data can use a non-zero knowledge service, while medium sensitivity data could go to a zero knowledge service or to what you decide is a secure- and trustworthy-enough non-zero knowledge service. 

Storage and backup

You now know that cloud services can be very secure and you know how to analyze their level of security with respect to the zero knowledge dimension. But why would you want to use cloud services in the first place?

I usually recommend to people and businesses that they store their key data in the cloud and back up all their data to the cloud. Why? By doing so, they get the convenience of being able to access their data from anywhere and they get the resilience that comes from no adverse event being able to destroy their data.

For example, if you have all the latest details of a current project carefully stored in your computer but can't get at them when away from home, that's not convenient; and if you have your computer data backed up to a local hard drive that gets stolen, burnt, or crushed at the same time as your computer, that's not resilient. By removing dependence on physical location and physical hardware, cloud storage and cloud backup make life and business so much more convenient and resilient. 

Seven cloud services

Now that I've covered some key security principles for cloud services, I'll now turn to an analysis of a few well-known and less-well-known cloud services for storage and backup.

The table below presents four non-zero knowledge storage services (A), a pure encryption (no storage) service in two versions (B), a zero knowledge storage service (C), and one mostly zero knowledge backup service (D). All the services are freemium model, except for the backup service (D) which is paid. For the six freemium services the table presents the free service level of each.

Boxcryptor (B) needs a bit of explanation. It's not a cloud storage service, rather it's a service (with no server) that runs on top of a cloud storage service, performing encryption and decryption on the fly using an encryption key that you control. In so doing it turns any non-zero knowledge cloud storage service into a zero knowledge service. As shown in the table there are two versions, the legacy Classic and the new 2.0.

The first three columns under the "Zero Knowledge?" heading show whether the service is zero knowledge for that particular access type, while the last three columns under "Zero Knowledge?" show whether the service is zero knowledge for each type of sharing. The cell values you'll see in these columns are:
  • --- = not applicable: that access type is not supported 
  • no = not zero knowledge 
  • YES = zero knowledge 

File sharing is a very important and popular use case for cloud storage services, so I've looked at the different types of sharing offered by the services I analyzed. The three types of sharing shown in the table are:
  • U-U = registered user to registered user, e.g., a registered user of the service changing one of their file's permissions to let another registered user access it 
  • U-NU = registered user to non-user, e.g., a download link that a registered user of the service provides (e.g., emails) to someone who doesn't have an account on the service 
  • NU-U = non-user to registered user, e.g., an upload link that a registered user of the service provides (e.g., emails) to someone who doesn't have an account on the service 

The U-U sharing type is the most secure, because it requires the recipient to authenticate themself to the service; whereas with U-NU and NU-U, anyone who has the link can use it. And if you send the link by email, U-NU and NU-U are even less secure.


Type
Service
Storage limit
Zero Knowledge?
Computer application
Mobile app
Web client
Sharing
U-U
Sharing
U-NU
Sharing
NU-U
Internet storage, regular security (A)
Dropbox
2 GB
no
no
no
no
no
no
Microsoft OneDrive
5 GB
no
no
no
no
no
---
Google Drive
15 GB
no
no
no
no
no
---
Apple iCloud Drive
5 GB
no
no
no
---
---
---
Internet storage encryption layer (B)
Boxcryptor 2.0 (n1)
n/a
YES
YES
---
YES
YES
(n6)
---
Boxcryptor Classic (n2)
n/a
YES
YES
---
---
---
---
Internet storage, high security (C)
Sync.com
5 GB
YES
YES
YES
YES
YES
(n3)
YES
(n3)
Internet backup (D)
CrashPlan
Unlimited
YES
(n4)
YES
(n4)
no+
(n5)
---
---
---

Table notes:
  • n1 = Boxcryptor 2.0 free service is limited to 2 devices per account. Supports Dropbox, Google Drive, Microsoft OneDrive, and Apple iCloud Drive. 
  • n2 = Boxcryptor Classic is the legacy product and Boxcryptor wants users to move to Boxcryptor 2.0; so you probably shouldn't start using it if you aren't already. Boxcryptor Classic free service supports at least 3 devices per account. Supports Dropbox, Google Drive, Box, and Microsoft OneDrive. 
  • n3 = Zero knowledge only if Enhanced Privacy mode is used. When Enhanced Privacy mode is used, the user must send the link "out of band" (i.e., not through Sync.com) to the non-registered user 
  • n4 = Zero knowledge only if "custom key" mode is used; not zero knowledge if the other modes ("standard encryption" or "archive key password") are used.
  • n5 = This is the "transiently non-zero knowledge" type mentioned earlier. The use case is "web restore" of backup data, which is a feature of the service you don't need to use: you can restore from the computer client or mobile client instead.
  • n6 = Boxcryptor combined with sister service Whisply.

Which service

From the table you can see that the "big four" cloud storage services are not zero knowledge, but that they become so when combined with Boxcryptor; and that Sync.com's storage service and CrashPlan's backup service are both natively zero knowledge, with a small proviso for the latter. (Boxcryptor, Sync.com, and CrashPlan are services that I like, but there are many other available with similar features.)

Given this, here are some examples of how and where to store or back up your data:
  • to store low sensitivity files: any of the non-zero knowledge cloud storage services in (A); 
  • to store high sensitivity files: you want a zero knowledge service, so either Sync.com (C), or a Boxcryptor service (B) combined with any service in (A); and 
  • to back up your files (high sensitivity): again, you want a zero knowledge service, so CrashPlan (D). 

For backup, if you don't have too much data, another option, not shown in the table, is to use computer-based file backup software (such as SyncBack) and store the backup data, through Boxcryptor, into one of the cloud storage services in (A).

Looking at the table a bit more deeply, you might be surprised to see that Sync.com is zero knowledge not only for the storage of a user's files but also for sharing of files with other users and even with non-users. If you're curious about how it's is possible to do all this in a zero knowledge way, read up a bit on public key cryptography and then consult Sync.com's website. Sync.com is hosted in Canada, which gives it an advantage with respect to some privacy issues.

By the way, in addition to cloud backup you should also have a local backup of your files on an external hard drive. Make sure that the drive is encrypted or that the files stored on it are encrypted, otherwise you're creating a new set of vulnerabilities. Unless your computer itself isn't encrypted, in which case you're already quite vulnerable. But that's for another post. 

. o O o .

Notes 2017-01-21: According to this post -- PSA: LastPass Does Not Encrypt Everything In Your Vault -- the URLs for the Sites in your LastPass vault are an exception to the otherwise zero knowledge-ness of LastPass.

Notes 2016-10-23: CrashPlan, too, is not willing to provide any details about the security of their iOS app.  Here is what I suggest for now to improve your security: do use the Boxcryptor 2.0, Sync.com, and CrashPlan iOS apps when you need to access your cloud files, but always completely sign out of the apps when you're done, i.e., completely disconnect the apps from the cloud account(s).  Boxcryptor 2.0 and CrashPlan both have a sign out button, but with Sync.com you'll currently have to uninstall the app to sign out; you can then install it again right away so that it's ready for when you need it the next time.

Notes 2016-10-16: Boxcryptor is not willing to provide any details about the security of their Boxcryptor 2.0 iOS app, other than to say that it doesn’t use iOS Data Protection.  So I suggest that you not use their iOS app in any way, until something changes.

Notes 2016-09-07: There is an important security caveat to Sync.com if you install it on your mobile device.  Once you connect the Sync.com client on your mobile device to your Sync.com account, your Sync.com mobile client is protected only by a 4-digit PIN (if you enable the PIN feature), there is no auto-logout after, say, 10 incorrect attempts, and there is no manual logout.  Until Sync.com fixes this -- I've asked them to -- I think it's best to either not use Sync.com for sensitive files, not use the iOS client, or have the client installed but not connected to the account.

Notes 2016-08-26: (1) There is a great review of Sync.com at https://suchanek.name/texts/reviews/tresorit.html#sync.  (2) Sync.com is more than just syncing: it's also a backup service, with file history and restoration of deleted files.

Update 2016-07-25: Added YES for Sharing U-NU for Boxcryptor 2.0.

Sign-up links:
If you decide to sign up for Sync.com, use this referral link and we'll both get an extra 1 GB of storage for free: https://www.sync.com/?_sync_refer=65069b0. And if you sign up for Boxcryptor using this referral link, I'll get an additional 1/5 of a sync device and you'll get a warm feeling: https://www.boxcryptor.com/app/referral/?code=wpEsk5fIxIpxI1Oa.