November 6, 2016

LastPass now mostly free for personal use

In case you didn't notice, as of last week LastPass is essentially free for personal use. A password manager is great way to improve your online security, because it allows you to use a unique, long, random password for every account.

LastPass announced a change to their pricing plan last week that make the vast majority of their non-enterprise features available to the Free tier. If you're not currently using a password manager, or if you're mixing your personal account into your enterprise account (if you have one through your company), this should interest you.  More info on their tiers at the bottom of: https://www.lastpass.com/

Some cool features of LastPass:
  • You can link your personal account to your enterprise account.  You can then access all your personal account logins/notes from your enterprise account, but your personal information stays inaccessible to enterprise admins.  More info: https://enterprise.lastpass.com/getting-started/link-personal-account/
  • If your partner/spouse/best friend/etc. gets a free account, you can set up selective sharing of logins/notes, and folders of logins/notes, between you and your partner.
  • You can set up Emergency Access between your account and your partner's account.  If something happens to you, your partner can request access to your account, and after a configurable delay of X days, they will get that access.  At any time during those X days you can reject the request.  More info: https://helpdesk.lastpass.com/emergency-access/

If you're wary of trusting your account credentials and other personal information to the cloud, know the LastPass is a "zero knowledge" service, meaning that all your secrets are encrypted on your computers/devices before they get sent to the LastPass servers, and the encryption keys used are never sent to the servers.  This applies to their sharing and Emergency Access features too.  More info: https://lastpass.com/enterprise/security/

October 23, 2016

A baseline set of software and services for a home or professional Windows computer

This is a first installment on a post I've been writing (on and off, with lots of distractions) for the last month or two.  I started walking a friend through a list of security concerns and recommendations for their Windows computer, but soon found the subject complex enough that I needed to write it all down.  Later, as I started to document it all, I realized that others would benefit from it too.  Then it ballooned into a much larger task than I could have imagined, so it's still not ready.

So here is the Coles Notes version.  I'll finish the full write-up as soon as I find the time.

Area
Setting, Software, or Service
Router
WPA2 Personal/PSK, AES


Computer
TPM, ideally
Windows OS
Windows 10 Pro or
Windows 10 Home
Regular updates
Full disk encryption
BitLocker -- ideally using TPM-and-PIN mode
or
Device Encryption


Firewall
Windows Defender
Antivirus
AVG Free
or
Avast Free
Antimalware
VoodooShield Free
Browser privacy - Chrome
HTTPS Everywhere
uBlock Origin
Internet usage monitoring
GlassWire
VPN
TunnelBear


Password manager
LastPass Premium
Authenticator for 2FA
Authy


Container encryption
VeraCrypt -- needed if your computer drive isn't encrypted
Drive free space wiping
CCleaner -- needed if your computer drive isn't encrypted


Cloud sync/storage - zero knowledge
Sync.com
or
Boxcryptor 2.0
Cloud sync/storage - regular
Dropbox, OneDrive, Google Drive, Apple iCloud, etc.,


Cloud backup
CrashPlan
Local backup
CrashPlan
or
SyncBackFree --  ideally to a drive encrypted with BitLocker To Go
Image backup
Windows system image backup


Drive cleanup
CCleaner
Update monitoring
Secunia PSI


Credentials monitoring
haveibeenpwned.com


Mobile security
Device encryption
Regular updates
Mobile local storage
Documents by Readdle

. o O o .

September 6, 2016

Automated Code Inspection Tools for C Code

I recently had to draw up a list of C code automated inspection tools for a client.  It took me several hours to find and distill good reviews on the web so I thought I'd share it here for what's worth.  If I wind up using (or trying to use) any of the tools on the client's code base, I'll report my experience here.

This is a list of tools that, based on seven reviews I found, look like good candidates to run.  Since C has been around forever, some of the reviews are from as far back as 2009 and 2010.


Tool
# Recom­mendations
Type
Web page / Notes
OPEN SOURCE



Flawfinder
5
Open source
Last update: 2014
Cppcheck
4
Open source
Last update: 2016
RATS
3
Open source
Last update: 2013
YASCA
3
Open source & Commercial
Last update: 2014
COMMERCIAL



Coverity (Synopsys)
3
Commercial
Klocwork
2
Commercial
Fortify Static Code Analyzer (SCA) (HP)
1
Commercial

. o O o . 

September 3, 2016

The chicken and egg of password security


It's easy to argue that, because Last.fm isn't a sensitive service, it's OK for users to pick insecure passwords.  But I suspect that this is a slippery slope: as a user uses more and more insecure passwords without anything bad happening, they become desensitized to security concerns (if they were ever sensitized in the first place) and move on to using such passwords on more and more sensitive services.  Eventually reality will bite them.

How can you blame uses for doing this?  They just want to use the services they like.  They aren't security experts and they don't understand the threat model or how dangerous the connected world is.

You can blame service providers that allow stupidly insecure passwords like "123456", "password", the name of the service, etc.  Microsoft disallows such passwords but the vast majority of service providers don't.

Now, a tougher question: can you blame service providers that allow passwords that are shorter than, say, 12 characters and not complex and random?  Anything less than that, as a bare minimum, is probably not secure enough against offline attacks.

But here's the chicken and egg:
  1. Since the vast majority of users don't use password managers, a service provider that required secure-enough passwords would likely be out of business in short order.
  2. If service providers don't require secure-enough passwords, why would users use them?  You can easily imagine the usability (and security issues) that such passwords would create for users that don't use a password manager.
  3. If users aren't forced to use secure-enough passwords, and given that they don't understand the need for unique passwords across all their services, why would they go to the trouble (they imagine) of using a password manager?  (That "trouble", by the way, is well worth it.)
As someone fascinated by security architecture -- and especially by how much better it could be -- this is the kind of problem I love to ponder.  My post Open Kimono Security presented one way to address this chicken-and-egg situation, but we might need something a bit more mainstream.

---

If you want to get a feel for password cracking time as a function of password length and complexity, try this:


Don't use a real password; instead compose a fake password that is similar to the password you want to test.  So if your password is "ChriSlove45" (don't laugh), use something like "CaseYbest92".  But then you probably already know that you shouldn't be using such passwords anyway: your passwords should all be long random (and unique) strings.

BTW, I suspect that the "MacBook Pro" times shown for that kind of password ("ChriSlove45", etc.) are wrong and should really be much shorter.

. o O o .

August 30, 2016

A good telescope for starting out in astronomy

Astronomy is an amazing hobby that can take you as far as you want to go, in all sorts of observing and scientific directions.  For people looking to get into astronomy, here is some great advice for buying a beginner telescope.  This is from Douglas George, Ottawa-based expert amateur astronomer and comet hunter, who was responding to a question from another friend of mine:
In the "few hundred dollar" range, telescopes vary from utter crap to quite decent.  Don't buy a telescope from anything but a specialty shop.  Don't buy anything that lists some huge magnification (800X !!!).  High magnification in a small aperture instrument is an attempt to violate the laws of physics.  Tip: physics win.  You'll only see a blur.

If you want a good telescope in that price range, it's going to be no-frills. That doesn't mean it won't be a very capable telescope; you just need to put your money into decent optics and a good solid mounting.  This means a "Dobsonian" style instrument.

Here is an example of a good beginner telescope:

Orion SkyQuest XT6 Classic Dobsonian Telescope | Orion Telescopes

This has a 6" diameter mirror, which means the telescope is actually quite capable.  At the same time, it is not too bulky.  The mount is a very stable design, being a simple up/down, left/right affair.  If you can't point the telescope at an object, you can't see it.  This is a far better design than a spindly tripod.

Another important factor is you need a good aiming device.  Telescopes have tunnel vision, so you need some help.  Many beginner telescopes are sold with really poor quality finder scopes, which are beyond difficult to use.  The telescope linked above has an "EZ Finder".  Another similar device is a "Telrad".  These devices don't magnify, they simply point - and are not just very easy to use, they are quite accurate.

If you can't afford a 6" telescope, go for a slightly smaller unit - say 4.5" diameter.  Don't go smaller than that.
. o O o . 

August 3, 2016

The Wrong Way to Embed Links in Emails

It's no surprise that many users are generally confused about computer and Internet security. One of the reasons is that the companies they deal with don't care enough about security and therefore force users to do insecure things in order to use their services. A very good and very vexing example of this is links embedded in emails that businesses send to their customers.

Over the weekend I had to use BCAA's roadside assistance service. The next day I received the following email asking me to give them feedback on the service. The service was excellent and I'd like to tell them that, but take a careful look at the email:

From: BCAA Customer Experience Team [mailto:BCAAQualityAssurance@hermes.responsetek.com]
Sent: Tuesday, August 2, 2016 06:21
To: Garland Sharratt
Subject: BCAA Roadside Assistance Quality Assurance Survey

Dear GARLAND SHARRATT,

Your participation and feedback are critical to helping us understand your needs. Please take a moment to share your experience during the interaction you recently had with BCAA’s Roadside Assistance and suggest ways in which we can serve you better.

The web link below will connect you to a short survey that will take less than five minutes to complete.

Click here to begin the survey.

On behalf of the BCAA Customer Experience team, thank you for taking the time to share your insight with us and helping us improve.


If you do not wish to participate in future email surveys from us, please
click here to unsubscribe.

Note: If you have difficulty with the survey link above, please copy the URL shown below and Paste it into your browser:
https://ecol-na3.responsetek.com/collection/Greeting.aspx?iguid=DETAILSMASKED&LangID=1&rt=1
Notice anything fishy?  All the links in the email -- one for the survey and another to unsubscribe -- (and even the sending email address) have a domain name of responsetek.com, not bcaa.com as I would expect for an email coming from BCAA. How do I know that this isn't a fishing email trying to get me to install malware hosted at responstek.com? I have to do some research before I can be somewhat sure that the links are safe.

I'm just using BCAA as an example; these days most of the business emails I get have third-party domain links -- especially for the link I most want to click, the unsubscribe link. No wonder users click links they shouldn't and get malware delivered to them.

What's the solution? There's nothing wrong with businesses using third-party services but they should do the tiny amount of work required to hide this from users. BCAA should have created one or two URLs on the bcaa.com website that redirect to the responsetek.com website, and embedded those bcaa.com URLs in the email.

So a link embedded in the email looking something like
https://bcaa.com/redirect/dest=responsetek.com&iguid=DETAILSMASKED&LangID=1&rt=1
would send my browser to
https://ecol-na3.responsetek.com/collection/Greeting.aspx?iguid=DETAILSMASKED&LangID=1&rt=1

With all links in the email going to bcaa.com, a domain I trust, I wouldn't have to worry (nearly as much) that it's a fishing email. If all businesses did this with their emails it would be a big step toward reducing user confusion around security and, eventually, reducing incidents of malware attacks.

. o O o .

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.