How to hack macOS login passwords (or: Why You Should Use Filevault)

(Note: Everything below is evil and should only be used to access data you are legitimately allowed to access. Also, while TV makes things look cool and easy, hacking someone’s macOS password is likely to take a very long time and should only be attempted if you’re comfortable with breaking your computer quite badly. Your Mileage May Vary. Do Not Feed The Dog. You get the idea…)

(Additional note: I’ve had some feedback from some nice people at Apple that the original version of this article was more of a hacking how-to than they were strictly comfortable with, so this has been edited to make it clear that the mechanics of trying to hack a macOS login password are messy, haphazard and extremely time and effort-intensive. And very easily defeated if you employ some of the built-in tools.)

I love watching “Mr Robot”. Not just because of Rami Malek’s extraordinary acting and weirdly hypnotic bug eyed monologuing (although that never gets old) – no, I love it for the same reason that a lot of people in my trade love it; because it tries very hard to stick to the actualities of computer and network securities and most of the time it does an excellent job. Sure, they fudge it a little here and there for the sake of the plot, but in general if our protagonist is going to do some particularly clever piece of hacking then what they show you on the screen will be at least broadly accurate.

My wife and I were watching a recent episode in which our Kali Linux-loving hoody-wearing pal was trying to hack into a Mac, and I spent the whole sequence grinning like an idiot. “Wait, is that possible?” my wife asked. “He just hacked into that Mac. I thought Macs were unhackable?”

And therein lies the rub. The old adage was that the only real security is physical security, and as long as your device is accessible there’s always a way in. These days – with modern advances like the T2 chip and Secure Enclave – that’s starting to look less like an absolute and more like a general rule that has the occasional exception.

If you’ve done any of the elementary things you can do to secure your Mac (Filevault, used the Startup Security Utility to limit external boot, put a firmware password in place) then you’re in good shape and your Mac is (at least as things stand right now) safe from miscreants and TV hackers.

Still, for fun, I thought I’d replicate the broad strokes of what our hero did to hack a macOS login password and gain access to an account on that Mac. Oddly enough, life mirrored art in that a week after figuring this all out I was contacted by a client who had an employee leave under strained circumstances and who had changed the login password on an important computer and then “forgotten” what they’d changed it to.

First we’re going to take it that you’re sat at a Mac that nobody has made any attempt to protect. No biometric precautions, no firmware password, not even Filevault. If you’re sat at the Mac login screen then you are – by default – presented with a list of users and a field for the password for that user. If you don’t know the password then you can get a hint, but let’s assume that when the target set up their Mac they made that hint either wildly inaccessible or just left the field blank. Without that password it’s impossible to get into the account in any meaningful way; sure, if you have an external bootable drive and you’re not dealing with a Mac that’s been set up to disallow external booting (and you know what you’re doing) then you can get some access to files, but passwords and protected data is off the table.

So, what do you do? Well, first things first; you make yourself an account on the machine with full admin privileges to do so:

• Boot into recovery by holding down Command-R

• In the Terminal, turn off SIP by typing in csrutil disable

• Reboot into Single-User mode by holding down the s key

• delete /var/db/.AppleSetupDone, then reboot.

The computer now thinks that it’s a brand new device and prompts you to create an account which will be – because it thinks its a new device – an account with full administrator privileges.

Congratulations! Now you have an account on the computer and can perform further mischief. At this point you could change the password on the account you want to access and be able to log in, but that would blow out the keychain password and you wouldn’t be able to get any other credentials or passwords off the thing – and you certainly wouldn’t be able to cover your tracks so that the legitimate owner of the machine wouldn’t know you’d been tinkering around.

No, to really give them a bad day you’ll need to find where the OS keeps the encrypted hash of their password and then throw that into something that’ll brute force it into submission.

As of macOS Catalina, password hashes for local accounts are kept in /var/db/dslocal/nodes, so once you know the name of the account you’re trying to access (for the sake of argument we’ll call it “test”) you’ll need to copy that users’ plist to some place where you can get at it, thus:

sudo cp /var/db/dslocal/nodes/Default/users/test.plist ~/Desktop

That gives you a file called test.plist, which contains all sorts of data that the OS stores relating to that user’s authentication on the computer. That file will still have the default permissions on it, so you’ll need to Get Info on it and add yourself as a user with read/write permissions to go further with it. The password for the account is stored in a hash that you can get out with an assortment of tools, but I like to use plist2hashcat, so download it and use the terminal to change to its directory to run the command thus:

sudo python ~/Desktop/test.plist

It’ll spit out the hash it pulls from that file, which will look something like this (note – example hash, not a real one):


Copy that to a file called, I don’t know, say, test_hash.txt on your Desktop.

Finally, you’ll need some way to brute force that hash against a list of passwords (and a list of passwords to use). There are many, many sources for passwords out there and I’m not going to link to them because a lot of them are taken from actual data breaches and there’s a fine line between an academic discussion of how a thing can be done and pointing people at resources to engage in criminal conspiracy. Suffice to say that there are sources out there, and that I have a passwords file that I’m going to call passwords.txt and put it on my Desktop along with test_hash.txt. We’re also going to need a place to dump the finished file, so let’s create a directory at the root level of user folder called pots, thus:

mkdir ~/pots/

Next, we’ll install hashcat. I like John The Ripper too, but hashcat is light and easy and relatively flexible, and besides, I think that’s what Eliot used. Download it, install it, then cd into its directory and type the following to tell it to select the test_hash file, pull from that dictionary file and dump the results into the pots directory:

sudo ./hashcat -a 0 -m 7100 ~/Desktop/test_hash.txt ~/Desktop/passwords.txt -w 4 --potfile-path ~/pots/result.pot

This will take – depending on the complexity of the password and the size/scope of the dictionary file – a while. And by “a while” I mean somewhere from light lunch to come-back-tomorrow-morning. Further, it’s in no way a slam-dunk certainty that you’ll get anything useful out of it, and while it looks cool on TV it is a moderately miserable experience in real life. It will, however, eventually spit out a password if you’re lucky (note: the password it found for Mr Test was test1, because I guess he/I wasn’t feeling that creative).

And really, what does it get you anyway? Access to the user’s keychain is handy, sure, but if you’re after files locked away in a user account there are far simpler and faster ways of getting access to those files that don’t require downloading and compiling a bunch of python scripts and trawling around some of the sketchier bits of the web for lists of hacked passwords.

And it’s readily defeated, too. When you set up a new machine you get the option to turn on Filevault – and you should absolutely do that (and you can do it afterwards at any point from the Security & Privacy Preference). Further, with T2 protected machines there are protections in place to prevent booting from external drives, which makes attempting to use another drive to boot into the machine pretty much impossible.

This is one that – except in very fringe cases – is either extraordinarily time consuming or woefully impractical. Looks good on TV, though…