Jedenfalls sind diese seit Oracle 8 möglich. In Oracle 8 gab es schon folgende Einstellungsmöglichkeiten:
- FAILED_LOGIN_ATTEMPTS ... Wie oft darf man sich beim Passwort vertippen, bevor das Account für PASSWORD_LOCK_TIME gesperrt wird. Der Default ist 10.
- PASSWORD_LOCK_TIME ... In Tagen. Wie lange ein Account gesperrt wird, wenn man sich beim Passwort FAILED_LOGIN_ATTEMPTS vertippt hat. Der Default ist 1 Tag.
- PASSWORD_LIFE_TIME ... In Tagen. Wie lange ein Passwort maximal genutzt werden darf. Der Default ist 180 Tage. Dies hat oft dazu geführt, dass nach einem halben Jahr Applikationen - inkl. Enterprise Manager - nicht mehr funktioniert haben.
- PASSWORD_GRACE_TIME ... In Tagen. Ab wann man vor dem Ablauf von PASSWORD_LIFE_TIME eine Warnung beim Login bekommt, dass das Passwort in Kürze abläuft. Der Default ist 7 Tage, aber die wenigsten Applikationen zeigen die Meldung korrekt an.
- PASSWORD_REUSE_TIME ... Wie viele Tage muss man warten, bevor man ein Passwort nochmals verwenden darf. Der Default ist UNLIMITED - also niemals.
- PASSWORD_VERIFY_FUNCTION ... Hier kann man eine PL/SQL Funktion angeben, die die Komplexität des Passworts überprüft. Oracle hat hierfür immer schon zumindest ein Beispiel mitgeliefert. Inzwischen gibt es mindestens 5 mitgelieferte Beispielfunktionen. Der Default ist NULL - keine Funktion nutzen.
Über die Jahre sind dann weitere Limits dazu gekommen:
- PASSWORD_REUSE_MAX mit Oracle 11g ... Gibt an, wie viele verschiedene Passwörter bereits verwendet worden sind, bevor man wieder ein altes Passwort verwenden darf. Der Default ist UNLIMITED, somit darf man Passwörter niemals wieder verwenden.
- INACTIVE_ACCOUNT_TIME mit Oracle 18c …In Tagen. Ab wann ein Account gesperrt wird, wenn sich der Benutzer in der Datenbank nicht angemeldet hat. Der Default ist UNLIMITED, also wird der Account niemals gesperrt.
- PASSWORD_ROLLOVER_TIME mit Oracle 19c …In Tagen. Wie lange sowohl das alte als auch das neue Passwort für das Login genutzt werden kann. Damit wird es einfacher ein Applikations-Passwort im laufenden Betrieb ohne Downtime zu ändern. Der Default ist 0, somit kann man nur das neue Passwort nutzen.
Die Default-Einstellungen kann man jederzeit selbst anpassen, da diese im Profile mit dem Namen DEFAULT hinterlegt sind. So viel zu den Grundlagen. Die wichtigste Frage ist jetzt, welche Einstellungen sollte man vornehmen beziehungsweise wie sollte man hier vorgehen.
Vorgehensweise bei der Einstellungswahl
Wenn man keine Erfahrung mit dem Thema hat, bietet sich natürlich an, dass man sich an Sicherheitsempfehlungen hält. Leider sind diese nicht immer gut durchdacht.
Schauen wir uns an, welche Empfehlungen Oracle (siehe docs.oracle.com/en/database/oracle/oracle-database/23/dbseg/managing-security-for-oracle-database-users.html ), der CIS Security Benchmarks (siehe www.cisecurity.org/benchmark/oracle_database) sowie STIG - Security Technical Implementation Guide (siehe public.cyber.mil/stigs/) machen.
Der Grund genau diese Empfehlungen zu nutzen ist, dass Oracle ab 23ai dafür eigene Profiles ausliefert (siehe docs.oracle.com/en/database/oracle/oracle-database/23/dbseg/managing-security-for-oracle-database-users.html) Diese Profiles kann man selbstverständlich auch in älteren Oracle-Versionen nutzen.
Wie schaut das Oracle-Default-Profile mit Oracle 23ai aus?
select resource_name, limit
from dba_profiles
where resource_type='PASSWORD' and profile = 'DEFAULT';
RESOURCE_NAME LIMIT
-------------------------------- -------------------
FAILED_LOGIN_ATTEMPTS 10
PASSWORD_LOCK_TIME 1
PASSWORD_LIFE_TIME 180
PASSWORD_GRACE_TIME 7
PASSWORD_REUSE_TIME UNLIMITED
PASSWORD_REUSE_MAX UNLIMITED
PASSWORD_VERIFY_FUNCTION NULL
INACTIVE_ACCOUNT_TIME 365
PASSWORD_ROLLOVER_TIME 0
Wie schaut das ORA_CIS_PROFILE aus?
CREATE PROFILE ORA_CIS_PROFILE
sessions_per_user 10
failed_login_attempts 5
password_lock_time 1
password_life_time 90
password_grace_time 5
password_reuse_time 365
password_reuse_max 20
password_verify_function ora12c_verify_function
inactive_account_time 120;
Im Fall von ORA_CIS_PROFILE gibt es noch eine weitere Einstellung. SESSION_PER_USER wird auf 10 limitiert. Die Argumentation ist, dass mehr als 10 Sessions eines Benutzers zu einem Denial-of-Service führen können.
Das Problem damit ist, dass sich sehr viele Applikationen mit einem Applikationsbenutzer anmelden und dieser oft duzende, wenn nicht hunderte Sessions, benötigt. Hält man sich an diese Empfehlung, würden solche Applikationen nicht mehr funktionieren.
Wie schaut das ORA_STIG_PROFILE aus?
CREATE PROFILE ORA_STIG_PROFILE
failed_login_attempts 3
password_lock_time unlimited
password_life_time 35
password_grace_time 0
password_reuse_time 175
password_reuse_max 5
password_verify_function ora12c_stig_verify_function
inactive_account_time 35
idle_time 15;
Im ORA_STIG_PROFILE wiederum wird die IDLE_TIME zusätzlich gefordert. Die IDLE_TIME gibt in Minuten an, wie lange in einer Session die Transaktion maximal nichts tun darf, bevor diese automatisch rollbacked wird.
Vergleicht man jetzt die Empfehlungen, fällt einem auf, dass diese sich massiv unterscheiden! Ok, die Oracle Defaults sind größtenteils aus den 1990ern und vielleicht nicht unbedingt aktuell, aber teilweise viel sicherer als die aktuellen Sicherheitsempfehlungen von STIG und CIS.
Empfehlungen für FAILED_LOGIN_ATTEMPTS sowie PASSWORD_LOCK_TIME
Diese muss man immer gemeinsam betrachten, da das Überschreiten der FAILED_LOGIN_ATTEMPTS zu einer automatischen Sperre für PASSWORD_LOCK_TIME Tagen führt. Die Empfehlungen für die FAILED_LOGIN_ATTEMPTS gehen von 3 (STIG) über 5 (CIS) bis 10 (Oracle) und die für PASSWORD_LOCK_TIME von 1 (Oracle, CIS) bis UNLIMTED (STIG).
In der Praxis bedeuten diese Einstellungen – speziell die für die PASSWORD_LOCK_TIME – verstärkten und unnötigen Aufwand für den Datenbank Support, zumindest wenn die Benutzer in der Datenbank Named Accounts (das ist die Empfehlung aller Sicherheitsrichtlinien) nutzen. Vertippt sich ein Benutzer mehrfach, wird sein Account für mindestens einen Tag gesperrt. Da der Benutzer in der Regel aber arbeiten soll, muss er über den Datenbank-Support dafür sorgen, dass sein Account wieder entsperrt wird. Optimal ist natürlich, wenn es dafür ein Self-Service gibt. Wenn nicht, vergeudet man unnötig viel Zeit (vom Mitarbeiter und den Support-Technikern).
Die Begründung für die lange Einstellung für PASSWORD_LOCK_TIME ist, dass man damit Password Hacking verhindern kann. Das ist zwar vollkommen korrekt, aber man erreicht das Gleiche auch – sofern die Benutzer sinnvolle Passwörter verwenden – wenn man die PASSWORD_LOCK_TIME auf 10 bis 15 Minuten setzt. Ist dieser Zeitraum den Benutzern bekannt, werden diese vermutlich nicht den Support anrufen und es nach Ablauf der Zeit wieder probieren. Sollten sie wirklich das Passwort vergessen haben, führt an einer Änderung (egal ob Selfservice oder via Support) nichts vorbei.
Empfehlungen für PASSWORD_LIFE_TIME sowie PASSWORD_GRACE_TIME
Auch diese Parameter sollte man sinnvollerweise gemeinsam betrachten. Nach der mit PASSWORD_LIFE_TIME definierten Zeit ist das Passwort abgelaufen. Die Empfehlungen reichen von 35 (STIG) über 90 (CIS) bis zu 180 (Oracle) Tage. Die Aufforderung das Passwort zu ändern, erhält man so viele Tage wie mit PASSWORD_GRACE_TIME angegeben wurde. Bei STIG sind es 0 Tage – das Passwort läuft ab und man bekommt KEINE Information, bis der Account gesperrt ist! Merkt man sich nicht anderweitig, wann man das Passwort ändern muss, kann man sich nicht mehr anmelden! Selbst die Werte von 5 (CIS) und 7 (Oracle) sind nicht praxistauglich. Ist man zum falschen Zeitpunkt krank oder im Urlaub, ist der Account ebenfalls gesperrt.
Die Empfehlungen über die Häufigkeit von Passwortwechsel und die Zeit in der man informiert wird, dass das Passwort abläuft, entsprechen keinerlei aktuellen Empfehlungen von maßgeblichen Institutionen wie NIST, CESG, BSI und anderen (siehe Referenzen am Ende des Artikels). Warum also Vorgaben machen, die weder der Praxis noch einer gelebten Realität entsprechen? Solange man dafür sorgt, dass die Länge der Passwörter groß genug ist, gibt es keinen Grund für häufiges Ändern. Wenn man trotzdem auf einem Passwortwechsel besteht, reicht es dieses einmal pro Jahr mit einem Monat (langer Urlaub / Krankenstand) Vorwarnung zu ändern, um allen behördlichen Empfehlungen zu entsprechen!
Empfehlungen für PASSWORD_REUSE_TIME sowie PASSWORD_REUSE_MAX
Auch hier gehen die Empfehlungen weit auseinander. Bei STIG darf man schon nach 175 Tagen ein Passwort wieder verwenden, bei CIS erst nach einem Jahr und bei Oracle niemals. Das gleiche Passwort nochmals zu nutzen ist bei STIG nach 5 Passwortwechseln erlaubt, bei CIS erst nach 20. Laut Oracle darf man Passwörter niemals recyclen. Die Frage ist: was bringt es, wenn man Passwörter spätestens alle 30 Tage ändern soll, aber nach einem halben Jahr das gleiche Passwort wieder nutzen darf? Die Empfehlung von Oracle, dass man Passwörter niemals wiederverwenden darf, ist hier absolut am sinnvollsten!
Empfehlung für PASSWORD_VERIFY_FUNCTION
Das Oracle keine Überprüfung der Komplexität von Passwörtern verlangt, liegt mit Sicherheit daran, dass der Default in den 1990ern definiert wurde, und sich seither nicht geändert hat. STIG und CIS empfehlen verschiedene Funktionen, die jeweils komplexe Passwörter (Buchstaben, Zahlen, Sonderzeichen) verlangen. Dies entspricht absolut nicht den Empfehlungen von maßgeblichen Government-Organisationen (siehe Referenzen am Ende des Artikels). Warum STIG und CIS auf den veralteten Ansatz der Komplexität bestehen, ist nicht nachvollziehbar. Aktuell lauten die Empfehlungen, dass man lieber auf längere als komplexere Passwörter setzen soll. Passwörter mit mindestens 12 Zeichen (teilweise werden auch 14 oder 16 genannt) gelten als mit aktuellen Technologien unhackbar. Viel wichtiger ist, dass man das gleiche Passwort nicht bei verschiedenen Zugängen nutzt. Diesen Empfehlungen kann ich mich nur anschließen und empfehle eine Passwortlänge von mindestens 16 Zeichen (egal welchen).
Mit Oracle 23ai hat Oracle das Limit von 30 Zeichen (Bytes) auf 1024 Zeichen (Bytes) für Passwörter erhöht – jetzt gibt es keinen Grund mehr, warum man nicht folgendes Passwort nutzen soll:
“Ich liebe die Oracle Datenbank!”
Das Passwort kann ich mir leicht merken, es hat 31 Zeichen und ist aller Voraussicht nach auch in vielen Jahrzehnten noch unhackbar. Selbst wenn man alle Rechnerkapazitäten auf der Welt nutzen würde, bräuchte man mit Brutal Force viel länger als das Alter unseres Universums.
Empfehlungen für INACTIVE_ACCOUNT_TIME
Auch hier reichen die Empfehlungen von 35 (STIG) über 120 (CIS) bis zu 365 (Oracle). Das alle diese Empfehlungen eigentlich sinnlos sind, weil die Accounts zu diesem Zeitpunkt sowieso schon auf Grund der Empfehlungen zu PASSWORD_LIFE_TIME sowie PASSWORD_GRACE_TIME gesperrt sind, hat offensichtlich niemand bedacht! Grundsätzlich ist es sinnvoll, dass ein Account, der nicht mehr genutzt wird, automatisiert gesperrt wird, nur muss man hier folgendes berücksichtigen:
Was ist die Aufgabe (der Job) des Accountnutzers?
Wenn in einem Unternehmen beispielsweise eindeutige Named-Benutzer verpflichtend sind, so wird sich nicht jeder Administrator in jede Datenbank regelmäßig einloggen, sondern nur, wenn er dort etwas zu tun hat. Gerade bei Unternehmen mit hunderten oder tausenden Datenbanken ist es überhaupt nicht realistisch, dass sich ein Administrator jedes Monat (35 Tage laut STIG) in jeder Datenbank anmeldet, nur damit sein Account nicht gesperrt wird. Handelt es sich aber um einen Account eines Applikationsusers, so kann man davon ausgehen, dass es einen Grund gibt, warum der Benutzer länger als 1 bis 2 Monate nicht angemeldet ist. In diesem Fall sollte man den Account sperren.
Empfehlung für PASSWORD_ROLLOVER_TIME
Lediglich Oracle gibt hier überhaupt etwas an – 0 Tage, also keine gleichzeitige Nutzung von altem und neuen Passwort. STIG und CIS ignorieren diese Einstellung komplett. Dabei ist es in der Praxis ungemein hilfreich, wenn man – sofern man mehrere Applikationsserver nutzt – das Passwort bei einem nach dem anderen Applikationsserver umkonfigurieren kann, ohne dass eine Downtime notwendig ist.
Weitere Empfehlungen wie IDLE_TIME, SESSIONS_PER_USER und andere
Der Einsatz von anderen Profile-Einstellungen, die aus Sicht der Oracle-Datenbank nichts mit den Passwort Limits, sondern mit Resource Limits zu tun haben, kann man nicht pauschalieren. Dies hängt von der Nutzung der Datenbank ab. Nutzt die Applikation – beispielsweise SAP – nur einen Benutzer in der Datenbank, wäre ein Limit von 10 Sessions pro Datenbankbenutzer (CIS) fatal. Auch die IDLE_TIME innerhalb einer Transaktion kann definitiv länger als 15 Minuten (STIG) betragen. Wenn man über eine CRM-Applikation ein komplexes Angebot erstellt und dabei mit Hilfe von anderen Tools (wie Excel) komplexere Kalkulationen durchführen muss, sind 15 Minuten schnell zu wenig.
Ähnliches gilt auch für CONNECT_TIME, mit der man definieren kann, wann eine Session spätestens abgemeldet werden soll. Bei Applikationen wie SAP ist die Konfiguration eines CONNECT_TIME Limits fatal. Applikationen, bei denen sich jeder Benutzer mit seinem eigenen Account anmeldet, kann man dafür sorgen, dass nicht geschlossene Fenster nicht zu "sehr langen" Sperren führen, wenn der Benutzer einfach nur seinen Notebook zuklappt und auf Urlaub geht. Hier sind Einstellungen von 12 bis 14 Stunden sicher empfehlenswert.
Empfehlungen für sinnvolle Real-World-Benutzer-Profiles
CREATE PROFILE DBMasters_DBA_PROFILE
failed_login_attempts 3
password_lock_time 10/(24*60) /* 10 Minuten */
password_life_time 390 /* ein Jahr oder länger */
password_grace_time 32 /* mindestens ein Monat */
password_reuse_time UNLIMITED
password_reuse_max UNLIMITED
password_verify_function check_length_16_chars
inactive_account_time 365 /* mindestens ein Jahr, eher UNLIMITED */
PASSWORD_ROLLOVER_TIME 7;
CREATE PROFILE DBMasters_USER_PROFILE
failed_login_attempts 3
password_lock_time 10/(24*60) /* 10 Minuten */
password_life_time 390 /* ein Jahr oder länger */
password_grace_time 32 /* mindestens ein Monat */
password_reuse_time UNLIMITED
password_reuse_max UNLIMITED
password_verify_function check_length_16_chars
inactive_account_time 32 /* mindestens ein Monat, maximal zwei Monate */
PASSWORD_ROLLOVER_TIME 7;
Die PASSWORD_VERIFY_FUNCTION ist sehr einfach. Es braucht nur sicherstellen, dass sich das neue Passwort von dem alten unterscheidet und dass die Länge des Passworts mindestens 16 Zeichen beträgt.
Referenzen - Empfehlungen zur Passwortkomplexität und -länge sowie Änderungshäufigkeit
- NIST Special Publication 800-63B aus 2017, Anhang: Strength of Memorized Secrets – siehe https://pages.nist.gov/800-63-3/sp800-63b.html#appA Die Länge eines Passworts ist wichtiger als die Komplexität. Der Zwang auf komplexe Passwörter ist nicht sinnvoll und führt zu Frustration der Benutzer.
- Die britische Communications Electronics Security Group (CESG) empfiehlt seit 2016, dass das häufige Ändern von Passwörtern sinnlos ist – siehe www.heise.de/news/Wider-den-Zwang-zur-Passwort-Aenderung-3176493.html
- Deutsches Bundesamt für Sicherheit in der IT (BIS) empfiehlt seit 2020 keine festen Regeln für die Länge und Komplexität von Passwörtern mehr! – siehe www.heise.de/news/Passwoerter-BSI-verabschiedet-sich-vom-praeventiven-Passwort-Wechsel-4652481.html
- Deutsches Bundesamt für Sicherheit in der IT (BIS) zur Passwortlänge siehe www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Checklisten/sichere_passwoerter_faktenblatt.pdf
- Passwort Länge und Cracking Zeit – siehe https://www.betterbuys.com/estimating-password-cracking-times/
Selbst einfache Passwörter mit nur 11 bis 12 Zeichen brauchen aktuell Dekaden bis diese mit Brutal Force geknackt werden können.
Christian Pfundtner
