Changing Linux user password after you lost them

This is something which happened over a year ago, but I remembered it and thought it’d be a good fit for this blog.

At the Linux space someone said they have an old laptop, but they lost the password. No biggy, they can just reinstall, but maybe trying to get access to it could be a fun project for someone.

It seemed like a fun thing to do to me, but I was already doing something else and didn’t want to spend time on that. What I could do, is explain all I know about this subject (which isn’t a lot), and maybe that could help.

Fun fact: by explaining things I knew, I suddenly figured out how to do it, and it worked :D

What I basically did, was boot up from a USB stick, and then change the user password on the original installation directly in the file where the relevant info is kept.

On password hashes

The first thing you need to understand, is how authentication generally works. A naive way could be to store someones username and password as plain text somewhere. Then, when they want to log in, they provide both, and you can check if they are correct. The problem is that you then have the password stored in plain text, readable for any one who gains access to the system. So instead of storing the password as such, generally only a hash is stored.

The hash of a password is the result of a hash function where you provide the password to. A hash function is a function with certain properties. (I’m writing this from memory, maybe I’m forgetting something, but it should give a general idea.)

1. It takes an input and provides an output. These are generally a list of bytes.
2. A small change in the input causes a seemingly random big change in the output. Seemingly random also implies that you can’t simply say “oh, if I want the output to change like this, I can just change this in the input”.
3. While it’s relatively easy to get the hash from something, there’s no easy way to deduce the original input from the hash. The only way you can get this, is by trying every possible input one by one until you have a hit.

So generally when you set a username and password, the username will be stored, but the password will be hashed, and then the hash will be stored. When you log in, the system will check if your username is known, hash the password you provided, and check if it’s the same hash as they have stored. If not, then you provided a wrong password. If yes, you provided a correct password.

Note that this isn’t Linux specific, this is just how passwords in general are done. If you ever get weird constraints on a service when setting a password, like a maximum number of characters, there’s a chance they store your password in plain text. Hashes typically have a fixed length, so the actual length of the password shouldn’t matter (unless you go so big that you hit other limits, like sending 3T of data as a password or something, y’ know). Another similar red flag is when you choose a long password, but then the password still works when you leave out one or more of the last characters. Or when you say you lost your password, and they can magically provide you with the password.

The shadow file

In Linux (well, generally in Unix systems, I guess), there’s a so called “shadow file”. You can find it in /etc/shadow. (Btw, in case you wonder etc stands for “et cetera”. There’s a standard for what folders a Linux distribution has, and this is part of that standard.) It contains the usernames, password hashes, and some other information of the users on the system. A normal user normally doesn’t have access to this file, but you can view and change it with root permissions.

The evil maid

If the data on your drive isn’t encrypted, then it’s accessible outside your system. It’s only a matter of how to gain access to it. One simple way is to boot a different OS, e.g. from a live usb stick. This is a so called “evil maid” attack. The name comes from the idea that devices are often left unattended in hotel rooms, so a maid who comes in to clean the room has access to the hardware.

Execution

So getting access is quite easy.

1. Boot from a different OS where you have root access
2. Make sure the original drive is mounted on the file system of your currently booted OS (let’s say it’s mounted on /media/sda1)
3. Now change the shadow file of the original drive (in our example /media/sda1/etc/shadow).
   • You can delete the hash. That way the user doesn’t have a password any more.
   • You can also first set a password on a user on your current OS. You can then check its shadow file (at /etc/shadow), and use that hash in the shadow file of the target system (in our example /media/sda1/etc/shadow)
   • You can store the original hash somewhere in case you want to set it back for some reason.
4. Now reboot into the original OS.

EZPZ, isn’t it. Changing password hashes like this, is something you can always do if you have read-write access to wherever the hashes are stored. Really the only way around this, is encryption. But that has usability disadvantages. For example, if you loose the decryption key, you’ll never have access to your own data ever any more. In the end everything is just a matter of what attacks you want to protect yourself from, and what disadvantages you are willing to accept.