3 ms·

What nobody seems to be pointing out here: Ben's account contains exactly what you want to hand off to Someone Else's Storage™. It's just GPG-encrypted backups

What nobody seems to be pointing out here: Ben's account contains exactly what you want to hand off to Someone Else's Storage™. It's just GPG-encrypted backups. Look. Here's what the innerText says, with the `\n`s interpreted: Upload Download New Folder Delete Snapshot Selected: 0 Files: 0 bytes Name Size Uploaded dbbackup_06_23_2017.sql.gpg 10.2 GB 06/23/2017 22:24 dbbackup_06_24_2017.sql.gpg 10.2 GB 06/24/2017 22:24 dbbackup_07_02_2017.sql.gpg 10.2 GB 07/02/2017 22:25 dbbackup_07_03_2017.sql.gpg 10.2 GB 07/03/2017 22:26 dbbackup_07_04_2017.sql.gpg 10.2 GB 07/04/2017 22:25 dbbackup_07_05_2017.sql.gpg 10.2 GB 07/05/2017 22:25 key.asc 3.9 KB 02/24/2016 22:01 Once again, noise. Perfect. (For the curious: I couldn't be bothered to install https://projectnaptha.com/ https://projectnaptha.com/ (probably would've worked), I just resized a terminal to the same column width and blindly retyped the text into a shell printf statement.)

cm2187 6y ago
And also when you upload something to blackblaze, you are already handing out your files to a third party. There shouldn't be anything sensitive that you didn't encrypt client side.
- nvarsj 6y ago
  Exactly... all my b2 files are client side encrypted. It would be a really bad idea not to do that.
  - dbmnt 6y ago
    Except... are the filenames encrypted? For many, if not most, filenames are plaintext. Backblaze's default "SSE-B2" encryption leaves the filenames in plaintext. GPG encryption typically leaves the filenames in plaintext. There's still information people consider private and didn't expect to be shared with Facebook.
    - nvarsj 6y ago
      That's server side encryption. My point is if you store sensitive files on a remote server not under your complete control, you should always use client side encryption. Good client side encryption will not leak filenames/directories either. A lot of them do, unfortunately.
durnygbur 6y ago
It's still revealing two levels of filename extesions - type of encryption and file format. Full filename should be simply random alphanumeric ASCII string without any filename extensions, although this requires to manage and store a map of keys and filenames.
- exikyut 6y ago
  Hmm. A possible counterargument: filenames like dRDDrOu44Rr84vzXJv2mcr2eg83zDN43mzUQ0N4 xzrI5Ha7HJ7gK3T8XfkGqNtvc7LMQPFjSwi 5Wb1XhHeR6LxQUC8XfyX9kvvooYvrp9fnxQVvH9C jgAzjd56DGWFjcae0gw9A1LZxJEqVHW7UmkZ XrpNNAZalPp6D4mnpLvVcCE3uWkDQzthSQwK9 (as generated by for example `head -c 30 /dev/urandom | base64 | tr -d '+/='`) are extremely suspicious-looking. To me that screams "obsessively paranoid". I reckon that if I were in law enforcement, the fact that there is absolutely nothing I can infer from these filenames, combined with the obvious complexity associated with correctly maintaining something like this, would actually make me that much more interested in decrypting this information simply to take a look at it and rule it out. Which is exactly why this would be a scenario in which I _would_ want to "reuse someone else's password", if you will, and I'd theoretically go digging for common archival file patterns, and use the most common I came across.
  - quchen 6y ago
    On-disk filenames should be hashes, much like .git contains lots of hash-named files. My Restic backup folders don’t show much beyond that they are Resic backup folders (if even?).
  - DVk6dqsfyx5i3ii 6y ago
    > as generated by for example `head -c 30 /dev/urandom | base64 | tr -d '+/='` If you want exactly 30 alphanumeric characters you could do `tr -dc '[:alnum:]' < /dev/urandom | head -c 30`
  - thebean11 6y ago
    Rclone crypt backends generate filenames like this, and are really not very difficult to set up.
aasasd 6y ago
There are programs that automatically encrypt files before storing them. A particularly enticing one is Cryptomator, which acts as a ‘disk’ keeping files on various providers and thus syncs between devices—however its Android app isn't open-source so I never actually tried it.

cm2187 6y ago

And also when you upload something to blackblaze, you are already handing out your files to a third party. There shouldn't be anything sensitive that you didn't encrypt client side.

nvarsj 6y ago
Exactly... all my b2 files are client side encrypted. It would be a really bad idea not to do that.
- dbmnt 6y ago
  Except... are the filenames encrypted? For many, if not most, filenames are plaintext. Backblaze's default "SSE-B2" encryption leaves the filenames in plaintext. GPG encryption typically leaves the filenames in plaintext. There's still information people consider private and didn't expect to be shared with Facebook.
  - nvarsj 6y ago
    That's server side encryption. My point is if you store sensitive files on a remote server not under your complete control, you should always use client side encryption. Good client side encryption will not leak filenames/directories either. A lot of them do, unfortunately.

durnygbur 6y ago

It's still revealing two levels of filename extesions - type of encryption and file format. Full filename should be simply random alphanumeric ASCII string without any filename extensions, although this requires to manage and store a map of keys and filenames.

exikyut 6y ago
Hmm. A possible counterargument: filenames like dRDDrOu44Rr84vzXJv2mcr2eg83zDN43mzUQ0N4 xzrI5Ha7HJ7gK3T8XfkGqNtvc7LMQPFjSwi 5Wb1XhHeR6LxQUC8XfyX9kvvooYvrp9fnxQVvH9C jgAzjd56DGWFjcae0gw9A1LZxJEqVHW7UmkZ XrpNNAZalPp6D4mnpLvVcCE3uWkDQzthSQwK9 (as generated by for example `head -c 30 /dev/urandom | base64 | tr -d '+/='`) are extremely suspicious-looking. To me that screams "obsessively paranoid". I reckon that if I were in law enforcement, the fact that there is absolutely nothing I can infer from these filenames, combined with the obvious complexity associated with correctly maintaining something like this, would actually make me that much more interested in decrypting this information simply to take a look at it and rule it out. Which is exactly why this would be a scenario in which I _would_ want to "reuse someone else's password", if you will, and I'd theoretically go digging for common archival file patterns, and use the most common I came across.
- quchen 6y ago
  On-disk filenames should be hashes, much like .git contains lots of hash-named files. My Restic backup folders don’t show much beyond that they are Resic backup folders (if even?).
- DVk6dqsfyx5i3ii 6y ago
  > as generated by for example `head -c 30 /dev/urandom | base64 | tr -d '+/='` If you want exactly 30 alphanumeric characters you could do `tr -dc '[:alnum:]' < /dev/urandom | head -c 30`
- thebean11 6y ago
  Rclone crypt backends generate filenames like this, and are really not very difficult to set up.

aasasd 6y ago

There are programs that automatically encrypt files before storing them. A particularly enticing one is Cryptomator, which acts as a ‘disk’ keeping files on various providers and thus syncs between devices—however its Android app isn't open-source so I never actually tried it.