News zu Oracle

Mehr Passwortsicherheit mit wenig Aufwand

Dass für Datenbankpasswörter ab Oracle Version 11g in Groß-/Kleinschreibung unter­schieden wird, dürfte mittler­weile hinlänglich bekannt sein. Dass sich allein dadurch aller­dings 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.

Einleitung

Die Verwendung case-sensi­tiver Passwörter erhöht den Suchraum für eine Attacke auf Passworthashes erheblich – soweit zur Theorie. Die Oracle Datenbank speichert aller­dings per Default und bis hinein in die aktuelle Version zusätzlich zu den sicheren Hashes auch weiterhin den Hash der case-insen­si­tiven 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 ermit­telbar, insbe­sondere bei zu weitrei­chend verge­benen Privilegien. Der Rest ist mit durch­schnitt­licher Rechenleistung (und wahlweise einem Dictionary) schnell erledigt. 

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

Welche Clientversionen unter­stützt werden und welche Passwortversionen dabei zum Einsatz kommen, ergibt sich aus einem Zusammenspiel von gestat­teten Authentisierungsprotokollen und in der Oracle Datenbank abgespei­cherten Passwortversionen. Nur wenn beides zuein­ander passt, ist eine erfolg­reiche Anmeldung an der Datenbank möglich.

Authentisierungsprotokolle

Die zuläs­sigen Authentisierungsprotokolle werden über den SQL*Net-Parameter

  • SQLNET.ALLOWED_LOGON_VERSION (bis 11gR2)

    bezie­hungs­weise

  • SQLNET.ALLOWED_LOGON_VERSION_SERVER (ab 12c)

konfi­gu­riert. 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 behan­delten 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 unter­stützten Clientversionen und ist in der Oracle Database Net Services Reference ausführ­licher 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_SERVER
Passwort Version 10g
Passwort Version 11g
Passwort Version 12c
8, 9, 10 oder 11 
12 
12a 

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 unter­stützt. Oder für ältere Clients, die mit Critical Patch Update October 2012 oder einem aktuel­leren 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äs­sigen 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 betrof­fenen Account zum Tragen. Das Anheben der Authentisierungsprotokollversion ist also nur in Verbindung mit der Neuvergabe aller Passworte (in einer neu gestar­teten Session!) wirklich sinnvoll.

DBA_USERS. PASSWORD_VERSIONS

Welche Passwortversionen letzt­endlich 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 abgespei­chert (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-sensi­tiver Passworte und dem Einsatz sicherer Hashes ab Oracle Database 11g gestiegen. Diese Verbesserungen kommen aber nur dann signi­fikant zum Tragen, wenn die

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

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

Hier findest du weitere Posts zu den Themen Security bzw. weitere DBA Tipps rund um Datenbanken aus unserem Insights & Updates Bereich.

icon-arrow_right_medium-violet-blue.svg

Share this article

Facebook 
Twitter 
LinkedIn 
XING 
WhatsApp 
Email