Discussion :

[Koo]

pour la perte de mot de passe, de toute manière ca sera à l'administrateur de décider quelle méthode est la plus adapté (on avais dejà discuté des solutions).

Pour le mail/question secrète je suis de l'avis du sub0. La sécurité de l'appli ne doit dépendre que d'elle même. Si on renvoie le mdp sur un mail pas sécure ca foutrait tout en l'air.
Quand au choix des questions, c'est encore une fois a l'admin de décider je pense

• • on peut proposer des question types comme ca été dis plus haut
  • l'admin peut mettredes question à la con s'il veut (quelle est votre couleur préférée ?)
  • l'utilisateur définir sa propre question

L'attaque par dico ne marche pas, et si la question est bien choisie, le risque est très faible.

Bien sûr, mais comme l'a dit Faaalllllling, il est plus simple de récuppérer la réponse à la question par SE que de s'approprier la boîte mail de quelqu'un...

ce n'est pas que le fait de s'approprier une boite mail, mais aussi de l'intercepter. D'ailleur je mettrai pas ma main au feu, que de retrouver le tel d'une personne à partir d'une IP et de réussir à lui soutirer son n° de permis pour répondre à la question sécrète, sois plus simple que de recuperer le passe dans un email pourri, par exemple.

quand au question, à la volée je dirait
• N° d'immatriculation de sa caisse
• Artiste préféré (je pense que le choix est vaste, tout le monde ne dira pas alizée comme moi)

[pjl]

On a paypal qui propose de retenir 2 questions différentes.
Les questions sont :
Nom de jeune fille de votre mère
- 4 derniers chiffres de votre carte d'identité
- Votre lieu de naissance
- Ville de naissance de votre père
- 4 derniers chiffres de votre permis de conduire.

[Altherac]

Pour les cookies d'autoreconnection, je suis assez contre l'idée d'y inclure quoi que ce soit comme donnée qui soit exploitable directement.
Un id utilisateur, un login ou un pass même hachés au moyens d'un md5 ou d'un sha-1 me paraissent déjà trop au niveau de l'exposition des données.

J'ai utilisé sur mon site un système de tickets.
Quand un utilisateur se connecte avec succès sur le site, il reçoit un numéro de ticket (généré aléatoirement, suffisamment long pour supprimer tout risque de collision).
Ce numéro de ticket est stocké dans un cookie sur son ordinateur.
Parallèllement, le serveur conserve le numéro de ticket auquel il associe le compte de l'utilisateur et des informations supplémentaires (timestamp pour l'expiration du ticket, ip, etc).
Lorsque l'utilisateur va revenir, le serveur va vérifier si son ticket existe et n'a pas expiré. Si c'est le cas il le connecte automatiquement et renouvelle le numéro de ticket.

J'espère que c'est assez clair =)
On peut ensuite associer un ticket à une IP si on est un peu parano, et on peut encore trouver d'autres astuces tordues, mais de base ce système permet de ne stocker côté client qu'une donnée arbitraire, à la façon d'un ID de session.

[segphault]

Salut,

Concernant la génération de hash, le MD5 est maintenant à proscrire. Cet algorithme est cassé depuis quelque temps maintenant et on peut créer des collisions. Mieux vaut se baser maintenant sur SHA-1. Nous avons pu voir qu'un groupe à réussi à prouver les risques de collisions sur cet algo existe aussi. Néanmoins, il est encore difficile à mettre en oeuvre par rapport au md5.

Pour plus d'information, je vous recommance dans un premier temps ces urls :

http://fr2.php.net/manual/fr/function.sha1.php
http://fr2.php.net/manual/fr/function.mhash.php



Il y a quelques infos dans ces articles sur les collisions de l'algo MD5 :

http://www.cryptography.com/cnews/hash.html
http://www.freedom-to-tinker.com/archives/000664.html

Cela ne veut pas non plus dire que c'est à la portée du premier scriptkiddie, mais ça reste possible. Néanmoins il y a un risque potentiel à prendre en considération selon la sensibilité de l'application développée. SHA-1 étant considéré plus sûr et ne demandant pas de complexité supplémentaire en terme de développement mérite d'être pris en considération.

Toutefois une longue série de post sur bugtraq sur le SHA-1 sont apparus au mois de février 2005 :

http://www.securityfocus.com/archive/1/390665

De plus, dans le 'hashage' d'un mot de passe, il est vivement recommandé d'utiliser une graine aléatoire pour chaque compte afin de rendre la génération de collision plus hardues. L'envoi d'un mot de passe 'hashé' en MD5 par une fonction javascript peut être cassé si il est intercépté. Mieux vaut utiliser directement une connection SSL.

Enfin tout dépend du niveau de sécurité souhaité

@+

[Mysticlolly]

Moi j'ai prévu un session_timeout au cas où le visiteur oublie de se déconnecter.
Quand tu vas sur une page sécurisée, si ça fait plus de X minutes que tu n'as rien fait, ben la session existante est détruite.

[Hastur]

Il y aussi la possibilité de bloquer apr adresse IP et de façon plus.... sûr l'adresse MAC... le problème c'est que la solution en question n'est pas souple du tout et en prime si la personne utilise une IP dynamique.... ce sera mort pour lui.

Sinon pour les gens qui possèdent une IP fixe cela augmentera la sécurité de façon bien plus importante. Le problème c'est qu'il existe des émulateurs d'adresse MAC.... mais j'ai du mal à imaginer le mec récupérer une adresse MAC, sauf dans le cas où il pirate l'ordi de la personne en question.

Mais je pense que tous les systèmes utilisés ne sont valables que pour des sites dits "sensibles"

[Sub0]

Suite à un topic sur l'authentification http, je poste ici le message que j'ai donné...

En fait, d'après ce que j'ai appris, les 3 seuls risques de piratage sont :

1) Le piratage par "force brute". L'utilisateur va essayer toutes les combinaisons de mot de passe jusqu'à tomber sur le bon. C'est un script qui se charge d'automatiser cette recherche. En général, ce genre de hack possède un dictionnaire contenant les mots de passe les plus courants afin d'augmenter les chances de trouver rapidement le bon password... Pour contrer le piratage par force brute, il suffit d'ajouter un compteur-bloqueur qui s'incrémente à chaque échec d'authentification et bloquera le compte au bout d'un certain nombre d'échecs consécutifs.

2) Le piratage par écoute du réseau, également appellé "man in the middle". Pour contrer l'écoute du réseau, la seule solution réellement efficace est d'utiliser une connexion sécurisée avec SSL ou OpenSSL (à la limite SSH, mais je ne le connais pas). L'écoute du réseau n'est pas facile à réaliser, ce n'est pas donné au 1er venu...

3) Les "injections SQL" (utilisation avec base de données uniquement) sont les données postées par l'utilisateur qui sont modifiées afin de détourner les requêtes envoyées à la base de données. Ces données peuvent permettre ainsi de contourner un système d'authentification. Pour contrer cette pratique, il suffit de contrôler et filtrer les variables postées, d'interdire certains caractères pour la saisie, de décomposer ses requêtes SQL en plusieurs, etc...

• Voici un exemple d'injection SQL avec une requête d'authentification courante :
SELECT * FROM mytable WHERE log='$log' AND pass='$pass'
Il suffira de donner comme mot de passe : ' OR 'a'='a et le login de son choix, on obtient :
SELECT * FROM mytable WHERE log='admin' AND pass='' OR 'a'='a'

• Autre exemple avec la même requête et en donnant ce login : admin'# on obtient :
SELECT * FROM mytable WHERE log='admin'#' AND pass=''
Le caractère # sert à commenter. Le code qui le suivra ne sera pas pris en compte...

Au niveau du formulaire, qu'il soit réalisé avec des inputs type=text ou le dialogue d'authentification de l'header http, cela revient au même. Voici le code que j'utilise pour l'authentificatrion rapide. J'essaye de miniser au maximum les failles de sécurité. J'utilise un formulaire standart et un fichier que je nomme "cnt.php" qui contiendra le nombre d'échecs consécutifs et quelques infos sur le client ayant provoqué l'échec. Ce fichier permettra de bloquer la vaidation du formulaire au bout de 3 échecs. Il possède l'extension php pour interdire l'affichage de son contenu (donc pas besoin d'un htaccess ici) :

Code :

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
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
<?php
//============================================================ 
//  PARAMETRES
//============================================================
$cfg['login'] = 'root';  // Le log d'accès 
$cfg['pass']  = '';      // Le mot de passe
$cfg['maxid'] = 3;       // Echec d'identification max
 
 
//==========================================================//
//  COMPTEUR-BLOQUEUR - SAUVEGARDE DANS LE FICHIER "cnt.php"
//==========================================================//
function Counter($add=''){
  global $cfg;
  $cnt=0;
  $fname=dirname($_SERVER['SCRIPT_FILENAME']).'/cnt.php';
  if(!file_exists($fname)) $f=fopen($fname,'w+');
  else{
    $f=fopen($fname,'r+');
    $lst=explode("\n",fread($f,filesize($fname))); 
  }
  fclose($f); 
  $lst[0]='<?php die("Accès refusé!");?'.'>';
  if($add=='reset') $lst='';
  else if(!empty($add) && !in_array($add,$lst)) $lst[]=$add; 
  $cnt=-1;
  @unlink($fname);
  $f=fopen($fname,'w'); 
  $start=max(count($lst)-($cfg['maxid']+2),0);
  for($x=$start;$x<count($lst);$x++) 
    if(!empty($lst[$x])){ fwrite($f,$lst[$x]."\n"); $cnt++; }
  fclose($f);  
  return $cnt;
}
 
//============================================================
//  AUTHENTIFICATION
//============================================================
$user=@$_POST['user'];
$pass=@$_POST['pass'];
$ess=Counter();
if($user!=$cfg['login'] || $pass!=$cfg['pass'] || $ess>=$cfg['maxid']){
  if(!empty($user))
    Die('Echec d\'identification (essai '.max(min(  
      Counter(@getenv('HTTP_CLIENT_IP').' '.date('d/m/y H:i:s')),$cfg['maxid']),0).
      '/'.$cfg['maxid'].')');
 
  echo '<form method="post">'. 
       'User : <input name="user" type="text" value="'.$user.'"/><br/>'.
       'Pass : <input name="pass" type="password" value=""/><br/><br/>'.
       '<input name="valider" type="submit" value=" VALIDER "/>'. 
       '</form>';
  exit;
}
if($ess>=1) Counter('reset');
echo 'AUTHENTIFICATION OK <br/>'; 
 
 
//============================================================
?>

D'autres failles existent, du genre des grossières erreurs comme ouvrir son firewall, laisser trainer son mot de passe sur son bureau ou dans un fichier non protégé, choisir le même mot de passe depuis toujours pour toutes ses appli et/ou super facile à trouver, faire un backup de sa base de données sur le serveur, permettre le listing du contenu des dossiers de son site, etc... La sécurité du système dépend du maillon le plus faible de la chaine de sécurité. La solution est de faire preuve de bon sens et de rigueur...

La loi est assez persuasive au sujet du hacking : L'accès et le maintien frauduleux (même involontaire) total ou partiel dans tout ou partie d'un système ou délit d'intrusion et propagation de virus est puni d'un an d'emprisonnement et de 15K€ d'amende. Cela est aussi le cas pour l'utilisation d'un code d'accès exact mais par une personne non autorisée à l'utiliser. Les peines sont doublées lorsque le délit entraine une modification ou suppression des données et triplées lorsque l'action est volontaire...

à+

[Sub0]

un $pass2=addslashes($pass) devrait suffire pour combler cette faille non ?

C'est un exemple que j'ai donné, c'est juste pour expliquer comment fonctionne une injection SQL. Trouver le code pour contrer cet exemple est inutile... enfin pour le projet d'espace membre. Pour les membres débutants, ça peut être un bon exercice.

Pour contrer cette pratique, il suffit de contrôler et filtrer les variables postées, d'interdire certains caractères pour la saisie, de décomposer ses requêtes SQL en plusieurs, etc...

Perso, j'utilise une fonction de filtrage pour les variables en entrée.
La fonction retourne une chaine vide si un caractère non permis est trouvé :

Code :

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
28
//============================================================ 
//  CONSTANTES POUR LA FONCTION "Filtre"
//============================================================
$F['num'] = '0123456789';
$F['hex'] = '0123456789abcdef';
$F['maj'] = 'ABCDEFGHIJKLMNOPQRSTUVWXYZ';
$F['min'] = 'abcdefghijklmnopqrstuvwxyz';
$F['acc'] = 'áàâäåãÁÀÂÄÅÃéèêëÉÈÊËíìîïÍÌÎÏóòôöõÓÒÔÖÕúùûüÚÙÛÜýÿÝçÇñÑšžŽœŒæÆ';
$F['all'] = $F['num'].$F['maj'].$F['min'].$F['acc'];
 
 
//============================================================
//  DETERMINE SI LA CHAINE EST VALIDE
//============================================================
function Filtre($chaine,$filters){
  if(empty($chaine)|| empty($filters)) return $chaine;
  $nofound=false;
  for($y=0;$y<strlen($chaine);$y++){
    $found=false;
    for($x=0;$x<strlen($filters);$x++)
      if($chaine[$y]==$filters[$x]){
        $found=true;
        break;
      }
    if(!$found) return false;
  }     
  return $chaine;
}

Exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
$log=Filtre(@$_POST['log'],$F['all']);
$pass=Filtre(@$_POST['pass'],$F['all']);
$email=Filtre(@$_POST['email'],$F['all'].'@.!":;,&()[]{}<>');

Je rappel que c'est dans le cas où l'on utilise l'accès à une bdd...
J'en profite pour donner ce lien :
http://dico.developpez.com/html/477-...te-attaque.php
à+

[Small Bug]

Détails primordiaux :
INJECTIONS SQL :
Ni la fonction AddSlashes(), Ni l'option magic_quotes(=ON) NE PROTEGENT DES INJECTIONS SQL
(l'encodage des caractères style %2527 permettent cette injection)

UTILISEZ mysql_real_escape_string();
exemple d'implémentation :

function safeQuote($value)
{
// Stripslashes
if (get_magic_quotes_gpc()) {
$value = stripslashes($value);
}
$value = "'" . mysql_real_escape_string($value) . "'";
return $value;
}

if(!empty($_POST['username']) && !empty($_POST['md5_hash'])) {
$sql = 'SELECT * FROM users WHERE name='.safeQuote($_POST['username']).' AND pwd='.safeQuote($_POST['md5_hash']).' LIMIT 1');

[...]
}

Au sujet du md5, conseillez vos utilisateurs (ou obligez les) à utilisez des mots de passes longs et forts ! (J9Os6G3djiu8FdhSIH3a est mot de passe fort, super1234 est mot de passe inutile)
Un mot de passe de 8 caractères se trouve en quelques minutes grâce aux Rainbow tables. (cf http://passcracking.com/)
Heureusement la génération de tables de hash devient trop longue au delà de 15-16 caractères (plusieurs années en ayant plusieurs ordinateurs dédiés à cela). Mais une fois ces tables calculées, la recherche du mot de passe est relativement rapide (quelques heures maximum). On vend sur Internet des disques durs entiers contenant ces tables. (encore une fois les mots de passes vraiment longs sont hors de portée)

Au sujet des collisions possibles du md5, il y a une confusion : l'algorithme permet de créer, à partir d'une source, un fichier qui aura la même signature que la source. Ce qui pose un problème puisqu'on peut donc insérer un virus dans un fichier et faire en sorte qu'il ait la même signature que l'original ! L'algorithme ne permet donc pas de trouver un mot de passe à partir de son Hash md5 MAIS peut, en théorie (car c'est pour l'instant très difficile à mettre en oeuvre) réaliser une attaque "Man In the middle" http://www.reseaux-telecoms.com/cso_...O/Newscso_view

Enfin, n'oubliez pas que le sacrosaint SSL n'est pas la solution miracle parfaite car certains certificats utilisent le md5 ou SHA... Mais il reste une excellente solution pour la sécurité surtout avec un encodage 3DES (clef de 168 bits)

[Fladnag]

la fonction mysql_real_escape_string() sert à filtrer les caractères à l’intérieur des données fournies par l’utilisateur, en les codant en leurs équivalents en HTML (« > » devient &gt ; , « < » devient &lt ;, etc…), en leur ajoutant un caractère d’échappement (« \ » par exemple), en les supprimant, ou en demandant à l’utilisateur de modifier sa saisie.

Non...

ca c'est html_special_chars ou html_entities... mysql_real_espace_string ne remplace jamais les entitées html...

De plus, je pense qu'il est toujours préférable de stocker en base EXACTEMENT ce que l'utilisateur a tapé. Sur un forum par exemple, il conviendra de stocker les retours chariots en \n et/ou \r au lieu de stocker <br>... pareil pour les entitées html.
Cela pour des problemes de modifications par exemple. Si tu edite ton message, tu va devoir te faire une methode pour faire l'inverse de html_special_chars... est-ce vraiment utile ??

[Digimag]

Bonjour,

Petite suggestion: Mettre un délais supplémentaire (une seconde) pendant la vérification du login/mot de passe par un compte. Ainsi, les ataques du type Brute Force deviendront inéficasses. Mais aussi, on peut suspendre tous les comptes pour quelques minutes minutes pour une IP ayant effectué trop de tentatives.

C'est un peu le concept du système d'authentification UNIX et l'idée du fail2ban que j'ai adoptée. Mais surtout, il s'agit du respect d'une stratégie de sécurité par le développeur.

[guidav]

J'ai lu dans la presse que certaines banques sont en train de mettre en place des systèmes de type Secure-ID (carte générant des numéros selon un algo prédéfini, à entrer lors de la connexion) pour les clients qui le demanderaient. Pourquoi juste ceux-là ? Parce que ca coûte cher.

[azmodan]

Concernant les banques ce n'est pas un projet mais une réalité, pour les banques Suisses du moins.
Elles utilisent 2 méthodes à ma connaissances pour l'E-Banking:

1) La banque t'envoie par courrier "réel" une liste de numéro à saisir (un par connection) en plus du login/mot de passe. A chaque connection tu biffes un numéro.

2) La banque t'envoie un petit boitier qui affiche un numéro digital qui change toutes les heures. Quand tu te connectes suffit de le saisir avec le login/mot de passe.

Bien sûr ils ont aussi des certificats et ils utilisent https...

Sinon moi j'ai commencé le php y'a 3 jours mais je vais quand même essayé de répondre à la question d'après les quelques infos que j'ai lues.

1) Enregistrement

Pour un espace membre il faut d'abord un formulaire d'inscription. Celui-ci enregistrera le mot de passe et login dans ta base de données, les sessions ne me semblent pas très utiles pour cette étape.

Concernant le mot de passe, il faut veiller à ce qu'il ne comporte pas de caractères invalides. Ca se fait grace aux fonctions de parsing, j'ai vu un exemple avec trim() et htmlspecialchars() combiné.

Il faut également hashé ton mot de passe, tu peux utiliser la fonction md5 pour le faire. Attention cette fonction renvoie une chaine de 32 caractères hexadécimals. Je suppose que pour le type de données faut donc choisir un VARCHAR(32).

Bref, tu n'auras plus le mot de passe initial donc pour les authentifications ultérieures tu devras systématiquement faire subir aux mots de passe le parsing/hashage que tu as utilisé à l'enregistrement.

Un des risques c'est le passage du mot de passe à travers le réseau, entre le client et le serveur. Si tu veux éviter qu'il passe en clair il faudra installer Https sur ton serveur. Ainsi les données seront cryptées sur la machine cliente puis décryptée une fois parvenue au serveur par un système de clés publiques/privées. Https c'est gratuit mais ça demande un peu de configuration, il n'y a rien à changer pour tes adresses d'après ce que j'ai vu, Apache s'en charge et pour les clients s'est aussi automatique.
Tu peux également acheter un certificat qui prouvera aux clients qu'ils sont sur un site de confiance (remarque les sociétés qui fournissent les certificats sont probablement pas 100% sûre de savoir si l'acheteur est honnête ou pas).

Bien sûr faut aussi forcer les gens à introduire un mot de passe de taille suffisante, avec des caractères spéciaux, etc.

2) l'authentification
Il y a plusieurs risques pendant l'authentification.

D'abord le brute-force que tu peux éviter efficacement en augmentant le délai de connection à chaque essai de l'utilisateur. Pour ça faut utiliser une session avec une variable qui vaut 1 à la 1ère tentative puis 2, 4, 8, etc. Enfin quelque chose du genre.

Un autre risque que j'ai retenu c'est les caractères invalides dans les zones de saisie, d'où l'intérêt du parsing.

Le répertoire où tu as tes fichiers de sessions peut être sécurisé je crois, je sais pas comment par contre. Sinon j'ai aussi vu qu'il existait un système nommé htacccess qui doit permettre de protèger l'accès à tes zones privées.

3) navigation
A l'issue de l'authentification tu peux remplir quelques variables de session contenant l'adresse IP ou le login. Ensuite à chaque ouverture de page tu vérifies que ces variables soient toujours là et tu compares l'adresse IP de la Session avec l'IP du client.

Sinon utilise plutôt la méthode POST, évite les cookies et utilise des champs password.

Y'a surement plein d'autres trucs mais j'en suis à mes débuts.

N'oublie pas aussi de sécuriser ta base de données, j'ai pas encore étudié les possibilités à ce niveau mais il faut probablement empêcher les requêtes provenant de l'extérieur et bloquer un maximum de port.

Y'a surement aussi quelque chose à faire au niveau de la connection à la base de données, faut peut-être éviter d'utiliser un compte root (administrateur) pour faire de simple SELECT en php. D'ailleurs si quelqu'un peut me donner une stratégie à ce sujet je suis preneur.

Voilà bonne chance!

[Maxoo]

Histoire de relancer de débat avec m@, mathieu, Sub0, et les autres :

j'ai plusieurs questions :

• 1. est-ce qu'un mail peut etre détruit ? on sait qu'il peut etre visionné, mais si il ne peut pas etre détruit par le hacker, il arrivera dans l'inbox du vrai mec et donc pourra le prevenir qu'il y a un danger d'usurpation ou autres.
  
  2. Si il y a un vol de session, la personne s'approprie la session entière ?
  je m'explique : on a un IDS sur son pc qui est relié avec la session php sur le serveur, et ca discute ensemble. Si le mec change son IDS pour prendre une autre session, il recoit la totalité des variables $_SESSION du serveur ? ou pas ?
  
  3.

  Si vous voulez résoudre ce souci de façon simple, il peut être utile d'activer session.use_only_cookies. Dans ce cas, les cookies devront être activés par le client, sinon, les sessions ne fonctionneront pas.

  je ne pige pas ce que ca fait d'obliger le client a mettre les cookies, en quoi ca resoud le probleme d'usurpation de sessions ??

Voila.

Sinon moi je pensais a ca comme systeme.
(sachant que pour éviter le sniffing de mdp il faut un SSL (https) ou utiliser la méthode du grain de sel)

- utilisation des sessions PHP.
- les scripts php stocke l'IP, type du navigateur, etc. du mec quand il se loggue.
et a chaque fois qu'on accede a un page web on reteste l'IP et les autres infos.
si il y a eu usurpations de sessions cela est découvert.

* dans le cas ou on peut penser que le hacker a aussi fait du spoofing d'IP et qu'il a la bonne IP et les bonnes caractéristiques pour se faire passer pour l'internautes.
Pourquoi ne pas généré un nombre aléatoire a la connexion de l'utilisateur et qu'il se trimbale avec dans l'url ou autre part (a vous de m'aider) pour faire cette vérification en plus...

Voila ou j'en suis arrivé apres la lecture de tout ces posts (ce fut long et heureusement que je les avais imprimés.)

Si j'ai loupé des trucs faite moi signe.

[Maxoo]

salut,

je viens rajouter mon grain de sel, car effectivement j'ai trouvé une faille dans celui-ci.

Je ne sais pas si SPIP utilise toujours ce que Mathieu a expliqué pour leur systeme de login, mais je pense avoir trouver une grosse faille.

la base de données contient les 3 champs suivant par login
- le grain de sel (que je vais appeler GDS)
- un champ égal à md5(GDS + mot de passe)
- le grain de sel suivant (GDS2)

La méthode est la suivante :
- un 1er formulaire demande le login
- envoie du login au serveur
- le serveur renvoie un 2ème formulaire de saisie du mot de passe. ce formulaire connaît GDS et GDS2 de la base de la base de donnée pour ce login
- le javascript de ce formulaire s'occupe de ne pas envoyer le mot de passe mais seulement les informations "md5(GDS + mot de passe)" et "md5(GDS2 + mot de passe)"
- le serveur compare la valeurs "md5(GDS + mot de passe)" avec la base de données et si c'est correct, l'utilisateur est authentifié, GDS2 remplace GDS dans la base de données, "md5(GDS2 + mot de passe)" est mis dans le 2ème champs et un nouveau GDS2 est généré.

Disons que l'utilisateur se loggue :
il entre son mdp et avec javascript il envoie au serveur md5(GDS+mdp) et md5(GDS2+mdp), le serveur dis oki ca correspond avec ce que j'ai, il remplace son md5 par md5(GDS2+mdp) remplace son GDS par GDS2 et recréé un nouveau GDS2.

Jusque la tout le monde est d'accord. mais en fait y avait un petit malin qui écoutait entre le pc et le serveur.

Je rappelle que dans ce cas on essayait de trouver un moyen pour ne pas utiliser un protocole SSL (https)

Donc le hacker a ecouter md5(GDS+mdp) et md5(GDS2+mdp) or voila le premier ne lui sert a rien on est bien d'accord, mais le deuxieme ... BAh c'est EXACTEMENT le md5 que le serveur attend pour la prochaine connexion !!! Y a comme un probleme ici.

Donc apres le hacker se connecte avec le md5(GDS2+mdp) en l'envoyant au serveur et en donnant un autre md5 (celui qu'il veut) et ainsi il prend la place de l'internaute sans aucune difficulté !!

Qu'en dites vous ??



Heureusement (il y a findus) j'ai une solution.

• Sur le serveur :
  1. Grain de Sel (GDS)
  2. le md5(mdp)
  
• Coté client :
  1. le mec demande a se connecter avec son login
  2. il a une demande de mdp, dans ce formulaire, il y a le GDS de son login
  3. le javascript (ou autre) fait un (suivez bien) md5(GDS+md5(mdp)) Ce qui fait que quelque chose d'inutile est envoyé en clair au serveur.
  4. le serveur recoit ce md5, fait (lui meme, donc en php) md5(Grain de sel de la BDD + md5(mdp) de la BDD) et compare ces deux md5.
  5. le GDS est changé.

• Avantages :
  - le md5 que le hacker peut chopper en clair ne sert qu'une seule foi et du coup c'est déja trop tard le GDS a été changé
  - l'utilisateur est content
  - pas besoin de SSL (la j'abuse je pense mais bon ...)
  
  Inconvenients :
  - besoin de deux formulaires

vous allez me dire que le md5(du mdp) est stocké comme ca sur la BDD, mais c'est le cas sur la plupart des appli non ??

[mathieu]

1. est-ce qu'un mail peut etre détruit ? on sait qu'il peut etre visionné, mais si il ne peut pas etre détruit par le hacker, il arrivera dans l'inbox du vrai mec et donc pourra le prevenir qu'il y a un danger d'usurpation ou autres.

tu parles d'un e-mail qui contient quoi ?
si le pirate est assez fort pour faire du spoofing d'IP il peut aussi triffouiller les DNS du pour que l'e-mail arrive autre part ou bien ilpeut tout simplement pirater la boite mail de l'utilisateur piraté

2. Si il y a un vol de session, la personne s'approprie la session entière ?
je m'explique : on a un IDS sur son pc qui est relié avec la session php sur le serveur, et ca discute ensemble. Si le mec change son IDS pour prendre une autre session, il recoit la totalité des variables $_SESSION du serveur ? ou pas ?

oui tout le contenu de $_SESSION est géré par un identifiant de session

3.

Si vous voulez résoudre ce souci de façon simple, il peut être utile d'activer session.use_only_cookies. Dans ce cas, les cookies devront être activés par le client, sinon, les sessions ne fonctionneront pas.

je ne pige pas ce que ca fait d'obliger le client a mettre les cookies, en quoi ca resoud le probleme d'usurpation de sessions ??

on a dit partout sur developpez.com qu'en cas de problème avec PHP il faut regarder dans le manuel PHP.
par contre on n'a jamais dire qu'il faut croire ce qu'il y est ecrit c'est comme les articles de developpez.com, il peut toujours arriver qu'il y aie une erreur, et comme il y a un très grand nombre de documents (sur php.net et developpez.com) on trouve des erreurs tous les jours

[Maxoo]

tu parles d'un e-mail qui contient quoi ?
si le pirate est assez fort pour faire du spoofing d'IP il peut aussi triffouiller les DNS du pour que l'e-mail arrive autre part ou bien ilpeut tout simplement pirater la boite mail de l'utilisateur piraté

en fait je parle si on envoie un mdp par un email ou une alerte a un client. si c'est le plus sur.

Parce qu'on dit : si il y a usurpation de ids il faut avertir le client etc.
mais si on peut pas comment fait on ?
Donc peut on vraiment considérer qu'un email peut etre détruit ou qu'il n'arrive pas à la personne ?

oui tout le contenu de $_SESSION est géré par un identifiant de session

donc si un hacker change son ids, on peut voir que c'est une usurpation par :
- son IP
- sa config de navigateur
- une variable dans l'url ??

parce que si on stocke des variables aléatoire pour reconnaitre une personne dans une variables de session il les aura en se changeant son ids.

Par contre : est-ce qu'on peut avoir deux sessions pour un meme utilisateurs ? histoire de rendre le vol d'ids plus difficile ?

Il faut trouver un méthode pour découvrir qu'il y a eu usurpation

par contre on n'a jamais dire qu'il faut croire ce qu'il y est ecrit c'est comme les articles de developpez.com, il peut toujours arriver qu'il y aie une erreur, et comme il y a un très grand nombre de documents (sur php.net et developpez.com) on trouve des erreurs tous les jours

ce qui répond à ma question ??
il faut ou ne faut pas activer session.use_only_cookies ??

Si je reviens à ce qu'on disait sur l'utilisation du GDS et de SPIP, je trouve que cette faille est vraiment grosse.

après je me dis que si on est pas en https (SSL) c'est la merde partout ?
je suis en train de voir que beaucoup de site qui devrait etre sécurisé ne le sont pas ... ca fait peur, je préferai quand je ne savais pas tout ca ??

Question : avec un pc sur un rezo local on peut sniffer
mais avec une connection direct à internet ? y a encore des risques ?

Et donc avec un SSL (https) il ne peut plus y avoir de sniffing ou c'est pas sur a 100 % ??

Pour exemple je viens de prendre le service eCarte Bleue de Bagoo pour ne pas donner mon numéro de carte bancaire sur internet.
Voici leur sécurité :
accès en https au site, ou au petit logiciel.

le login est une combinaison de lettre qu'on ne choisit pas, le mdp aussi
ceux deux informations sont envoyés par la poste dans deux courriers séparé.

lors de la premiere connexion il faut changer son mdp. (la j'ai mis un truc chiffre + lettre + MAJ pour rester dans le costaux)

Et voila.

[Sub0]

[PHP] Espace membre :
http://www.developpez.net/forums/showthread.php?t=14438

[Yogui]

Dans ce sujet, vg33 propose une méthode intéressante :
http://www.developpez.net/forums/showthread.php?t=98673

Mots clefs pour recherche ultérieure : md5 login membre

[Maxoo]

c'est pareil pour spip ou pour ce forum, il y a un script coté client, mais si la personne a désactivé le javascript : le formulaire envoie le mdp en clair, et donc coté serveur il faut prévoir l'arrivée sous deux formes, soit en clair soit en hash.

mais ca marche parfaitement bien dans les deux cas.

tu peux tester sur le forum