sql >> Database >  >> RDS >> Oracle

Oracle 12c GEDENTIFICEERD DOOR WAARDEN

Sinds ik me in mijn carrière bij Oracle kan herinneren, heb ik het wachtwoord van een gebruiker kunnen wijzigen in de wachtwoord-hash. De truc die ik soms heb gebruikt, was om de hash van het gebruikersnaam/wachtwoord op te slaan, het wachtwoord te wijzigen in iets dat ik ken, verbinding te maken met de database als die gebruiker en dan mijn werk te doen. Als u klaar bent met mijn werk, stelt u het wachtwoord in op wat het was, vergelijkbaar met het volgende:

ALTER GEBRUIKER bob GEDENTIFICEERD DOOR WAARDEN 'asdf1234%^&*qwerty';

Ik hoefde nooit het wachtwoord van de gebruiker te weten om het terug te zetten naar wat het was, zolang ik maar wist dat de hash-waarde was. Gisteren heb ik informatie gevonden waarbij mensen de volgende foutmelding kregen bij een poging om op deze manier een wachtwoord in te stellen in 12c:

ORA-02153:ongeldige VALUES wachtwoordreeks

Als u deze fout opzoekt in My Oracle Support, komt u hoogstwaarschijnlijk terecht op Note 2096579.1. Daarin staat dat deze methode niet meer mogelijk is. Er staat:"Dit is een nieuwe functionaliteit in 12c om gebruikers te dwingen op de juiste manier te worden gemaakt". Maar ik heb ontdekt dat dit niet helemaal waar is.

Oracle 12c heeft nieuwe functionaliteit geïntroduceerd om de hash-waarden voor gebruikers-ID/wachtwoord veiliger te maken. Hier is een link naar de 12c Security Guide waar het gaat over de 12c Verifier voor wachtwoorden. Merk op dat in die sectie een zoutwaarde wordt genoemd die aan het wachtwoord wordt toegevoegd wanneer het wordt gehasht. Laten we een voorbeeld bekijken om te zien waarom dit belangrijk is. Ik maak een gebruiker aan en kijk naar de gebruikers-ID/wachtwoord-hash die is opgeslagen in de SPARE4-kolom van 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

In eerdere versies zou de SPARE4-kolom niet zoveel tekens bevatten. Dit is beslist complexer dan pre-12c-versies. Mijn gok, hoewel niet bevestigd, is dat het S:-gedeelte van de bovenstaande uitvoer de zoutwaarde is. Ik weet niet zeker wat H:en T:voorstellen.

We kunnen het pakket DBMS_METADATA gebruiken om een ​​gebruiker te reverse-engineeren. Als we dat doen, kunnen we zien dat we nog steeds de IDENTIFICEERD BY VALUES-clausule kunnen gebruiken.

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"

En in feite werkt dat ook. Ik verander het wachtwoord van BOB in iets anders, verander het dan in deze hashwaarde en maak verbinding met het oude wachtwoord.

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.

We hebben dus geen functionaliteit verloren, zoals de MOS-notitie suggereerde. We hebben hier alleen te maken met een veel langere hash-waarde.

Waar dit echt belangrijk wordt, is wanneer u exp/imp of Data Pump probeert te gebruiken om gebruikers van een pre-12c-versie naar 12c te verplaatsen. Als u een VOLLEDIGE export van een Oracle 11g-database uitvoert, bevat de dump de oude wachtwoord-hashwaarden. Wanneer u importeert in 12c, ontvangt u de ORA-02153-foutmelding. Om dit probleem te omzeilen, maakt u vooraf de gebruikers in de 12c-database aan met bekende wachtwoorden.


  1. Opstartomgeving configureren in SQL Server Management Studio (SSMS) - SQL Server / TSQL-zelfstudie, deel 7

  2. Oracle 12:deelnemen aan door komma's gescheiden lijst?

  3. Een IF-statement gebruiken in een MySQL SELECT-query

  4. sqlite:hoe voeg ik de totale tijd toe uu:mm:ss waarbij het kolomgegevenstype DATETIME is?