Password Security Oracle Datenbank 11g
Meldung vom 29.07.2011
Die Version 11 der Oracle Datenbank wartet mit einer wesentlichen Neuerung in der Verwendung von Passworten auf. Es wird ab dieser Version standardmäßig zwischen Groß- und Kleinschreibung unterschieden. In der Praxis sind dabei einige Dinge zu beachten. Die Unterscheidung gilt nur für Passworte, die unter 11g vergeben wurden. Für Passworte von Benutzern, die aus einer 10g oder früher auf 11g migriert wurden, wird nach wie vor nicht nach Schreibweise unterschieden. Erst wenn das Passwort innerhalb der 11g geändert wurde, gilt die neue Einschränkung.
Ob das Passwort eines Benutzers noch aus einer 10g oder früher stammt oder unter 11g gesetzt oder geändert wurde, lässt sich übrigens anhand der Spalte PASSWORD_VERSIONS der View DBA_USERS überprüfen. Für Benutzer, die in dieser Spalte ausschließlich den Wert "10g" stehen haben, gilt noch die alte, nicht case-sensitive Passwortprüfung.
Verwenden Sie Database Links zwischen Datenbanken vor 11g und migrieren nur eine der beiden Datenbanken auf 11g, ist bei der zukünftigen Passwortvergabe folgendes zu beachten:
- Link von <11g zu 11g: Das Passwort des 11g Users darf Buchstaben nur großgeschrieben verwenden, da Datenbanken kleiner 11g dass Passwort implizit in Großbuchstaben ändern und so an die 11g übergeben werden.
- Link von 11g zu <11g: Es sind keine besonderen Maßnahmen erforderlich. Das Passwort wird zwar von der 11g in exakter Schreibweise an die Vor-11g-Version übergeben. Diese unterscheidet aber die Schreibweise nicht.
Sollte es aus bestimmten Gründen gewünscht sein, dass auch unter 11g nicht zwischen Groß- und Kleinschreibung unterschieden wird (z.B. weil eine nachgelagerte Anwendung das erfordert), lässt sich mit der Parametereinstellung
ALTER SYSTEM SET SEC_CASE_SENSITIVE_LOGON=FALSE;
das alte Verhalten wiederherstellen.
Der aufmerksame Beobachter hat auch bei Verwendung des Database Configuration Assistant 11g (DBCA) einen neuen Dialog "Security Settings" bemerkt
Abhängig von der hier getroffenen Auswahl werden die Passwortlimits des Default-Nutzerprofils festgelegt. Die restriktiveren und daher empfohlenen Einstellungen setzt der DBCA mit der ersten Option "Keep the enhanced 11g default security settings":
FAILED_LOGIN_ATTEMPTS 10
PASSWORD_GRACE_TIME 7
PASSWORD_LIFE_TIME 180
PASSWORD_LOCK_TIME 1
Passworte laufen demnach nach 180 Tage ab, dürfen aber noch bis zu 7 Tage nach Ablauf verwendert werden. Accounts werden nach 10 fehlgeschlagenen Anmeldeversuchen für 1 Tag gesperrt.
Die zweite Option "Revert to pre-11g default security settings" deaktiviert im Zuge der Datenbankerstellung diese Restriktionen hingegen zum Großteil wieder:
FAILED_LOGIN_ATTEMPTS 10
PASSWORD_LIFE_TIME UNLIMITED
PASSWORD_GRACE_TIME UNLIMITED
PASSWORD_LOCK_TIME UNLIMITED
Weiterhin lässt sich im Nutzerprofil eine Passwortprüffunktion angeben (Limit PASSWORD_VERIFY_FUNCTION). Zwei vorgefertigte Funktionen (SYS.VERIFY_FUNCTION_11G und SYS.VERIFY_FUNCTION) werden durch Ausführen des Skripts $ORACLE_HOME/rdbms/admin/utlpwdmg.sql in der Datenbank installiert.
Das Skript setzt, neben den o.a restriktiven Passwortrestriktionen, auch verify_function_11G als Passwortprüffunktion des DEFAULT Profiles. Sollten die dort implementierten Prüfungen nicht ausreichen, kann an ihrer Stelle auch eine selbst implementierte und im SYS-Schema abgelegte, Prüfroutine verwendet werden:
ALTER PROFILE DEFAULT /* OR ANY PROFILE YOU WANT */LIMIT PASSWORD_VERIFY_FUNCTION my_function;
Zum Abschluss nun noch einige Quick-Tipps:
-
Ein weithin bekannter Weg, ein Benutzerpasswort im SQL*Plus zu setzen, ist:
ALTER USER username IDENTIFIED BY "passwort";
Problematisch ist hierbei allerdings, dass das Kennwort im Klartext sichtbar ist. Alternativ kann der PASSWORD Befehl genutzt werden, bei dem das Kennwort verborgen bleibt:
PASSWORD; (für das eigene) oder PASSWORD username; (für fremde Passworte)
Jeder Benutzer mit "ALTER USER" Privileg kann mittels "ALTER USER" oder "PASSWORD" das Passwort fremder Benutzer ändern. -
Ein "ungewollt" abgelaufenes Passwort kann wieder aktiviert werden, auch wenn es nicht bekannt ist. Voraussetzung dafür ist natürlich, dass das dem betroffenen Benutzer zugeordnete Profile hinsichtlich der Einstellungen für PASSWORD_REUSE_TIME und PASSWORD_REUSE_MAX entsprechend konfiguriert ist. Die Benutzerkennworte sind zwar nirgends in der Datenbank hinterlegt, wohl aber die zugehörigen Hashwerte. Diese findet man in der Spalte PASSWORD der Tabelle SYS.USER$, bis 10g auch noch in der gleichnamigen Spalte der DBA_USERS View. Der Account wird nun unter Beibehaltung des Passwortes folgendermaßen reaktiviert:
ALTER USER username IDENTIFIED BY VALUES 'passwort aus sys.user$' ACCOUNT UNLOCK;
Nach diesem Rücksetzen wird übrigens SYS.DBA_USERS.PASSWORD_VERSIONS auf "10G" gesetzt und das Passwort ist nicht mehr case-sensitive.
Sollte für die Datenbank bereits der von Oracle empfohlene SHA-1 Hash Algorithmus aktiviert worden sein (sqlnet.allowed_logon_version=11), wird das Passwort nicht mehr in SYS.USER$ abgelegt. Wir raten derzeit allerdings von der Verwendung von sqlnet.allowed_logon_version=11 ab, da die Umsetzung noch lückenhaft ist. U.a. werden unter dieser Einstellung gesetzte Passworte nicht in DataPump Exporte übernommen, was folglich beim Versuch, den betroffenen Nutzer anzulegen, zum Abbruch des DataPump Imports führt. - Werfen Sie doch mal einen Blick in die View DBA_USERS_WITH_DEFPWD. Diese View existiert seit Version 11g und listet alle Oracle Standard Accounts auf, für die noch die zur Installation voreingestellten Passworte gelten. Diese Accounts stellen also ein erhöhtes Sicherheitsrisiko dar, ihre Kennworte sollten umgehend geändert werden. Ein Blick in die Viewdefinition zeigt, dass sich die Erkenntnis, ob ein Account noch sein initiales Kennwort verwendet, hier lediglich auf Hashwerte gründet, die statisch in der Tabelle SYS.DEFAULT_PWD$, Spalte PWD_VERIFIER, hinterlegt sind. Das Auslesen der DBA_USERS_WITH_DEFPWD View ist übrigens Bestandteil des ASPICON Database Healthchecks.
Zurück
