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.
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:
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 =).
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.
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.
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?
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.
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.)
> 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'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.
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.)
> 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
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.
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.
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.
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! :)
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.
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.
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?
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.
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? :-)
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.
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 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.
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.
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
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.
> 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.
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.
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.
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.
> 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.
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?
Wonder how many times are the same items posted: https://news.ycombinator.com/from?site=filippo.io