[RESOLU] Protection formulaires.

Répondre


Cette question est un moyen d’empêcher des soumissions automatisées de formulaires par des robots.
Smileys
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :!: :?: :idea: :arrow: :| :mrgreen: =D> #-o =P~ :^o :non: :priere: 8-|
Voir plus de smileys
  Revue du sujet
 

  Étendre la vue Revue du sujet : [RESOLU] Protection formulaires.

Re: [RESOLU] Protection formulaires.

par niconicochan » 27 janv. 2015, 22:21

Merci encore :D

Grâce à toute ton aide je connais maintenant pas mal de choses sur la sécurité
et j'ai pu beaucoup mieux sécuriser mes pages.

Merci pour tout :D :D :D

Re: [RESOLU] Protection formulaires.

par AB » 27 janv. 2015, 19:42

Bah le "gros pavé" fonctionnera toujours...

Les anciennes versions de jquery continuent de fonctionner, c'est juste qu'elles ne disposent pas des dernières fonctionnalités mais pour du code qui a été écrit pour une version x, le code continuera de fonctionner avec cette version x.

Comme en plus je ne crois pas avoir utilisé des fonctionnalités jquery obsolètes (qui seront supprimées dans le futur) tu pourras sans doute faire des mises à jour de jquery pendant longtemps avant que le code écrit ne fonctionne plus. Dans ce cas tu pourras mettre mon code à jour mais si tu veux pas te prendre la tête, tu pourras toujours rester avec la dernière version de jquery qui fonctionne avec le code écrit :wink:

Re: [RESOLU] Protection formulaires.

par niconicochan » 27 janv. 2015, 13:22

Salut,

Un grand merci pour tout.
Pour les points 1), 2) et 3) c'est super clair, et tes explications sont d'autant plus intéressantes quand on les recoupe
avec celles que tu m'avais donné le 5 décembre - page 4, dans ce même message. Je comprends super bien avec ces deux messages lus ensembles :D :D :D

Oui, je me suis mélangé les pinceaux concernant les points 4) et 5).
Maintenant j'ai rappatrié jquery sur mon serveur et ça focntionne!!

Le point 4) aussi c'est réglé :D

Il n'y a donc plus que la question 5 qui me pose un petit peu soucis.
Je reformule ma question qui concerne donc jquery:

5) Le code de la bibliothèque m'a l'air très complexe, ... comment dire ...
ce serait écrit en russe je crois que je n'y verrai pas trop la différence.
J'ai toujours la même interrogation: si un jour la bibliothèque ne fonctionne
plus à cause d'un problème d'obsolescence du code par exemple,
je me vois mal aller corriger ce qu'il y a à l'intérieur du gros pavé de code!!
Comment faut-il appréhender la chose le jour où le code du "gros pavé"
ne marche plus?

Re: [RESOLU] Protection formulaires.

par AB » 26 janv. 2015, 21:46

1/ En php il y a curl par exemple

2/ Non, le pirate pas plus que l'utilisateur ne peuvent définir des variables de session. S'il arrive à voler l'identifiant de session, un pirate peut voler celles définies pour un autre utilisateur pour la session en cours, mais dès la session terminée toutes les variables sont supprimées.

3/ Il est plus facile d'écouter un réseau non crypté que de pirater une bdd, enfin je parle si y'a pas de trous de sécurité dans le code sql mais c'est relativement simple de se protéger avec des requêtes préparées. Et puis si le serveur est piraté on pourra connaître le système de concaténation/hashage qui est forcément quelque part dans un fichier sur le serveur. Donc un système de codage caché ne protège que dans certains cas. Après vaut-il mieux privilégier ces "certains" cas et laisser transiter le mot de passe en clair ou simplement hasché ?
En clair c'est très imprudent, limite cancre sauf si on utilise une connexion cryptée genre ssl.
Reste le choix entre hashage simple et hashage avec grain de sel. Là cela peut se discuter un peu plus. Un haschage simple permet d'utiliser des dictionnaires de hash existants alors qu'un grain de sel oblige à créer une nouvelle table et ce n'est pas une petite différence. D'autant plus que le sel étant différent pour chaque utilisateur il faudra créer une nouvelle table pour chaque utilisateur. Pour le pirate c'est assez dissuasif surtout qu'il ne sait pas trop où il va (le mot de passe peut être très long). Alors que pour un simple hash (sans sel) il lui suffira d'interroger une table de hash déjà existante pour voir si ça match. Et puis par ailleurs, si le post est toujours identique, en cas de piratage de ce post (écoute du réseau) cela permet de s'identifier sans avoir rien à déchiffrer (sans besoin de connaître le mot de passe) !!! Au sel unique par utilisateur j'ai donc ajouté un sel par session. Globalement c'est le plus sécurisé pour qui ne dispose pas de ssl (mais je précise bien à la fin du tuto que pour ceux qui disposent de ssl il est conseillé de maximiser la sécurité côté serveur).

4 et 5/ Je t'ai déjà dis plusieurs fois de télécharger jquery sur ton serveur pour éviter d'avoir à faire appel à google. Et je n'ai jamais dit que le lien google apportait plus de sécurité. Tu as compris le contraire de ce que j'ai écris :(

Re: Protection formulaires.

par niconicochan » 26 janv. 2015, 11:17

Bonjour,

J'ai réussi à adapter complètement le deuxième tuto à mon site :D :D :D :D :D
Un très grand merci pour toute l'aide apportée à la résolution de mon problème!!
Ca a été pour moi un très bon exercice aussi d'arriver à adapter mon captcha à l'authentification,
et comme tu le comprends, si j'arrive à l'intégrer au tuto je peux donc aussi très facilement l'enlever maintenant :D

Comme il se doit, je mets donc le sujet comme résolu.

A vrai dire, j'avais gardé quelques questions clefs que je voulais
te poser une fois seulement que tout est fini pour ne pas "couper" sans cesse l'avancement
du travail.
Je t'assure n'avoir jamais posé autant de questions sur un message mais le sujet est vraiment pointu.
Mon but n'est pas de faire traîner le discours avec plein de questions (le message est mis comme étant résolu)
mais d'avoir une vue d'ensemble complète sur un sujet aussi difficile!! :)

1) A un moment, tu dis qu'un pirate peut utiliser un "faux formulaire" (réponse du 27 novembre 2014 - page 4).
J'aimerais bien savoir ce que tu entends par "faux formulaire".

2) Lors d'une attaque réseau, le pirate arrive à s'authentifier, certes pour une durée très limitée seulement du fait
du sel aléatoire qui donne une unicité au POST. Si jamais durant le vol de session il arrive à récupérer le login
dans la bdd qui lui est en clair, il a alors bien le même login qui est la seul valeur vérifiée dans la variable du login
sur toutes les pages de la session. N'a t-il pas alors un moyen d'envoyer cette valeur sur les pages de la session
pour pouvoir se connecter d'où il veut, quand il veut et autant de temps qu'il veut?
(sur les pages de la session autres donc, que la page d'authentification, on ne vérifie plus ni mot de passe,
ni sel aléatoire). Il y a un lien entre cette question et la première.

3) Le javascript qui récupère puis efface le mot de passe de l'utilisateur permet, contrairement au php,
de protéger le mot de passe car ce dernier n'est pas envoyé sur le serveur jusqu'à son effacement.
En revanche, le code source indique tout le processus de concaténation des variables écrit en js.
A mon sens, cela enlève pas mal l'intérêt du grain de sel fixe:
le pirate qui arrive à voler les données en bdd connaît donc le grain de sel fixe et sait comment
ce dernier est utilisé dans le processus de concaténation.
Avec une rainbow table s'il arrive à "déhashé" l'ensemble "mot de passe + grain de sel fixe",
le mot de passe est à porter de main. Il a aussi le login.
Il a donc tout ce qu'il faut pour s'authentifier.

4) Je ne comprends pas bien pourquoi le lien google apporte davantage de sécurité par rapport,
par exemple, à un programme Ajax écrit soi-même, qui contient un token lui-aussi.

5) Je suppose donc qu'en cas d'obsolescence du code du lien, il faille téléchargé un lien plus récent de la même
librairie (à moins que Google veille à ce que le contenu des librairies en ligne soit régulièrement mis à jour).
Ma question est, si un jour je m'aperçois que le lien ne fonctionne plus, comment dois-je m'y prendre?

Que tu acceptes ou non de répondre à ces dernières questions, je te dis en tout cas un TRES GRAND MERCI
pour tout l'aide apportée :D

Re: Protection formulaires.

par AB » 21 janv. 2015, 19:34

Surtout qu'on met quasiment jamais de chapta pour une authentification. Cela fait double emploi et tu risque de bassiner (emm**) trop les visiteurs.

Re: Protection formulaires.

par niconicochan » 21 janv. 2015, 15:06

En fait, avec un tableau $_POST je récupère ma variable :D
Je serais néanmoins curieux de savoir pourquoi le js lui ne fonctionnait pas...

Mais bon, je peux continuer à travailler en tout cas!

Re: Protection formulaires.

par niconicochan » 21 janv. 2015, 14:09

Merci.

J'ai fait le plus dur maintenant!!
Mais il me reste à adapter le captcha. C'est pas du gâteau!! :(
Je comprends très bien le code en php, constitué grosso modo de 3 tableaux associatifs imbriqués les uns dans les autres
et d'une fonction array_rand.
Mais c'est le javascript qui me fait des misères!

J'ai un bouton qui permet à l'utilisateur d'écrire la réponse de mon captcha question/reponse:
]<input type="text" name="captcha_response" />
Dans un premier temps, je cherche juste à récupérer sa réponse et à la mettre dans une variable.
Je m'y prends ainsi:
<input type="text" name="captcha_response" id="captcha_response" onblur="reponseQuestion" />
<!-- ajout d'un id et de l'évènement onblur pour récupérer la réponse lors de la perte du focus.-->
Plus haut, j'écris la fonction reponseQuestion:
[javascript]
<script type="text/javascript">
function reponseQuestion(reponseCaptcha){
var reponseCaptcha = document.getElementById("captcha_response").value;
return reponseCaptcha;
}
</script>
[/javascript]

Hors, une alert reponseCaptcha dans ou en dehors de la fonction ne donne rien.
J'ai fait d'autres tests avec alert qui me laissent dire que la fonction n'est tout simplement pas lue.

Est-ce que tu peux m'aider en m'expliquant pourquoi?

On dirait que le navigateur ne fait pas de lien entre ce qu'il y a dans mon input et ma fonction.

J'ai un peu honte de poser cette question car je sais que c'est du javascript très rudimentaire :oops:

Re: Protection formulaires.

par AB » 19 janv. 2015, 21:28

Dans l'absolu ça sert à rien que le sel soit hasché, l'important est qu'il soit unique et non devinable.

Je m'en sert pour formater la chaine de caractères qui constitue le sel avec une longueur de valeur fixe et aussi parce que j'utilise "openssl_random_pseudo_bytes" qui sinon renvoie des caractères barbares. C'est une façon habituelle de faire.

Re: Protection formulaires.

par niconicochan » 19 janv. 2015, 19:22

Merci, la méthodologie est excellente!! :D
Du coup, lorsque les identifiants sont corrects j'arrive maintenant à obtenir le message: Vous êtes maintenant connecté !
avec la page et la table de mon site!

J'ai par ailleurs remarqué que le sel fixe de la table du tuto est hashé (oui, je remarque ça seulement maintenant!).
J'ai trouvé ça curieux car chez moi par contre, le sel fixe de l'utilisateur X est en clair.
J'ai appris que dans une bdd j'ai le hash de l'ensemble mot de passe + sel fixe contaténé et à côté le sel fixe en clair.
Toi, non. Est-ce mieux comme tu fais?
A moins que tu aies juste mis un sel fixe qui est en réalité n'est pas hashé, mais paraît hashé de part sa longueur et sa combinaison...

Re: Protection formulaires.

par AB » 16 janv. 2015, 01:32

Oui, comme tu l'a compris, l'entêtement n'est pas toujours rentable surtout sur un sujet sensible qu'on ne connaît pas bien. Peu de tutos proposent un code complet et fonctionnel, alors se serait dommage de ne pas en profiter. Rien ne t'empêcheras de comprendre les lignes unes à unes plus tard. Mais en attendant tu seras parti sur de bonne bases qui te permettront d'évoluer plus facilement par la suite.

La procédure "standard" est de partir du tuto installé dans une page vierge, de mettre les bons paramètres de connexion dans les deux fichiers php, sans oublier de créer la table sql pour rendre l'ensemble fonctionnel. Tu l'as déjà fais au moins une fois donc tu sauras le refaire si besoin.

Ensuite quand tu modifies le code tu fais des tests à chaque changement un peu risqué pour vérifier le comportement. Fais des sauvegardes du fichier sous différents noms pour chaque étape un peu importante ça t'éviteras de perdre trop de travail en cas de problème. Ensuite il te suffira de te demander "à quelle étape de mes sauvegardes (et donc à cause de quels changements) mon sel n'est-il plus récupéré ?". Et ainsi de suite pour les autres problèmes qui surviendront :)

Re: Protection formulaires.

par niconicochan » 15 janv. 2015, 23:34

En fait, c'est toi qui avait raison!
Je reconnais avoir été un peu têtu :mrgreen:

C'est bien mieux de tout remettre à plat comme tu dis, j'ai tout à gagner!

Du coup, je me suis remis à bosser en utilisant le tuto à 100%.
J'ai en ce moment un soucis pour récupérer le sel fixe via l'Ajax. Il est vide!!
Comme tu m'as conseillé, je m'aide de plusieurs alert et aussi de document.write()
pour comprendre où ça cloche et où ça marche.
A mon avis je devrais trouver la solution la semaine prochaine.

Mais maintenant je te dis juste où j'en suis, je ne pose pas de questions :mrgreen:

Re: Protection formulaires.

par AB » 15 janv. 2015, 21:53

A/
A ton avis que veut dire :
A noter que par facilité j'utilise jquery et ici avec un lien google. Je conseille plutôt (envers et contre tous ceux qui disent le contraire) de rapatrier jquery sur votre serveur car je conçois mal qu'on puisse se mettre sous la dépendance d'un autre serveur (quand bien même s'appellerait-il google qu'on a vu suffisamment de fois ramer au passage) pour les services importants d'un site.
Que pourrais-tu donc faire pour suivre ce conseil ? Bon je t'aide un peu, tu vas ici et tu cliques sur "Download the compressed, production jQuery 1.11.2". Je te laisse imaginer la suite.

B/
Si tu ne reprends pas le code php, il faudra faire de toutes façon l'équivalent. Eventuellement tu peux passer à mysqli mais pour le reste la logique doit rester inchangée si tu veux les mêmes fonctionnalités. Et je ne te demande pas d'adapter ton site au tuto, je te demande d'adapter la page de connexion de ton site, et uniquement celle-ci, au tuto. Ou inversement si tu préfère, mais en changeant simplement les css et la partie html par exemple car ce que je veux dire est que tous les éléments de programmation du tuto (nom des champs du formulaire, code php, requête ajax) sont indissociables pour un fonctionnement correct.

Pour les autres pages il suffira de protéger celles qui le nécessitent avec la ligne de code qui vérifie l'existence de la variable de session définie lors de l'authentification. C'est tout.

Tu cherche vraiment des complications inutiles en voulant mélanger ton ancien code et celui-ci. Quel intérêt y-a-t-il puisque celui-ci est complet ? Au pire s"il te manque des champs dans le formulaire il te suffit de les rajouter ce sera infiniment plus simple.

Après, que tu sois satisfait de ton précédent code n'est pas un argument, sauf s'il possède exactement les mêmes fonctionnalités que celles souhaitées. Pour passer certains paliers il vaut parfois mieux tout remettre à plat, car la modifications de certaines lignes ça et là n'est pas suffisante ou obligerait à des codes fastidieux/périlleux/bancaux.

J'ai fais un tuto pour montrer comment passer le palier d'une authentification avec sel côté client et côté serveur. Libre à toi de l'utiliser intelligemment, ou pas. Si t'as pas le temps, laisses tomber et reviens éventuellement sur le problème quand tu auras le temps.

Evites de penser que tu va pouvoir prendre une fonction par ici, une autre par là et secouer le tout pour obtenir un résultat. Il faut maîtriser le code sur le bout des doigts pour faire cela et c'est assez pointu quand il s'agit de sécurité. D'une part tu n'en as pas encore les capacités mais surtout et c'est le plus important, je ne vois strictement aucun intérêt : encore une fois il ne s'agit que du code d'authentification (donc pour la seule page d'authentification) et il est complet.

Re: Protection formulaires.

par niconicochan » 15 janv. 2015, 14:54

Salut,

J'avais déjà relu tout le tuto en détail et m'étais au préalable renseigné sur certaines fonctions php
qui m'étaient nouvelles, donc j'avais bien en tête, par exemple,
le sens de filter_input.
Je garde bien en tête que le temps que vous me consacrez est précieux pour vous et pour moi,
et ce n'est bien entendu pas dans mon intention de vous demander des choses que je peux vérifier moi-même
(c'est aussi pour cela que j'ai pris soin de relire tous les messages écrits depuis le début, pour
éviter toute répétition de votre part dans la mesure du possible).

Maintenant, mon problème concerne la récupération du grain de sel fixe.
Tout le reste fonctionne merveilleusement bien!
Ton programme Ajax pour aller chercher le grain de sel fixe à l'air plus sécurisé que le miens,
et il part de la fonction javascript ce qui n'était pas non plus le cas du miens.

J'entends très bien ta recommandation que j'utilise le code du tuto "difficile"
pour terminer ma programmation, et j'entends également que dans cet élan
je ne cherche pas coûte que coûte à tout vouloir comprendre tout de suite.
Je suis OK. Si je termine ma programmation, c'est mission accomplie.
Je laisse donc mes quelques autres interrogations sur le sel aléatoire de côté...

Mais j'ai des difficultés pour terminer cette programmation:

A.
Si je veux utiliser la librairie, je suis donc dépendant de Google.
Si demain il y a un problème au sein de la librairie pour x raison
(le code est devenu obsolète par exemple), je suis complètement coincé.
Et si des utilisateurs me font savoir qu'ils n'arrivent pas à se connecter
je ne serai pas à même de réparer une librairie dont je ne connais pas le code,
ce qui est d'autant plus embêtant "s'il faut faire vite" (ce point est très important).

C'est pour cela que je ne peux m'empêcher de penser si je n'aurais pas intérêt à garder
mon programme Ajax qui par ailleurs marche, et à l'adapter pour qu'il fonctionne à partir de la fonction
js avec un grain de sel aléatoire faisant office de token.

B.
Maintenant, car l'idée c'est quand même de travailler à partir du tuto "difficile",
je vais de toute façon adapter ce tuto à mon site, et non adapter mon site au tuto.
L'idée est de ne pratiquement rien changer de la partie en js,
mais je ne vais pas reprendre la partie suivante:
<?php 
ini_set('session.use_only_cookies', true);
session_start();
header('Content-type: text/html; charset=UTF-8');

// Activer openssl si possible (sur le serveur) pour pouvoir se servir de la fonction 'openssl_random_pseudo_bytes'
function Unique_Sel()
{
        return function_exists('openssl_random_pseudo_bytes')? hash("sha512",openssl_random_pseudo_bytes("128", $cstrong)) : hash("sha512",uniqid(rand(), true));
}

// On part du principe que le mot de passe est enregistrer comme ci-dessous en bdd (définir un passe) :
/*
$mot_de_passe = 'b';

// et rentrez ces valeurs en bdd (avec un login correspondant)
echo 'sel = '. $sel = Unique_Sel();
echo '<br>';
echo 'pass = '. hash("sha512",$mot_de_passe.$sel);
*/



// $_SESSION["login"] est définie uniquement si l'authentification est réussie. Si l'on est déjà enregistré normalement on fait un header de redirection vers une page souhaitée par exemple "menu.php"
if(isset($_SESSION["login"]))
{
        // Désactivé pour l'exemple. 
        /*
                header('Location: menu.php');
                exit;
        */
}

// Teste les retours attendus du formulaire
$reponse = filter_input(INPUT_POST,'reponse', FILTER_SANITIZE_STRING, FILTER_FLAG_STRIP_LOW | FILTER_FLAG_STRIP_HIGH);
$login = filter_input(INPUT_POST,'nom', FILTER_SANITIZE_STRING, FILTER_FLAG_STRIP_LOW);

// Définition et récupération du sel aléatoire de session
$_SESSION["sel"] = isset($reponse,$_SESSION["sel"]) ? $_SESSION["sel"] : Unique_Sel();


// Message par défaut
$message = null;
// Initialisation des erreurs
$erreur = null;

// Si le formulaire est envoyé 
if (isset($login,$reponse))
{ 
        // Connexion à la base de donnée, ici test sur une bdd en local       
        // normalement on enregistre ces variables dans un fichier que l'on inclus avec un require
        $hostname = "127.0.0.1";
        $database = "nom_de_ma_base";
        $username = "root";
        $password = "";
        
        try
        {
                // Configuration de PDO et connexion
                // récupération mode objet
                $pdo_options[PDO::ATTR_DEFAULT_FETCH_MODE] = PDO::FETCH_OBJ;

                // mode d'erreurs
                $pdo_options[PDO::ATTR_ERRMODE] = PDO::ERRMODE_EXCEPTION;
                
                // Indispensable pour ne pas avoir execute qui formate en string avec un tableau en paramètre  (incompatible avec la clause limit)
                $pdo_options[PDO::ATTR_EMULATE_PREPARES] = false;
                
                //charset reconnu dans la connexion à partir de php 5.3.6 auquel cas on peut supprimer l'option MYSQL_ATTR_INIT_COMMAND ci-dessous
                //$pdo_options[PDO::MYSQL_ATTR_INIT_COMMAND] = "SET NAMES utf8";
                
                $connexion  = new PDO('mysql:host='.$hostname.';dbname='.$database.';charset=utf8', $username, $password, $pdo_options);        

                // Sélection du mot de passe correspondant au login (structure pour requête préparée)
                $query = "SELECT pass FROM test WHERE login = ?";
                
                // On prépare la requête
                $stmt = $connexion->prepare($query);
                // On lie la variable avec binParam
                $stmt->bindParam(1, $login);
                // Et on exécute
                $stmt->execute();
                
                // On récupère le tout dans un tableau (ce qui permet ici de compter facilement les résultats)
                $result = $stmt->fetchAll();
                
                if (empty($result))
                {
                        // On sait ici que le login est non valide mais pas besoin de renseigner plus présicément les pirates
                        throw new Exception("Identifiants non valides");
                }

                // On ne devrait jamais rentrer dans la condition ci-dessous si la table est bien construite avec une clé primaire sur la colonne du login. Cela dit ce contrôle complémentaire ne coûte pas cher...                
                if (count($result) > 1)
                {
                        throw new Exception("Erreur d'unicité du login");
                }
                
                // Récupération du pass (première ligne du tableau $result) qui est égal à : hash("sha512",mot_de_passe.sel_bdd);
                $pass = $result[0]->pass;
                
                // On reconstruit la même chaine que celle construite avec javascript pour renseigner le champ "reponse"
                $compare_bdd = hash("sha512",$_SESSION["sel"].$pass);
                
                // On compare les deux valeurs et si oui
                if($reponse == $compare_bdd)
                {
                        // On efface cette variable de session qui ne sert plus à rien
                        unset($_SESSION["sel"]);
                        
                        // On régénère les identifiants de session
                        session_regenerate_id(true);
                        
                        // Déclaration de la variable de session témoin de l'enregistrement
                        $_SESSION["login"] = 1;
                        
                        // On envoie un message, sauf si on préfère la redirection mise en commentaire juste après
                        $message = "Vous êtes maintenant connecté !";

                        // Désactivé pour l'exemple. Normalement on fait un header de redirection vers une page souhaitée par exemple "menu.php"
                        /*
                                        header('Location: menu.php');
                                        exit;
                        */
                }
                else
                {
                        // On sait ici que le pass est non valide mais pas besoin de renseigner plus présicément les pirates
                        throw new Exception("Identifiants non valides");
                }
        }
        catch (PDOException $e)// on récupère les erreurs PDO
        {
                // message en production
                $erreur = "Erreur dans la requête d'authentification";
                
                // message complet en développement -> !!!!!!! IMPORTANT mettre la ligne ci-dessous en commmentaires pour la production (pas besoin de renseigner plus précisément les pirates !!!!!!!! 
                $erreur .= ' : '.$e->getMessage();
        }
        catch (Exception $e)// puis on récupère les autres erreurs générées avec throw
        {
                $erreur = $e->getMessage();
        }
        
        $message = isset($erreur) ? $erreur : $message; 
}
        
?>
J'ai déjà codé cette partie dans un fichier de traitement de formulaire,
et comme je suis très satisfait de cette partie de mon travail
je ne vais pas tout rechanger.

Je reprends également tel quel tout ton programme sur l'Ajax,
ce qui fait qu'au final je reprends pratiquement tout ce qu'il y a dans ton tuto.

Je risque d'avoir peut-être des soucis d'adaptation du tuto sur mon site,
mais ça je t'en parlerai après dans le cas seulement où je me retrouve complètement bloqué.
Il se peut donc, et je l'espère, que j'y arrive tout seul.

Re: Protection formulaires.

par AB » 14 janv. 2015, 21:31

Et même s'il pense faire une rainbow table afin de récupérer le mot de passe en clair le grain de sel aléatoire faussera de toute façon tout l'intérêt de la table!
Il peut créer une table puisque s'il a piraté le réseau il dispose de toutes les variables sauf le mot de passe. Mais il ne pourra pas créer de table à l'avance à cause du sel aléatoire et non plus se servir d'un dictionnaire. Pour lui c'est très handicapant, et rien ne dit que ton mot de passe n'est pas très long ce qui le rendrait indéchiffrable avant de longues années. Par exemple, pour un administrateur on pourrait imaginer se servir d'une chaine de plusieurs centaines (voir plus) de caractères.
Est-ce que tu le fais simplement car cette variable ne sert plus à rien ou parce que sa présence peut me porter préjudice?
Il me semble que j'ai déjà répondu à cette question suite à une de tes interrogations précédentes. Et d'après toi ?
Je comprends que suite à l'authentification j'enlève mes $_SESSION['sel_aleatoire'] en haut de chacune de mes pages de session
car cela n'a aucune utilité.
Surtout que le dernier tuto ne fait jamais mention de cette variable. Encore une fois, merci de ne faire référence qu'au dernier tuto ici. Les autres exemples étaient des bouts de code incomplets et tu risque de tout mélanger (la preuve avec cette variable).
Autre chose, est-ce qu'à ton avis, dans la foulée, c'est mieux d'effacer aussi la variable du mot de passe
(qui consiste en la concaténation du mot de passe et du sel fixe, cet ensemble hashé, puis lui-même concaténé au sel aléatoire et le tout à nouveau hashé)
et que je déclare en début de session seulement l'id_user et le login vérifiés en haut de chaque page de session?
Ou bien est-ce que tu prônerais plutôt pour le garder, le déclarer en début de session avec l'id_user et le login et vérifier sur chacune de mes pages de session
que j'ai à la fois l'id_user, le login et le mot de passe de l'utilisateur?
Cela fait plusieurs fois que je t'ai montré le code pour vérifier l'authentification. Cela se compose d'une variable de session (login dans mon exemple), les autres sont inutiles mais si tu veux mettre une autre en plus pourquoi pas. En TOUS CAS il ne faut en aucun cas garder le mot de passe en session, haché ou pas (sauf besoin impératif mais qui normalement ne se pose pas). Au passage j'ai de de gros doute sur l'utilité d'un id_user dans ta table puisque normalement "login" doit être unique et doit pouvoir faire office de clé primaire.

Les tokens servent pour contrer les "failles csrf" (déjà dit). Rentre cette expression dans un moteur de recherche pour en savoir plus, c'est pour éviter les requêtes forgées (faites en dehors de ton site).

Que voudrais-tu que l'on fasse de plus comme vérification dans la page "recuperation_sel.php" ??
Au passage je te signale que filter_input est une fonction qui filtre. Il faut que tu comprenne toutes les fonctions utilisées (dans un premier temps dans le code php) sinon t'a pas fini de te poser des questions. Tu prends le nom de la fonction tu la colle dans google et tu auras le manuel php très souvent en lien en première ligne.

Je réponds pas à tes questions suivantes, tu devrais trouver par toi même puisque j'ai déjà répondu à chacune d'entre elles. Enfin bon je préfère oublier l'histoire d'un token fixe, tout ça pour ça :evil: (si un token peut être prévu à l'avance il ne sert à rien).

Arrêtes un peu de poser des questions (elles tournent en rond) et bosse le code php pour le comprendre ligne par ligne. Quand tu auras compris tu auras tes réponses (surtout que chaque ligne est commentée).
Et puis rien ne sert de courir, il te faudra plusieurs mois avant de ne plus être débutant. Il faut trouver des réponses aux questions unes à unes, je veux dire bien comprendre la première avant de s'interroger sur la suivante. Avec une lecture globale on peut saisir vaguement le sens, mais dans la réalité d'un code il faut tout saisir avec précision et savoir pourquoi on le fait :wink:

Après c'est normal que tu rames. Le tuto n'est pas prévu pour des débutants contrairement à celui-ci qui propose la base d'une authentification (mais sans sel). Normalement tu aurais du commencer par ce premier, puis acquérir de l'expérience - en faisant des exercices de code fonctionnel dans des pages séparées et pas seulement une lecture - puis t'intéresser aux problèmes de sécurités, puis étudier le dernier tuto avec sel. Tu peux peut-être éviter la première étape, pas les suivantes :wink: