I've been following this pretty closely. In the early days of the internet, the fear was that eavesdroppers would read your messages. The cure was SSL, which encrypts your messages as they cross the net. MLO Cloud Synch uses SSL, so your data is safe as it crosses the net. For what it's worth, I haven't heard about any type of breach involving eavesdropping in a decade or two Once the data is received at MLO Cloud servers (which, the last I
knew a couple of years ago, were running on Amazon's AWS) it's
stored on Amazon's disk storage. It's not encrypted. There are
three main attack vectors for data like this. First one is no threat at all for MLO, it is to attack whatever web-based interface is available to allow users to directly access their cloud-stored data using a browser. This is no threat because MLO does not allow you to access your cloud-stored data by browser. A lot of users have requested that MLO implement web access - if this ever happens the risk of data breach goes way up. Second attack vector is to gain access to Amazon's disk storage. This could involve bribing an Amazon database administrator or hacking into any access (if there is such a thing) that Amazon database administrators use to access and service the database remotely. Two reasons not to feel threatened by this one: First, MLO's data is in MLO's own format which, as those recently trying to export their tasks have found, is no picnic. It's not unbreakable but it would be a lot of work for low return. Suppose you had your bank passwords in a task - the hacker would still have to figure out what person owns that task (I'm not sure MLO even knows). If you create a task that has your name, address, bank account number, date of birth and bank password all in the same note it might have value but I doubt many people have done this. Second reason not to fear this vector, lots of businesses keep encrypted data on AWS, there are loads of ready-to-use credit cards, billions of dollars of transactions flow through the system, if a hacker had DBA access why would they waste their time reading people's task lists. Unless you have written out a project plan to topple the government of some country or explode somebody's military your tasks are just not as valuable as the other stuff on AWS. Third attack vector is to bribe an MLO employee, get a court order forcing an MLO employee to comply or hack the interface that MLO staff use to access and maintain their data on AWS. This is the vector that I believe carries the highest risk. There are not many MLO employees which keeps the risk lower. Let's consider two ways that this could be done. Method 1: The data leaves your computer unencrypted but shielded by SSL. It arrives at AWS, gets encrypted and stored. When needed, the data is retrieved, decrypted and delivered or processed for synch. This is the method used by most apps that tell you their databases are encrypted. This also means that the vendor holds all the encryption keys. This kind of encryption is effective against the second attack vector, it prevents access to your data by anyone who is an Amazon DBA or who has hacked or bribed an Amazon DBA. But that was already a low risk. If the attack is coming from an MLO employee or someone who has hacked or bribed an MLO employee, they will just use MLO's copy of the encryption key to decrypt the data. The final bit, at-rest encryption method two, is end-to-end encryption. This is the ultimate method of securing this kind of data. The data is encrypted on your computer and then sent, encrypted, to the server and stored without ever being decrypted. When a synch occurs, the synch is done with data that's still encrypted. (Synch would need a few fields to be not encrypted: a user ID, a time of last change, and a record ID. the rest could be encrypted.) If updated records need to be sent out to your MLO on other devices, it is sent there still encrypted and does not get decrypted until it has arrived at your other device. Nobody but you sees the clear data. If someone gets a warrant and brings it to MLO and demands them to decrypt your data, their reply is "I dont have the key". This is where you get real security. It's also very unusual, deployed only in extreme circumstances, extremely expensive, and possibly illegal due to the risk of violating US laws designed to prevent enemies of the US from having this much security. Also, most cases that use end-to-end encryption involve a single device talking with a single server and then getting the data back again to the same device. For example, some iPhone cloud backups work this way. The only place the key exists is burned onto a custom, inaccessible chip in the iphone. MLO Cloud Synch would require that a task encrypted on your computer be decrypted on your phone. This means that we want the keys to be shared between all of your devices but not the server through which they contact each other. This is the kind of security challenge that the world's best spy agencies have been working on since World War II. I do not know whether they have solved it yet, but I am pretty sure that they are not sharing any solutions with MLO. SO, I would really like to see MLO do end-to-end encryption. I
think that any encryption other than end-to-end us a useless
marketing ploy - sounds good but does nothing to reduce real
risks. I understand that end-to-end encryption is not feasible
today, especially for a company outside of the US and especially
where key sharing is required. I hope MLO does not implement web
access until this is resolved, and I don't put any life-and-death
secrets into my tasks (I use my encrypted key manager for those.)
Hope this helps, I've tried not to be "bland". -Dwight On 8/28/2019 5:52 AM, Jon Lastname
wrote:
-- |
- [MLO] Is MLO Cloud sync still unenctrypted? Joel
- [MLO] Re: Is MLO Cloud sync still unenctrypted? Jon Lastname
- Re: [MLO] Re: Is MLO Cloud sync still unenctrypted? Dwight Arthur
- Re: [MLO] Is MLO Cloud sync still unenctrypted? Jeff Smith
- [MLO] Re: Is MLO Cloud sync still unenctrypted? Joel