Vzhledem k tomu, že si pamatuji, že jsem ve své kariéře pracoval s Oracle, dokázal jsem upravit heslo uživatele na hash hesla. Trik, který jsem někdy používal, bylo uložit uživatelské ID/heslo hash, změnit heslo na něco, co znám, připojit se k databázi jako tento uživatel a pak dělat svou práci. Až skončím s prací, nastavte heslo zpět na cokoliv, co bylo podobné následujícímu:
ALTER USER bob IDENTIFIED BY VALUES ‘asdf1234%^&*qwerty’;
Nikdy jsem nepotřeboval znát heslo uživatele, abych ho mohl nastavit zpět na to, co bylo, pokud jsem věděl, že je to hash hodnota. Včera jsem našel nějaké informace, kde se lidem při pokusu o nastavení hesla tímto způsobem v 12c zobrazila následující chyba:
ORA-02153:neplatný řetězec hesla VALUES
Pokud tuto chybu vyhledáte v My Oracle Support, pravděpodobně se dostanete na Note 2096579.1. V této poznámce uvádí, že tento způsob již není možný. Říká:„Toto je nová funkce v 12c, která přinutí uživatele, aby byli vytvořeni správným způsobem“. Ale zjistil jsem, že to není tak úplně pravda.
Oracle 12c zavedl novou funkcionalitu pro větší zabezpečení hodnot hash userid/password. Zde je odkaz na 12c Security Guide, kde se hovoří o 12c Verifier pro hesla. Všimněte si, že v této části se zmiňuje hodnota soli přidaná k heslu, když je hashováno. Abychom pochopili, proč je to důležité, podívejme se na příklad. Vytvořím uživatele a podívám se na hash userid/password uložený ve sloupci SPARE4 v SYS.USER$.
SQL> create user bob identified by abc123;
User created.
SQL> grant create session to bob;
Grant succeeded.
SQL> select spare4 from sys.user$ where name='BOB';
SPARE4 -------------------------------------------------------------------------------- S:44F34BA1369D58A6CB262D166587D5238D9148FC9BDD390A98C29A3B6A34;H:FD30F9DA6ECB907 6C10C04D20AFF9492;T:450FF7F2A4BB8104E33E7C09FF1698AEA2DE3EBD60BFA681942057D83EE2 DD773BB4F7B1046355D1CB63EBF256BC7B466BB1B3185A0988D1CBAE3276D1B181756DB27BB40505 8C44152DB2DD41074396
V předchozích verzích sloupec SPARE4 neobsahoval ani zdaleka tolik znaků. To je rozhodně složitější než verze před 12c. Můj odhad, i když nepotvrzený, je, že část S:výše uvedeného výstupu je hodnota soli. Nejsem si jistý, co H:a T:představují.
Pro zpětnou analýzu uživatele můžeme použít balíček DBMS_METADATA. Když to uděláme, uvidíme, že stále můžeme použít klauzuli IDENTIFIED BY VALUES.
SQL> select dbms_metadata.get_ddl('USER','BOB') from dual; DBMS_METADATA.GET_DDL('USER','BOB')
-------------------------------------------------------------------------------- CREATE USER "BOB" IDENTIFIED BY VALUES 'S:44F34BA1369D58A6CB262D166587D5238D9 148FC9BDD390A98C29A3B6A34;H:FD30F9DA6ECB9076C10C04D20AFF9492;T:450FF7F2A4BB8104E 33E7C09FF1698AEA2DE3EBD60BFA681942057D83EE2DD773BB4F7B1046355D1CB63EBF256BC7B466 BB1B3185A0988D1CBAE3276D1B181756DB27BB405058C44152DB2DD41074396;5844087A3D506FD3 ' DEFAULT TABLESPACE "USERS" TEMPORARY TABLESPACE "TEMP"
A ve skutečnosti to funguje. Změním heslo BOB na něco jiného, pak ho změním na tuto hodnotu hash a připojím se ke starému heslu.
SQL> alter user bob identified by newpass;
User altered.
SQL> alter user bob identified by values 'S:44F34BA1369D58A6CB262D166587D5238D9148FC9BDD390A98C29A3B6A34;H:FD30F9DA6ECB9076C10C04D20AFF9492;T:450FF7F2A4BB8104E33E7C09FF1698AEA2DE3EBD60BFA681942057D83EE2DD773BB4F7B1046355D1CB63EBF256BC7B466BB1B3185A0988D1CBAE3276D1B181756DB27BB405058C44152DB2DD41074396;5844087A3D506FD3';
User altered.
SQL> connect bob/abc123 Connected.
Neztratili jsme tedy žádnou funkci, jak naznačuje MOS Note. Jen se zde musíme vypořádat s mnohem delší hash hodnotou.
Tam, kde to začíná být opravdu důležité, je pokus použít exp/imp nebo Data Pump k přesunu uživatelů z verze před 12c na 12c. Pokud provedete ÚPLNÝ export databáze Oracle 11g, výpis bude obsahovat staré hodnoty hash hesla. Při importu do 12c se zobrazí chyba ORA-02153. Chcete-li tento problém obejít, předem vytvořte uživatele v databázi 12c se známými hesly.