Verbesserte Passwortsicherheit in Version 11g

04.
April
2011
Veröffentlicht von: Matthias Meyer

Haben Sie sich auch bereits gefragt, warum ab Version 11g die PASSWORD-Spalte in der View DBA_USERS leer ist und was es mit der Spalte PASSWORD_VERSIONS in selbiger View auf sich hat? Der folgende Beitrag fasst Ihnen das Wichtigste rund um die Passwortsicherheit in 11g zusammen.

Haben Sie sich auch bereits gefragt, warum ab Version 11g die PASSWORD-Spalte in der View DBA_USERS leer ist und was es mit der Spalte PASSWORD_VERSIONS in selbiger View auf sich hat? Der folgende Beitrag fasst Ihnen das Wichtigste rund um die Passwortsicherheit in 11g zusammen.

Grundlegende Sicherheitsmaßnahmen

Das Streben der Unternehmen nach verbesserten Sicherheitsmaßnahmen lässt sich ab Oracle Version 11g auch bei der Passwortverwaltung erkennen. Neben der Änderung des DEFAULT Benutzer-Profils (siehe <link blog-detailansicht das-wichtigste-rund-um-benutzer-profile.html external-link-new-window external link in new>Opens external link in new windowTipp des Monats Januar 2010) setzt Oracle nun auf einen verbesserten (stärkeren) Algorithmus bei der Passwortverschlüsselung. Der alte 64-bit DES (Data Encryption Standard) Algorithmus wurde durch den 160-bit Secure Hash Algorithmus (SHA-1) abgelöst. Darüber hinaus unterscheidet Oracle jetzt zwischen Groß- und Kleinschreibung bei den Passwörtern (was eigentlich lange überfällig war).

Case-sensitive Passwörter

Standardmäßig werden Passwörter ab Version 11g case-sensitiv angelegt. Dieses Verhalten kann über den dynamischen SPFILE-Parameter sec_case_sensitive_logon ein- oder ausgeschaltet werden.

Dazu ein Beispiel:

SHOW PARAMETER sec_case_sensitive_logon

NAME                                 TYPE        VALUE
------------------------------------ ----------- --------
sec_case_sensitive_logon             boolean     TRUE

CREATE USER test IDENTIFIED BY Test;
GRANT connect TO test;

connect test/Test
Connect durchgeführt.

connect test/test
ERROR:
ORA-01017: invalid username/password; logon denied

Jetz wird der Parameter auf FALSE gesetzt und das gleiche noch einmal getestet.

ALTER SYSTEM SET sec_case_sensitive_logon = FALSE;

connect test/Test
Connect durchgeführt.

connect test/test
Connect durchgeführt.

Setzt man den Parameter auf FALSE, ist das Passwort wieder case-insensitiv und damit spielt die Groß- und Kleinschreibung - wie in früheren Versionen - keine Rolle mehr.

Verschiedene Versionen des Passworts

Ganz so einfach, wie es das obige Beispiel vermuten lässt, hat es sich Oracle aber auch wieder nicht gemacht. Der Clou in 11g: es gibt verschiedene Versionen für die Passwörter. Die Version bestimmt den Sicherheitsstandard, also die Verschlüsselung des Passworts.

Dazu werfen wir einen Blick auf eine neue Spalte in der DBA_USERS View. Die Spalte PASSWORD_VERSIONS kann drei unterschiedliche Werte enthalten und legt damit die Kennwortmethode fest.

SELECT DISTINCT password_versions FROM DBA_USERS;

PASSWORD
--------
10G 11G
10G
11G

Der Wert "10G 11G" ist der Default und besagt, dass für das Passwort sowohl der alte wie auch der neue Hash-Wert abgelegt wurde. Über den Parameter sec_case_sensitve_logon wird eingestellt, welcher Hash-Wert überprüft wird.

Der Wert "10G" bezieht sich auf Benutzer, die aus früheren Oracle-Versionen migriert oder importiert wurden. Ihre Passwörter sind nicht case-sensitiv und für sie ist lediglich der alte Hash-Wert abgelegt worden. Ihr Passwort sollte möglichst bald neu gesetzt werden und damit dem neuen Standard angepasst werden. Hier wirkt sich eine Änderung des Parameters sec_case_sensitive_logon nicht auf die Anmeldung aus.

Der Wert "11G" kennzeichnet, dass nur der 160-bit Hash-Wert abgespeichert wurde und somit die exakte Schreibweise des Passworts erforderlich ist. Wird die Überprüfung durch sec_case_sensitive_logon=FALSE ausgeschaltet, kann sich dieser Benutzer gar nicht mehr anmelden.

Das folgende Beispiel soll das Ganze etwas anschaulicher machen. Dazu werden als Erstes noch zwei weitere Benutzer angelegt:

CREATE USER test10 IDENTIFIED BY Test10;
CREATE USER test11 IDENTIFIED BY Test11;
GRANT connect TO test10, test11;

Durch das Zuweisen des Passworts in der üblichen Form, werden beide Hash-Werte abgelegt. Die PASSWORD_VERSIONS Spalte enthält demnach den (Standard-)Wert "10G 11G".

Da aus Sicherheitsgründen der verschlüsselte Passwortstring in der View DBA_USERS nicht mehr angezeigt wird, ist ein Zugriff auf die Data Dictionary Tabelle SYS.USER$ erforderlich. Dazu werden besondere Berechtigungen benötigt, wie z.B. SELECT ANY DICTIONARY. In der Spalte PASSWORD wird der Hash-Wert des alten (DES-)Algorithmus angezeigt und in der Spalte SPARE4 der Hash-Wert der neuen (SHA-)Verschlüsselung:

SELECT v1.username, v1.password_versions, v2.password, v2.spare4
  FROM dba_users v1, sys.user$ v2
 WHERE v1.user_id = v2.user#
   AND v1.username like 'TEST%';

USERNAME PASSWORD PASSWORD        
-------- -------- ----------------
SPARE4
--------------------------------------------------------------
TEST     10G 11G  7A0F2B316C212D67 S:DA5FB2FE519E66A417BE527E869477D07F79A53D9F4EE5AFA9248682A552
TEST10   10G 11G  9CA4F097EAAF50A2 S:AA9DE26615A402F90BF26C1677987401350FE2F20803BFC4BD29BA15A61E
TEST11   10G 11G  D566130C13944F70 S:FE891E945105E9F8B1DB098717A065ACB03AEF066DD0CE43E79D6DCCF442

Die Passwörter der Benutzer TEST10 und TEST11 werden nun durch die Angabe der unterschiedlichen Hash-Werte neu gesetzt:

ALTER USER test10 IDENTIFIED BY VALUES '9CA4F097EAAF50A2';
ALTER USER test11 IDENTIFIED BY VALUES 'S:FE891E945105E9F8B1DB098717A065ACB03AEF066DD0CE43E79D6DCCF442';

Die Wiederholung der obigen Abfrage ergibt dann folgende Ausgabe:

SELECT v1.username, v1.password_versions, v2.password, v2.spare4
  FROM dba_users v1, sys.user$ v2
 WHERE v1.user_id = v2.user#
   AND v1.username like 'TEST%';
 
USERNAME PASSWORD PASSWORD        
-------- -------- ----------------
SPARE4
--------------------------------------------------------------
TEST     10G 11G  7A0F2B316C212D67 S:DA5FB2FE519E66A417BE527E869477D07F79A53D9F4EE5AFA9248682A552
TEST10   10G      9CA4F097EAAF50A2
TEST11   11G                       S:FE891E945105E9F8B1DB098717A065ACB03AEF066DD0CE43E79D6DCCF442

Hier lassen sich die verschiedenen Passwortversionen deutlich erkennen. Für den Benutzer TEST sind beide Hash-Werte vorhanden und somit beide Kennwortmethoden möglich, für die beiden anderen Benutzer besteht jeweils nur ein Hash-Wert zur Authentifizierung.

Bleibt noch die Überprüfung der Anmeldemöglichkeiten in Abhängigkeit des Parameters sec_case_sensitive_logon:

-- Variante 1: case-sensitive Methode (entspricht dem Standard)
ALTER SYSTEM SET sec_case_sensitive_logon = TRUE;

-- Benutzer TEST
connect test/Test
Connect durchgeführt.

connect test/test
ERROR:
ORA-01017: invalid username/password; logon denied

-- Benutzer TEST10
connect test10/Test10
Connect durchgeführt.

connect test10/test10
Connect durchgeführt.

-- Benutzer TEST11
connect test11/Test11
Connect durchgeführt.

connect test11/test11
ERROR:
ORA-01017: invalid username/password; logon denied

-- Variante 2: case-insensitive Methode
ALTER SYSTEM SET sec_case_sensitive_logon = FALSE;

-- Benutzer TEST
connect test/Test
Connect durchgeführt.

connect test/test
Connect durchgeführt.

-- Benutzer TEST10
connect test10/Test10
Connect durchgeführt.

connect test10/test10
Connect durchgeführt.

-- Benutzer TEST11
connect test11/Test11
ERROR:
ORA-01017: invalid username/password; logon denied

connect test11/test11
ERROR:
ORA-01017: invalid username/password; logon denied

Sie sehen, der Benutzer TEST11 kann sich überhaupt nicht mehr anmelden und für die beiden anderen Benutzer wird die alte Passwortversion verwendet.

Tipps zur Passwortverwaltung in Version 11g

Kontrollieren Sie nach einem Schema- oder Full Import aus älteren Oracle Versionen in Version 11g die PASSWORD_VERSIONS Spalte der View DBA_USERS. Ist der Wert "10G" zu finden, sollte das Passwort für den entsprechenden Benutzer neu gesetzt werden. Der einzige Grund, warum für ausgewählte Benutzer die alte Passwortversion verwendet werden sollte, liegt in möglichen Kompatibilitätsproblemen mit älteren Applikationen.

Da Passwörter bis Version 10g immer in Großbuchstaben abgelegt worden sind, kann es bei der Benutzung von Database Links zu einer Datenbank Version 11g zu Problemen kommen. Eventuell ist hier die Neuanlage des Passworts in Großbuchstaben in der Zieldatenbank erforderlich.

Die Berücksichtigung der Groß- und Kleinschreibung bei Passwörtern gilt auch für die remote Anmeldung als SYSDBA oder SYSOPER. Hier erfolgt die Authentifizierung über die Passwortdatei. Auch das kann durch die Neuerzeugung der Passwortdatei und der Angabe des Parameters IGNORECASE=y deaktiviert werden.

Überprüfen Sie Ihre Datenbank regelmäßig auf geöffnete Accounts mit Standardpasswörtern. Dazu gibt es die neue View DBA_USERS_WITH_DEFPWD. Die folgende Abfrage liefert Ihnen alle problematischen Accounts zurück:

SELECT * FROM dba_users_with_defpwd
 WHERE username IN (SELECT username FROM dba_users
                     WHERE account_status = 'OPEN');

Weitere Tipps und Informationen zu Security-Features von Oracle erhalten Sie in unseren Opens internal link in current windowNeuerungen 11g oder Security-Kursen.

DBA Security

Jede Menge Know-how für Sie!

In unserer Know-How Datenbank finden Sie mehr als 300 ausführliche Beiträge zu den Oracle-Themen wie DBA, SQL, PL/SQL, APEX und vielem mehr.
Hier erhalten Sie Antworten auf Ihre Fragen.