25

The permissions of /etc/shadow are 600, which means it is not readable for anyone except root.

However, as all passwords inside it are not stored in clear text but as hashes (which means it is impossible to compute the original password from the hash), why may it not be read by everyone?

3
  • Are you sure the permissions for /etc/shadow are 600?
    – edwinksl
    Sep 21, 2016 at 2:20
  • 4
    If a password of your Stackoverflow account is hashed, are you willing to show your hashed password to others?
    – Jeon
    Sep 21, 2016 at 8:21
  • 5
    @ByteCommander. Sometimes I want a way to upvote edits.
    – TRiG
    Sep 21, 2016 at 11:44

4 Answers 4

62

To prevent offline brute-force attacks.

Even though you can't reverse a hash, you can still try hashing every possible password until you find a match, and you can do millions of tries per second with good hardware and local access to the file.

If the file had 644 permissions, then anyone who logged in to your system, even in a guest session, would be able to copy this file off of your computer (whether to a USB stick or remotely via scp) and attempt an offline brute-force attack, without leaving any evidence of this on your computer.


Note that the permissions on Ubuntu are actually 640, not 600:

$ ls -l /etc/shadow
-rw-r----- 1 root shadow 1239 Jun 25 04:35 /etc/shadow

This doesn't matter much though, since there are still no permissions for others, and, by default, no one is in the shadow group.


Originally, hashes were stored in /etc/passwd (which is why it's called passwd), as back when Linux was created, cracking a hash, even the weak types used back then, was practically impossible. Eventually, though, processing power advanced to the point where cracking a hash, at least of a relatively weak password, became feasible.

Changing the permissions of /etc/passwd to 640 or 600 wouldn't work, as there are many legitimate reasons to be able to read /etc/passwd as a normal user (converting UIDs to usernames, getting a user's full name, phone number, etc), so hashes were moved to /etc/shadow, which was given 640 permissions. An x in place of the password hash field for a user in /etc/passwd is used to indicate that the hash for that user is stored in /etc/shadow instead.

11
  • 1
    Good call on the copying of the file!
    – Rinzwind
    Sep 20, 2016 at 20:46
  • 1
    and I do not need the rep ;-) edit: hmm he set it on mine :P sorry :D edit2 and now it is back again. eh :D
    – Rinzwind
    Sep 20, 2016 at 20:52
  • 6
    Last I checked you could put the hashed password back into /etc/passwd and remove the line from /etc/shadow and expect to be able to log in. /etc/shadow exists so that it can be set to 600 for the reason given in this answer.
    – Joshua
    Sep 20, 2016 at 21:16
  • 8
    It's worth noting that the permissions for /etc/passwd are 644. I believe that historically, the password hashes used to be stored here. However, changing this file to 640 would have caused all sorts of compatibility problems, so instead the password hashes were moved to shadow and removed from passwd - this allows the other information in passwd to remain world readable while the password hashes are kept secret in a different file.
    – Rodney
    Sep 21, 2016 at 8:25
  • 4
    @Rodney as someone who grew up on BSD 4.3, you are correct. Hashes were stored in /etc/passwd. Back when the Vax 11/780 was state of the art, a brute force attack on the passwords in the file was considered impossible. Perhaps more importantly, the Internet [Arpanet] was a sleepy little backwater, and such things were hardly considered; there was no ssh- only rlogin/telnet. Keeping the password file 644 means that utilities such as ls don't need to be setuid root in order to translate from uid to name.
    – Mike S
    Sep 21, 2016 at 13:57
13

Actually, /etc/shadow was created to allow moving away from a publicly readable list of user names and passwords.

Hang in there, this will be a little bit of a history lesson, before we get to the actual answer. If you don't care about history, just scroll down a bit.

In the old days, Unix-like OSes, including Linux, generally all kept the passwords in /etc/passwd. That file was world readable, and still is, because it contains information allowing mapping for example between numeric user IDs and user names. That information is highly useful even to ordinary users for perfectly legitimate purposes, so having the file world readable was of great benefit to usability.

Even back then, people realized that having the passwords in plain text in a file in a well-known location that anyone who could log in could read freely was a bad idea. So passwords were hashed, in a sense. That's the old "crypt" password hashing mechanism, which is almost never used on modern systems, but often supported for legacy purposes.

Take a look at /etc/passwd on your system. See that second field, which says x everywhere? It used to hold the hashed password for the account in question.

The problem was that people could download /etc/passwd, or even not download it, and work on cracking the passwords. This wasn't a big problem while computers weren't particularly powerful (Clifford Stoll, in The Cuckoo's Egg, gives, as I recall, the time to hash one password on an IBM PC class system in the mid-1980s as about a second), but it became a problem as processing power increased. At some point, with a decent word list, cracking those passwords became too easy. For technical reasons, this scheme also couldn't support passwords longer than eight bytes.

Two things were done to solve this:

  • Moving to stronger hash functions. The old crypt() had outlived its useful life, and more modern schemes were devised that were both future-proofed and computationally stronger.
  • Move the hashed passwords into a file that wasn't readable by just anyone. This way, even if a password hash function turned out to be weaker than expected, or if someone had a weak password to begin with, there was another obstacle for an attacker to gain access to the hash values to begin with. It was no longer free-for-all.

That file is /etc/shadow.

The software that works with /etc/shadow is generally very small, highly focused, and tends to receive some extra scrutiny in reviews because of the potential for problems. It also runs with special permissions, which allows it to read and modify /etc/shadow, while keeping ordinary users unable to look at that file.

So there you have it: The permissions on /etc/shadow are restrictive (though, as pointed out already, not quite as restrictive as you state) because the whole purpose of that file is to restrict access to sensitive data.

A password hash is supposed to be strong, but if your password is on the Top 500 Passwords on the Internet lists, anyone with access to the hash will still be able to find the password quickly. Protecting the hash prevents that simple attack and raises the bar for a successful attack from simple peeking to requiring one to either be a system administrator on the host already, or go through a privilege escalation attack first. Especially on a correctly administered multi-user system, both of those are significantly more difficult than just looking at a world-readable file.

5
  • i really like the way you describe every thing :) (y) Sep 21, 2016 at 20:39
  • Terminology / etymology: /etc/shadow doesn't hold "shadow passwords" (because that's not a thing). The whole file is a shadow of /etc/passwd. See the way the terminology is used in the Linux Shadow Password HOWTO: Why shadow your passwd file?. Unlike some other uses of the term "Shadow" in computing, it's not a shadow copy, though (like shadowing BIOS code into RAM instead of running from ROM). The field in /etc/passwd is a placeholder, containing a special character that means "the real password hash is in /etc/shadow". Sep 22, 2016 at 2:41
  • Good history but 1 sec. per password was hardly limiting even in the 1980s, not when the top passwords were used by more than 1% of the people each.
    – Warren Dew
    Sep 22, 2016 at 12:16
  • 1
    @WarrenDew Not sure if you are making a statement of fact, or opinion. crypt() has a 12 bit salt and 12+64 bit output for an eight-byte password (then commonly base64 encoded). For common passwords, yes, you could probably attack them by brute force, but it didn't take that much of a password to make cracking by brute force infeasible if every password check took a second. Precomputing a salted table for even a single password would take on the order of an hour at a rate of one encryption per second, plus you had to contend with limited storage (40-80 MB was a lot in those days).
    – user
    Sep 23, 2016 at 18:17
  • @PeterCordes Good point. I'm deleting that passage because it really isn't particularly relevant to answering the OP's question.
    – user
    Sep 23, 2016 at 18:17
10

Why permission for /etc/shadow file is set to be 600?

Who told you that?

$ls -l /etc/shadow
-rw-r----- 1 root shadow 1407 mei 18 10:05 /etc/shadow
  • it is 640.

Simple answer: permissions in Linux are taken serious. There is no reason for "others" to do anything with /etc/shadow. And there is no reason for group "shadow" to write to it. And execution is out of the order.

However, as all passwords inside it are not stored in clear text but as hashes (which means it is impossible to compute the original password from the hash), why may it not be read by everyone?

Because there is not a single reason to do so.

Hashes are one-way. Giving someone read access makes it possible for him to use a script to abuse this one-way: just list any word you can imagine and create the hash. At some point it might match the password. Might take a while though too.

This answer is interesting and has some estimates on brute forcing.

2
  • 640 is for normal user ?? group user can read shadow file?? Sep 20, 2016 at 20:46
  • Sorry? The file is 640. So read, write for user "root" and read for group "shadow". "shadow" is a privileged system created group for this specific purpose.
    – Rinzwind
    Sep 20, 2016 at 20:48
2

Important background: /etc/shadow exists solely for the purpose of keeping the password hashes hidden. In ye Early Days of Unix, password hashes were stored in /etc/passwd. As computers got more powerful, network connections more persistent and security exploits more sophisticated, people realized that keeping password hashes word-readable was asking for trouble. (I won't detail the exploits; there's enough good answers about that already.)

But /etc/passwd couldn't be read-protected: It is used by all sorts of programs to map numeric user ids to usernames, and to look up home directories, default shells, the user's full name (and office number etc. -- check out man finger). So the sensitive part, the password hashes, was moved to /etc/shadow, and the rest remained as it was. That's why /etc/passwd, despide the name, contains everything except the (hashed) password.

1
  • thanks for your reply on my question, now i got a complete idea of /etc/passwd and /etc/shadow file. Sep 21, 2016 at 20:25

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .