Discussion :

[patic]

Bonjour,

Après digestion du livre suivant https://www.editions-eni.fr/supports...-9782409006340 et de plusieurs documents de l'OWASP, je réfléchis maintenant à mettre en place tout cela.

Pour information, je travaille avec le framework web asynchrone Sanic.

Deux questions se présentent à moi :

1. D'abord, le stockage du mot de passe des utilisateurs.
Le support sera une table dans une base de données Postgresql. Je choisis de hasher les mots de passe du côté du code Python, et non directement dans la base de données (avec pgcrypto).
Evidemment, exit les md5 ou sha1, totalement périmé pour faire cela. J'envisage d'utiliser la bibliothèque passlib avec argon2 ou bcrypt. scrypt est également proposé, mais je l'ai exclus sans raison apparente. J'hésite à utiliser argon2 car cela semble très récent (trop ???), même si je lis ici et là que c'est la solution numéro un.
Avec bcrypt, il y a un système que je n'ai pas compris totalement qui permet de stocker le sel avec le hash. Il s'agirait d'un sel dynamique, qui change à chaque fois ...
L'OWASP préconise d'utiliser un sel dynamique, c'est à dire qu'il change à chaque utilisation. On fait cela par exemple en chiffrant en AES l'identifiant qui va avec le mot de passe. On obtient bien ainsi un sel différent qui change à chaque fois, mais qu'il est possible de retrouver facilement.
Pour chiffrer en AES, j'utiliserai la bibliothèque cryptography.
Donc ma solution est de concaténer l'identifiant chiffré au mot de passe puis de hasher cela en bcrypt. Qu'en pensez vous ? Est ce une bonne pratique ?


2. Ensuite, le stockage de tout ce qui est sensible dans la code. Par exemple un sel, les identifiants et mots de passe aux bases de données et autres, etc.
Mes recherches m'ont conduite principalement vers deux solutions : soit le stockage dans un fichier de configuration, soit le stockage dans des variables d'environnement.
Pensez vous à d'autres solutions ? Que pensez vous de ces solutions ci-dessus ?
Bien évidemment, si un pirate expert prend la main sur le serveur, il aura de toute façon accès aux informations sensibles, au moins en lecture, quelque soit l'endroit où on les met.
J'ai tout de même un petite idée. Et si je mettais dans un fichier séparé (par exemple avec l'aide du module configparser) les données sensibles sous un format chiffré en AES. Ensuite avec l'aide du module argparse je fais en sorte de passer en paramètre la clé de déchiffrement. Il n'y a plus alors qu'un seul secret visible et celui ci sera du côté du paramétrage du démon (sous ubuntu) pour démarrer le serveur si je ne dis pas de bêtises (je ne l'ai jamais fait encore).
Au lancement du serveur je récupère la clé et je déchiffre toutes les valeurs sensibles qui seront alors chargées en mémoire.
Qu'en pensez vous ? Quels conseils me donneriez vous ?

Merci par avance pour votre aide.

[hotcryx]

La méthode est de stocker:

Code :

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

HASH( <password> + <salt> ) => hashed password

Ca permet de réduire l'utilisation des rainbow tables car il y a autant de possibilités qu'il y a de salt pour un seul mot de passe.

Le salt doit être long et différent pour chaque mot de passe.

[patic]

@hotcryx

Merci,
C'est effectivement la préconisation de l'OWASP, mais comment fais tu de ton côté pour avoir un "salt" différent à chaque fois ? Et cette histoire de sel avec bcrypt, est ce suffisant tout seul ?

[VinsS]

Salut,
Regarde du côté de Werkzeug, c'est une boîte d'outils en Python. Elle gère le "salted hash".

Tu ne dois pas t'occuper du "sel" c'est son problème.

http://werkzeug.pocoo.org/docs/0.12/...kzeug.security

Edit: un exemple retrouvé dans mes archives:

Code :

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

1
2
3
4
 
from werkzeug.security import generate_password_hash
pswd = generate_password_hash('déjàvu', method='pbkdf2:sha1', salt_length=8)
print pswd

[patic]

@VinsS

Merci pour ta proposition.

werkzeug étant derrière Flask et étant donné que j'ai souvent vu dans les tutoriels de Flask qu'on créait une variable globale contenant une phrase secrète, je pense que le sel provient de là. J'avoue, j'ai la flemme d'aller chercher les sources pour en être sûr.

J'attire au passage ton attention sur la faiblesse de cette implémentation utilisant 'pbkdf2:sha1'. Même avec sha256 disponible dans werkzeug, cela reste peut recommandé à la vue des lectures que j'ai faite récemment.

Regarde ici par exemple : https://paragonie.com/blog/2016/02/how-safely-store-password-in-2016

En fait, il faut distinguer les algorithmes de hashage, pour le stockage des mots de passe, des autres. Les seconds doivent être rapides, alors que les premiers doivent être lents.
A défaut avec les capacités de l'informatique d'aujourd'hui on peut estimer accessible la possibilité de retrouver la valeur d'origine. Sans compter qu'on a réussi à trouver des collisions dans md5 ou sha1 (ou les deux je ne sais plus). Une collision signifie qu'à partir de deux valeurs d'origine distinctes on a obtenu les mêmes valeurs hashées. Je ne saurai expliquer en détails pourquoi mais cela est une faille importante.
Les certificats TLS qui utilisait sha1 par exemple ont été bannis.

Le problème avec les conseils de l'OWASP, c'est qu'ils donnent peu d'indications sur les solutions à mettre en œuvre avec du python. Ils disent surtout ce qu'il ne faut pas faire. Pour moi qui suis novice, j'ai du mal à être sûr de la solution que je choisis, c'est pour cette raison que j'essaie d'avoir des avis sur le forum.

Merci pour ton aide

[hotcryx]

Salut Patic,

Tu ne dois pas utiliser MD5 et SHA1.
Passes à SHA2...

Rem: le salt ne doit pas être court => 8 caractères ça me semble court.

"werkzeug étant derrière Flask et étant donné que j'ai souvent vu dans les tutoriels de Flask qu'on créait une variable globale contenant une phrase secrète, je pense que le sel provient de là. J'avoue, j'ai la flemme d'aller chercher les sources pour en être sûr."

Quand tu regardes d'autres frameworks comme Mojolicious (Perl), il fait exactement la même chose pour sécuriser les cookies.