News
DBA-Tipp: Mehr Passwortsicherheit mit wenig Aufwand

Die Information ist ein schnelllebiges Gut. Jeden Tag werden wir mit hunderten Informationen zugemüllt. Deshalb sind wir bestrebt uns auf das Wesentliche zu konzentrieren und nur substantiell nachhaltige Informationen bereitzustellen.

Icon Unternehmen

Dass für Datenbankpassworte ab Version 11g Groß-/Kleinschreibung unterschieden wird, dürfte mittlerweile hinlänglich bekannt sein. Dass sich allein dadurch allerdings die Passwortsicherheit nur marginal verbessert hat, eher weniger. Der heutige DBA-Tipp erklärt, warum auch seit 11g das Passwort ohne weiteres Zutun nicht wesentlich sicherer ist und was man tun kann, um tatsächlich von den neuen, besseren Hashalgorithmen zu profitieren.

Einleitung

Die Verwendung case-sensitiver Passworte erhöht zwar den Suchraum für eine Attacke auf Passworthashes theoretisch erheblich. Die Oracle Datenbank speichert allerdings per Default und bis hinein in die aktuelle Version 12.1.0.2 zusätzlich zu den sicheren Hashes auch weiterhin den Hash der case-insensitiven 10g-Variante des Passwortes ab und macht den Vorteil damit eigentlich wieder zunichte. Hintergedanke dabei ist, dass die Kompatibilität mit älteren Clients und somit älteren Authentisierungsprotokollen und Hashalgorithmen gewahrt bleiben soll. Da die alten Passworthashes sehr simpel aufgebaut sind (Passwort, Username als SALT), sind sie ein sehr beliebtes Angriffsziel für Passwortattacken. Username (user$.name) und Passworthash (user$.password) sind relativ einfach aus der Datenbank ermittelbar, insbesondere bei zu weitreichend vergebenen Privilegien. Der Rest ist mit durchschnittlicher Rechenleistung (und wahlweise einem Dictionary) schnell erledigt. 

In den meisten Fällen ist diese von Oracle hier angebotene Abwärtskompatibilität jedoch gar nicht erforderlich. Clientinstallationen können und sollten (spätestens) im Zuge eines Oracle-Updates ohnehin durch aktuelle Software ersetzt werden.

Welche Clientversionen unterstützt werden und welche Passwordversionen dabei zum Einsatz kommen, ergibt sich aus einem Zusammenspiel von gestatteten Authentisierungsprotokollen und in der Oracle Datenbank abgespeicherten Passwordversionen. Nur wenn beides zueinander passt, ist eine erfolgreiche Anmeldung an der Datenbank möglich.

Authentisierungsprotokolle

Die zulässigen Authentisierungsprotokolle werden über den SQL*Net-Parameter

  • SQLNET.ALLOWED_LOGON_VERSION (bis 11gR2) 

    beziehungsweise
     
  • SQLNET.ALLOWED_LOGON_VERSION_SERVER (ab 12c)

konfiguriert. Sie können auf 8 (default bis 11gR2), 9, 10, 11 (default in 12c), 12 und 12a (nur in 12.1.0.2 verfügbar) gesetzt werden, wobei hinsichtlich der hier behandelten Speicherung der Passwortversionen in der Datenbank nur die Unterscheidung in

  • 8-11, 
  • 12 und 
  • 12a 

praktische Relevanz besitzt. Die feinere Abstufung hat dann nur noch Auswirkungen auf die unterstützten Clientversionen und ist in der Oracle Database Net Services Reference ausführlicher beschrieben (https://docs.oracle.com/database/121/NETRF/sqlnet.htm#NETRF2016). 

Passwortversionen

Abhängig von der in der sqlnet.ora des Servers gesetzten Authentisierungsprotokollversion werden bei Vergabe eines Passwortes folgende Passwortversionen angelegt

ALLOWED_LOGON_VERSION_SERVERPasswordversion 10gPasswordversion 11gPasswordversion 12c
8, 9, 10 oder 11XXX
12 XX
12a  X

Wie der Tabelle zu entnehmen ist, sind also alle Authentisierungsprotokollversionen kleiner als 12 zu vermeiden. Andernfalls werden, neben den besseren 11g- und 12c-Passwordversionen auch die simpler angreifbare 10g-Variante in der Oracle Datenbank abgelegt. Die empfohlene Authentisierungsprotokollversion ist 12 und wird für alle Clients ab Version 11.2.0.3 unterstützt. Oder für ältere Clients, die mit Critical Patch Update October 2012 oder einem aktuelleren CPU/PSU gepatcht wurden. Protokollversion 12a ist zwar die sicherste, schränkt jedoch die Clients auf Version 12.1.0.2 oder höher ein und könnte daher Probleme mit Anwendungszertifizierungen nach sich ziehen.

Das Ändern der  zulässigen Authentisierungsprotokolle in der sqlnet.ora erfordert keinen Neustart von Serverkomponenten. Allerdings kommt sie erst bei Neuvergabe eines Passwortes und dann natürlich auch nur für den betroffenen Account zum Tragen. Das Anheben der Authentisierungsprotokollversion ist also nur in Verbindung mit der Neuvergabe aller Passworte (in einer neu gestarteten Session!) wirklich sinnvoll.

DBA_USERS. PASSWORD_VERSIONS

Welche Passwortversionen letztendlich für die einzelnen Accounts tatsächlich in der Oracle Datenbank vorliegen, kann in der Spalte PASSWORD_VERSIONS der View DBA_USERS überprüft werden. Idealerweise sollten hier keine Accounts auftauchen, in denen noch „10G“ gelistet ist.

Beispiel

In der sqlnet.ora eines 12c-Servers wird

SQLNET.ALLOWED_LOGON_VERSION_SERVER=11 

gesetzt und ein Account neu angelegt:

$ echo 'SQLNET.ALLOWED_LOGON_VERSION_SERVER=11' >$OH/network/admin/sqlnet.ora

SQL> create user foo identified by bar;

User created.

SQL> select dba_users.PASSWORD_VERSIONS, user$.PASSWORD, user$.SPARE4 from dba_users, user$ where username=name and name='FOO'

PASSWORD_VERSIONS
--------------------
PASSWORD
---------------------------------------------------------------------
SPARE4
---------------------------------------------------------------------
10G 11G 12C
707156934A6318D4
S:CD62E86C632E9C16083796C1DD1E6930BADFD3856D34A9C4132CA7F7195
2;H:0D24086E9AB9A4C77292577B1416838F;T:D681B8FA82F2FF2D5A7B09
BA1C27BC8024E5708F56E9307F714F2A4D02F7B248D1B57949FBE3A2A1E6E
960F0E23AF585620E95EE97D3A2390CDCABD78BEF4EA8B982295DCE94CDC6
565FC269CCAD0368

Mit  Authentisierungsprotokollversion 11 (oder kleiner) werden in einer 12c-Datenbank also alle drei Passwortversionen abgespeichert (dba_users.PASSWORD_VERSIONS='10G 11G 12C'):

  • die 10g-Passwortversion in user$.PASSWORD (Wert: 707156934A6318D4)
  • die 11g-Passwortversion in user$.SPARE4 (Wert: S:CD6...952) und 
  • die 12c-Passwortversion in user$.SPARE4 (Wert: H:0D2...38F;T:D681...368)

Ändern wir SQLNET.ALLOWED_LOGON_VERSION_SERVER in der sqlnet.ora des Servers auf den Wert 12 und setzen das Passwort des users „foo“ neu, ist die 10g-Passwortversion nicht mehr zu finden (dba_users.PASSWORD_VERSIONS='11G 12C', user$.PASSWORD is NULL):

$ echo 'SQLNET.ALLOWED_LOGON_VERSION_SERVER=12' >$OH/network/admin/sqlnet.ora

SQL> alter user foo identified by bar ;

User altered.

SQL> select dba_users.PASSWORD_VERSIONS, user$.PASSWORD, user$.SPARE4 from dba_users, user$ where username=name and name='FOO';

PASSWORD_VERSIONS
--------------------
PASSWORD
---------------------------------------------------------------------
SPARE4
---------------------------------------------------------------------
11G 12C
S:C0BE960A205C6E246AC55EAA4B58D1387E735788609647871F46B2A6D72
F;H:0D24086E9AB9A4C77292577B1416838F;T:82C1928C0C0113CF1F6399
94FBDA542601889348B42FBD8E895D9533BABE1B5EC35AA435DF9D0279A16
124536283579F69DC7ED5A4B42A9B8D4438630CFCD3E9F31AE96E2E93FEBD
9F06673C60B1EF78

Fazit

Grundsätzlich ist die Passwortsicherheit mit Einführung case-sensitiver Passworte und dem Einsatz sicherer Hashes ab Oracle Database 11g gestiegen. Diese Verbesserungen kommen aber nur dann signifikant zum Tragen, wenn 

  • die Clientinstallationen im Unternehmen auf einen modernen Stand angehoben,
  • die Nutzung alter Clients unterbunden und 
  • die alten, unsicheren Hashes aus der Datenbank entfernt werden.

Dabei können die beiden letztgenannten Punkte durch simples Anpassen der sqlnet.ora und Neuvergabe der Datenbankpassworte mit überschaubarem Aufwand umgesetzt werden. Der Gegenwert ist eine Datenbank, die gegen dictionary-basierte- oder brute-force-Passwortattacken besser geschützt ist.