So I lost my OpenBSD FDE password (2016)(words.filippo.io)
words.filippo.io
So I lost my OpenBSD FDE password (2016)
https://words.filippo.io/so-i-lost-my-openbsd-fde-password/
76 comments
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.
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.
> something that most security conscious people would have figured out by storing it in a password vault.
Whatever that is if not another system protected by long password you're likely to lose, or that might bitrot past the point of recovery.
Whatever that is if not another system protected by long password you're likely to lose, or that might bitrot past the point of recovery.
Any security-conscious person backs up their password manager.
Stored encrypted of course with a long password...
My response was in regard to the bitrot argument.
Backing up software isn't going to help against it bitrotting away.
Sure it does if you use redundant storage like cloud. Of course that also has downsides, but I find encrypted cloud backups a solid solution. I personally use pass + encrypted git backups with 3 yubikeys (1 primary, 2 backup, all of them using ECC ciphers for encryption and auth).
[deleted]
A lot of things get done asymptotically close to the True Scotsman singularity.
> "with our approach to information security"
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
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
Writing passwords on a sticky note on the bottom of your keyboard in an office is obviously a bad practice. A unique string password on a piece of paper in a drawer at home only you would normally have access to? Not clear. And obviously you can hide things in a house more thoroughly than that with the risk that you get too clever.
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.
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.
Yeah my comment's tangential to the article. The problem there is that there is an FDE password in the process of securing your data that you can't backup reliably (Filippo misspelled the password). This would have caused the loss of an entire RAID drive for anyone, not for Filippo in this case obviously. Such a basic UX problem causes catastrophes.
Microsoft avoids that by backing up your key (not password) to a USB drive or even cloud first. There's no typo issue. There's no forgotten password issue.
Microsoft avoids that by backing up your key (not password) to a USB drive or even cloud first. There's no typo issue. There's no forgotten password issue.
> Microsoft avoids that by backing up your key (not password) to a USB drive or even cloud first. There's no typo issue. There's no forgotten password issue.
The issue is that now the forgotten password moves to the cloud, especially since Bitlocker is activated automatically, without notifying the user, when an MS account is used. So regular Joe probably has no idea his drive is encrypted.
And since MS also push for authenticating to the account by using the TPM combined with a fingerprint / webcam / PIN, if you can't use your laptop (which is likely the case if you can't remember the unlock password – which you've probably never knwon was even a thing to begin with) you're pretty much SoL if you can't remember the cloud password – which you haven't used in months, possibly.
I think the old, manual way of activating BitLocker was best, where they tried to coax you into backing up that key someplace.
The issue is that now the forgotten password moves to the cloud, especially since Bitlocker is activated automatically, without notifying the user, when an MS account is used. So regular Joe probably has no idea his drive is encrypted.
And since MS also push for authenticating to the account by using the TPM combined with a fingerprint / webcam / PIN, if you can't use your laptop (which is likely the case if you can't remember the unlock password – which you've probably never knwon was even a thing to begin with) you're pretty much SoL if you can't remember the cloud password – which you haven't used in months, possibly.
I think the old, manual way of activating BitLocker was best, where they tried to coax you into backing up that key someplace.
> manual way of activating BitLocker
That method lead to tons of people not using it. It also lead to tons of drive lockouts due to people not knowing the password and not backing up the key. Good security is transparent to the user, making the user do things makes them insecure.
There are a ton of authentication options for a Microsoft account that aren’t passwords (they are the “passwordless” people after all). You can set up as many as you want (and will be nagged about it until you do!). Install Authenticator, configure whatever your phone offers for biometrics to unlock it, and get on with your day.
That method lead to tons of people not using it. It also lead to tons of drive lockouts due to people not knowing the password and not backing up the key. Good security is transparent to the user, making the user do things makes them insecure.
There are a ton of authentication options for a Microsoft account that aren’t passwords (they are the “passwordless” people after all). You can set up as many as you want (and will be nagged about it until you do!). Install Authenticator, configure whatever your phone offers for biometrics to unlock it, and get on with your day.
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
[2] yeah, I know…
[3] or that uses the same, now lost, credentials
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
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'
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'
FDE with someone "in the cloud" having the key is defeating the purpose of FDE.
Windows used to offer printing a very long key on paper.
Depends on your threat model.
Most people protect against access by whoever stole their laptop, with Microsoft and TLAs not being considered a threat. Those who do probably don't use Windows in the first place.
Most people protect against access by whoever stole their laptop, with Microsoft and TLAs not being considered a threat. Those who do probably don't use Windows in the first place.
It's actually a really elegant solution as there is nil correlation of risk: the key is useless without physical access and physical access is useless without knowing the login.
Your government might be able to get the key - if that's part of your threat model - but they probably have easier ways to force you to give it up.
Anyway, FDE is often on by default. Do you really believe the average user is going to print out the backup key?! Do even tech savvy users have printouts of all their eg 2FA codes? Anyway, that would have worse correlation of risk as users would probably keep the printout next to their computer.
Your government might be able to get the key - if that's part of your threat model - but they probably have easier ways to force you to give it up.
Anyway, FDE is often on by default. Do you really believe the average user is going to print out the backup key?! Do even tech savvy users have printouts of all their eg 2FA codes? Anyway, that would have worse correlation of risk as users would probably keep the printout next to their computer.
> It's actually a really elegant solution as there is nil correlation of risk: the key is useless without physical access and physical access is useless without knowing the login.
That is assuming you somehow forget your encryption key but remember the login to your microsoft account... that you used once 2 years ago when you were installing the machine.
It also means anyone that does get the login for your MS stuff can decrypt your laptop
That is assuming you somehow forget your encryption key but remember the login to your microsoft account... that you used once 2 years ago when you were installing the machine.
It also means anyone that does get the login for your MS stuff can decrypt your laptop
The encryption key is much longer than the typical password, and people often use password managers to store website login, so I think it is reasonable to assume that they can forget the encryption key and remember their microsoft account login.
Anyone that does get the login for that MS account can decrypt the laptop, but often times they don't have physical access to the laptop (say some hacker who does not know you personally). If they let people around them get the credential, I think it is likely that they will let others get the encryption key even if it is not saved on the cloud.
And I think backup using the cloud is a nice option, although it would be better to have a master password that you remember and doesn't require writing it down physically. That way people having access to your cloud will not be able to read it, and you still have it when your house burn down (which does happen for some people...).
Anyone that does get the login for that MS account can decrypt the laptop, but often times they don't have physical access to the laptop (say some hacker who does not know you personally). If they let people around them get the credential, I think it is likely that they will let others get the encryption key even if it is not saved on the cloud.
And I think backup using the cloud is a nice option, although it would be better to have a master password that you remember and doesn't require writing it down physically. That way people having access to your cloud will not be able to read it, and you still have it when your house burn down (which does happen for some people...).
>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.
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.
My happy medium is encrypted PCs that sync everything onto my unencrypted home server.
If you're already in my bedroom, I've got bigger problems than my family photos.
If I leave my laptop on the bus, it's a VISA problem.
This isn't for everybody, but it's probably the safest my family can be.
If you're already in my bedroom, I've got bigger problems than my family photos.
If I leave my laptop on the bus, it's a VISA problem.
This isn't for everybody, but it's probably the safest my family can be.
This is not great from a robbery point of view or a disposal point of view.
Syncing to a cloud service would be better.
Syncing to a cloud service would be better.
This is the other side of the problem: the issue is wider than your data and doesn't even need to be about FDE or other encryption. Simply using decent passwords/passphrases more generally is a hurdle to jump before even considering FDE because the other set of risks are when a bot gains access to the machine by those means it may be able to gain access to information to enable identity fraud or even get direct access to banking information (most care a lot more when their money is at stake than just their data or reputation). The circumstance in this post may not seem relevant here to us, but to a non-technical user the two are easily conflated (“I heard about someone who used a strong password and lost access to everything when it was forgotten”).
Everyone forgets about the CIA triad - security is not just about confidentiality, but also integrity and availability.
I am sitting on a 12TB array after my move I just can't come up with the combination...
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
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
As much as I adore my Yuibikey, my girlfriend thinks I’m decidedly weird because I have two: one on my actual keys, and a backup that’s in my safe at home. Which is annoying because not every system lets me setup two Yubikeys (though TOTP is fine at least). I’m not using it for FDE, but I am using it for securing my password manager (which does support both keys) which holds the backup keys for said FDE and so on.
Name and shame sites that don't support using multiple Yubikeys! I'm pretty sure they're violating the guidelines in the standard if they do that.
The issue I have is that the second key can't really sit in the safe all the time because everytime you setup new service, it needs to be taken out and added.
It's weird that we had that issue solved ages ago (like SSH, just add multiple public keys to the account, no need to have private key available for that), yet keep inventing worse way to do it.
Especially that most YK versions do support pub/private key auth...
Especially that most YK versions do support pub/private key auth...
Absolutely, but it's worth the trade-off for me personally. I get weird looks from my partner because of it though haha
> Solutions, that don't involve someone being an unpaid 24/7 infrastructure support tech, on a postcard please!
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.
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.
So as long as you keep your data unencrypted next to your encrypted data, you're fine. Checks out.
I get it, it’s fun to make jabs at posts on HN. You don’t need to lean so hard into the trope.
I may have assumed that your backups were encrypted, just because so many backup tools do it automatically. And I didn’t put that in the post. Predictably, I get some kind of jerk replying to the comment with a sarcastic jab, rather than any kind of interesting discussion.
Accidental data loss is the big risk, and for most people, it’s a bigger risk than any risk of someone reading your unencrypted data. It makes sense to start with the most serious risks (data loss), and work your way down to the minor risks (compromise).
It makes not sense to start by encrypting your data, because it significantly increases your risk of data loss, in the absence of good backups. That’s what the article is talking about.
I may have assumed that your backups were encrypted, just because so many backup tools do it automatically. And I didn’t put that in the post. Predictably, I get some kind of jerk replying to the comment with a sarcastic jab, rather than any kind of interesting discussion.
Accidental data loss is the big risk, and for most people, it’s a bigger risk than any risk of someone reading your unencrypted data. It makes sense to start with the most serious risks (data loss), and work your way down to the minor risks (compromise).
It makes not sense to start by encrypting your data, because it significantly increases your risk of data loss, in the absence of good backups. That’s what the article is talking about.
I legitimately didn't, and still don't, see how this solves the problem of less technical users losing their encryption keys.
Because it gives you a longer period of time to learn the keys without consequences if you forget.
If you encrypt your HD, you’re suddenly in a position where forgetting your key will lose all your data. It’s like walking off a cliff and hoping you can fly.
If you start by making backups and doing test restores, there’s a period of time where you are still forced to remember the key (to do the restore), but the consequences for losing it are low.
If you encrypt your HD, you’re suddenly in a position where forgetting your key will lose all your data. It’s like walking off a cliff and hoping you can fly.
If you start by making backups and doing test restores, there’s a period of time where you are still forced to remember the key (to do the restore), but the consequences for losing it are low.
Yeah I don't think this would help my mother.
Your mother wouldn’t benefit from backups? The idea here is that you get backups working first, because data loss is the most serious risk, and then you later consider whether you want full disk encryption once you have backups working.
Encryption is designed to make data difficult to access, so it makes sense to consider backups and encryption jointly. I don’t understand why someone would consider this controversial.
Encryption is designed to make data difficult to access, so it makes sense to consider backups and encryption jointly. I don’t understand why someone would consider this controversial.
Now you need to manage password to your backups (that you would encrypt, else why bother with encryption in the first place?) and to your encryption.
Or maybe just capitulate and admit that a bunch of kids, people and cat pictures maybe don't need to sit on encrypted storage
Or maybe just capitulate and admit that a bunch of kids, people and cat pictures maybe don't need to sit on encrypted storage
Yes, it seems we agree on all these points here. I don’t think we have any disagreements. My whole argument is that backups are more important than encryption for most people, and encryption is (1) not necessary and (2) shouldn’t be attempted until you have good backups.
You seem to be arguing against something here, but it sounds like it’s really just a miscommunication. The original prompt was to fit the instructions on a postcard, and and perhaps it’s not really possible to fit good instructions on a postcard.
In order to fit instructions on a postcard, there are a number of things I left out with the idea that someone could figure them out. Stuff like “how do I do backups” or “should I encrypt my backups”. I thought that people could figure out to encrypt their backups if they wanted to, because backup solutions have that option. I also thought that people could figure out that you’d also encrypt your backups if you encrypted your hard drive. Maybe I should have spelled it out in excruciating detail.
As far as I can tell, that’s the lesson here—spell things out in excruciating detail, or you’ll get sarcastic jabs in the replies.
You seem to be arguing against something here, but it sounds like it’s really just a miscommunication. The original prompt was to fit the instructions on a postcard, and and perhaps it’s not really possible to fit good instructions on a postcard.
In order to fit instructions on a postcard, there are a number of things I left out with the idea that someone could figure them out. Stuff like “how do I do backups” or “should I encrypt my backups”. I thought that people could figure out to encrypt their backups if they wanted to, because backup solutions have that option. I also thought that people could figure out that you’d also encrypt your backups if you encrypted your hard drive. Maybe I should have spelled it out in excruciating detail.
As far as I can tell, that’s the lesson here—spell things out in excruciating detail, or you’ll get sarcastic jabs in the replies.
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.
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.
No need to imagine someone trying to hack your EFI or bios when they can just insert a usb keyboard sniffer ordered off amazon or aliexpress
> I’ll never forget it
I used to think that, too. Narrator: He did forget it... Lesson learned. As always, YMMV.
I used to think that, too. Narrator: He did forget it... Lesson learned. As always, YMMV.
battery horse stapler in a playfair grid?
https://en.wikipedia.org/wiki/Playfair_cipher
Not the full cypher but just reading out the letters in the grid in a different direction.
https://en.wikipedia.org/wiki/Playfair_cipher
Not the full cypher but just reading out the letters in the grid in a different direction.
Sorry, I assumed wrongly that most people heard of this: https://xkcd.com/936/
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 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.
Guaranteed one of them will lose a piece
Shard it with Shamir Secret Sharing and give out shards to more trusted friends?
Or be in the tragic accident with you
It's good to have a vulnerability some times.
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...
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...
96 comment thread from back then (2016)
https://news.ycombinator.com/item?id=12431248
https://news.ycombinator.com/item?id=12431248
This is a big reason why I don't use full-disk encryption; I simply have no threat model that would warrant the risk of using it.
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).
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).
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)
I'll just have to add a macro key to my keyboard that automatically types the correct number of "a"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.
>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.
But FDE avoids tampering.
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.
So if your motherboard needs to be replaced you can't recover your data? Nice!
It's effectively just multiple key protectors. TPM+PIN is one way to protect the data encryption key. You can also backup the actual encryption key (which is the recovery key). You can also add a password that protects the key or back the key up to an online Microsoft account or enterprise Active Directory account.
The actual encryption key for the volume data isn't the recovery key, it's the FVEK (full volume encryption key), which is encrypted using the VMK (volume master key).
The recovery key is a 128-bit value (entered as 8 groups of 7 digits, each of which when divided by 11 gives a 16-bit value, where a non-zero remainder indicates the group has been incorrectly entered) which gets hashed repeatedly, with a salt, to derive a 256-bit key that decrypts a copy of the VMK.
The recovery key is a 128-bit value (entered as 8 groups of 7 digits, each of which when divided by 11 gives a 16-bit value, where a non-zero remainder indicates the group has been incorrectly entered) which gets hashed repeatedly, with a salt, to derive a 256-bit key that decrypts a copy of the VMK.
No, you would use the recovery key in that scenario.
And we're back to the problem of having to store some rarely used credential somewhere.
So you... put it in USB drive then dig it out 5 years later and discover it's dead and you're fucked.
So you... put it in USB drive then dig it out 5 years later and discover it's dead and you're fucked.
That is indeed a worst case event to be wary of and avoid, for any secret data that one may need to retrieve infrequently.
But my original point was that sealing the key to the TPM is better because it prevents adversaries from accessing the volume data by tampering with the boot chain, and provides a lockout where there are too many failed PIN attempts.
The bruteforce attack described by the author wouldn't have been possible on a BitLocker volume that was set up with TPM+PIN.
But my original point was that sealing the key to the TPM is better because it prevents adversaries from accessing the volume data by tampering with the boot chain, and provides a lockout where there are too many failed PIN attempts.
The bruteforce attack described by the author wouldn't have been possible on a BitLocker volume that was set up with TPM+PIN.
correct horse battery staple something something
Nah, I'll stick with Tr0ubAdor&3, thank you very much :-)
"batchelder is a fine person really but I do think s/he lacks entropy"
(2016)
[deleted]
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.