Tout à fait.

Salut,
On est bien d'accord là dessus : on ne stocke rien en clair. Mon message prêtait peut-être à confusion.
La difficulté que j'évoquais réside plutôt dans l'étape de vérification du hash coté BDD : password_hash() générant un hash différent à chaque fois, il m'est impossible de le comparer au hash stocké en BDD, depuis ma ps.
En revanche, si je génère le salt aléatoire du compte moi même, que je le passe en paramètre à password_hash avec ledit password et que j'enregistre ça en BDD, il me suffirait lors de la connexion de :

1) récupérer le couple login/pwd saisi par l'utilisateur
2) récupérer le salt associé au login (le salt aura été sauvegardé dans un champ à part afin de le récupérer),
3) passer un coup de password_hash() sur le PWD saisi en fournissant le salt (et le cout mais là rien de sorcier)
4) envoyer le résultat du 3) et le login à ma PS /requête

Euh... On ne retourne jamais de toute manière le mot de passe en clair côté PHP (sauf celui rentré dans le formulaire à la rigueur).
Quand on fait la plus simple des requêtes on envoi le mot de passe hashé et le login.
Et la requête renvoie les informations de la table (sauf le mot de passe), ou non si le couple n'est pas bon.
Du coup ta procédure stockée fait ce qu'une banale requête fait.

Salut,

Je suis en train de chercher des techniques me permettant de sécuriser au mieux les mots de passe de mes applications. J'ai déjà jeté un oeil à l'API password de PHP dispo depuis la 5.5, mais je me suis dit que je pouvais éventuellement pousser le vice plus loin en effectuant directement le contrôle en base de données au lieu de passer par password_verify() : depuis une fonction, une procédure stockée ou une routine (rayer la mention inutile).

Je galère un peu à trouver une solution propre dans la mesure ou j'aimerais produire une fonction à laquelle je fournis simplement le login et le mot de passe, et qui me renverrai un booleen m'indiquant si le couple est bon ou pas.

Outre le fait de pousser la paranoïa un peu plus loin, je cherche à retirer complètement de mes sources un accès direct aux mots de passe contenus en base de données, même hashés. Voilà donc ce à quoi j'en suis arrivé :

Soient une table "user", contenant un ID, un login unique, un password et un salt.
Soit une procédure stockée authenticate() acceptant un login et un password hashé en paramètre, retournant true si le hash correspond à l'enregistrement donné pour le login donné, false sinon.

1. Lors d'une tentative de login, Bob saisit son login (Bob) mot de passe depuis un formulaire. Son mot de passe a été sécurisé avec crypt(), blowfish et un salt aléatoire en BDD lors de son inscription.
2. PHP récupère les données du formulaire.
3. A l'aide du login, PHP est en mesure de demander le salt aléatoire associé à Bob.
4. PHP appelle crypt() sur le login, le mot de passe saisi dans le formulaire et le salt récupéré en 3..
5. PHP appelle une procédure stockée contenant le résultat de la fonction crypt() appellée en 4., ainsi que le login de bob
6. SQL exécute cette procédure stockée : elle compare le résultat de crypt() avec le contenu du champ password pour l'entrée concernant Bob, et retourne le résultat à PHP.
7. PHP vérifie le résultat, et permet à bob de se logger ou non.

En procédant ainsi, le "vrai" mot de passe ne déboule jamais coté PHP (sauf si c'est l'utilisateur qui l'a entré, mais dans ce cas là ce n'est pas vraiment un problème). En revanche on récupère le salt de l'utilisateur : c'est mieux mais à mon avis perfectible. On pourrait récupérer le salt lors de l'exécution de la procédure stockée mais comment alors régénérer le mot de passe tel qu'il est sauvé en BDD ?

Qu'en pensez vous ? J'insiste sur le fait qu'il s'agit plus d'une réflexion qu'une réelle nécessité, mais je pense qu'il est possible de trouver des cas concrets dans lesquels ce type de configuration pourrait être utile.

Merci d'avance pour les avis !