Salut à tous,
Voilà je fais un petit site qui à un petit caractère communautaire.
Quelle est la meilleure façon de crypter un mot de passe.
J'utilise le connu MD5 mais cette fonction de hachage ne permet pas de "dé-hacher" le pass, or je voudrais quand même pouvoir voir le pass en clair...
 
Merci d'avance.

GRMLRMLML!!! Je vais le redire encore une fois pour ceux qui ne l'aurait pas lu:
 
LE HASHAGE N'EST PAS DU CRYPTAGE. HACHER SES MOT DES PASSE, C'EST SE CREER VOLONTAIREMENT UNE FAILLE DE SECURITE!!!!

Je sais, c'est justement pour ca que je souhaite utiliser autre chose

http://www.dwam.net/docs/php_fr/manuel_ref.mcrypt.html
 
apparemment bijective. saches que c'est idiot

"apparemment bijective. saches que c'est idiot "
Lol je doit être idiot moi aussi mais j'ai pas compris ^^

 
Idiot? Pourquoi?
C'est ce que j'utilise, je ne trouve pas ça idiot...

C'est bien beau d'utiliser crypt() mais si t'as besoin de ton pass en clair a un moment ou un autre t'as l'air fin avec cette fonction.

Un algo de cryptage est TOUJOURS réversible. Autrement tu ne peux pas garantir que le produit de ton cryptage est unique et donc tu introduis une faille.

 
Tu peux m'expliquer comment decrypter une chaine de caracteres cryptée avec crypt()?

ouais tu dois en avoir pour quelques années c'est vrai .....
 
> pour les autres : c'est idiot car a priori tu peux très bien te passer d'avoir besoin de ton password en clair et ca cosntitue une faille

Donc je garde md5 ?

 
il faudrait que je regarde comment fonctionne l'algo, mais ce ne doit pas être très compliqué.

 
on est plus au temps des 8088. Trouver un mot qui aura la même clefs md5 qu'un autre ne mettra, au plus, que quelques jours.

je demande a voir pour des chaines avec plusieurs caracteres ( au moins 5-6 ) ...

Mais on s'en fout du nombre de caractère! un algo de hashage te donnera TOUJOURS un résultat codé sur un nombre de bits IDENTIQUE. Avec cela, tu pourras donc trouver une infinité de chaines qui donneront ce même résultat. Peu importe que le mot de passe originel fasse 1 ou 100 caractères, ce qui compte, c'est le premier que tu trouvera qui donnera le même résultat.

Tu connais la taille de l'espace d'arrivée ?
C'est égal à 2 ^ 128 soit environ 3 * 10 ^ 38   !!!
 
Je sais pas si tu réalises bien à quoi cela correspond (l'âge de l'univers vaut environ 3 * 10 ^ 17 secondes).

 
Tu crois pas que tu exageres un tout petit peu?
 

 
A moins d'avoir un sacré paquet de machines dispo chez toi je crois que tu reves vraiment.
 
EDIT : md5 je sais pas. Je parlais de la fonction crypt(). On peut utiliser DES ou Blowfish avec cette fonction.

 
Pour éviter en partie cela, et vu que je suis limite parano quand même, moi je fais un truc qui détecte les brute force (nb de tentative par x secondes par exemple) sur mes pages d'authentification

Pour éviter le brute force on peut aussi faire un système d'image aléatoire avec un code indiqué sur l'image qu'il faut retaper.

c vrai ke c une solution plutôt radicale

pas vraiment adapté à un module d'authentification quand même

 
Ouais c'est clair, un p'tit peu lourd quand même

Pourquoi ? Je veux des arguments valables

Lourd pour l'utilisateur, devoir taper login, mot de passe + le truc aléatoire à chaque fois qu'il se connecte, c'est vite saoulant.

gizmo minifestement tu ne sais pas de quoi tu parles...  Le hashage n'est pas du cryptage certes, mais pour un site web c'est la seule solution sûre, justement parce qu'il est difficile (beaucoup plus que tu ne le laisse entendre) de trouver un pass qui donne un hashage donné. Si tu utilises un algo de chiffrage a clée comme tu sembles le suggérer, alors la clée en question est forcément aussi facile à récupérer que le mot de passe chiffré lui même (sinon un soft ne serait pas capable seul de dechiffrer le passe chiffré). Cherche l'erreur...
 
Et quant a cracker du md5 en quelques jours sur un PC, je crois que tu n'a pas la notion de l'immensité de l'espace de recherche.

n'importe quoi! le md5 ne donne des clefs uniques, au maximum, que pour des pass d'au plus 16 caractères. En comptant les pass de moins de 16 caractères, on diminue encore ce nombre.
 
Et quand tu utilises une protection avec clefn non seulement tu utilise un principe de clef public/clef privée, ce qui permet de ne pas faire voyager n'importe quoi sur le réseau, mais en outre tu le fais via un canal sécurisé, https par exemple.
 
Si tu ne fais pas cela, mis à part pour éviter les attaques sur le serveurs et que tu ne veux pas que le hackeur choppe les mots de pass originels, le hashage n'est pas une sécurité en soi.

 
j'ai rien compris à ce que tu dis mais toi je crois que tu n'as rien compris au md5...dans le même genre on peut aussi utiliser comme hash SHA-1
 
md5("a" ) = "0cc175b9c0f1b6a831c399e269772661"
sha("a" ) = "86f7e437faa5a7fce15d1ddcb9eaeaea377667b8"

De toute façon pour pouvoir exploiter la non-unicité des hash md5, il faut justement avoir récupéré le hash md5 du mot de passe. Ce qu'on trouve généralement dans un cookie déposé pour éviter à l'utilisateur de rerentrer son mot de passe (lorsqu'on ne passe pas par un identifiant unique de session).
 
A ma connaissance, le vol de cookies ou d'id de session ne peut se faire que s'il existe déjà d'autres vulnérabilités sur le site ou sur la machine cliente. Donc ça revient à dire "si le site a des failles, le md5 présente un risque". Autant lutter directement contre les problèmes existants, notamment l'injection et le vol d'id de sessions.
 
Pour éviter la force brute, le système utilisé par Yahoo est assez simple : au bout de 5 essais manqués, la saisie d'un texte depuis une image générée est requise. Les erreurs d'innatention ou de frappe de l'utilisateur ne sont pas pénalisantes pour lui, un bot faisant du bruteforce sera systématiquement débouté.
 
Sinon il est toujours possible d'utiliser un cryptage plus complexe sur le mot de passe (en dehors de toute considération de https) et de conserver une clé sur le serveur. A la condition que ni la clé ni les versions cryptées du pass ne soient accessibles, l'attaquant peut toujours essayer de trouver un pass qui marche (il aura plus vite fait de tenter quelques passwords classiques de dictionnaire)

Dans le cas ou on stocke dans un cookie le mdp de l'utilisateur, hashé en md5 par exemple, j'vaais pensé à le traffiquer un tout petit peu, genre je prends la dernière lettre du truc généré par le md5 et je la fous au début. Comme ca, si quelqu'un essaye de faire un truc à partir de ce md5, il partira dès le départ sur un truc faux. Evidemment après sur le site suffit juste de faire l'opération inverse pour retrouver le "vrai" md5.

Je pensais moi à "md5isé" le mot de pass, puis de lui ajouter le sha de ce meme mot de passe, l'insérer dans la base et ainsi la personne qui accède a la base de données, va chercher soit un sha soit un md5...
Bref varianter le résultat ...

 
Et si tu lisais ce que j'ai écrit, tu comprendrais que l'utilisation de clée privées et publiques ne change rien au problème. Si tu chiffres les mots de passe, c'est parce que tu as peur que quelqu'un accède aux passwords. Or si ce quelqu'un peut accéder aux passwords (chiffrés), il peut tout aussi bien accéder a la clée privée, puisque cette clée privée est faite pour être lue par le même programme qui lit aussi les pass chiffrés. Physiquement elle sera sur la même machine que les pass, ou pas bien loin. Mais en tout cas accessible.

Sauf que tu supposes que l'attaque se fait sur le serveur, alors qu'il est NETTEMENT plus facile de s'attaque au client.