This is one the main problems with our approach to information security: we disproportionately prioritize protection of our data against theft/law enforcement/rogue bigtech employee over losing it in any other way. That's why many have lost their thousands of bitcoins, because they secured their keys so hard against theft that their data has eventually become unrecoverable despite that there'd be no thief, officer, rogue employee perhaps for a decade.
People who advise not using cloud for backups, suggesting cold wallets and whatnot as blanket advice have been harmful by giving way to the orders of magnitude more likely but the catastrophic scenario that is simple data loss.
Some people bash on Microsoft for backing up your drive encryption keys in the cloud for example, but it's the most common failure mode they're trying to address. No thief would access your cloud, no state-level actor would be deterred by lack of cloud (see: xkcd wrench), no rogue employee could make use of your hard drive encryption keys.
Get your priorities based on your threat model, and get your threat model right, people.
Having encrypted data I wouldn't say is disproportionately prioritising protection over losing it in another way. The person simply forget what was a long password, something that most security conscious people would have figured out by storing it in a password vault.
However I do agree that "going alone" with security can make us the victim of our own fragility. I can see this happening in the new blockchain world of decentralisation. If I lose my Bitcoin wallet or lose the password, who can I speak with to validate my identity? Nobody. Currently, I can go to the Bank and validate myself with other forms of ID to access my account, but with Bitcoin it's all on me. Imagine losing your entire life savings because you forgot your password or access to your email account.
This is where centralising certain things works for the overwhelming majority of the population. That's not to say that those systems work perfectly, but they are vetted and have laws and regulations to protect us.
Yeah, especially here on HN you hear about people not thinking about threat models. And yes, Denial-of-service by forgetting the password or having it inaccessible is a threat model
That's why I just laugh at the people who think putting everything in a password manager is the best way. It is good, but you need to understand your cases/threats and risks
Sometimes writing it in a piece of paper is the best solution
I skimmed back the article after reading this comment, and I'm still not really sure how this follows. Of course you should always make redundant backups with parameters suitable for however much assurances you want to have that you will not lose data. However, I dunno if there's any particular evidence to suggest that data loss is the main concern here. I mean, I have a backup strategy for most of my data, but I'd choose to spend at least some time trying to avoid the need to restore a backup first. Plus, I don't think there's good evidence to suggest that data theft is not a huge concern for people. Inside this article is a link back to a previous article about a NAS vulnerability that allows anyone to change the password of the NAS and enable SSH without authentication. I dunno if it's the same vulnerability I remember from some years ago, but there was a pretty real situation where many WD MyCloud users had their data stolen and NASes wiped. (I actually had a thankfully-mostly-decommissioned MyCloud at the time and it did in fact get pwned.)
Backup strategies and good security posture is a "why not both" type of situation. It's harder than it should be, but sometimes that's the cost of doing business.
This is something that is difficult when trying to encourage less technical users to be secure. Once you convince them to do things right, they've heard of circumstances like this and are petrified of accidentally losing something.
In a commercial environment there are ways and means¹ but getting a non-technical user to securely and safely manage access credentials is can be a time consuming education process. Especially after the first time someone comes to you to hack their stuff because they've lost their keys & they never did do that backup thing you good then about³ and you tell them it simply isn't possible.
Even those of us with experience in the field sometimes make mistakes that we can't revert, so people without that experience can be forgiven to an extent for trading security for what they think is safety (but is really just convenience).
Solutions, that don't involve someone being an unpaid 24/7 infrastructure support tech, on a postcard please!
----
[1] if procedures are properly followed² code is in source control and documents are in equivalent storage, the most you should be able to lose is today's work
This is why Microsoft Windows is so adamant about having you create an online account as your means of sign-in on modern Windows versions. FDE requires it on some versions.
Telling users that forgot their password that not only do they need to reinstall Windows, but that every single document, photo, video of their grandkids, etc. is now lost forever is untenable. At the same time, FDE is important for security, so what is a reasonable compromise? Allow some form of online recovery options (secured by the full expertise of MS security folks) by linking an account to serve as your 'IT-guy managed AD in the cloud'
>trying to encourage less technical users to be secure
The threat of “losing the keys to all the data” is considerably larger than the threat of having your computer and data stolen for an average home user. It can’t just be a matter of more secure is better… you have to have an idea of what you’re trying to prevent.
All of our shit has been lost in one leak or another so at this point it seems like it barely matters.
I’ve just been using the same password for my FDE forever, and only for that purpose. I figure it keeps my data safe from theft, but probably not from the feds or my wife if she wanted in there, because they could either compel me to unlock it or have access to put some keyboard sniffer in my boot loader.
The password is quite a few random characters that I memorized when I first used FDE decades ago and I’ve never had reason to change it.
I rotate my other passwords often and never use this one anywhere other than a boot loader; I don’t even type it into a running operating system to save it.
I’ll never forget it, but if I had to change it then I think I would go with the “battery horse stapler” method of pass phrase.
With encryption, you always have to balance the risk of having others access to your data to that of you also potentially losing access to your data forever. In other words, is it more important that no one, not even myself, can gain access, or is it more important that I can always have access, even if that means everyone else could? I suspect for much of the data people have, they'll categorise it as the latter instead of the former.
If you're looking for something in between, then deliberately weaker encryption might be what you want, although almost no one seems to mention that much.
If you're worried about something like what happens to your FDE volumes after you die, and you don't want to write down a passphrase somewhere, you could do something like pick three extremely trustworthy family members, swear them to secrecy, and give each of them one third of the passphrase.
A couple years ago someone lent me an Android phone to do some development on (it had some hardware feature I didn't already have on my testing phones). I don't use my main google account on dev phones so I promptly set it up with whatever google generated for me and I forgot both the email and the password.
6 months later I have to give it back, and I hit reset to defaults. Surprise! The phone asks me for the previous account and password!
Back then the feature was new, which is why I didn't know about it. Fortunately, being new it was also buggy.
I managed to complete the factory reset through a complicated process that involved going through accessibility options, replacing some system apk with an older version (via adb i think) and some other trickery that I forget. But the stuff was mostly in the open on youtube.
This being strictly a dev phone, I had no data to lose. It only had on it apps I was working on and thus I had the full source code in git. Still, it was good to not create more ewaste.
I've been paying attention on newer test phones though. I don't think that security feature is as easy to bypass these days...
I've been meaning to do this with my LUKS headers and zpool headers since reading about fast bcrypts via GPU a few weeks ago; I suspect that my FDE passwords are not powerful enough, but I'd like to put them to the test.
just add aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa in front of it so bruteforcing will not try anything with enough characters to even get close to your password (/s)
BitLocker does this much better. With TPM+PIN mode, the TPM will only decrypt the volume master key if all the right hashes are in the platform configuration registers for the BIOS, option ROMs, MBR, filesystem headers and bootloader, and the user-specified PIN is correct. Or if you enter the 128-bit recovery key.
The BSDs and Linux have a lot of catching up to do.
>The BSDs and Linux have a lot of catching up to do.
Stop putting every BSD in the same basket.
Also, this is Unix, you can put encrypted slices/partitions with ease. You can omit to encrypt the system files and encrypt the data and config partitions.
sedatk|3 years ago
People who advise not using cloud for backups, suggesting cold wallets and whatnot as blanket advice have been harmful by giving way to the orders of magnitude more likely but the catastrophic scenario that is simple data loss.
Some people bash on Microsoft for backing up your drive encryption keys in the cloud for example, but it's the most common failure mode they're trying to address. No thief would access your cloud, no state-level actor would be deterred by lack of cloud (see: xkcd wrench), no rogue employee could make use of your hard drive encryption keys.
Get your priorities based on your threat model, and get your threat model right, people.
NoPicklez|3 years ago
However I do agree that "going alone" with security can make us the victim of our own fragility. I can see this happening in the new blockchain world of decentralisation. If I lose my Bitcoin wallet or lose the password, who can I speak with to validate my identity? Nobody. Currently, I can go to the Bank and validate myself with other forms of ID to access my account, but with Bitcoin it's all on me. Imagine losing your entire life savings because you forgot your password or access to your email account.
This is where centralising certain things works for the overwhelming majority of the population. That's not to say that those systems work perfectly, but they are vetted and have laws and regulations to protect us.
raverbashing|3 years ago
Yeah, especially here on HN you hear about people not thinking about threat models. And yes, Denial-of-service by forgetting the password or having it inaccessible is a threat model
That's why I just laugh at the people who think putting everything in a password manager is the best way. It is good, but you need to understand your cases/threats and risks
Sometimes writing it in a piece of paper is the best solution
jchw|3 years ago
Backup strategies and good security posture is a "why not both" type of situation. It's harder than it should be, but sometimes that's the cost of doing business.
dspillett|3 years ago
In a commercial environment there are ways and means¹ but getting a non-technical user to securely and safely manage access credentials is can be a time consuming education process. Especially after the first time someone comes to you to hack their stuff because they've lost their keys & they never did do that backup thing you good then about³ and you tell them it simply isn't possible.
Even those of us with experience in the field sometimes make mistakes that we can't revert, so people without that experience can be forgiven to an extent for trading security for what they think is safety (but is really just convenience).
Solutions, that don't involve someone being an unpaid 24/7 infrastructure support tech, on a postcard please!
----
[1] if procedures are properly followed² code is in source control and documents are in equivalent storage, the most you should be able to lose is today's work
[2] yeah, I know…
[3] or that uses the same, now lost, credentials
briHass|3 years ago
Telling users that forgot their password that not only do they need to reinstall Windows, but that every single document, photo, video of their grandkids, etc. is now lost forever is untenable. At the same time, FDE is important for security, so what is a reasonable compromise? Allow some form of online recovery options (secured by the full expertise of MS security folks) by linking an account to serve as your 'IT-guy managed AD in the cloud'
colechristensen|3 years ago
The threat of “losing the keys to all the data” is considerably larger than the threat of having your computer and data stolen for an average home user. It can’t just be a matter of more secure is better… you have to have an idea of what you’re trying to prevent.
All of our shit has been lost in one leak or another so at this point it seems like it barely matters.
ipython|3 years ago
calvinmorrison|3 years ago
However, there are better options for users - how about Smartcards? You know, like yubikey / U2F before the web?
You can even use it with LUKS
klodolph|3 years ago
One step at a time!
1. Back up your data.
2. Test restoring your data.
3. Automate your backups.
4. Automate your test restores.
5. Now you are ready for full-disk encryption.
It is okay if you do not complete all steps. More steps is better. Do not skip ahead.
ok_dad|3 years ago
The password is quite a few random characters that I memorized when I first used FDE decades ago and I’ve never had reason to change it.
I rotate my other passwords often and never use this one anywhere other than a boot loader; I don’t even type it into a running operating system to save it.
I’ll never forget it, but if I had to change it then I think I would go with the “battery horse stapler” method of pass phrase.
heeen2|3 years ago
jsrcout|3 years ago
I used to think that, too. Narrator: He did forget it... Lesson learned. As always, YMMV.
2b3a51|3 years ago
https://en.wikipedia.org/wiki/Playfair_cipher
Not the full cypher but just reading out the letters in the grid in a different direction.
userbinator|3 years ago
If you're looking for something in between, then deliberately weaker encryption might be what you want, although almost no one seems to mention that much.
walrus01|3 years ago
nottorp|3 years ago
A couple years ago someone lent me an Android phone to do some development on (it had some hardware feature I didn't already have on my testing phones). I don't use my main google account on dev phones so I promptly set it up with whatever google generated for me and I forgot both the email and the password.
6 months later I have to give it back, and I hit reset to defaults. Surprise! The phone asks me for the previous account and password!
Back then the feature was new, which is why I didn't know about it. Fortunately, being new it was also buggy.
I managed to complete the factory reset through a complicated process that involved going through accessibility options, replacing some system apk with an older version (via adb i think) and some other trickery that I forget. But the stuff was mostly in the open on youtube.
This being strictly a dev phone, I had no data to lose. It only had on it apps I was working on and thus I had the full source code in git. Still, it was good to not create more ewaste.
I've been paying attention on newer test phones though. I don't think that security feature is as easy to bypass these days...
pvg|3 years ago
https://news.ycombinator.com/item?id=12431248
kstenerud|3 years ago
FDE doesn't protect against remote attacks, and anyone who would physically make off with my devices (a VERY unlikely event) is either:
* A thief who will turn around and sell them to someone who will erase them.
* A state actor who will get the data no matter what I do (and find it of no interest anyway).
GauntletWizard|3 years ago
ilyt|3 years ago
nutto|3 years ago
The BSDs and Linux have a lot of catching up to do.
anthk|3 years ago
Stop putting every BSD in the same basket.
Also, this is Unix, you can put encrypted slices/partitions with ease. You can omit to encrypt the system files and encrypt the data and config partitions.
But FDE avoids tampering.
orangepurple|3 years ago
cassepipe|3 years ago
bbatchelder|3 years ago
llui85|3 years ago
unknown|3 years ago
[deleted]