login + mdp formulaire en clair

21 avr. 2010, 19:58

Bonjour à tous,

J'ai pour but de développer un mini projet intégrant entre autre un formulaire permettant d'entrer dans une zone sécurisée.
Mon formulaire fonctionne parfaitement avec accès à ma base SQL et me permet d'entrer ds la zone sécurisée.

Comment puis-je me prémunir de qqn qui snifferait le réseau et qui verrait le mot de passe en clair ?

Après essai, il s'avère bien qu'avec wireshark j'arrive à retrouver mon login + mdp en clair issu de ma requête POST.

Y a t-il une solution permettant une authentification sans divulgation en clair du mot de passe?

Je vous remercie de vos lumières

21 avr. 2010, 20:19

Heu... c'est quoi wireshark ?

Pour sécuriser un mot de passe tu peux utiliser la technique du grain de sable.
Le mot de passe est concaténé à un grain de sable (chaine aléatoire hashée en sha1 par exemple) et l'ensemble est hashé en sha1 (par exemple) en javascript avant d'être envoyé dans les tuyaux du web. A réception tu fais la même opération en php pour comparer les mots de passe (le grain de sable aléatoire peut avoir été enregistré dans une variable de session).

Cette technique rend inexploitable l'écoute du trafic web.

Par contre reste encore le problème des logiciels espions qui pourraient se trouver sur l'ordinateur de l'utilisateur et qui enregistreraient les frappes sur le clavier. C'est pour cette raison que les banques et autres organismes très sécurisés emploient une fenêtre à cliquer plutôt que l'emploi du clavier pour rentrer son mot de passe. On peut se passer de cette fonctionnalité à condition d'être sur un poste individuel suffisamment protégé des logiciels espions.

22 avr. 2010, 10:36

c'est grain de sable ou grain de sel ?

22 avr. 2010, 12:17

c'est grain de sable ou grain de sel ?

J'ai dèjà vu cette question lol lol lol...

Autre question, AB si j'ai bien compris :
1. tu prends ton mot de passe
2. tu le "lies" à une chaine déjà haché en sha1
3. tu haches le tout en sha1 via javascript ?

Ma question et ta concaténation : tu la fais par javascript ? Moi je ne vois pas d'autres méthodes...

22 avr. 2010, 14:07

ça fonctionne a merveille pour le hashage en sha1 depuis le client avec javascript.
Le mot de passe ne transite plus en clair : indétectable avec Wireshark (anciennement ethereal (analyseur de trame)).

Par contre je galère un peu avec la concaténation mdp + gds unique par utilisateur... je test toujours ...

Merci

22 avr. 2010, 14:13

Oui mais pour pouvoir comparer les deux mots de passe il faut que la fonction de hachage et le salt soit le même à chaque fois ... donc le mec qui écoute ne saura pas le mot de passe mais pourra tout de même se connecter sur le site. Cette technique ne remplacera jamais SSL ou TLS. Non ?

22 avr. 2010, 14:15

C'est normal que tu le voyais en clair via le sniffer.

Par contre, javascript... Si tu veux vraiment contrer les sniffer, il faut faire du https.

Enfin c'est comme ça que je vois la chose.

22 avr. 2010, 14:17

c'est grain de sable ou grain de sel ?
J'ai dèjà vu cette question lol lol lol...

ouai en anglais c'est "salt", comme on voie un peu des 2...

22 avr. 2010, 16:45

Oui mais pour pouvoir comparer les deux mots de passe il faut que la fonction de hachage et le salt soit le même à chaque fois ... donc le mec qui écoute ne saura pas le mot de passe mais pourra tout de même se connecter sur le site. Cette technique ne remplacera jamais SSL ou TLS. Non ?

Oui le mot de passe est le même.
Non le salt, grain de sable ou de sel n'est pas identique à chaque fois. C'est une variable générée aléatoirement à chaque authentification. On la hash puis on la concatène au mot de passe (on pourrait ne pas la hasher avant concaténation), mais l'important est de concaténer le tout et d'hasher l'ensemble en javascript et de renvoyer le résultat dans le post d'authentification.
Si cette variable aléatoire a été enregistrée dans une variable de session, le serveur la connait et donc on peut faire l'opération inverse en php à réception du post.

L'avantage est que quelqu'un qui sniffe les tuyaux ne pourra récupérer qu'une valeur toujours différente composée du hash de la concaténation d'une valeur aléatoire et du mdp. Donc impossible de retrouver le mot de passe.
Et cette valeur étant unique pour chaque connexion/session elle ne sera d'aucune utilité pour les sessions suivantes.

Le nécessaire est donc de disposer d'une libraire de hashage en javascript pour hasher niveau visiteur qui soit compatible en php pour comparaison de l'ensemble niveau serveur.

On peut choisir le sah1 256. Voici une lib JS

Code : Tout sélectionner

<script type="text/javascript">
function SHA256(s){
 
	var chrsz   = 8;
	var hexcase = 0;
 
	function safe_add (x, y) {
		var lsw = (x & 0xFFFF) + (y & 0xFFFF);
		var msw = (x >> 16) + (y >> 16) + (lsw >> 16);
		return (msw << 16) | (lsw & 0xFFFF);
	}
 
	function S (X, n) { return ( X >>> n ) | (X << (32 - n)); }
	function R (X, n) { return ( X >>> n ); }
	function Ch(x, y, z) { return ((x & y) ^ ((~x) & z)); }
	function Maj(x, y, z) { return ((x & y) ^ (x & z) ^ (y & z)); }
	function Sigma0256(x) { return (S(x, 2) ^ S(x, 13) ^ S(x, 22)); }
	function Sigma1256(x) { return (S(x, 6) ^ S(x, 11) ^ S(x, 25)); }
	function Gamma0256(x) { return (S(x, 7) ^ S(x, 18) ^ R(x, 3)); }
	function Gamma1256(x) { return (S(x, 17) ^ S(x, 19) ^ R(x, 10)); }
 
	function core_sha256 (m, l) {
		var K = new Array(0x428A2F98, 0x71374491, 0xB5C0FBCF, 0xE9B5DBA5, 0x3956C25B, 0x59F111F1, 0x923F82A4, 0xAB1C5ED5, 0xD807AA98, 0x12835B01, 0x243185BE, 0x550C7DC3, 0x72BE5D74, 0x80DEB1FE, 0x9BDC06A7, 0xC19BF174, 0xE49B69C1, 0xEFBE4786, 0xFC19DC6, 0x240CA1CC, 0x2DE92C6F, 0x4A7484AA, 0x5CB0A9DC, 0x76F988DA, 0x983E5152, 0xA831C66D, 0xB00327C8, 0xBF597FC7, 0xC6E00BF3, 0xD5A79147, 0x6CA6351, 0x14292967, 0x27B70A85, 0x2E1B2138, 0x4D2C6DFC, 0x53380D13, 0x650A7354, 0x766A0ABB, 0x81C2C92E, 0x92722C85, 0xA2BFE8A1, 0xA81A664B, 0xC24B8B70, 0xC76C51A3, 0xD192E819, 0xD6990624, 0xF40E3585, 0x106AA070, 0x19A4C116, 0x1E376C08, 0x2748774C, 0x34B0BCB5, 0x391C0CB3, 0x4ED8AA4A, 0x5B9CCA4F, 0x682E6FF3, 0x748F82EE, 0x78A5636F, 0x84C87814, 0x8CC70208, 0x90BEFFFA, 0xA4506CEB, 0xBEF9A3F7, 0xC67178F2);
		var HASH = new Array(0x6A09E667, 0xBB67AE85, 0x3C6EF372, 0xA54FF53A, 0x510E527F, 0x9B05688C, 0x1F83D9AB, 0x5BE0CD19);
		var W = new Array(64);
		var a, b, c, d, e, f, g, h, i, j;
		var T1, T2;
 
		m[l >> 5] |= 0x80 << (24 - l % 32);
		m[((l + 64 >> 9) << 4) + 15] = l;
 
		for ( var i = 0; i<m.length; i+=16 ) {
			a = HASH[0];
			b = HASH[1];
			c = HASH[2];
			d = HASH[3];
			e = HASH[4];
			f = HASH[5];
			g = HASH[6];
			h = HASH[7];
 
			for ( var j = 0; j<64; j++) {
				if (j < 16) W[j] = m[j + i];
				else W[j] = safe_add(safe_add(safe_add(Gamma1256(W[j - 2]), W[j - 7]), Gamma0256(W[j - 15])), W[j - 16]);
 
				T1 = safe_add(safe_add(safe_add(safe_add(h, Sigma1256(e)), Ch(e, f, g)), K[j]), W[j]);
				T2 = safe_add(Sigma0256(a), Maj(a, b, c));
 
				h = g;
				g = f;
				f = e;
				e = safe_add(d, T1);
				d = c;
				c = b;
				b = a;
				a = safe_add(T1, T2);
			}
 
			HASH[0] = safe_add(a, HASH[0]);
			HASH[1] = safe_add(b, HASH[1]);
			HASH[2] = safe_add(c, HASH[2]);
			HASH[3] = safe_add(d, HASH[3]);
			HASH[4] = safe_add(e, HASH[4]);
			HASH[5] = safe_add(f, HASH[5]);
			HASH[6] = safe_add(g, HASH[6]);
			HASH[7] = safe_add(h, HASH[7]);
		}
		return HASH;
	}
 
	function str2binb (str) {
		var bin = Array();
		var mask = (1 << chrsz) - 1;
		for(var i = 0; i < str.length * chrsz; i += chrsz) {
			bin[i>>5] |= (str.charCodeAt(i / chrsz) & mask) << (24 - i%32);
		}
		return bin;
	}
 
	function Utf8Encode(string) {
		string = string.replace(/\r\n/g,"\n");
		var utftext = "";
 
		for (var n = 0; n < string.length; n++) {
 
			var c = string.charCodeAt(n);
 
			if (c < 128) {
				utftext += String.fromCharCode(c);
			}
			else if((c > 127) && (c < 2048)) {
				utftext += String.fromCharCode((c >> 6) | 192);
				utftext += String.fromCharCode((c & 63) | 128);
			}
			else {
				utftext += String.fromCharCode((c >> 12) | 224);
				utftext += String.fromCharCode(((c >> 6) & 63) | 128);
				utftext += String.fromCharCode((c & 63) | 128);
			}
 
		}
 
		return utftext;
	}
 
	function binb2hex (binarray) {
		var hex_tab = hexcase ? "0123456789ABCDEF" : "0123456789abcdef";
		var str = "";
		for(var i = 0; i < binarray.length * 4; i++) {
			str += hex_tab.charAt((binarray[i>>2] >> ((3 - i%4)*8+4)) & 0xF) +
			hex_tab.charAt((binarray[i>>2] >> ((3 - i%4)*8  )) & 0xF);
		}
		return str;
	}
 
	s = Utf8Encode(s);
	return binb2hex(core_sha256(str2binb(s), s.length * chrsz));
 

}
</script>

en php la fonction équivalente, par exemple :

$_SESSION['sel'] = hash("sha256",(uniqid(rand(), true)));

22 avr. 2010, 18:41

L'avantage est que quelqu'un qui sniffe les tuyaux ne pourra récupérer qu'une valeur toujours différente composée du hash de la concaténation d'une valeur aléatoire et du mdp

Oui mais alors php ne peut pas retrouver le mot de passe d'origine ... Enfin, moi je comprends ça de deux façons :

- Soit tu as dans ta base de données un mot de passe x hashé en md5 (on va faire simple). Là, ta technique peut éventuellement fonctionner si ce n'est que pour que le serveur est le mot de passe haché sans sel, il a fallu lui transmettre un moment donné.

Enfin, bon je vais pas sortir la deuxième façon. Mais j'ai du mal à comprendre que cela puisse être sécurisé on va dire de l'inscription à la connexion. Après le coup des spyware de claviers, c'est encore autre chose (je dis ça vu qu'on en a parlé dans le post). Actuellement, je développe (mais là j'ai ma formation) une classe php iniSecure qui a pour rôle d'initier et de sécuriser. Cette classe ne servira peut-être jamais, mais elle me donne une sorte de sommaire des choses à faire. Et éventuellement, un jour, un outil de travail. J'ai donc une protection XSS (deux méthodes de classe : une htmlentities, et une qui supprime tous les tags sauf ceux spécifiés par l'utilisateur --> vive la fonction déjà toute faite par php

), une protection de formulaires par tokens (donc une méthode pour créer un token, une méthode pour vérifier un token, etc ...), une vérification du navigateur voire d'un bout de l'adresse IP de l'utilisateur d'une session pour éviter les vols de sessions, un petit commentaire (vu que pas de méthodes) pour dire : attention, ne rien écrire non crypté ou hashé dans les sessions car la lecture de sessions par des utilisateurs du même serveur peut être possible), etc ...).

Alors j'avais développé un "clavier" ou plutot un ensemble d'images représentants des lettres et chiffres, avec des ID aléatoire, des positions aléatoire contre les spyware et les écoute de connexion (mais très limité dans ce dernier cas), et bref ce type de méthodes peut m'intéresser. Le problème, c'est que je ne comprends pas en quoi elle est un gage important de sécurité. Donc je suis tout ouï

22 avr. 2010, 20:01

Donc je suis tout ouï

T'es assez grand pour comprendre en réfléchissant par toi-même. Evidemment cette technique n'est valable que pour la connexion, pas pour l'inscription... puisque le hashage est irréversible

22 avr. 2010, 22:16

Pour moi ,
salt / grain de sel / poivre ou sable , permet principalement d'offusquer des données , utile pour rendre des formulaire unique , évitant les formulaires forgés , ou offusquer les variables stockées en cookie par exemple , ect ect ...

Mais pour ce qui est du passage des mots de passes , la seule solution valable à mes yeux , c'est bien d'utiliser une connexion sécurisé https .
Faire confiance à javascript me semble très faible ...

Ch.

23 avr. 2010, 05:34

Mais pour ce qui est du passage des mots de passes , la seule solution valable à mes yeux , c'est bien d'utiliser une connexion sécurisé https .
Faire confiance à javascript me semble très faible ...
Ch.

Fait confiance à ce que tu peux comprendre en fonction du contexte

Je pensais que vous aviez compris que la méthode que j'ai énoncée est la plus fiable (à ma connaissance) en dehors de l'utilisation d'une connexion https. Jamais je n'ai dit qu'elle pouvait la remplacer

Mais pour des utilisations courantes - genre espace administrable - ça peut rendre un grand service, d'autant plus que rien n'interdit d'imposer la présence de javascript pour l'envoi du formulaire... Après suffit de dire de ne pas se connecter depuis un réseau, un espace public, en bref d'un endroit peu sûr, où de toute façon un spyware de type Keylogger viendrait aussi facilement à bout d'une connexion https pour un mot de passe rentré au clavier

Enfin pour dire qu'entre des grands moyens de type bancaire, avec un clic sur un écran de saisie (heu... au passage ça a bien l'air d'être du javascript ... niveau confiance max), tout ça au sein d'une connexion https, il existe des intermédiaires en comparaison avec une connexion standard non sécurisée.

Une connexion standard peut être "infiniment" plus protégée par la méthode du grain de sel énoncée plus haut, que si elle ne l'était pas. Et la différence n'est pas anecdotique

23 avr. 2010, 08:21

AB , ta méthode est tout à fait valable ,
maintenant au départ , matoo7254 nous indique qu'avec un analyseur de trame , il voit tout les dialogues en clair .
Mettre en place la solution que tu as énoncée peut "dépanner" si l'on ne souhaite pas mettre en place https pour la page concerné , mais on ne peut pas mettre ce système partout , surtout si l'on utilise des ressources que l'on a pas développées soit même .

Bref pour rendre tout dialogue client serveur illisible par un analyseur de trame , et sans avoir à faire des développements supplémentaires , https est là solution à son problème .

Maintenant , s'il ne souhaite que offusquer un login et mdp mais laisser le reste tel quel alors oui la lib js est la solution .

Enfin pour dire qu'entre des grands moyens de type bancaire, avec un clic sur un écran de saisie (heu... au passage ça a bien l'air d'être du javascript ... niveau confiance max)

Js n'est utilisé dans ce cas uniquement pour la saisie , afin d'éviter d'utiliser un clavier.

Une connexion standard peut être "infiniment" plus protégée par la méthode du grain de sel énoncée plus haut, que si elle ne l'était pas. Et la différence n'est pas anecdotique

Disons les formulaires choisis , pas la connexion complète c'est bien là la limite .

Mais encore une fois , je suis d'accord avec toi sur l'efficacité de ta méthode JS , mais qui ne s'utilise qu'à des endroits bien précis et voulue , et non pour la connexion complète , après ça dépend de ce que souhaite faire le développeur .

Ch.

login + mdp formulaire en clair

Qui est en ligne