Sécuriser sa table utilisateur

[niahoo]

sticky plz

[Argorate]

Pour ce qui est d'empêcher le pirate de copier son mot de passe pour prendre le contrôle d'un autre utilisateur, es-ce bien utile?
Normalement, vous avez des back up de votre BDD de 24 ou 48h dans le pire des cas, donc peut importe se qu'il fera avec, on pourra le rétablir, je pense plutôt qu'au lieu de perdre du temps et des ressources a protéger ça, il vaut mieux protéger à la source => empêcher les injonctions sql et autres piratages d'accès a la bdd.
Qu'en pensez-vous?

[srm]

Concernant la salt on en a déjà parlé mais le mieux c'est d'avoir une salt aléatoire par utilisateur que tu stock en base.

---

Argorate tu ne sais pas forcément quand le gars t'a piraté, il a pu t'avoir piraté il y a 3 mois et pourrir ton système avec des ajustements mineurs. Et donc ton backup sert à rien car tu ne sais pas lequel est le bon, ou tu dois revenir bien trop loin en historique.

[niahoo]

Oui mais ça fera du bien de répéter un peu. Par exemple, pour le salt unique pour chaque user et stocké en base, je me souviens avoir admis que c'était cool, mais je ne sais plus pourquoi, car quand j'y réfléchis, je me dis que si quelqu'un à accès aux mots de passes hashés il a accès à tes tables et donc au salt.

[niahoo]

up

J'aimerais bien que quelqu'un réponde à mon post précédent car je souhaite mettre en place un truc similaire et je ne sais pas où stocker la graine unique de chaque utilisateur.

[Sephi-Chan]

Le pirate ne sait pas comment tu exploites le salt (si tu fais [ password, salt ].join("*") ou juste password + salt.


Sephi-Chan

[niahoo]

Ah ben c'est ce que je me disais mais ça me semblait cheap

[nicodd]

Et même dans la situation très favorable ou l'on connait les mots de passe hashés, l'algorithme de hashage et le salt correspondant à chaque utilisateur :
Avec un seul salt, on peut bruteforcer tous les mot de passe d'un coup, ou générer une seule rainbow-table.
Avec un salt par utilisateur, il faut bruteforcer chaque mot de passe indépendamment ou créer une rainbow-table par utilisateur, ce qui fait exploser le temps de calcul (qui avec un algorithme de hashage sérieux est déja énorme pour un seul mot de passe).

[Argorate]

si tu connais pas le salt (parce que tu ne le met pas en bdd) et que tu ne connais pas l'algorithme de hashage et l'utilisation du salt (car dans le code), tu pourras bruteforcer ce que tu veux, je vois mal comment tu pourras "bruteforcer tous les mot de passe d'un coup"?

[nicodd]

L'algorithme de hashage utilisé, tu peux le deviner dans 80% des cas grâce à la taille du hash généré. Ensuite, ce n'est pas parce que une partie de ta sécurité est dans le code qu'elle est inviolable (collaboration avec d'autres personnes, fuite au niveau de l'hébergeur, problème de configuration, plantage du serveur...).
Finalement, si tu veux bruteforcer le salt en supposant par exemple que le salt est simplement concaténé au mot de passe, il te suffit de le faire sur la ligne correspondant à ton compte, puisque tu connais déjà le mot de passe et le résultat, il ne te reste plus qu'a trouver le salt.
Le mieux me semble être un salt statique(code) + un salt dynamique (bdd), les deux suffisement longs, le tout avec quelque chose d'un peu plus sérieux que du md5.