Odkąd pamiętam w swojej karierze współpracującej z Oracle, udało mi się zmienić hasło użytkownika na hash hasła. Sztuczka, którą czasami stosowałem, polegała na przechowywaniu skrótu identyfikatora użytkownika/hasła, zmianie hasła na coś, co znam, połączeniu się z bazą danych jako ten użytkownik, a następnie wykonaniu mojej pracy. Po zakończeniu pracy ustaw hasło z powrotem na to, co było podobne do następującego:
ALTER USER bob IDENTYFIKOWANY PRZEZ WARTOŚCI ‘asdf1234%^&*qwerty’;
Nigdy nie musiałem znać hasła użytkownika, aby przywrócić je do tego, co było, dopóki wiedziałem, że jest to wartość skrótu. Wczoraj znalazłem informacje, w których ludzie otrzymywali następujący błąd podczas próby ustawienia hasła w ten sposób w 12c:
ORA-02153:nieprawidłowy ciąg hasła VALUES
Jeśli wyszukasz ten błąd w My Oracle Support, najprawdopodobniej wylądujesz w nocie 2096579.1. W tej notatce stwierdza się, że ta metoda nie jest już możliwa. Mówi:„To nowa funkcja w 12c, która zmusza użytkowników do tworzenia we właściwy sposób”. Ale odkryłem, że to nie do końca prawda.
Oracle 12c wprowadził nową funkcjonalność, aby zwiększyć bezpieczeństwo wartości skrótu identyfikatora użytkownika/hasła. Oto link do przewodnika bezpieczeństwa 12c, w którym mówi się o weryfikatorze 12c dla haseł. Uwaga w tej sekcji wspomina o wartości soli dodanej do hasła, gdy jest ono zahaszowane. Aby zobaczyć, dlaczego jest to ważne, spójrzmy na przykład. Stworzę użytkownika i zobaczę skrót identyfikatora użytkownika/hasła przechowywany w kolumnie SARE4 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
W poprzednich wersjach kolumna SARE4 nie zawierałaby prawie tylu znaków. Jest to zdecydowanie bardziej złożone niż wersje przed 12c. Domyślam się, choć niepotwierdzony, że część S:powyższego wyniku to wartość soli. Nie jestem pewien, co reprezentują H:i T:.
Możemy użyć pakietu DBMS_METADATA do wstecznej inżynierii użytkownika. Gdy to zrobimy, widzimy, że nadal możemy użyć 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"
I faktycznie to działa. Zmienię hasło BOB na coś innego, a następnie zmienię je na tę wartość skrótu i połączę się ze starym hasłem.
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.
Więc nie straciliśmy żadnej funkcjonalności, jak sugerowała notatka MOS. Po prostu mamy tutaj do czynienia ze znacznie dłuższą wartością skrótu.
Naprawdę ważne staje się to, gdy próbujesz użyć exp/imp lub Data Pump, aby przenieść użytkowników z wersji sprzed 12c na 12c. Jeśli wykonasz PEŁNY eksport bazy danych Oracle 11g, zrzut będzie zawierał stare wartości skrótu hasła. Podczas importowania do 12c pojawi się błąd ORA-02153. Aby obejść ten problem, utwórz wstępnie użytkowników w bazie danych 12c ze znanymi hasłami.