Is Random Password Rclone safe?

Hi. I have set one my password on crypt configuration for password1 and on password2 I choose a random rclone key. Is it safe? I should have added a personal salt to it for more security?

More is usually better in general.

I personally rather use my own password as I can store that somewhere and keep it that way so I wouldn't use a random one. I don't think the random is any different from using your own unless you are picking a really weak password.

I used random for password1 and password2, 250 characters in length each. I also commit all configuration files for each of my servers into private github repos so I don't lose stuff, including my rclone.conf. As far as if random is better than selecting your own, all it's really going to come down to for your encryption to be safe is just to make sure you're not 'weak' passwords. Don't use dictionary words, don't use programmatic incremental passwords (abcdefghijkl, 1234567890, a1b2c3d4e5f6. I have complete faith in my randomly generated rclone passwords.

100% true. In the IT security world, I can tell you that passwords for DoD SIPR classified systems are a minimum of 16 characters, including 2 uppercase, 2 lowercase, 2 numbers, 2 special characters [they also specify no keyboard patterns or repeating characters, but for your encryption you don't have to consider that as seriously as they do].

If you meet that condition you literally have a military-grade password. In my employer's FEDRAMP cloud environment (the portion of AWS where weirdos like the CIA put non-classified systems) the same password complexity is enforced minus the keyboard pattern and repeating character bits.

The math behind these complexity requirements, and I don't know who did the math, but it was to state that that these levels of complexity should take a single computer (single hacker) 1 trillion years to crack. A supercomputer would even be hard-pressed to crack that before the end of Earth. A quantum supercomputer could probably do it within our lifetime, but unless you're of the equivalent worldwide recognition level of Steve Jobs/Bill Gates, you're not going to be the target of such a dedication of hardware.

Security through obscurity comes into play too. There are tons of Plex users with encrypted vaults in Google Drive. There are also a lot of medical companies that use GSuite and rclone or similar means to store encrypted database chunks in the cloud (the other largest location of these being AWS Glacier). You're an encrypted needle in an encrypted haystack in an encrypted field.

Sources: USAF SIPR admin (separated), AWS Certified Solutions Architect, 15 years experience network security.

But, what if there is a breach/hack in github's security?

It's a risk. But if you managed break into GitHub and steal everything, there is far more interesting stuff than my tiny repos and it would be enough time to regenerate the credentials and tokens. Even with my encryption passwords, I doubt anyone would be able to break into Drive well enough to mess with my library.

Remember, lots of companies (Fortune 500) have IP in private repos in GitHub. My employer included. Between the time of the breach, the announcement of the breach, and the time it would take for them to be interested in my Plex library, I'd have already had the time to change all my tokens and they still wouldn't have access - even with the encryption passwords.

At that point, the only people who could do anything with it would be Google themselves. I'd simply migrate the data to a new drive with new encryption passwords and remount. No one would ever get anywhere with that information unless I was the initial target.

I seriously doubt anyone would go through all that effort and risk 20-to-life in prison to get at my video files. It would require a massive coordinated attack.

Sign yourself up for things like haveibeenpwned and similar services and you can safely store data privately in the cloud without too much worry. It basically would boil down to changing your password(s) whenever it happens.

Also remember, they don't put all the eggs in one database. That's why it's very rare for a breach to be "complete", and the breached data is usually limited to certain subset of user information, but not total access to the systems. If you ever see a breach that is "complete" like that, it means the company wasn't practicing any security practices, let alone best practices.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.