Live data from Hacker News

So I lost my OpenBSD FDE password (2016)

words.filippo.io

51–60 of 77 posts

Re: So I lost my OpenBSD FDE password (2016)

#51
post #43
post #31

Earlier quoted context omitted.

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.

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...

Re: So I lost my OpenBSD FDE password (2016)

#52

Earlier quoted context omitted.

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…

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

Re: So I lost my OpenBSD FDE password (2016)

#53
post #23

Earlier quoted context omitted.

So if your motherboard needs to be replaced you can't recover your data? Nice!

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.

Re: So I lost my OpenBSD FDE password (2016)

#54

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)

Re: So I lost my OpenBSD FDE password (2016)

#55
post #38

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 h…

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

Re: So I lost my OpenBSD FDE password (2016)

#56
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...

Re: So I lost my OpenBSD FDE password (2016)

#57
post #37

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, r…

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 o…

> 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.

Re: So I lost my OpenBSD FDE password (2016)

#58
post #50

Earlier quoted context omitted.

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 o…

> 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…

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...).

Re: So I lost my OpenBSD FDE password (2016)

#60
post #53
post #23

Earlier quoted context omitted.

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.

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.

Post reply on HN