Passwörter wiederherstellen in Oracle 11g

,

In der Datenbank Version 11gR1 hat Oracle bekanntlich case-sensitive Passwörter und einen neuen Passwort-Algorithmus eingeführt. In der Datenbank werden nicht die Klartext-Passwörter, sondern nur deren Hashes abgelegt, und der Algorithmus, mit dem diese Hashes berechnet werden, war bei 10g 3DES, und ist seit 11g SHA1. Im 10g-Hashverfahren fliesst der Username als Salt in den Hash mit ein, während ab 11g ein zufälliges Salt verwendet wird. Ab 11g können die Hashes also zwischen verschiedenen Benutzern geteilt werden.

Will man das Passwort eines Benutzers sichern, um es beispielsweise in einer anderen Datenbank wieder einzuspielen, kann man sich den Hash im Data Dictionary suchen (der 10g Hash steht in SYS.USER$.PASSWORD, der 11g Hash in SYS.USER$.SPARE4), und dessen Wert mit Hilfe der „BY VALUES“ Klausel beim Anlegen eines neuen Users angeben:

CREATE USER AKIRA IDENTIFIED BY VALUES ‚DA3A39221404DD55‘; –10g hash

ALTER USER AKIRA IDENTIFIED BY VALUES ‚S:3CAFD1F43D6958FD4F67C2EDD91B3FF54913344723750F6AE48C802D37E4‘ –11g hash

Oracle erkennt hier selbstständig aus dem verwendeten Wert, ob es sich im einen 10g oder um einen 11g Hash handelt. Wird ein 11g Hash angegeben, löscht die Datenbank allerdings den 10g Hash aus dem Dictionary – und umgekehrt. Normalerweise kann man mit dieser Syntax also nur entweder einen alten oder einen neuen Hash setzen, aber nicht beide, wie man es zur vollständigen Wiederherstellung eines bisherigen Zustandes in einigen Fällen bräuchte.

In der MOS Note (Doc ID 1051962.101) hat Oracle beschrieben, wie man beide Hashes mit der „BY VALUES“ Syntax eintragen kann:

alter user TEST identified by values
‚7A0F2B316C212D67;S:F3F4BA77C0E960A5973095AF787988CBE52410CB2EA53F6AF008AD99179B‘;

Indem man beide Hashes mit einem Semikolon getrennt zusammen angibt.

Bei der Authentifikation ab 11g existiert eine erschreckende Sicherheitslücke im O5LOGON Protokoll, das es einem Angreifer ermöglicht, den Session Key und das Salt auszulesen, ohne Spuren zu hinterlassen. Um sie zu schließen, haben einige Datenbankadminstratoren die 11g-Authentifizierung ganz ausgeschaltet, indem sie den Parameter „SEC_CASE_SENSITIVE_LOGON=FALSE“ gesetzt oder alle 11g-Hashes aus dem Dictionary gelöscht haben.

In dieser Kombination kann es zu dem Effekt kommen, dass Passwörter zum Beispiel beim Aufbau einer Testumgebung mittels der BY VALUE Methode mit einem gespeicherten 11g-Hash zurückgesetzt werden, sich aber danach kein Anwender anmelden kann, weil in der Quell-Datenbank noch der 10g-Hash verwendet wurde, dieser aber durch das Neu-Setzen des 11g-Hashes überschrieben wurde, und die Anmeldung nur mit einem 11g-Hash nicht funktioniert. Hier hilft dann die oben beschriebene Methode, beide Hashes anzugeben, so man sie denn gesichert hatte.

Siehe auch zum Thema:

Infrastructure Repository Databases

Eine RMAN-Catalog-Datenbank zum Speichern der Metadaten von RMAN-Sicherungen muss ab Version 12.1.0.2 auf einer Enterprise-Edition (EE) – Datenbank betrieben werden, weil sie nun Partitionierung verwendet.

Ansonsten erhält man beim Aktualisieren (upgrade) des Katalogs folgenden Fehler:

RMAN> upgrade catalog;error creating create_deleted_object_seq
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-06004: ORACLE error from recovery catalog database: ORA-00439: feature not enabled: Partitioning

Was zunächst wirkt wie eine enorme Lizenz-Verteuerung durch die Hintertür, relativiert sich durch die neu geschaffene Möglichkeit, eine sogenannte „Infrastructure Repository Database“ zu verwenden. Eine solche Datenbank, immer als Enterprise Edition zu installieren, erfordert keine zusätzliche Lizensierung, wenn sie nur mittels Oracle-Tools verwendet wird:

A separate single instance Oracle Database can be installed and used as an infrastructure repository for RMAN, Oracle Enterprise Manager Cloud Control, Automatic Workload Repository (AWR) Warehouse, Global Data Services Catalog, and Grid Infrastructure Management Repository without additional license requirements, provided that all the targets are correctly licensed.

Siehe: RMAN Catalog requires Enterprise Edition (EE) since Oracle Database 12.1.0.2

Praxisvergleich: IOS/iPhone Flight Tracker Apps

Das Warten am Gate eine halbe Stunde nach der ursprünglich geplanten Boarding-Zeit ist eine gute Gelegenheit, einmal alle Flight Tracker Apps, die installiert sind, durchzuprobieren: Welche Informationen bieten sie?

  • Flying App

Die vielgelobte junge App ist nett anzusehen, aber bringt über den versprochenen sozialen Ansatz hinaus kaum nützliche Informationen.

Flying App

 

Kein Gate, die Verspätung wird gar nicht dargestellt, keine Notifications (sind als In App Purchase erhältlich, habe ich aber nicht ausprobiert, da die Verspätung ja noch nicht einmal erkannt wurde).

Flying App bietet die Synchronisation der Daten mit Tripit an.

  • Gateguru

Das Icon dieser App verursacht zwar spontanes Augenleiden, aber die Darstellung des Fluges ist erst einmal sehr gefällig.

GateGuru

 

Die angezeigte Verspätung entspricht zwar nicht der Realität (5 Minuten statt der tatsächlichen 30), aber da dies auf alle Apps zutraf, scheint die Airline bzw. der Flughafen noch keine aktuelleren Daten zur Verfügung gestellt zu haben.

Wir auch bei Flying wird nur das Terminal, aber nicht das aktuelle Gate angezeigt, obwohl dies in den Displays am Flughafen längst veröffentlicht war.

Es gibt eine Schätzung der Wartezeit an der Security, deren Genauigkeit man durch das Eingeben der eigenen Wartezeit verbessern helfen kann. Eine Unterscheidung zwischen Fast Lane und normaler Security gibt es aber hier nicht.

Die App ernährt sich durch das Aufschwatzen einer Vielzahl von Services, die rund um den gewählten Flug verfügbar sind (Hotels, Mietwagen…).

Wer seine Daten auf einen Sirenenserver hochladen möchte, kann sie serverseitig mit Tripit und Kayak synchronisieren.

  • FlightTrack

FlightTrack

Diese App habe ich persönlich bereits am längsten installiert. Es gibt inzwischen, sehe ich gerade, eine neue Version mit dem Namen „Flight Track 5„. Auch die ursprüngliche Version bietet die Basisdienste und zeigt die Verspätung mit 5 Minuten sowie das Terminal und eine geschätzte Verspätungswahrscheinlichkeit an. Sehr schön ist der Link zu SeatGuru, wo einem die schlechten Sitzplätze für den vorgesehenen Flugzeugtyp gelb und rot markiert werden. Das Gate wird aber auch hier nicht ausgewiesen.

  • AirBerlin App

AirBerlins eigene App kann sich mit Pebble synchronisieren. Das Gate kann sie nicht anzeigen, dafür gibt es das Wetter.. und viele Hinweise auf Mietwagen- und Hotel-Angebote, die der Airline wahrscheinlich Vermittlungsprovisionen einbringen.

Über die Verspätung schweigt sich die App wohl bewusst aus.

AB App

Immerhin gibt es eine Passbook-Integration, diese scheint aber eher widerwillig. Gerade beim Rückflug verschwindet sie häufig, und man hat den Eindruck, dass der Benutzer lieber zum Öffnen der Airline-eigenen App verleitet werden soll, vielleicht, um dort noch für Werbeeinnahmen zu sorgen.

Die Air Berlin App bietet natürlich auch das Check-In, aber dieses war in den letzten Monaten sehr problembelastet. Nach dem Erhalt der Check In Einladung per IOS Notification und eMail steht in der App das Checkin meist noch Stunden nicht zur Verfügung, und die App stürzt beim Auswahl des Sitzplatzes gerne ab.

  • Passbook

Am Gate hektisch nach der richtigen App fummeln, um die Bordkarte zu suchen, muss man mit Passbook nicht mehr, da sie direkt auf dem Home Screen liegt, wenn man am Flughafen ist.

Passbook

Soweit ich weiss, können Passbook Karten dynamisch aktualisiert werden, wenn der Aussteller neue Daten bereitstellt, also könnte eine Verspätung oder das richtige Gate eigentlich aktuell sein, ist es aber bei Air Berlin nicht. Bei Lufthansa soll das gehen, ich habe es aber noch nicht ausprobiert.