Depuis que je me souviens de ma carrière chez Oracle, j'ai pu modifier le mot de passe d'un utilisateur en hachage de mot de passe. L'astuce que j'ai parfois employée consistait à stocker le hachage ID utilisateur / mot de passe, à changer le mot de passe en quelque chose que je connais, à me connecter à la base de données en tant qu'utilisateur, puis à faire mon travail. Une fois mon travail terminé, redéfinissez le mot de passe sur ce qui ressemblait à ce qui suit :
MODIFIER L'UTILISATEUR bob IDENTIFIÉ PAR LES VALEURS 'asdf1234%^&*qwerty';
Je n'ai jamais eu besoin de connaître le mot de passe de l'utilisateur pour le remettre à ce qu'il était tant que je savais que la valeur de hachage était. Hier, j'ai trouvé des informations où les gens recevaient l'erreur suivante lorsqu'ils tentaient de définir un mot de passe de cette manière en 12c :
ORA-02153 :chaîne de mot de passe VALUES invalide
Si vous recherchez cette erreur dans My Oracle Support, vous tomberez très probablement sur la note 2096579.1. Dans cette note, il est indiqué que cette méthode n'est plus possible. Il dit "Il s'agit d'une nouvelle fonctionnalité dans 12c pour forcer les utilisateurs à être créés de la bonne manière". Mais j'ai découvert que ce n'est pas tout à fait vrai.
Oracle 12c a introduit une nouvelle fonctionnalité pour rendre les valeurs de hachage ID utilisateur/mot de passe plus sécurisées. Voici un lien vers le Guide de sécurité 12c où il est question du vérificateur 12c pour les mots de passe. Notez que dans cette section, il est mentionné une valeur de sel ajoutée au mot de passe lorsqu'il est haché. Pour voir pourquoi c'est important, regardons un exemple. Je vais créer un utilisateur et regarder le hachage ID utilisateur/mot de passe stocké dans la colonne SPARE4 de 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
Dans les versions précédentes, la colonne SPARE4 ne contenait pas autant de caractères. C'est nettement plus complexe que les versions antérieures à la 12c. Ma conjecture, bien que non confirmée, est que la partie S:de la sortie ci-dessus est la valeur du sel. Je ne suis pas sûr de ce que H :et T :représentent.
Nous pouvons utiliser le package DBMS_METADATA pour désosser un utilisateur. Lorsque nous faisons cela, nous pouvons voir que nous pouvons toujours utiliser la clause 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"
Et en fait, ça marche. Je vais changer le mot de passe de BOB en quelque chose de différent, puis le remplacer par cette valeur de hachage et me connecter avec l'ancien mot de passe.
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.
Nous n'avons donc perdu aucune fonctionnalité comme l'implique la note MOS. Nous devons juste faire face à une valeur de hachage beaucoup plus longue ici.
Là où cela devient vraiment important, c'est lorsque vous essayez d'utiliser exp/imp ou Data Pump pour déplacer les utilisateurs d'une version antérieure à 12c vers 12c. Si vous effectuez une exportation COMPLÈTE d'une base de données Oracle 11g, le vidage contiendra les anciennes valeurs de hachage du mot de passe. Lors de l'importation dans 12c, c'est à ce moment que vous recevrez l'erreur ORA-02153. Pour contourner ce problème, pré-créez les utilisateurs dans la base de données 12c avec des mots de passe connus.
