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

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

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

Bonjour,

J'ai réussi à adapter complètement le deuxième tuto à mon site
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

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

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

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

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é

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?

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

Merci encore

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