News zu Oracle
Dass für Datenbankpasswörter ab Oracle Version 11g in 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 Oracle 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.
Die Verwendung case-sensitiver Passwörter erhöht den Suchraum für eine Attacke auf Passworthashes erheblich – soweit zur Theorie. Die Oracle Datenbank speichert allerdings per Default und bis hinein in die aktuelle Version 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 Passwortversionen dabei zum Einsatz kommen, ergibt sich aus einem Zusammenspiel von gestatteten Authentisierungsprotokollen und in der Oracle Datenbank abgespeicherten Passwortversionen. Nur wenn beides zueinander passt, ist eine erfolgreiche Anmeldung an der Datenbank möglich.
Die zulässigen Authentisierungsprotokolle werden über den SQL*Net-Parameter
beziehungsweise
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
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).
Abhängig von der in der sqlnet.ora des Servers gesetzten Authentisierungsprotokollversion werden bei Vergabe eines Passwortes folgende Passwortversionen angelegt
ALLOWED_LOGON_VERSION_SERVER | Passwort Version 10g | Passwort Version 11g | Passwort Version 12c |
|---|---|---|---|
8, 9, 10 oder 11 |
X |
X |
X |
12 |
X |
X | |
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.
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’):
Ä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
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
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.
Share this article