Siden jeg kan huske i min karriere, hvor jeg arbejdede med Oracle, har jeg været i stand til at ændre en brugers adgangskode til kodeords-hashen. Det trick, jeg nogle gange har brugt, var at gemme bruger-id/adgangskode-hash, ændre adgangskoden til noget, jeg kender, oprette forbindelse til databasen som den bruger og derefter udføre mit arbejde. Når du er færdig med mit arbejde, skal du sætte adgangskoden tilbage til det, der ligner følgende:
ÆNDRE BRUGER bob IDENTIFICERET AF VÆRDI 'asdf1234%^&*qwerty';
Jeg behøvede aldrig at kende brugerens adgangskode for at sætte den tilbage til, hvad den var, så længe jeg vidste, at hash-værdien var. I går fandt jeg nogle oplysninger, hvor folk modtog følgende fejl, da de forsøgte at indstille en adgangskode på denne måde i 12c:
ORA-02153:ugyldig VALUES-adgangskodestreng
Hvis du slår denne fejl op i My Oracle Support, vil du højst sandsynligt lande på Note 2096579.1. I det notat står der, at denne metode ikke længere er mulig. Det siger "Dette er ny funktionalitet i 12c for at tvinge brugere til at blive oprettet på den rigtige måde". Men jeg har fundet ud af, at det ikke er helt rigtigt.
Oracle 12c introducerede ny funktionalitet for at gøre hashværdierne for bruger-id/adgangskode mere sikre. Her er et link til 12c Security Guide, hvor den taler om 12c Verifier for adgangskoder. Bemærk i den sektion, at den nævner en saltværdi tilføjet til adgangskoden, når den hashes. For at se hvorfor dette er vigtigt, lad os se på et eksempel. Jeg opretter en bruger og ser på bruger-id/adgangskode-hash, der er gemt i SPARE4-kolonnen i 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
I tidligere versioner ville SPARE4-kolonnen ikke indeholde nær så mange tegn. Dette er bestemt mere komplekst end før-12c-versioner. Mit gæt er, selvom det ikke er bekræftet, at S:-delen af outputtet ovenfor er saltværdien. Jeg er ikke sikker på, hvad H:og T:repræsenterer.
Vi kan bruge DBMS_METADATA-pakken til at reverse engineering af en bruger. Når vi gør det, kan vi se, at vi stadig kan bruge IDENTIFIED BY VALUES-sætningen.
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"
Og faktisk virker det. Jeg ændrer BOBs adgangskode til noget andet, så ændrer jeg den til denne hashværdi og forbinder med den gamle adgangskode.
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.
Så vi har ikke mistet nogen funktionalitet, som MOS Note antydede. Vi skal bare forholde os til en meget længere hashværdi her.
Hvor dette bliver virkelig vigtigt, er når man prøver at bruge exp/imp eller Data Pump til at flytte brugere fra en pre-12c version til 12c. Hvis du udfører en FULD eksport af en Oracle 11g-database, vil dumpet indeholde de gamle password-hash-værdier. Når du importerer til 12c, vil du modtage fejlen ORA-02153. For at omgå dette problem skal du på forhånd oprette brugerne i 12c-databasen med kendte adgangskoder.