Discussion :

[steph68b]

... sachant que le zéro risque et 100% safe n'existe pas: coté serveur ou coté client, si on veut on peut!

ce à quoi je pensais au final:
-> juste restreindre à disons 20 car (min 6) le pass saisi par le user
-> rajouter un bon préfix+suffix en salt
-> reste à savoir où stocker le salt:

* une $variable dans un fichier .php stocké hors www?

* en bdd, mais il transitera aussi?

HTTPS: j'y avais pensé oui, mais ne me suis pas encore penché sur la question, comment faire, etc...

password pas en clair en base: aaaaaaaaaaaaaaah bon????? naaaaaaaaaaaaaaaan!!! on m'aurait menti?????

[sekaijin]

non côté client ou côté serveur ce n'est pas du tout pareil

je vais caricaturer avec des règles débile
^[AB][a-z]{2}$
bref soit A soit B suivit de deux caractères.

avec une règle aussi débile pour attaquer le système qui n'expose rien (tout côté serveur) le hacker part sans aucune connaissance il va donc passer du temps à chercher de mots de passe hors de la règle.

si maintenant je mets ça dans le code js côté client
le hacker lit la règle ^[AB][a-z]{2}$ dans le fichier js.
il sait donc qu'il a 2 X 26 X 26 possibilités il peut donc se concentrer sur celles-ci.

Il y a là une sacré différence.

si tu choisis d'utiliser un logiciel de hack pour valider tes mots de passe. tu va éliminer les mots de passe trop faibles sans pour autant réduire drastiquement le champs des possibles.

si tu fais un appel ajax pour valider le mots de passe il faut que cette url soit libre et tu ouvre donc une porte pour faciliter les attaques.

alors que si tu ne vérifie rien avant l'envoi du formulaire tu peux valider le mot de passe avec une formule connue que du serveur (dico de hack min max par exemple) et quelque soit la raison pour laquelle tu invalide le mot de passe (les deux saisie différentes, trop faible trop court trop long etc.) tu retourne simplement "mot de passe incorrect"

L'utilisateur sera contraint d'en saisir un autre mais tu ne lui dit pas pourquoi. ainsi tu ne le dit pas non plus à un hacker.

et pour arranger la sauce tu peux dès le début avertir ton utilisateur
"Veillez à choisir un mot de passe robuste, vous n'avez droit qu'à 3 tentatives et par mesure de sécurité aucune information ne vous sera fourni en cas d'échec !"

etc.

bref la solution qui consiste à donner au hacker les règles d'écriture des mots de passe est la pire de toutes.

A+JYT

[mathspountz]

Bonjour à tous,

Je suis un peu hors sujet, mais pourquoi conseillez-vous de stocker le salt et le hash du mot de passe dans deux endroits différents ?

Bien à vous,

[Gnuum]

Si tu te fais hacker ta base de données utilisateurs et que l'attaquant récupère les mots de passe cryptés + le salt, il peut retrouver l'algorithme de cryptage en faisant du brute force (en gros je concatène salt + azerty) et je teste différents algorithmes jusqu'à ce que j'arrive à décoder un des mots de passe. Ensuite, je peux appliquer la méthode sur les autres pour essayer de les décoder.

C'est là que la dureté intrinsèque du mot de passe entre en jeu. Il est beaucoup plus difficile d'arriver à décoder chaque mot de passe même en ayant le salt (car on utilise la brute force) et plus le mot de passe est compliqué, plus il faut tester de combinaisons. On peut également remarquer que la façon dont est concaténé le salt peut en lui même être une sécurité car l'attaquant a peu de chance de déterminer cette liaison (sauf s'il vole le code en même temps que la base!) si elle est non habituelle (e.g. '@15465' + salt + '#F87pez' + password).

Enfin, si le salt est stocké sur une autre base de données, il faut que l'attaquant arrive à voler les 2 bases de données pour avoir une chance de reconstituer les mots de passe. C'est un peu plus compliqué à mettre en place, c'est sûr. Mais si tu fais le reste c'est déjà bien.

Pour revenir, sur les suggestions de non divigulgation des règles de mot de passe et de vérification AJAX, je me permets de faire remarquer que cela ne sert à rien. Tester le format du mot de passe côté serveur plutôt juste du client est une nécessité car on ne peut se contenter de vérifier un input côté client (javascript du formulaire facilement falsifiable). En revanche, faire une requête AJAX pour cacher les règles n'a aucun intérêt puisqu'on sera bien obligé de me les rappeler si je mets un mot de passe avec un mauvais format de toute façon!

[steph68b]

Débat très intéressant dites-donc, je ne pensais vraiment pas à certaines choses, au départ...

Par contre, quid de la solution avec une $variable dans un fichier .php stocké hors www?
-> le serveur web, lui, peut y accéder
-> en principe un user lambda non, puisque tu ne peux pas entrer 1 url "hors web", à priori, non?

[Gnuum]

Par contre, quid de la solution avec une $variable dans un fichier .php stocké hors www?

Je ne comprends pas très bien ce que tu veux dire exactement mais, en PHP, une variable ne stocke une valeur que le temps où le script qui l'a produite s'exécute (i.e. une requête). Je ne vois pas trop ce que tu veux/peux en faire donc.

-> le serveur web, lui, peut y accéder
-> en principe un user lambda non, puisque tu ne peux pas entrer 1 url "hors web", à priori, non?

Si un utilisateur ne peut accéder à un fichier .php (potentiellement interprété), cela veut dire que le serveur web non plus.
En revanche, un fichier PHP qui n'est pas rendu accessible par le serveur web peut l'être indirectement s'il est inclus par un autre fichier qui lui est rendu accessible par le serveur web.

[steph68b]

Oui voilà, il me semblait avoir lu un truc comme ça, une fois, dans un bouquin:

toto.php

Code :

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

require($pathhorsweb+"safe.php");

safe.php

Code :

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

1
2
3
4
$host = "......";
$user = "...........";
$pass = ".............";
$bdd  = "..........";

par exemple pour la chaine de connexion à la DB

ou par extension

Code :

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

define("SALT", "....................");

[Gnuum]

La différence entre ta chaîne de connexion à la base de données et ton salt, c'est que c'est mieux que ton salt soit unique par utilisateur (pour maximiser la difficulté de décodage pour chaque utilisateur). De plus, ce n'est pas évident de stocker sa chaîne de connexion à la base de données dans la base de données..
En revanche, comme je disais, ajouter une sorte de "double salt" via une concaténation complexe dans ton code peut être une sécurité supplémentaire.

[steph68b]

Ok, donc le principe du fichier hors web, utilisé comme ça, n'est pas bidon alors! Cool, faut que je teste ça!

De mémoire, dans le bouquin, pour les data sensibles de ce style, y avait aussi:
-> le php.ini
-> des variables d'environnement

[steph68b]

laquelle des 3 méthodes serait la plus safe, pour vous?

[steph68b]

Pas d'avis sur la question?

[steph68b]

Bon, ben tant pis.