Are login passwords saved on the machine or only a hash version of the password? If only a hash version of the login password is saved, which hash method is used? In which folder is it stored on the machine? I am using Ubuntu 22.04.

  • 2
    I would read the manpages of shadow and crypt, which explain it in MUCH more detail
    – Thomas Ward
    Nov 4 at 19:01
  • IF by login passwords you mean your system user passwords, then read my answer. There is no restriction on how different programs store their data on system (some store plain text, some store as salted hashes, some are hard-encrypted by proprietary static-compiled keys, etc.)
    – Thomas Ward
    Nov 7 at 1:27

2 Answers 2


Per man shadow, which explains how passwords are stored for users:

   encrypted password
       This field may be empty, in which case no passwords are required to
       authenticate as the specified login name. However, some
       applications which read the /etc/shadow file may decide not to
       permit any access at all if the password field is empty.

       A password field which starts with an exclamation mark means that
       the password is locked. The remaining characters on the line
       represent the password field before the password was locked.

       Refer to crypt(3) for details on how this string is interpreted.

       If the password field contains some string that is not a valid
       result of crypt(3), for instance ! or *, the user will not be able
       to use a unix password to log in (but the user may log in the
       system by other means).

Accordingly, per man 3 crypt we see this explains the encryption:

     The crypt, crypt_r, crypt_rn, and crypt_ra functions irreversibly 
     “hash” phrase for storage in the system password database (shadow(5)) 
     using a cryptographic “hashing method.” The result of this operation 
     is called a “hashed passphrase” or just a “hash.” Hashing methods are 
     described in crypt(5).

Following, that, we look at man 5 crypt:

     The hashing methods implemented by crypt(3) are designed only to process user 
     passphrases for storage and authentication; they are not suitable for use as 
     general-purpose cryptographic hashes.

     Passphrase hashing is not a replacement for strong passphrases.  It is always 
     possible for an attacker with access to the hashed passphrases to guess and check 
     possible cleartext passphrases.  However, with a strong hashing method, guessing will 
     be too slow for the attacker to discover a strong passphrase.

     All of the hashing methods use a “salt” to perturb the hash function, so that the 
     same passphrase may produce many possible hashes.  Newer methods accept longer 
     salt strings.  The salt should be chosen at random for each user.  Salt defeats a 
     number of attacks:

     1.   It is not possible to hash a passphrase once and then test it against each 
          account's stored hash; the hash calculation must be repeated for each account.

     2.   It is not possible to tell whether two accounts use the same passphrase without 
          successfully guessing one of the phrases.

     3.   Tables of precalculated hashes of commonly used passphrases must have an entry 
          for each possible salt, which makes them impractically large.

     All of the hashing methods are also deliberately engineered to be slow; they use many 
     iterations of an underlying cryptographic primitive to increase the cost of each 
     guess.  The newer hashing methods allow the number of iterations to be adjusted, 
     using the “CPU time cost” parameter to crypt_gensalt(3).  This makes it possible to 
     keep the hash slow as hardware improves.

By following this chain (man shadow to man 3 crypt to man 5 crypt) we can see that passwords are stored in /etc/shadow as salted hashed passwords. There are numerous hash mechanisms and methods available so you have to deep-dive into the manpages to really interpret the data in /etc/shadow to determine which hash mechanism is in use on your environment by default.

  • what do you mean by "salted" in salted hashed passwords?
    – user823
    Nov 4 at 22:42
  • 1
    @user823 A hashing algorithm takes input (your password) and produces output (the hashed text) via an irreversible process. But it's still just an algorithm. If you and I both run MD5 on the same text, we'll get the same output. If everyone did that on all services, one good data breach could reveal everyone's passwords on everything. "Salting" is the act of prepending a string to the password before hashing it. Nov 5 at 4:05
  • 1
    If I salt my hashes for my system with "roses" and you salt yours with "violets", then even if someone gets their hands on a table of plaintext passwords for my service, that table is useless for cracking your service, since the hash you get from a password is different than the hash I would get for the same password. Nov 5 at 4:05
  • 1
    @user823 It's explained in the third section of manpages as well as by Silvio. "All of the hashing methods use a 'salt' to perturb the hash function, so that the same passphrase may produce many possible hashes." Put another way, a "salt" is a random string prepended to the actual password before being passed into the hashing functions. It is explained in the third section of man 5 crypt in my answer in depth how this protects and strengthens password hashes more.
    – Thomas Ward
    Nov 5 at 5:30
  • @aroth that's the point of manpages and kernel documentation. Arguing otherwise is not meant for here.
    – Thomas Ward
    Nov 6 at 16:56

In addition to hashed / salted passwords, some are stored in plain text where no one else can read them.

For example ~/.netrc:

  • .netrc file should be located in your home directory and the permissions on the file must be set so that you are the only user who can read it, i.e. it is unreadable to everyone else. It should be set to at least Read (400), or Read/Write (600).

For small developers who wish to avoid the complexities of managing passwords with hashing algorithms, the ~/.netrc methodology can be considered. The methodology is used in SSH to automatically log into remote servers.

You must log in to answer this question.

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