<para>
    <literal>trust</literal> authentication is only suitable for TCP/IP connections
    if you trust every user on every machine that is allowed to connect
    to the server by the <filename>pg_hba.conf</filename> lines that specify
    <literal>trust</literal>.  It is seldom reasonable to use <literal>trust</literal>
    for any TCP/IP connections other than those from <systemitem>localhost</systemitem> (127.0.0.1).
   </para>

  </sect1>

  <sect1 id="auth-password">
   <title>Password Authentication</title>

   <indexterm>
    <primary>MD5</primary>
   </indexterm>
   <indexterm>
    <primary>SCRAM</primary>
   </indexterm>
   <indexterm>
    <primary>password</primary>
    <secondary>authentication</secondary>
   </indexterm>

   <para>
    There are several password-based authentication methods.  These methods
    operate similarly but differ in how the users' passwords are stored on the
    server and how the password provided by a client is sent across the
    connection.
   </para>

   <variablelist>
    <varlistentry>
     <term><literal>scram-sha-256</literal></term>
     <listitem>
      <para>
       The method <literal>scram-sha-256</literal> performs SCRAM-SHA-256
       authentication, as described in
       <ulink url="https://datatracker.ietf.org/doc/html/rfc7677">RFC 7677</ulink>.  It
       is a challenge-response scheme that prevents password sniffing on
       untrusted connections and supports storing passwords on the server in a
       cryptographically hashed form that is thought to be secure.
      </para>

      <para>
       This is the most secure of the currently provided methods, but it is
       not supported by older client libraries.
      </para>
     </listitem>
    </varlistentry>

    <varlistentry>
     <term><literal>md5</literal></term>
     <listitem>
      <para>
       The method <literal>md5</literal> uses a custom less secure challenge-response
       mechanism.  It prevents password sniffing and avoids storing passwords
       on the server in plain text but provides no protection if an attacker
       manages to steal the password hash from the server.  Also, the MD5 hash
       algorithm is nowadays no longer considered secure against determined
       attacks.
      </para>

      <para>
       To ease transition from the <literal>md5</literal> method to the newer
       SCRAM method, if <literal>md5</literal> is specified as a method
       in <filename>pg_hba.conf</filename> but the user's password on the
       server is encrypted for SCRAM (see below), then SCRAM-based
       authentication will automatically be chosen instead.
      </para>

      <warning>
       <para>
        Support for MD5-encrypted passwords is deprecated and will be removed
        in a future release of <productname>PostgreSQL</productname>.  Refer to
        the text below for details about migrating to another password type.
       </para>
      </warning>
     </listitem>
    </varlistentry>

    <varlistentry>
     <term><literal>password</literal></term>
     <listitem>
      <para>
       The method <literal>password</literal> sends the password in clear-text and is
       therefore vulnerable to password <quote>sniffing</quote> attacks. It should
       always be avoided if possible. If the connection is protected by SSL
       encryption then <literal>password</literal> can be used safely, though.
       (Though SSL certificate authentication might be a better choice if one
       is depending on using SSL).
      </para>
     </listitem>
    </varlistentry>
   </variablelist>

   <para>
    <productname>PostgreSQL</productname> database passwords are
    separate from operating system user passwords. The password for
    each database user is stored in the <literal>pg_authid</literal> system
    catalog. Passwords can be managed with the SQL commands
    <xref linkend="sql-createrole"/> and
    <xref linkend="sql-alterrole"/>,
    e.g., <userinput>CREATE ROLE foo WITH LOGIN PASSWORD