<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 'secret'</userinput>,
    or the <application>psql</application>
    command <literal>\password</literal>.
    If no password has been set up for a user, the stored password
    is null and password authentication will always fail for that user.
   </para>

   <para>
    The availability of the different password-based authentication methods
    depends on how a user's password on the server is encrypted (or hashed,
    more accurately).  This is controlled by the configuration
    parameter <xref linkend="guc-password-encryption"/> at the time the
    password is set.  If a password was encrypted using
    the <literal>scram-sha-256</literal> setting, then it can be used for the
    authentication methods <literal>scram-sha-256</literal>
    and <literal>password</literal> (but password transmission will be in
    plain text in the latter case).  The authentication method
    specification <literal>md5</literal> will automatically switch to using
    the <literal>scram-sha-256</literal> method in this case, as explained
    above, so it will also work.  If a password was encrypted using
    the <literal>md5</literal> setting, then it can be used only for
    the <literal>md5</literal> and <literal>password</literal> authentication
    method specifications (again, with the password transmitted in plain text
    in the latter case).  (Previous PostgreSQL releases supported storing the
    password on the server in plain text.  This is no longer possible.)  To
    check the currently stored password hashes, see the system
    catalog <literal>pg_authid</literal>.
   </para>

   <para>
    To upgrade an existing installation from <literal>md5</literal>
    to <literal>scram-sha-256</literal>, after having ensured that all client
    libraries in use are new enough to support SCRAM,
    set <literal>password_encryption = 'scram-sha-256'</literal>
    in <filename>postgresql.conf</filename>, make all users set new passwords,
    and change the authentication method specifications
    in <filename>pg_hba.conf</filename> to <literal>scram-sha-256</literal>.
   </para>
  </sect1>

  <sect1 id="gssapi-auth">
   <title>GSSAPI Authentication</title>

   <indexterm zone="gssapi-auth">
    <primary>GSSAPI</primary>
   </indexterm>

   <para>
    <productname>GSSAPI</productname> is an industry-standard protocol
    for secure authentication defined in
    <ulink url="https://datatracker.ietf.org/doc/html/rfc2743">RFC 2743</ulink>.
    <productname>PostgreSQL</productname>
    supports <productname>GSSAPI</productname> for authentication,
    communications encryption, or both.
    <productname>GSSAPI</productname> provides automatic authentication
    (single sign-on) for systems that support it. The authentication itself is
    secure.  If <productname>GSSAPI</productname> encryption
    or <acronym>SSL</acronym> encryption is
    used, the data sent along the database connection will be encrypted;
    otherwise, it will not.
   </para>

   <para>