Quel cryptage "sans clé" aujourd'hui ?

Salut, tout est dans le titre… quel cryptage “sans-clé” peut-on utiliser aujourd’hui, pour crypter les mots de passe en base Oracle, à tout hasard (c’est là que ça se complique).
Par que MD5 c’est mort (j’ai pu tester sur un mot de passe aléatoire sur un site russe : cracké en 2h), SHA-1 c’est pas mieux.
C’est quoi le nouveau “standard” en la matière (et qui demande pas 300 jours à pondre, qui soit reconnu par la majorité des bignous du marché… parceque MD5 est mort y’a bientot 2 ans, alors faudrait qu’ils commencent à changer, les standards) ?

C’est quoi l’adresse du site russe? Ca m’intéresse, pour tester des mots de passe. Pour voir combien mes mots de passe à 10+ caractères tiennent, et tester en augmentant la longueur.

Je ne sais pas si c’est bien dans la politique de cafzone de donner ce genre de lien, alors si les modos le sentent pas, qu’ils fassent le ménage sans trop chercher (parceque c’est quand même comme donner un lien sur le site de la mule… on peut toujours dire qu’on est pas responsable de ce que les gens en font, mais bon…)
http://passcrack.spb.ru (qui crack les hash MD5 et SHA-1)

Les 2 que j’ai testé, proches de mots de passe que j’utilise, n’étaient pas dans leur table de hash. Toujours ça de pris, mais vu que ce ne sont pas exactement les mots de passe que j’utilise, ça ne me sert finalement pas à grand chose :stuck_out_tongue:

Merci pour le lien en tout cas

[quote=« Coldorak, post:4, topic: 27622 »]Les 2 que j’ai testé, proches de mots de passe que j’utilise, n’étaient pas dans leur table de hash. Toujours ça de pris, mais vu que ce ne sont pas exactement les mots de passe que j’utilise, ça ne me sert finalement pas à grand chose :stuck_out_tongue:

Merci pour le lien en tout cas[/quote]
Oui mais attention ! Y’a la 2eme chance au grattage !
Tu as surement testé face au « dictionnaire » de 10 millions de mots, mais il faut aussi les mettre à l’épreuve du RainbowCrack (etape 2), qui elle a pris 2 heures lors de mes essais

Les miens passent pas au Rainbow, ya des caractères chelous dedans (vive les passwords en UTF8 :P)

Déja, on dit pas cryptage, mais chiffrage. Et là, on parle pas de chiffrage, mais de hashage (fonction a sens unique), et vu les méthodes de cassage utilisées (force brute sur le clair), tu pourra faire ce que tu veux, ca sera toujours “cassable”. Pasque que ca soit MD5 ou SHA-1, ce sont des fonctions surjectives… (pour un SHA-1 ou MD5 donné, t’as plein de sources possibles, avec effectivement des plus probables que d’autres).

Par contre, si ton but, c’est de pas pouvoir avoir les mots de passe directement en ayant le MD5 ou le SHA-1, c’est déja le cas. Par contre, peut-être interressant de rajouter un grain de sel avant de faire le MD5 (utiliser bien sur le même grain avant stockage ou comparaison).

[quote=“urdle, post:1, topic: 27622”]Salut, tout est dans le titre… quel cryptage “sans-clé” peut-on utiliser aujourd’hui, pour crypter les mots de passe en base Oracle, à tout hasard (c’est là que ça se complique).
Par que MD5 c’est mort (j’ai pu tester sur un mot de passe aléatoire sur un site russe : cracké en 2h), SHA-1 c’est pas mieux.
C’est quoi le nouveau “standard” en la matière (et qui demande pas 300 jours à pondre, qui soit reconnu par la majorité des bignous du marché… parceque MD5 est mort y’a bientot 2 ans, alors faudrait qu’ils commencent à changer, les standards) ?[/quote]

SHA-256.

+1. A mon avis pour ton problème, rajoutes simplement une bosse gross valeur de salt sur les mots de passe et tu gardes cette clé dans ton appli (ce qui sous-entend qu’avant de lancer une attaque sur tes mdp, il faudra, en plus de ta base, avoir récupéré le source de ton appli).

SHA-256 changera rien au problème. Vu le type d’attaque, suffit que le mot de passe soit pas trop gros, et on a vite fait de retrouver un mot de passe dont le SHA-256 correspond. Après, normalement, si la base et l’appli sont bien concues, le hash du password ne doit pas sortir de la base, et mieux, être en ecriture seule (avec une proc-stoc pour la vérification).

[quote=“Tzim, post:7, topic: 27622”]Déja, on dit pas cryptage, mais chiffrage. Et là, on parle pas de chiffrage, mais de hashage (fonction a sens unique)[/quote]Bouuuuuhouhouh… j’me fais grooonder. Oui bon effectivement, j’ai été imprécis sur les termes, je m’en excuse.
Si le mot de passe est court, la force brute en viendra forcement à bout, reste à voir en combien de temps, mais ce que je reproche à MD5, c’est qu’on en vienne à bout en 2h montre en main. Même un vieux chiffrage tout pourrave comme celui de la SAM sous NT4 (48 bits, houlàlà) on met plus de 2h à cracker un mot de passe sur une bécane normale.
Après tu me parles “d’appli bien codée” et justement c’est là tout le problème… moi, je suis le client dans l’affaire, et avoir un mot de passe chiffré MD5 ou pas chiffré, c’est finalement pareil (vu comme c’est standard le MD5, tu m’étonnes que le pirate en herbe il va commencer par tester celui là d’algo de chiffrage sur un truc qui est une chaine de 32 caractères hexadecimaux… d’ailleurs c’est ce que j’ai fait moi quand j’ai voulu savoir quel algo ils utilisaient).
Le coup de la procédure stockée, ahahah, j’en rigole d’avance vu les branquignoles, mais tu as parfaitement raison (c’est d’ailleurs la conclusion à laquelle j’étais arrivé cet après midi), mais j’irai plus loin, stocker des mots de passes dans la base oracle pour une application actuelle, devrait être considéré comme une hérésie à moins d’intégrer ça dans un vrai protocole d’authentification à grand coup de procédures stockées (empecher le rejeu, etc, etc)… Mais bon, à chacun son metier, et c’est pas le metier d’oracle que de faire de l’authentification.

SHA-256 semble tenir la route quand même (les mots de passe sont pas des mots en général, et les utilisateurs “sensibles” ont été … sensibilisés… mouahahahah ahahahah… oh pinaise, j’ai besoin de vacances moi).

Merci

Bah, si ca s’appelle fonction de hachage et pas fonction de chiffrage, ca à bien une raison. Le but d’une fonction de hash, c’est juste de te filer une chaine de bits de longeur fixe a partir d’une chaine d’octets de longueur quelconque.
Après, si MD5 et SHA-1 tiennent moins longtemps que SHA-256, c’est tout simplement que calculer un SHA-256 est sensiblement plus long, mais calculatoirement, c’est tout aussi “facile” a casser sur un parcours exaustif des passwords possible.

Alors effectivement, MD5 et SHA-1 ont été cassés. Mais faut savoir comment. Une fonction de hash crypto doit avoir les 3 propriétés suivantes :
* il est très difficile de trouver le contenu du message à partir de la signature (attaque sur la première préimage)
* à partir d’un message donné et de sa signature, il est très difficile de générer un autre message qui donne la même signature (attaque sur la seconde préimage)
* il est très difficile de trouver deux messages aléatoires qui donnent la même signature (résistance aux collisions)

Alors, oui, MD5 et SHA-1 sont tombées, et ca a fait tout un foin, car ne respectent plus là 3eme propriété. Mais dans le cas précis, c’est la première qui nous interresse, et elle est toujours valable, car il n’y a pas vraiment autre chose qu’une recherche exhaustive dans l’algo de tes amis russes. Note : pour les controles sur les fichiers, c’est bien sur la seconde qui est interressante…

(Je savais tout ce que tu racontes… euh… à une époque :stuck_out_tongue: Ca énerve de se rendre compte du nombre de trucs qu’on a oubliés/déformés)
En 2h c’est par force brute sur MD5 ? La vache… Nan mais alors ça a jamais été vraiment sûr pour stocker des mots de passe d’utilisateur ! Quand j’ai lu qu’ils « déconseillaient désormais », j’ai supposé qu’à un moment ils considéraient qu’on pouvait… j’suis naïf des fois :stuck_out_tongue:

Donc y’a rien à foutre, faut passer au level supérieur, j’vais leur dire d’utiliser un chiffrage par clé asymétrique (par une clé qu’on fourni NOUS), et puisqu’on a pas besoin de retrouver le mot de passe on aura pris soin de jeter la clé privée aux oubliettes du confin de la galaxie…
Bon, RSA est pas encore cassé ? (il me semble avoir lu craquelait un peu sur les bords, non ?)

Ca y est, je vais devenir paranoïaque.

[quote=“urdle, post:13, topic: 27622”]Donc y’a rien à foutre, faut passer au level supérieur, j’vais leur dire d’utiliser un chiffrage par clé asymétrique (par une clé qu’on fourni NOUS), et puisqu’on a pas besoin de retrouver le mot de passe on aura pris soin de jeter la clé privée aux oubliettes du confin de la galaxie…
Bon, RSA est pas encore cassé ? (il me semble avoir lu craquelait un peu sur les bords, non ?)[/quote]
Ca t’avancera a rien.
Si j’ai la clé publique, que t’es bien obligé de garder dans le code qui va inserer les mots de passe, je fais pareil : je chiffre tout les mots de passe possibles, je trouverais bien celui qui donne le même chiffré. Ca va juste me prendre un poil plus de temps, pasque faire un RSA, c’est un poil plus long. Si le mot de passe est faible, ca va rien changer.

Si tu es capable de proteger le code, le mieux est d’utiliser SHA1 ou SHA256 avec un grain de sel… et de protéger le grain de sel.

bah a la limite, vu qu’a ma connaissance, il n’y a pas encore de "vraieé solution de remplacement pour sha1 et md5, t’as qu’à utiliser les deux…
un truc du style sha1(md5(clé) + aléa) ou aléa est une graine… avec ca, je suis pas sûr que ca soit super crackable. Ou alors md5(md5(clé)) (c’est le principe même de md5)
ah et puis comme algo qui existe, y a hmac-md5 ou hmac sha. ils ne sont pas affectés par les collisions sur md5/sha

Ouiiiiiin ! Mamaaaaan ! Y’a tzim il fait rien qu’à m’embeter !
Bon, ok, j’avoue, c’est pas la connaissance qui me fait défaut sur ce coup, c’est le recul et la réflexion, je dis que des conneries. Merci Tzim de m’ouvrir les yeux.
Face à une attaque par force brute, on ne peut rien, faut interdire l’accès en lecture aux mots de passe et basta (comme tout système d’authentification qui se respecte quoi, c’est tellement logique), mais vu les stars en face (niveau qualité du bouleau général, ça c’est un détail dans la liste des trucs qu’on leur reproche), je pense que c’est rapé (j’suis même pas sûr qu’ils sachent faire une procédure stockée), mais j’vais les titiller voir si ils tiquent.

merci encore

Voila :stuck_out_tongue: Bon, je me permet juste d’insister sur le grain de sel. Ca évite la comparaison toute bète de hash (du genre « tiens, dans l’appli truc et l’appli much, son mot de passe donne le même hash → c’est le même »). Bon, chuis désolé, mais pour moi, c’est tout frais (certains trucs que je viens de revoir dans les dernières heures, NB : le GSM, c’est tout pété, ca se casse en 8 trammes transmises bouh !).

OK, et le grain de sel, on le code en dur dans l’application ?

En dur, dans un fichier sur le disque… tout dépends de ton modele de sécurité…