Hacker News Reader

Comment by random5634 | Hacker News Reader

Having dealt with this at some scale.

Simplicity is everything. Skip the encryption - seriously. Or do what Microsoft does and send the keys somewhere you can absolutely get them (bitkeeper can be forced to backup into AD).

You want good access control and fantastic ability to recover. Your transfer will be over a secure link.

I did the client side encryption. I'm not convinced it's worth it or I have secrets so important that I need to worry about someone at AWS reading my S3 bucket (which has its own encryption).

View on HN

> Simplicity is everything. Skip the encryption - seriously.

I think it's reasonable to assume that anything we upload "to the internet" will stay there forever and there is a chance it'll become public at some moment in the future. Anyone can become a subject of scrutinity by legal or state actors, or high value target for blackmailers. If it happens it'll be in the worst moment and will incur major costs.

Encrypting data at rest, including backups can easily become a regulatory item. Of course there is a risk that you will lose your keys, so don't and check your back-ups integrity and your ability to restore frequently so that when the time comes you will have it down to a routine.

The alternative is that one day you find that your precious backups have taken a stroll through the countryside and end up on pastebin or something worse depending on the contents. Backups are typically much less secure than the servers they are copies of, hence the good practice of encrypting them.

If your backups do not contain data that would embarrass you or someone else if it should get lost then you probably shouldn't encrypt on the off chance that you will lose access to the keys. Lots of scientific data would fall under that description (but not all, for instance, studies could easily contain PII or sensitive info).

Exactly this: people don't realize that encryption involves considering risk of losing your data (lost keys) against risk of someone seeing your data (no encryption).

Most cheap storage services available to people for offsite backup in the global west are subject to military surveillance, making the latter risk probability approach 1 if you visit certain websites or search for certain terms.

If you are that concerned about encryption keys, just print them and store in some place off-site. Make as many copies as you wish.

But don't send data in bulk into the internet without encryption. If you are not reviewing what is there before you send, then you may be sending anything.

Also, don't trust a service that will send your keys to some place you don't control.

I'm pretty much in agreement, for the most part. Which is why I didn't put encryption as a priority on my backup tool for quite a while.

Two things that you'd want encryption on

1) for compliance (dealing with customer data, patient medical records etc).

2) Lots of secrets in your browser data directory (logged in session IDs, cookie values, site data).

For home stuff, I go for simplicity and idiot-proofness. Run everything in VMs, and backup the disk image. I don’t even trust myself with vhdx snapshots. Copying the vhdx between two nvme drives first to reduce the VM down time, then to NAS.

I agree, I think with access controls the encryption is not always worth it. I am going to add am optional way to bupstash to skip encryption for this reason.

In the EU with GDPR it is nearly impossible to skip encryption.

Access control would be needed to be very stringent double so if you don't control the hardware.

If you lose that data bc not encrypting it it can cost you millions (trade-off if you lose the keys your company light be toast)

Reply on news.ycombinator.com