Discussion :

[mattrixx]

Bonjour à tous,

Voilà mon petit problème, enfin question.

je travail avec un cryptage AES au niveau de ma DB en MySQL, je crypte avec une clef qui se trouve dans une méthode et je passe tout cela dans la requete sql qui va crypter le MDP dans la db

pour le décryptage je reviens de la DB avec le MDP décrypter par cette même procédure, c'est à dire méthode jsp envoie clef vers DB et DB renvoie le MDP décrypter vers l'application


Enfin je vous explique, enfin je vais essayer

Les mots de passe sont cryptés en AES au niveau de la DB, dans l’application j’appelle une méthode qui contient la clef d’encryption, et je la passe en argument lors de la requête en DB.

Donc là première faille, la clef passe de l’application vers la Db en claire, un sniffer et bingo.

Deuxième faille on décompile l’application et on peut trouver la clef d’encryption dans une méthode de l'application, un fichier contant plus précisément.

Je me dis je tape la clef dans la DB (dans les procédures en dure), mais alors un changement de la clef et je suis bon à revoir toutes les procédures.

Puis je me dis que je peux aller chercher en DB le MDP et le vérifier via l’application pour comparaison, mais pour moi cette solution n’est pas idéale non plus.

Donc je viens vers vous pour savoir comment vous fonctionner à ce niveau-là qu’elles sont tes techniques pour la sécurisation des MDP entre l’application et la Db.

Je me prends la tête depuis juin, mais je tourne en rond.


Un grand merci pour vos lumières J

M@t

[Jimmy_]

Bonjour,

La technique pour les mots de passe n'est pas celle là.

Il faut jeter les mots de passes et ne conserver que leur hashage. Il faut utiliser de nos jours un algorithme SHA-256 au moins. Ensuite pour valider un acces, tu hashes le mot saisi et tu regardes si dans ta base c'est bien le même.
La propriété de SHA-256 te garantie que si le hash est identique, le mot d'origine est identique. L'autre propriété est qu'il est quasi impossible en un temps humain de retrouver le mot de passe avec le hash.

Les seules attaques possibles, sont les attaques par dictionnaire, donc pas de mot de passe faible par exemple ...


Plusieurs avantages :
- En cas de vol de ta base, il est impossible de retrouver les mots de passes des gens.
- Aucune information en clair ne circule.


Bon courage,

[mattrixx]

Merci pour l'info

d'autre personne utilise autre chose ?

[tchize_]

La propriété de SHA-256 te garantie que si le hash est identique, le mot d'origine est identique.

Mmm non, du tout. Le hash te garanti que si les mot de passe sont identiques, les hashs le seront aussi, pas l'inverse. Une des caracéristiques principale d'une fonction de hashage est justement de ne pas être bijective
[/QUOTE]

Sinon, c'est effectivement la voie à suivre, tout autre technique ne serait que bidouille dangereuse pour tes utilisateurs.

Pour résumer

a la creation
mot de passe -> hash() -> insert

au login
mot de passe -> hash() -> select where user=... and hashedPassword=...

Les seules attaques possibles, sont les attaques par dictionnaire, donc pas de mot de passe faible par exemple ...

Et surtout, toujours saler le mot de passe pour ne pas se faire avoir par une ferme de hash précalculé . Le salage consiste à ajouter une chaine statique
devant le mot de passe. Ainsi, même si tu as acheté un dictionnaire complet de hash précalculés dans lequel il est mit que fb05beae7f226651d6a65bf840531b617e5c17650a408534a803cf17e6d54312 correspond à htx69Az, ça n'avancera à rien pour l'attaque car on a prix soin de rajouter {trucbidule} devant, ce qui donne ae455d884a3c3fa5a1c41226ec87b1b4e2f0827fc518922495b6c75d32a7fe45. Et comme trucbidule t'es le seul à utiliser, aucun chance qu'une liste statique ne soit déjà précalculée pour

[mattrixx]

Super et je viesn de voir que ce n est pas complexe à mettre en oeuvre.
Par contre j ai Lu que AES étais un des meilleur cryptage. Pourquoi alors hacher avec cette algo

Merci

[tchize_]

AES et un algo de chiffrement, SHA est un algo de hashage, ce n'est pas du tout prévu pour les même usage. Avec du chiffrement, on veux pouvoir inverser avec la bonne clé, avec du hashage, on veux interdire l'inversion.

[mattrixx]

Ok merci pour l info.
Mais alors quand va t on utiliser aes ?
Desoler pour le boulet mais je voudrais comprendre, merci

[tchize_]

On utilisera l'AES pour le chiffrement symétrique. C'est à dire avec une clé secrète que les deux parties doivent connaître. C'est utilisé par exemple pour le chiffrement dans les protocole TLS et SSL. C'est aussi utilisé indirectement dans les protocole de chiffrement assymétrique afin d'augmenter la sécurité.

[mattrixx]

super merci a tous pour vos reponses

[Jimmy_]

La propriété de SHA-256 te garantie que si le hash est identique, le mot d'origine est identique.

Mmm non, du tout. Le hash te garanti que si les mot de passe sont identiques, les hashs le seront aussi, pas l'inverse.

Oui j'aurai du ajouter que trouver deux mot de passe différent, donnant le même hash relève pour l'instant de l'impossible en pratique , cela reste théoriquement possible bien entendu.

[tchize_]

Oui j'aurai du ajouter que trouver deux mot de passe différent, donnant le même hash relève pour l'instant de l'impossible en pratique ,

De la même manière qu'il est très difficile de trouver 1 mot de passe qui corresponde au Hash.

Ici c'est rendu encore plus compliqué par le fait que les hash font 32 byte, et que le mot de passe de monsieur tout le monde fait moins de 32 symboles. L'espaces des hashs est donc en général plus grand que celui des mots de passe

Mais meme en md5 avec 16 bytes on peux trouver des collisions.

[mattrixx]

commence à devenir dur à vous suivre là :-)

pour finir c'est sécur ou pas comme méthode ?

[Jimmy_]

pour finir c'est sécur ou pas comme méthode ?

Oui comparer les hashs et non les mots de passe est la méthode standard pour de l'authentification simple par mot de passe.

Tu ne prends jamais le risque de stocker ou de faire transiter un mot de passe en clair.