Connections and Authentication / Authentication

authentication_timeout

• What it does: Sets the maximum time allowed for a client to complete the authentication process after establishing a connection.
• Why it matters: This parameter is crucial for preventing resource exhaustion attacks where malicious clients establish connections but never complete authentication. A properly set timeout ensures that hung authentication attempts don't consume valuable connection slots and system resources, while still allowing legitimate clients sufficient time to complete complex authentication procedures.
• Ideal value & Best Practice: Default 1min is reasonable for most environments. For high-latency networks or complex authentication setups (like Kerberos in large enterprises), consider increasing to 2min. Never set this higher than 5min to maintain security against connection exhaustion attacks.

gss_accept_delegation

• What it does: Controls whether PostgreSQL will accept credential delegation when using GSSAPI authentication.
• Why it matters: Credential delegation allows the database server to act on behalf of the client when accessing other services. This is powerful for integrated authentication scenarios but introduces security considerations as it extends the server's privileges using client credentials.
• Ideal value & Best Practice: Default off is recommended for most environments. Enable this only in controlled enterprise environments where you fully trust the infrastructure and have a specific need for credential delegation. Always ensure proper security measures are in place when enabling delegation.

krb_caseins_users

• What it does: Determines whether Kerberos and GSSAPI user names are treated as case-insensitive.
• Why it matters: This setting affects how usernames are matched between Kerberos principals and PostgreSQL users. Case sensitivity can cause authentication failures if there's inconsistency between how usernames are formatted in different systems. Enabling case-insensitive matching can improve interoperability but may have security implications in strictly controlled environments.
• Ideal value & Best Practice: Default off (case-sensitive) is recommended for security-conscious environments. Set to on only if you experience authentication issues due to case mismatches and you're confident this doesn't create security vulnerabilities in your specific setup.

krb_server_keyfile

• What it does: Specifies the location of the Kerberos server key file (keytab) that PostgreSQL uses for Kerberos authentication.
• Why it matters: The keytab file contains the service principals and keys that allow PostgreSQL to authenticate Kerberos clients. Proper configuration is essential for Kerberos authentication to work correctly. The file must be securely stored and accessible only to the PostgreSQL server process.
• Ideal value & Best Practice: Typically set to FILE:/etc/postgresql/krb5.keytab or similar path. Ensure the file has strict permissions (usually 600) and is owned by the PostgreSQL user. Regularly rotate keytab files according to your organization's security policies.

password_encryption

• What it does: Determines the encryption algorithm used for hashing passwords when creating or altering user passwords.
• Why it matters: This parameter directly impacts password security. Stronger encryption methods provide better protection against password cracking attempts. PostgreSQL supports multiple algorithms with different security characteristics, and choosing the right one is crucial for maintaining a secure authentication system.
• Ideal value & Best Practice: Set to scram-sha-256 for maximum security. This is the strongest available method and protects against various attacks. Avoid older methods like md5 unless required for backward compatibility with very old clients. Remember that this setting only affects new passwords; existing passwords remain encrypted with their original method.

scram_iterations

• What it does: Sets the number of iterations used in the SCRAM-SHA-256 password hashing algorithm.
• Why it matters: The iteration count determines how computationally expensive the password hashing process is, which directly affects resistance against brute-force attacks. Higher values provide better security but require more CPU resources during authentication. This parameter allows you to balance security needs with performance requirements.
• Ideal value & Best Practice: Default 4096 provides a good balance for most applications. For high-security environments, consider increasing to 10000 or higher. For systems with very high authentication rates, you might need to lower this value, but never go below 4096. Monitor authentication performance after changing this value.

---

Try pghealth Free Today 🚀

Configuring authentication parameters correctly is essential for database security and access control.

With pghealth, you can:

• Audit your current authentication settings against security best practices
• Identify potential security vulnerabilities in your authentication configuration
• Get tailored recommendations for your specific security requirements
• Monitor authentication attempts and detect suspicious patterns

Start securing your PostgreSQL authentication today with our free trial — no installation or commitment required.

👉 Start Free Trial Now