Discussion :

[ctxnop]

Je ne connais pas le WEP, comment c'est fait tout ca, je sais juste qu'il ne vaut rien niveau sécurité.
Mais je ne vois pas en quoi, une fourberie telle que je l'ai expliquée pourrait mettre en péril le véritable hash utilisé ou induire des failles. Après tout, le type de fourberies utilisées ne combine pas plusieurs algo, ni rien, ca ne fait que stocker le hash, exactement comme on le fait normalement. Sauf qu'au lieu de le stocker dans une champ bien a part, on le noie dans d'autres infos afin de cacher sa présence.
Je suis pas contre avoir un peu plus d'infos sur ce point, les failles induites par l'utilisation capilotractée des protections.

Edit: Au passage, je rappelle que les tromperies que j'ai expliquée n'ont court uniquement que dans le cadre donné par l'article : la protection de la base des mots de passes. Je n'ai jamais pensé à ce type de fourberie pour la protection d'un protocole réseau par exemple.

[deadalnix]

Dans le cas du WEP, la clef est deux parties :
1/ Une partie en dur, qui est la clef d'accès au réseau.
2/ Une partie variable, qui est le vecteur d'initialisation. Le vecteur d'initialisation est échangé en clair entre la source et le récepteur. L'ensemble clef + vecteur d'initialisation permet de faire une communication cryptée.

Tout d'abord, il faut rappeler que le principe de vecteur d'initialisation est nécessaire sans quoi, une attaque statistique est possible.

Mais, le vecteur d'initialisation peut être amené à être renvoyé et recréé souvent, car si une nouvelle personne se connecte, elle ne connais pas l'IV courant (par exemple).

Si l'on écoute le réseau, on peut ainsi récupérer un ensemble de chiffrés, dont on ne connais pas le clair, mais dont on sait qu'ils donnent tous le même clair, et les IVs correspondants. Par exemple, les requêtes ARP sont un bon client.

Il est possible de retrouver la clef à partir de cet ensemble.

[Oranble]

Oulah ! Désolé mais je n'ai voulu offenser personne, je ne suis absolument pas spécialiste en chiffrement, j'en connais juste les principes et j'ai bien compris que c'était plus ou moins le cas de tous le monde sur ce fil.

C'est justement pour ca que je dit qu'il est extrêmement dangereux d'employer des "solutions maison" qui pourraient s'avérer inefficaces. Je ne parle absolument d'un algorithme en particulier avec telle longueur de clef. Ma remarque était générale, à moins d'être chevronné en maths, il vaut mieux se contenter d'utiliser des outils et méthodes reconnues de tous. Tous les algorithmes de cryptographie ont une spécificité qui est censé les rendre incassable. En mixant des algorithmes, on peut sans le vouloir faire tomber ces techniques. Le Double DES est un exemple qui montre que répéter un algo peut ne rien amener d'intéressant, mais j'ai déjà vu d'autres exemples (désolé je n'arrive pas à les retrouver) où cela affaibli l'algorithme au point de le rendre moins performant que l'original voire tout simplement de ne rien chiffrer du tout.

Donc pour résumer je ne voulais prendre personne de haut, et je m'en excuse si c'est paru comme tel. Je voulais tout simplement mettre en garde ceux qui pourraient avoir l'envie de mixer des algorithmes de cryptographie.

[StreamEarth]

Et si on insère une chaine de caractère dans le mot de passe en clair ?

md5('chaine en +'.'mot de passe saisi du formulaire'.'autre chaine en +');

La si un hackeur a effectivement piqué la base de données, le mot de passe en clair qu'il aura pris du md5 de la base de données sera inutile dans le formulaire de connexion du site.
Vu que ex: Le membre toto a pour mdp "toto", il aura pour md5 "chaine1 + toto + chaine2", la chaine en clair que le hacker aura ne sera donc jamais pareil car sa chaine en clair précédé et suivi par les 2 chaines personnalisés génèrera par le serveur un md5 complètement différent et donc l'attaque complètement inutile.
MD5 de "chain1 + toto + chain2" = ab23e41aa96cd49b12a8e6f1adf8e63c
L'attaquant qui va tester les mdp sans les chain1 et 2 trouvera donc de "ab23e41aa96cd49b12a8e6f1adf8e63c" genre : aze521 qu'il va retester sur le formulaire qui va faire "chain1 + aze521 + chain2" et refusera la connexion à moins de tomber sur le même hashage, gros coup de bol.
(sauf s'il a le code source qui contient la ligne php cité plus haut à moins de protéger le code source par Zend par exemple ^^).

Enfin c'était qu'une idée.

[Jenna]

..."chain1 + toto + chain2"...

C'est une idée effectivement, ajouter une chaine secrête pour complexifier l'attaque.

Mais, le devenir de toute chaine secrête est d'être connue et un jour ou l'autre, elle le sera.

De plus, le jour où tu voudras changer tes chaines secretes (quelqu'en soient les raisons), tu ne pourras pas car comme tu ne peux retourner l'algorithme, tu ne peut pas connaitre le mot de passe et tu ne peux en recréer un nouveau avec tes nouvelles chaines.

L'histoire a montré qu'un bon algorihtme ne doit pas reposer sur le secret de l'algorithme (tes chaines secrêtes font partie de l'algorithme).

[kaymak]

@kaymak:
Ça c'est peut-être ta façon de faire, ce n'est pas celle que j'ai expliqué. Je n'ai pas parlé de sel variant par user et/ou dans le temps. Et si tu fais ainsi, il faudra bien que tu conserve le sel utilisé si tu veux t'assurer que le mot de passe fournit en login est bien le même que celui enregistré en base. Donc retour à la case départ.
Quand à bcrypt, il y a une fonction php fournie avec l'installation par défaut, présente depuis un sacré paquet d'années. Mais encore une fois, c'est du chiffrement, pas du hashage, ca peut paraître semblable, mais les applications en sont totalement différentes. Le chiffrement c'est quand on veux protéger une donner dont la valeur d'origine à une réelle importance. Alors que le hash sert de contrôle uniquement, la valeur d'origine n'a aucune importance. On s'en sert par exemple après un téléchargement, si hash est le même qu'indiqué sur le site du téléchargement, c'est qu'il n'y a pas eu de corruption pendant le transfert. Mais si les hash diffèrent, alors le hash ne te sera absolument d'aucune aide pour trouver ce qui à été corrompu et encore moins pour réparer.

OK, j'ai bien vu le petit oubli de ma part. Méthode intelligente ; ) Et efficace si l'attaquant recherche l'exhaustivité plutôt qu'une information particulière.

pour Bcrypt je n'avais pas percuté plutôt que c'était du cryptage (malgrè le nom de l'algo.... lol), j'avais fais confiance à la newz les yeux fermés.

@Katleen, !!!!

[ILP]

@ctnxop : Je pense qu'en matière de sécurité, il faut toujours développer en prennant en compte le fait qu'un hacker puisse avoir accès au code source. Si un hacker n'est pas trop con en piratant un site Web, je pense qu'il va récupérer les scripts des pages d'identification en plus du contenu de la base utilisateurs.
Il faut donc faire en sorte que même avec le code source, l'interprétation d'un mot de passe crypté soit la plus difficile possible.

[ctxnop]

Jamais dis le contraire.
Seulement, en général, on stock bêtement le hash, donc que l'attaquant arrive a prendre le source avec ou non ca change rien.
En faisant une petite fourberie comme j'ai fais, si l'attaquant à réussit a prendre le source aussi, on se retrouve avec la même sécurité que sans la fourberie, et si l'attaquant n'arrive pas a chopper le script, bah du coup il aura d'abord à s'apercevoir de la tromperie mise en place.
Donc au final, soit la tromperie n'a aucun effet, soit elle fait perdre du temps à l'attaquant.
Vu la simplicité de mise en œuvre, personnellement, je préfère le faire, ca me coute 1h de boulot et j'ai une chance que ca coute un sacré paquet d'heure de mal de tête a l'attaquant...

[belsinker]

Vous semblez considérer tous comme un acquis que si l'attaquant a accès à la BDD, il a accès aux sources ( PHP dans ce cas ).
Or souvent la BDD est sur un autre serveur que le site ( pour les mutualisés payants et les gros sites ) .

[deadalnix]

Ce n'est pas nous.

C'est un principe de base connue et appliqué en sécurité depuis maintenant 130 ans. Fait donc une recherche sur Kerckhoffs, ça devrait éclairer ta lanterne.

Franchement, tu crois que la méthode peut rester secrète longtemps ? Tu es à ce point fidèle à ta boite que tu ne lâche rien même avec des coups de batte dans les tibias ?

Et bien moi pour l'instant, on ne me paye pas assez cher pour un tel niveau de sécurité. D'autant plus que je peux tout cracher, les systèmes que je fait son balance-proof.

[ctxnop]

Je n'aurais pas fait ressortir le nom de Kerckhoffs, mais quoi qu'il en soit, pour moi, il est évident que si on veut faire une sécurité il faut se considérer dans la pire situation qui puisse exister : l'attaquant a accès illimité à tout (BDD, sources, infos système, ...)
Après si tu trouves ça fiable de faire une sécurité en considérant que l'attaquant n'a accès à rien, à aucune connaissance, pourquoi pas, mais ne m'en veux pas si je ne te confie pas mes données

[martvefun]

Je remonte un peu ce vieux post pour reparler du sujet de base (ça a un peu dévié)

Concernant bcrypt il me semble (à confirmer) qu'il s'agit bien d'un algorithme de chiffrement à la base mais dans la doc php de la fonction crypt (on parle bien de celle là ?), ils sont bien clairs :

crypt — One-way string hashing

mais je ne comprends pas comment ils arrivent à utiliser des fonctions de chiffrement symétrique pour les transformer en fonction à sens unique (bon je ne suis pas un spécialiste non plus)

Je n'arrive pas non plus à trouver d'exemple clair d'utilisation de cette méthode (avec un temps d'exécution défini)


J'ai trouvé cet article assez bien fait qui conseil bcrypt comme solution
Enough With The Rainbow Tables: What You Need To Know About Secure Password Schemes


Après évidemment ça dépend de combien de temps bcrypt va résister...
Il est clair qu'il n'existe aucune solution parfaite et qui le resteront mais bcrypt avec des salts et compagnie me semble une bonne idée.

De toute façon, le maillon faible de la chaine restera toujours la stupidité de l'utilisateur qui utilise 1234 comme mot de passe ou le note sur un post it quand on lui en impose un compliqué...


edit: je pense avoir compris comment ça fonctionne

Code php :

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
26
27
<?php
	$str = "hello world";
 
	$salt1 = hash('sha256',microtime()."this is a simple but still hard to guess salt");
	$time1 = microtime(1);
	$user1 = crypt($str,'$2a$10$'.$salt1.'$');
	$time2 = microtime(1);
 
	echo $str."<br/>";
	echo "<br/>user1: ".$user1."<br>salt: ".$salt1."<br>";
	echo "<br>diff: ".($time2-$time1)."<br>";
 
	echo "egal ? ".(crypt($str,$user1)==$user1)."<br><br>";
 
 
	$salt2 = hash('sha256',microtime()."this is a simple but still hard to guess salt");
	$time1 = microtime(1);
	$user2 = crypt($str,'$2a$10$'.$salt2.'$');
	$time2 = microtime(1);
 
	echo "<br/>user2: ".$user2."<br>salt: ".$salt2."<br>";
	echo "<br>diff: ".($time2-$time1)."<br>";
 
	echo "egal ? ".(crypt($str,$user2)==$user2);
?>
 
?>

qui me donne

hello world

user1: $2a$10$eddc466a2e5c360daa86auThhtJUkyexEUwkk3PANuTWgp/UrhuCS
salt: eddc466a2e5c360daa86a9ab656f1cb3a028f86c39927eb7c47003c8cf417026

diff: 0.090398073196411
egal ? 1


user2: $2a$10$93dfd9d62ea4617a7af62uViXNslwmQTnU9wDlC.dfXnXQ6GJbPXW
salt: 93dfd9d62ea4617a7af627e319fa848eca82a1465b6a50d540c2ad206f5942fe

diff: 0.089483976364136
egal ? 1

le paramètre '$2a$10$' permet de faire une exécution d'un dixième de seconde sur mon pc, ce qui n'est pas trop mal il me semble...
2 mot de passe identiques pour deux utilisateurs et des hash différents

[ctxnop]

concernant bcrypt il me semble (à confirmer) qu'il s'agit bien d'un algorithme de chiffrement à la base mais dans la doc php de la fonction crypt (on parle bien de celle là ?)

Non, ce n'est pas la bonne fonction.
Le chiffrement en blowfish se fait par la fonction mcrypt_encrypt avec 'MCRYPT_BLOWFISH' comme premier paramètre (cipher).