I lost my OpenBSD full-disk encryption password | Hacker News Reader

I lost my OpenBSD full-disk encryption password

blog.filippo.io

498 pointsoskarth96 comments

Enlightenment always takes a while :)

  I later found a nice article documenting the entire system. It
  also includes references to JohnTheRipper having a module for
  this. Well, this was more fun.

Wonder how many times are the same items posted: https://news.ycombinator.com/from?site=filippo.io

Off-topic, but my personal work sometimes ends up on the front page, and I'm always amazed how much reposting there is on HN - probably more than on Reddit and similar sites. Say, here's my stuff:

https://news.ycombinator.com/from?site=lcamtuf.blogspot.com

https://news.ycombinator.com/from?site=coredump.cx

The process seems quite random; sometimes, the same link is submitted four times and lingers at score 1, and then some random dude's fifth attempt goes to #1. May be an interesting thing to graph (and get a #1 story on HN out of =).

Thanks for helping people make better software.

There are several factors that lead to the posting ending up on the first page. One factor is time of day--if it is there early in the morning east coast time, it is more likely to get attention.

And early votes (like within the first hour) will more likely propel it to the first page.

Unfortunately, that tends to work against posters like me from East Asia with about a half-day time difference. So far, I haven't given in to the temptation to switch to posting on HN after midnight...};-)

Sounds like you should make a side project which will post to HN on your behalf at an arbitrary time. I think the first trial post should be about the project itself.

That is a problem, but it has been a bit better since HN auto-reposts some submissions (either automatically or moderator-triggered).

I've had submissions several times now that had been totally ignored and dropped off /newest, only to see them on the front page hours later.

I wish that more personal projects were posted here on the site. It's a bit tiresome to read about startups.

I suspect they just get lost in the noise. HN is pretty high volume, the front page is short, and articles quickly fall down under if they don't manage to get enough attention from the get-go.

Certainly these are more interesting for me than news about whatever the big tech companies are doing right now.

As somebody whose personal project never made it to the frontpage (I think because of bad timing, it's otherwise p much tailor made for hnews), that's heartening!

Do you think I should post it again myself or try and find somebody else to?

lcamtuf is just a great man. Take a look at his biography and inventions. I love this works same as Gynvaels http://gynvael.coldwind.pl/?blog=1&lang=en

When they post something, it's always interesting and very often innovating.

Doing something for the sake of learning doesn't ever feel like wasted time. When I was first getting into networking I wanted to connect two computers directly without have a router or a switch between them. I carefully researched how to cut and crimp an ethernet cable into be a crossover cable, and successfully connected the two.

Feeling proud of myself, I scrolled farther down the page that described it only to read that most NICs will automatically do it for you and you don't need to make crossover cables any more. I'm still glad I took the time.

They do? Huh.. Think I still have a crossover cable lying in my drawer "just in case"

I guess it makes sense, AUTO-MDIX is easy enough to be implemented and can save time from a lot of people.

#that I didn't know! I made one for my Win98 machines. Haven't really wanted to do it much since because networks!

BTW, I wonder which category of users need to supply passwords. Until now it seemed that captchas were inevitable.

Well there's a reason they say 70% of programming is done in the library...

The previous article, about a lost password for a NAS, is hilarious and well worth a read as well:

https://blog.filippo.io/so-i-lost-the-password-of-my-nas/

He's lost two VITAL passwords? This seems like a false premise then (which is fine, but the fictional premise seems unneeded and disrespectful).

Ehhmmmm. stares at feet

I wish I could tell you anything better than "in my defense, I seem to forget only one vital password per year..."

(But seriously, I never risked data: the WD didn't have FDE, it was just a matter of salvaging the hardware; the OpenBSD was still in the middle of a migration and I had the source still accessible, so it was a matter of saving time. And it's fun.)

Simply put (since the article neglected to include the password), what should we learn from the article?

I imagine the password was "too short".

PS - My POV is fully critical. Please, do not be personally offended. [emoticon smile]

I think the thing to learn from the article is "how to go deep diving into an operating system's internals"

>what should we learn from the article?

Off-the shelf NAS' security is shit.

> I seem to forget only one vital password per year

For me, it helps to enter the passwords from time to time. The easiest way to do this is to reboot.

If you have moral issues with rebooting a system where rebooting is not necessary, maybe run just the password checker, e.g. by unlocking a second volume that has the same password, or something.

I would probably forget my FDE passphrase if my laptop did not have a processor fault causing it to spontaneously reboot every couple weeks (particularly in hotter weather.)

I've recently gotten in the habit of writing passwords (or at least a part of them) down in a notebook. There are just too many passwords to remember, some of which I use very very rarely. I don't trust any password managers running on a networked computer or (gasp) phone, so paper is good for me. Plus it's more reliable.

From the article:

> Turns out all the password fields except the login form have maxlength=16, so when resetting the password I pasted it from the password manager and it got cut without me knowing.

So it could have been another WTF on the NAS that was silently truncating his passwords.

...or he could have become a super-hacker because his memory for passwords is terrible. :P

> ...or he could have become a super-hacker because his memory for passwords is terrible. :P

Necessity is the mother of invention. :)

(The password trunction is quite a "WTF" though. Thanks for mentioning that.)

Why assume bad faith?

I tend to forget passphrases very soon after creating them, around the time I am memorizing or changing a new passphrase, or after a month or so of not using one (depending on how long I have used it for.) Other people may have other patterns.

I have a fair number of passphrases that cannot be reasonably stored in password managers. As we know, it's hard to memorize a lot of high-entropy strings. I suspect that memorizing new ones tends to push out old ones.

> which is fine, but the fictional premise seems unneeded and disrespectful

I don't see how taking the effort to write a more compelling story is 'disrespectful' to the reader.

This sort of lie doesn't hurt the reader; this isn't the news, and the writer hasn't distorted any of the technical facts.

Quick question for the more cryptographically inclined: apparently after decryption the code does an HMAC validation:

    /* Check that the key decrypted properly. */
    sr_crypto_calculate_check_hmac_sha1(sd->mds.mdd_crypto.scr_maskkey,

Does this mean it's using Mac-Then-Encrypt? And if so, is it likely doomed [1]?

[1] https://moxie.org/blog/the-cryptographic-doom-principle/

That is a good principle, but the context here is different.

FDE doesn't have space for and can't afford (because of the random read patterns) authentication tags, so it uses modes like AES-XTS instead.

What that HMAC does is just confirming that the passphrase is the right one. Think of it as a checksum, not as authentication.

It's not doing very much before validating, which would reduce the risk. But more importantly it doesn't have any information to leak. The whole block of data is public.

OpenBSD uses XTS, which is what you should do for disk crypto (only). For more background, see http://sockpuppet.org/blog/2014/04/30/you-dont-want-xts/.

Awesome article, thanks for posting.

This explains better than I could the whole point of doing encryption in bcachefs:

https://bcache.evilpiepirate.org/Encryption/ https://news.ycombinator.com/item?id=12410798

It checks the key against some kind of authenticator in the superblock, which is what one would expect from any kind of offline crypto.

The real problem is that FDE in the usual sense is (from the strict cryptological sense) very weak encryption, because it cannot afford to expand the encrypted data and has to allow random access (so no random IVs, no authentication tags...). It's relatively trivial to design FDE scheme that is fully secure, but it has 2x block io-op amplification for both read and write, which means unusable performance (certainly on rotating disks, probably even on SSD). Various wide-block encryption modes (AES-XTS etc.) attempt to mitigate attack vectors caused by this, but are secure only under certain FDE-specific attack models.

[Edit: formatting and last sentence]

If he wanted to know the value of the salt for his disk, wouldn't it be easier if he just modified the sources so it would be printed it out?

I... Actually didn't think of that, to be honest. But it would have involved rebuilding the OpenBSD kernel, so it probably wasn't easier. Also, the tool wouldn't have been reusable. But yeah, good thinking.

I am not familiar with OpenBSD, so it never occured to me one might have to rebuild kernel for this... Anyway, nice write-up, glad you cracked it in the end! :)

Could you have set a breakpoint on the function and traced it while it created the new encrypted test image until you could dump the salt from memory?

the rounds number 0x2000

Does anyone know if this is the default? If I'm understanding this correctly, it's around 10 ms of key derivation time; on FreeBSD we default to 2 s, which should make cracking disk encryption 200x more expensive.

That's the default. Easy to override--and I did after this--but admittedly ew. Maybe we should email the OpenBSD list?

Please do. I'm not sure exactly which list would be appropriate, and I don't want to provoke a "FreeBSD guy coming in and trying to tell us what to do" reaction anyway.

Well its SHA-1 after all, so you're up against a GTX 980 GPU pushing about 4GH/s. (so I think 0x2000 is about 2ns in that case)

Sure, scrypt would be much better than pbkdf2 here. But that's still no reason to not take a 200x increase in cracking cost; no matter how fast your adversary's ASICs are, there's a range of passphrase complexity where it will matter.

What key derivation time would you advise targeting for a server with 20-100 disks, where each disk has a unique KDF salt?

How many times stronger would scrypt targeting 2s be compared to PBKDF2 targeting 2s? If using scrypt for many disks would it then be safe to target 10-100ms so as not to impact on reboot times?

What's the usage model here? When you boot up the server, someone sits down at the console and types in 100 unique passphrases?

It's a single process managing multiple disks with a fixed-size extent system on each.

1. The process has a single passphrase entered at startup.

2. This passphrase is then used to derive the master key encryption key for each disk using the disk's own parameters (KDF_SALT, KDF_ITERATIONS) which are generated and estimated when the disk is formatted and added to the array (disks may come and go).

3. The master key encryption key for each disk is then used to decrypt the AF-split master key for each disk, similar to LUKS.

While reading I had the feeling that the author was reverse-engineering open source software...

In essence, that's precisely what he's doing. The exact on-disk metadata layout may not be documented anywhere, so he pieced it together using the structure definitions in the source code.

For those reading along at home, what is being done here is a run-of-the-mill bruteforce, this article could be about any FDE implementation.

So now the real question .. what was the password? :-)

hunter2

All I see is * * * * * *

I've had to do a similar thing with OpenBSD's softraid. In an unfortunate incident with a problematic hard drive that mostly works but sometimes gets stuck reading / clicking for a while. That while once took too long and resulted in a timeout, softraid flagged the disk as being offline. I started a rebuild, but later on got a bit paranoid and ran smart checks on both of the mirrored disks. Well, the other disk didn't respond well to smart and got itself flagged offline. Now my softraid mirror was down with one disk halfway through a rebuild and the other disk just fine but flagged bad.
Recovery was a matter of finding the right metadata bit on the disk that tells softraid about the disk's status. That was the hardest part (and not that hard, but it certainly felt like reverse-engineering the system). I flipped a byte with dd and my brought the raid up again.

When deciding to encrypt, lets say a backup, you need to ask yourself, is the data better lost then in the hands of the wrong people.

Another way to look at this, is to ask yourself what your threat model is. For example, if your primary concern is losing your laptop while traveling, then writing down your pass phrase and keeping it with other important paperwork (tax returns, property deeds, birth certificate etc) in a home safe or a bank safety deposit box seems totally reasonable. If you have concerns about Protecting your data from law enforcement, then the pass phrase needs to be stored out of the reach of a warrant - a trickier proposition.

Indeed. Good data encryption is also far stronger than the things like locks that people make analogies to in the real world. There is essentially no locksmith. If you lose the key, your data is gone forever. As illustrated by this article, if you have weak passphrases there are ways around it, so I suppose it is possible to "tune" the strength of your encryption that way.

I think the implication wasn't that the passphrase was weak, but that it was mostly known.

I briefly went all-in on security, cryptocurrency, tor, etc., and had a locked down desktop machine encrypted with LUKS. Then, I moved, and it took me a few weeks to get the computer set back up. In that time, I'd forgotten my passphrase. So, I have a desktop machine containing (at least) a couple hundred bucks worth of cryptocurrencies that I can't open. I still think I remember the passphrase I used, but it doesn't work, so I'm obviously missing a word or a punctuation addition (I used the CorrectHorseBatteryStaple method of making a memorable passphrase in this case).
I've been known to do dumb things, and going down the rabbit hole of cryptocurrencies and how to securely use said currencies was one of them. These days I put everything of importance into Google drive, Dropbox, and/or git (not github...a privately hosted git that I access via ssh and runs on a VM on hardware I own in a data center I trust). If it is sensitive, it is encrypted with a passphrase I've been using for a couple decades, and so it unlikely to be forgotten. A high capability attacker could thwart my protections, I'm sure, but I don't have any reason to believe a high capability attacker has any interest in me.
And, I don't hold much cryptocurrency, and what I do hold is at Coinbase, just sitting there on the off chance Bitcoin really does take over the world and a small amount turns into a big value.

but I don't have any reason to believe a high capability attacker has any interest in me
Note what George Smiley is known to reply: "There was every reason":
Peter Guillam: Well, at the time there was no reason to suppose the phone was tapped... George Smiley: There was every reason.
(from http://www.imdb.com/character/ch0030043/quotes as well as the book)

Shouldn't bruteforce work?

So, for the layman, does this mean, the encryption can be practically cracked or not?

No. He just made a brute forcing tool.

If you almost know the right passphrase, it can be. If you don't, and the passphrase is good, it can't.

Thats, that is reassuring :). Would have been a good addition to that article. Of course, if you are lacking just a few letters in the password, brute forcing gets much more applicable.

To be clear, it's if you know more or less the right passphrase. This is why your passphrase should be randomly generated. Word based passwords are still fine (for memorability, a la xkcd), but you need real entropy that can't be guessed.
For example, if you choose your daughter's middle name your favorite animal, and the street you grew up on, then you have a small amount of entropy, and you'll be screwed in an offline attack scenario like this. The attacker can narrow it down to combinations of words and numbers related to you, and the brute force becomes feasible. If you use four randomly chosen words from a dictionary of 2000 words, then cracking it is roughly equivalent to cracking 13 random digits.
Side note: cycling through multiple random pass-phrases of this type until you find something memorable has difficult-to-analyze negative effects on the final entropy. Ideally, you should be using the first output it gives you.

Yeah - this solves the "I know I used 'correct horse battery staple', but can't remember if it was correct-horse-battery-staple or correct_horse_battery_staple or c0rrect+h0rse+battery+staple or c0rr3cth0r53b4tt3ryst4pl3 or whatever...
None of this would have helped if he wasn't sure exactly which error he'd made with a password like %)]5ZJ'HDb]n.'Y&4P-dMZMvS

He probably just misremembered a few characters of his password, like mypass1234, mypass1235, mypass4321, etc. It would be time consuming for human to try all the 4 digits but trivial for computer to try out the 9999 enumeration.
The complication is finding out the algorithm used and the parameters applied to the algorithm. Once figured out, he wrote the small program to brute force the small enumeration.
This is a very good illustration of the need for long and non-trivial password; otherwise, it can be easily guessed.

Hm, if it were me and I had just set up the new system and then promptly forgot the password, I'd just reinstall.

Why not have your passwords be hashes of passphrases?

Because that would add little entropy at the cost of much inconvenience, which is the opposite of what you want.

That's why I keep them written down in my safe!

I do that too! I have the same "suffix" that's on all of them that I leave off the written version for a tiny bit of extra security. It's just a few characters that I've been using consistently for years on written-down passwords.

That's why you always
1) store passwords in the password manager, even the ones you think aren't important.
2) backup your data

> 1) store passwords in the password manager, even the ones you think aren't important.
Losing the password that unlocks full disk encryption (FDE) is like losing the password that unlocks your password manager. At some point you have to have something stored only in your mind.
Now sure you could have your FDE password stored in a password manager as well but that's probably not a good idea. Also, compared to just about everything else saved in a password manager, you'd have to manually type the FDE password at boot. You can't copy/paste it as if anything your password manager would be running on a different computer.

Unless you use a hardware password mgr which can emulate a USB keyboard :)

> stored only in your mind
A sticky note at home is reasonably safe, unless you're legitimately worried that a dedicated person may target you specifically.

I have portions of my password safe passphrase stored with certain friends. If I get hit by a bus, those friends will almost certainly work out who each other are and what to do with the snippets they have. (And I "mind" several snippets of passphrase for some of them as well).
Not "nation state" secure, but I'm reasonable sure it's well beyond petty thief, curious cow-orker, 4chan/anonymous, or local LEO's capability to subvert.

It's easy to read off your phone and type at boot if you use a passphrase. You'll probably memorize it anyways after a couple of days.

How would backing up help? If you back up the encrypted data, then your backup is still useless because you don't have your password. If you back up an unencrypted copy, that defeats the purpose of encryption.

Backing up the password manager data (provided you did store all passwords in there, and that you don't forget at least the master password) would _definitely_ help in this scenario.

You could make a encrypted backup with a different password. That way if somebody compromises one drive they still have to work for the other.

But it's a backup? If you have one copy, you pretty much have the other, right? And that just adds another password you can't forget, lest you lose your data.

Scribbling the passwords in a notebook isn't a bad idea (although don't write "My Passwords" on the front cover). The security of physical things is well understood by most humans.

Just put the notebook in a safety deposit box.

You already have a lifetime of training for taking care of small, folding pieces of paper in your wallet.

That is true only for rapidly decreasing part of the population, especially in certain parts of the world.

Think of it as a small, non-folding piece of plastic in your wallet, then.

> Scribbling the passwords in a notebook isn't a bad idea (although don't write "My Passwords" on the front cover). The security of physical things is well understood by most humans.
"Not Passwords" :D

I don't write down my most important passwords and they're randomly generated gibberish. About a month back, for whatever reason I just couldn't remember one for a minute and it damned near gave me a heart attack. I think I ought to go with your strategy now.

> I don't write down my most important passwords and they're randomly generated gibberish.
How the hell do you remember randomly generated gibberish of a length that would be cryptographically secure?
Multi-word passphrases work great for me for everything that has to be kept in my mind safe. If I had to remember things like "LOZOktjR33IxVbACQsgicUtDubOyz9o2" I'd definitely have to drink less.

Even better, store the password with recovery instructions in your will. That's both safe and available because wills share many of the security treats of passwords. And it's also a good backup plan for your relatives to access bank accounts, cancel subscription services etc in the event of accidents.

And/or maybe in a sealed and tamper-evident container. So you or your family can access it in an emergency, but you will know if this has occurred. The hiding location could be outlined in your will?

how would a physical tamper resistant container work? just curious. if it's something one can buy, what prevents an attacker to buy one same container itself to replace the damaged after the fact?

Sealed with tape, with your signature on the tape? And/or some tiny mark on the container that's hard to find.

ah silly me I was thinking about buyable products but that sounds both easy and feasible

Or just remember TWO passwords... it's not that hard.

Reply on news.ycombinator.com