oh no!
https://blog.mega.io/mega-security-update/
"Customers who have logged into their MEGA account at least 512 times (the more, the higher the exposure). Note that resuming an existing session does not count as a login. While all MEGA client products use permanent sessions by default, some third-party clients such as Rclone do not, so their users may be exposed."
This is one of the many reasons when a service says it is encrypted, (e.g. OneDrive Private Vault), I still use rclone's crypt!
Reading the blog:
For MEGA, as an end-to-end-encrypted (E2EE) storage provider with high standards, this is a serious matter, whereas for providers not using E2EE, such as Dropbox, OneDrive or Google Drive, a compromised back-end or man-in-the-middle attack is of course always fatal. Their privacy guarantees to users are entirely based on policy .
Makes sense but man does it feel slimy to have both a "we screwed up" and "we're better than the competitor" in the same article. Though, to be fair, they are right.
1 Like
I've never trusted any storage provider 'built-in' security, MEGA most of all as they are really sneaky on a lot of their practices.
And rclone's encryption is so well implemented, so transparent and efficient there's really no reason not to use it all the time.
Remember, folks: "there is no cloud, it's just someone else's computer"! And anyone trusting 'someone else's computer' with your data's secrecy is just fooling themselves.
hi, at work, for compliance reasons, cannot use rclone crypt remote.
instead, many s3 backends, support client side encryption called SSE-C.
that crypts only the contents of the the file, not the filename, not the dirname.
1 Like
Hi @asdffdsa ,
I understand and sympathize. One of the reasons I started my own company, back in the days, was not having to deal with the 'compliance' and similar people who make rules without having to make the stuff they are ruling about actually work.
Yep, I've seen many clients (for S3 and otherwise) implementing client-side encryption. Wasn't aware of SSE-C particularly, but IMHO not encrypting file names is a serious deficiency and reason enough for not using it for the large majority of my data.
As a side note, why 'compliance' greenlights SSE-C which is both weak and specific to S3, and forbids RClone's native encryption which works with any provider and is therefore both more proven and more portable (in the sense you could move the encrypted data to a different provider and keep using rclone to access it, changing just a couple of lines on its configuration) is perfectly on par to me with the rest of their pathos... 
i have been that way since the mid 1980's.
rclone has never been proven, audited , etc.
and if you go thru the changelog, there have been a bunch of bugs and
https://rclone.org/changelog/#v1-53-3-2020-11-19
and
https://github.com/rclone/rclone/issues/4783
i do not mean to be harsh, but with rclone crypt, some guy wrote some software, that currently works.
the entire rclone project could end tomorrow, as many open source projects do.
i cannot entrust client's backups to that.
in the end, good to have choices.
@asdffdsa, thanks for the thoughtful reply.
You mean, publicly audited. That's okay, I never said it had.
What I meant by "proven" is being widely used and therefore having a lot of eyes on it. In fact, enough eyes to detect and fix the (very minor IMHO) bug you mentioned below.
Those two are actually about the same bug, right?
And I think this is a very minor bug: it only affects the optional automatic password generation (which should never be used by anyone worried about security anyway), and is therefore far from being anywhere near the core of RClone's cryptography.
No harshness taken, and not meaning any either: we're just two guys talking shop, and the fact we have different opinions don't mean any of us has to be wrong -- we are probably both right, each in our own domain of application.
I do trust my own, and my client's, backups to RClone's encryption, as IMO:
-
It's always "some guy [or gal] wrote some software": neither corporations nor any other entity ever write any software, only people do. And having worked both in and for some pretty large entities (think multinational corporations on the Fortune-100), I'm absolutely not impressed with any of the software "they" have produced. I'm much more comfortable with quality software written by a single gifted person like our own @ncw or by very small teams of competent, independent people (like Unix, vim and GCC, to mention only three).
-
Corporations and other entities change course and abandon "their" software and their clients all the time. I don't think it's your case, but IME most guys that recommend "big corporation" software/products aren't really worried about any continuity but their own ("no one was ever fired for buying IBM/MS/Digital/") and/or, in extreme cases, are even getting kickbacks from them.
-
Should @ncw (Divine forbids!) ever tire or become unable of maintaining/evolving RClone, it's opensource software, and very well writen, maintainable, legible software at that. -- and its large community almost guarantees that someone (or someones) would step up and keep doing his great work. In the absolute worst case, it guarantees I myself could do it, even if only for me or my clients' specific use cases.
We're in full agreement here. If there were no choices, there would be no horse races 
Cheers, and peace,
--
Durval.
Not only that, but you only need rclone to work long enough to migrate. I view data archive, backup, and storage as at least minimally active. I keep up with the goings on so that I know if I have to move.
One thing I never understood about this is that, even if it is client side, you are relying on an often closed-source tool, right? I guess client side still isn't too bad, but the server side encryption I see offered on some S3 products really confounds me. You are relying on the provider to (a) do what they say they are doing and (b) do it correctly.
--- as i understand it and from scanning the rclone source code.
aws has an open source go module on github, and that is what rclone uses.
so the file is crypted using the aws source code, not rclone crypt
I think he's saying if you wrap any remote around the crypt remote, you are using the rclone crypt function.
If you use the s3 remote with server side encrypt, you are not using the crypt remote and 'trusting' the provider at that point rather than the crypt remote which you can review the code.
it is confusing
agreed, what i posted about is sse-c which is based on trusted open source code.
and that source code is doing the encryption.