Discussion :

[pascale86]

On a un serveur avec une base oracle. Un nouveau serveur a été installé, la société qui maintient l'appli a installé a distance oracle et a laissé des instructions pour implanter la base de l'ancien serveur sur le nouveau serveur.
A savoir (je remets texto) :
- lister tous les utilisateurs de l'ancien serveur, avec leur mot de passe
- recréer ces utilisateurs sur la nouvelle base avec le même mot de passe et le même role
- faire un export full de l'ancien serveur
- faire un import sur le nouveau en précisant fromuser=(....)
- recréer les synonymes publics pour toutes les tables

voilà

[nuke_y]

- lister tous les utilisateurs de l'ancien serveur, avec leur mot de passe
- recréer ces utilisateurs sur la nouvelle base avec le même mot de passe et le même role

Si l'intérêt de la liste du point 1) c'est juste de pouvoir alimenter le point 2), alors la liste des USERS + mdp cryptés suffira (cf exemples au dessus).

Par contre si le but c'est d'obtenir une liste exhaustive des utilisateurs ET de leurs mots de passe en clair, alors il faudra faire une demande aux utilisateurs pour obtenir leurs mots de passe.

[remi4444]

En gros, est-ce que ton point 1 fait partie du besoin (et dans ce cas là pourquoi), ou est-ce une "premiere étape" pour résoudre le point 2 ?

Si c'est texto les instructions que tu as, alors la société en question a tout simplement demandé un truc impossible...

Non seulement impossible, mais surtout absoluement INTERDIT d'un point de vue sécurité et éthique... pourquoi?... parcequ'à notre époque, on sait tres bien qu'on utilise tous plus ou moins les mêmes mots de passes pour les dizaines d'accès qu'on a à droite et à gauche, donc si tu demandes un mot de passe utlisateur qu'il a choisi sur un programme, tu peux t'amuser à l'essayer sur son site de compte en banque, mail ou autre...

[orafrance]

avec toutes les infos c'est beaucoup plus clair et en effet, la recréation des users avec l'option identified by value comme ça a été montré auparavant suffira amplement

[Arkadius]

Bonjour,

Je reprends ce message car j'ai une question similaire tout en étant tout à fait différentes sur la plan moral.

En fait je suis en train de développer une application de reporting (php/oracle) autour d’un ERP.

En tant que RSI je connais tous les mots de passe des utilisateurs (puisque c’est moi qui les ai crée….)

Mon objectif est de parmettre à chaque utilisateur de se connecter à son espace personnalisé en utilisant le couple profil/ mot de passe stocké dans la base. Aujourd’hui l’accès se fait avec un mot de passe générique.

Donc j’ai les mots de passes en clair
J’ai les logins


Comment faire pour tester si le mot de passe saisi en clair par l’utilisateur dans l’appli correspond au mot de passe crypté dans la base de données ?

Merci d’avance pour vos réponses.

[orafrance]

déjà d'un point de vue de la sécurité c'est très mal fait. Tu aurais dû stocker les mots de passe crypter en utilisant la fonction de cryptage utilisé par l'appli.

Pour répondre à la question, tu dois crypter le password clair pour comparer les 2 valeurs cryptées.

[Arkadius]

On ne s'est pas compris...

Les mots de passe dans la base de données sont cryptés. Les couples login/mot de passe sont créer dans la base de données via l'application développé avec forms.

Moi, je connais ces couples login/mdp (puisque j'ai crée les comptes dans l'application métier).

Mais les mots de passe sont justement cryptés dans labase or lorsque je passe par l'application que j'ai crée moi en php/Oracle... le mot de passe saisi par l'utilisateur est saisi en clair.

Quelle fonction dois-je appliquer à ce mot de passe saisi en clair pour le crypter afin de vérifier finalement l'équivalence entre le mdp saisi ainsi et le mot de passe présent dans la BDD (qui lui est déjà stocké crypté).


Merci

PS: En espérant avoir été un peu plus clair

[LeoAnderson]

Deux solutions :
1. Soit vous avez une deuxième base et vous y crééz les users avec les mots de passe en clair puis vous comparez les hash codes obtenus (lourd !)
2. Soit vous essayez de vous connecter avec les mots de passe en clair : si la connection réussit, c'est donc que le hash de dba_users correspond au mot de passe en clair (simple )

[orafrance]

une autre technique sous Oracle consiste à créer la concaténation user/mdp qui existe mais avec un user qui n'existe pas... je m'explique

TOTO/TATA = TOTOTA/TA

Le hash de la colonne password est le hash de la concaténation user + password. Donc pour vérifier que le user TOTO a bien le password TATA tu peux crééer le user TOTOT avec le password ATA et comparer les hash values.

Attention, cela ne fonctionne plus après la 9i où la sécurité a été améliorée

[LeoAnderson]

une autre technique sous Oracle consiste à créer la concaténation user/mdp qui existe mais avec un user qui n'existe pas... je m'explique

TOTO/TATA = TOTOTA/TA

Le hash de la colonne password est le hash de la concaténation user + password. Donc pour vérifier que le user TOTO a bien le password TATA tu peux crééer le user TOTOT avec le password ATA et comparer les hash values.

Attention, cela ne fonctionne plus après la 9i où la sécurité a été améliorée

Ah bon ??????????????????

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
 
SQL > create user scott identified by tiger;
 
User created.
 
SQL > create user scottti identified by ger;
 
User created.
 
SQL > select username, password from dba_users where UserName like 'SCOTT%';
 
USERNAME                       PASSWORD
------------------------------ ------------------------------
SCOTT                          F894844C34402B67
SCOTTTI                        F894844C34402B67
 
SQL > select * from v$version;
 
BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bi
PL/SQL Release 10.2.0.3.0 - Production
CORE    10.2.0.3.0      Production
TNS for Solaris: Version 10.2.0.3.0 - Production
NLSRTL Version 10.2.0.3.0 - Production

[orafrance]

on m'avait dit que c'était réglé... et je l'ai cru naïvement

[LeoAnderson]

on m'avait dit que c'était réglé... et je l'ai cru naïvement

et tu le répètes... sans prendre la peine de vérifier ?

[orafrance]

j'avoue ... pour info en 11g la colonne... est vide

[laurentschneider]

ça a été changé en 11g (pas 10g), avec les mots de passes "case-sensitives".

La valeur de la vue DBA_USERS.PASSWORD est null, et dans la table SYS.USER$.PASSWORD, on retrouve la valeur concaténée SCOTTTIGER, par contre dans SYS.USER$.SPARE4 on trouve une chaine plus complexe.

la valeur est calculée avec l'algorithme SHA1 et avec un sel (SALT), mais toujours apparement en fonction de la concaténation des chaines. C'est à dire, le mdp de SCOTTT/IGER fonctionnera aussi pour SCO/TTTIGER (mais pas sCotTt/iGeR)


PS: dernière remarque non-testée pour l'instant

[orafrance]

C'est à dire, le mdp de SCOTTT/IGER fonctionnera aussi pour SCO/TTTIGER (mais pas sCotTt/iGeR)

ce qui reste une calamité pour la sécurité

[laurentschneider]

bon la grosse différence c'est qu'ils auront des chaines user$.spare4 différentes, mais vu qu'ils auront toujours la même chaine user$.password on aura rien gagné.

Je pense que l'intérêt de supprimer l'affichage de PASSWORD dans DBA_USERS est pour les clients puissants style TOAD à qui l'ont peut donner uniquement SELECT_CATALOG_ROLE

PS: scott/tiger peut avoir des milliers de mot de passe 11g possibles grace au sel.

[SnakeNET256]

Bonjour,

Je suis DBA sous Oracle 8 ,9 et 10, et j'ai trouvé un soft pour cracker en brute force le mot de passe d'un utilisateur.

Requis : nom de l'utilisateur et son mot de passe crypté. (facile car je suis DBA)

Ca met beaucoup de temps (environ 20 heures) pour un mot de passe standard, mais ca me permet de récupérer des mots de passe que les utilisateurs ne veulent pas me donner...

C'est pas vraiment légal mais ca me facilite beaucoup la vie.

[dgi77]

Très très étonnant ! Je suis hyper-sceptique !
Il est de notoriété publique que l'algorithme de cryptage est irréversible.
Donc, tant que tu ne m'auras pas prouver le contraire, je ferais plus confiance à Oracle qu'à toi...
Des milliers de personnes dans le monde se sont penchées sur le problème, et toi tu nous balances ce genre de fake à la figure. Tu nous prends pour des jambons ou quoi ?
Pourquoi tu nous dis avoir trouvé ce crack et tu ne nous le montres pas ?

Edit : tu entends quoi par "brute force" ?
Un algo qui essaie toutes le combinaisons jusqu'à tomber sur la bonne au bout de 20 heures, un peu comme ceux qui crackent Canal + ?

[orafrance]

c'est effectivement faisable et 20h ça parait même très long... ça prend quelques dizaines secondes pour un mot de passe de 6 lettres. Mais évidemment c'est illégal

Il est de notoriété publique que l'algorithme de cryptage est irréversible.

le brut-force ne décrypte pas le password mais en essaye des milliers... il est de notoriété public que la sécurité sur Oracle est déplorable

[laurentschneider]

bon, 20h c'est bidon comme mesure, je pense qu'avec un mot de passe de 12 charactères employant chiffres, lettres et charactères spéciaux ça va prendre plus (environ le temps d'essayer 100^12 mot de passes, donc quelques siècles!!!)