0% found this document useful (0 votes)
22 views

PostgreSQL Client Authentication (slides)

Uploaded by

bupbechanh
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
22 views

PostgreSQL Client Authentication (slides)

Uploaded by

bupbechanh
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 39

Beyond Trust

PostgreSQL Client Authentication

Christoph Mönch-Tegeder

2ndQuadrant
http://www.2ndquadrant.com/

2017-02-05
Part I

Authentication
Why Authentication?

I Too complicated
I Nobody knows my database
I Nobody will attack us
Rich Data

https://blog.malwarebytes.com/cybercrime/2016/04/comelec- breach- data- released- online- fully- searchable/


Rich Data (2)

https://www.theregister.co.uk/2016/04/25/mexico_voter_data_breach/
Racketeering

https://krebsonsecurity.com/2017/01/extortionists- wipe- thousands- of- databases- victims- who- pay- up- get- stiffed/
Racketeering (2)

https://www.theregister.co.uk/2017/01/09/mongodb/
It’s not only that database

https://www.bleepingcomputer.com/news/security/mongodb- hijackers- move- on- to- elasticsearch- servers/


Why Authentication?

I Not the Open Data we wanted!


I Not the kind of support we want to pay!
Why Authentication?

I Not the Open Data we wanted!


I Not the kind of support we want to pay!
I Regulations
I Nobody wants to explain these incidents
You cannot hide

I https://www.shodan.io
I https://www.zoomeye.org
So. . . Secure Your Database!

I Network Security and Firewalls


I keep unauthorized users out
I PostgreSQL listens on localhost only by default
I Fine Grained Access Control
I do not run your app as postgres
I Secure your application
I Authenticate legitimate users
Some Definitions

I Identification declaration of identity


I ”I am user42”
I Authentication proof of identity
I what (only) you know, have, are
I Authorization allows actions on objects
I GRANT SELECT ON tbl TO user42, RLS, . . .
I Audit Log who did what and when
I log_connections, pgaudit
Secret Handling

I Shared Keys, Asymmetric Secrets


I hardcoded, configuration files, . . .
I How to change secrets?
I Do not put secrets on Github!
I To Backup or Not To Backup?
I how to guard backups? how to restore secrets?
I Hardware Security Module (HSM)
I what if lost/destroyed?
Authentication Security

I Passive Attacks
I sniffing authentication info off the net
I and all other traffic
I Active Attacks
I Man in the Middle (MitM)
I may modify traffic
I There is no safe authentication unless you authenticate whom
you’re authenticating against first. (Martin Seeger)
PostgreSQL Authentication

I Highly configurable, well documented


I Flexible: up to 13 methods
I Per database, user, source and connection type
I pg_hba.conf, Host Based Authentication
I checked from top to first match
I Document your configuration, check if it still matches reality
I Users always have to exist in PostgreSQL
I only authentication can be handled externally
Host Based Authentication Configuration

# IPv4 local connections:


host all all 127.0.0.1/32 md5

I type of connection
I local on unix-like platforms only
I database (all, @file, replication, sameuser, samerole)
I user (all, +group, @file)
I non-local: source network
I authentication method and options
Identification mapping

I pg_ident.conf allows mapping of external usernames to


PostgreSQL usernames
I mappings selected by map parameter in pg_hba.conf
I regular expression support

# MAPNAME SYSTEM-USERNAME PG-USERNAME


sslmap "Test User" ssluser
krbmap /^([^@]+)@MY.KRB5.REALM \1
Part II

Authentication Mechanisms
Trust - there is none

I no authentication - just identification


I do not use on servers
I for testing, some embedded systems
I sometimes used in initial pg_hba.conf
Ident - ask remote

I contact source host, ask for local user name


I uses Identification Protocol (RFC1413) - less common today
I additional TCP connection
I relies on security of source host

The Identification Protocol is not intended as an


authorization or access control protocol.
RFC1413 https: // www. rfc- editor. org/ rfc/ rfc1413. txt
Peer - Unix Credentials

I on local connections only


I get system user name from unix socket
I great for local administration
I as secure as the host OS
I limited use - no remote support, inflexible
Reject - Blacklisting

I explicitly reject access


I reject one, allow all
I temporary block during maintenance
I non-authentication method
Password - clear as text

I password authentication
I hashes stored in PostgreSQL – pg_authid
I sends password in clear
I do not use
I use md5 instead
MD5 - hashed password

I password authentication reloaded


I hashes stored in PostgreSQL – pg_authid
I on the wire:
’md5’ + md5(md5(password + username) + salt)
I replay: 50% chance after 2 billion connections (4 byte salt)
I MD5 hash considered broken – regulatory problems
I does not authenticate server
LDAP - Lightweight Directory Access Protocol

I authenticates against LDAP backend (not included)


I simple mode: use credentials to bind (authenticate) to the
LDAP server
I search+bind mode: bind to LDAP server and search for user
with given credentials
I can use TLS connection to the LDAP server
I STARTTLS only (as per RFC 5413) - no LDAP over SSL
I some servers do not support STARTTLS
I cleartext password, does not authenticate server
I TLS for PostgreSQL connection recommended
PAM – Pluggable Authentication Modules

I modules (plugins) handle authentication (and more)


I configuration in /etc/pam.d/ or similar
I cannot access /etc/shadow (when running in PostgreSQL)
I can be used to lock out clients or accounts after failed logins
I cleartext password, does not authenticate server
I TLS for PostgreSQL connection recommended
GSS - Generic Security Services API

I uses KerberosV (Kerberos infrastructure not included)


I realm, principal, ticket, TGT
I client authenticates Key Distribution Center (KDC)
I Service Server PostgreSQL must be known to KDC
I requires accurate time across all systems
I periodic ticket renewal
I no clear text passwords on the network, all entities
authenticated
GSS (2)

I KDC password store: local databases, LDAP, . . .


I Client-KDC authentication: password (most common),
PKINIT (public key), . . .
I keytab files for non-interactive processes: stored secrets
I mapping of Kerberos principals to PostgreSQL users

# MAPNAME SYSTEM-USERNAME PG-USERNAME


krbmap /^([^@]+)@MY.KRB5.REALM \1
GSS (3)

I Simple configuration on the PostgreSQL side


I postgresql.conf

krb_server_keyfile = ’krb5.keytab’

I pg_hba.conf

host all all 10.0.1.0/24 gss krb_realm=MY.KRB5.REALM

I DSN: krbsrvname=postgres
Cert - TLS Client Certificate

I only for TLS connections (hostssl)


I as the client verifies the server’s certificate, the server verifies
the client’s certificate
I requires: PKI (not included)
I possible to create and sign certificates by hand
I for more than a few hosts, use real CA software
Cert (2)

I minimal server configuration

ssl = on
ssl_cert_file = ’server_cert.pem’
ssl_key_file = ’server_cert.key’
ssl_ca_file = ’user_ca.pem’

I recommended: do not re-use server CA for user certificates


I does not require external CA for users
I DSN: sslcert=cert.pem sslkey=cert.key
Cert (3)

I private keys are stored secrets


I client certificates expire: can be changed on the fly
I server certificates and CAs expire: change needs restart
I disable client certificate: Certificate Revocation List (CRL)
I ssl_crl_file
I requires restart in PostgreSQL < 10
I map certificate Common Name (CN) to PostgreSQL user

# MAPNAME SYSTEM-USERNAME PG-USERNAME


sslmap "Test User" ssluser
Other Mechanisms

I radius Remote Authentication Dial-In User Service


I RADIUS uncommon, except for telco environments
I sspi Security Support Provider Interface
I Windows Single Sign On, Kerberos with NTLM fallback
I bsdauth OpenBSD authentication framework
I OpenBSD only, ideas like PAM
Part III

Considerations
Some Notes on TLS

I default cipher list too broad, set ssl_ciphers


I generate your own DH-parameters
I recent PostgreSQL supports ECC (ECDSA)
I new connections are expensive
I not that much overhead once connection is up
Connection Pooling

I Clients authenticate to pooler


I Pooler authenticates to PostgreSQL
I Forwarding of authentication with plaintext password only
I Terminates TLS
Summary

I Secure your databases


I Authenticate clients (and servers)
I At least, use passwords
I Encrypt connections (use TLS)
I Always verify certificates
Questions?

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy