Produits Entr'ouvert » w.c.s.

Stocker directement la version hashée (voir plusieur comme tu dis) ça me parait le mieux; pour vous simplifiez la vie vous pouvez vous reposer sur les classes fournies par Django et les deux autres qu'on a nous même (w.c.s et Drupal); ça vous fait déjà une belle liste.

Yep. Mais il faut aussi permettre de stocker une version cryptée au cas où on doive ensuite l'envoyer à un webservice (ou autre) qui nécessite d'avoir le mot de passe en clair pour créer le compte. Breffllle...

Pour la liste Django :

('django.contrib.auth.hashers.PBKDF2PasswordHasher',
'django.contrib.auth.hashers.PBKDF2SHA1PasswordHasher',
'django.contrib.auth.hashers.BCryptPasswordHasher',
'django.contrib.auth.hashers.SHA1PasswordHasher',
'django.contrib.auth.hashers.MD5PasswordHasher',
'django.contrib.auth.hashers.UnsaltedMD5PasswordHasher',
'django.contrib.auth.hashers.CryptPasswordHasher',)

avec plein de code dans https://github.com/django/django/blob/master/django/contrib/auth/hashers.py

En option du champ, prévoir un champ regex de validation, où on pourra mettre :

^(?=.*[A-Z].*[A-Z])(?=.*[!@#$&*])(?=.*[0-9].*[0-9])(?=.*[a-z].*[a-z].*[a-z]).{6,}$

(de http://stackoverflow.com/questions/5142103/regex-for-password-strength)

redmine@entrouvert.com écrivait:

La demande #3201 a été mise à jour par Thomas Noël.

Yep. Mais il faut aussi permettre de stocker une version cryptée au
cas où on doive ensuite l'envoyer à un webservice (ou autre) qui
nécessite d'avoir le mot de passe en clair pour créer le compte.
Breffllle...

Si la clé de chiffrement n'est définissable que via site-options.cfg et
pas via l'admin web, ça protège de l'admin w.c.s qui modifie le workflow
pour récupérer un mot de passe mais qui n'a pas d'accès au serveur
d'hébergement par contre ça ne protège pas d'un admin unix indélicat.

Donc il faudrait que cet option ne soit utilisable que si cet clé est
défini. À ce propose je me demande si ce ne serait pas utile de générer
une 'secret_key' globale à l'installation du paquet w.c.s. un peu comme
la secret-key dans les projets Django ou alors à l'initialisation d'un
virtualhost par qommon on pourrait générer un site-options.cfg générique
contenant la secret-key.

redmine@entrouvert.com écrivait:

En option du champ, prévoir un champ regex de validation, où on pourra
mettre :

^(?=.*[A-Z].*[A-Z])(?=.*[@#$&*])(?=.*[0-9].*[0-9])(?=.*[a-z].*[a-z].*[a-z]).{6,}$

(de http://stackoverflow.com/questions/5142103/regex-for-password-strength)

Think of the users please. C'est carrément obscure et je suis sûr que ça
ne couvre pas des tas de politiques débiles sur la force des mots de
passe (« ne contient pas un élément du login » vu explicitement sur le
projet Gabriel de Formiris). Au pire je préfèrerai encore un champ
expression python, c'est tout aussi obscure mais au moins on peut tout
faire.

Benjamin Dauvergne a écrit :

Think of the users please. C'est carrément obscure et je suis sûr que ça
ne couvre pas des tas de politiques débiles sur la force des mots de
passe (« ne contient pas un élément du login » vu explicitement sur le
projet Gabriel de Formiris). Au pire je préfèrerai encore un champ
expression python, c'est tout aussi obscure mais au moins on peut tout
faire.

Comme ta proposition se contredit elle-même, je reste sur mon idée d'une bête regex comme dans les champs textes. Et tant pis si c'est limité et obscur. Na.

(blague à part : la notion de contrainte "générique" sur les champs d'un formulaire ou d'une page, c'est une chose à travailler ailleurs, de façon globale, et pas seulement sur ce champ là).

Benjamin Dauvergne a écrit :

redmine@entrouvert.com écrivait:
(...) Donc il faudrait que cet option ne soit utilisable que si cet
clé est défini.

Yep, bonne idée.

À ce propose je me demande si ce ne serait pas utile de générer
une 'secret_key' globale à l'installation du paquet w.c.s. un peu comme
la secret-key dans les projets Django ou alors à l'initialisation d'un
virtualhost par qommon on pourrait générer un site-options.cfg générique
contenant la secret-key.

Zou #3208 un peu pour mémoire et pour discussions

Note dans le cadre CG14 : les mots de passe seront à fournir en hash "Blowfish-based, variant 2a" (dans leur base actuelle ils utilisent dans la requête postgresql : crypt('motdepasse', gen_salt('bf', 8)) ).

Petit soucis : je ne trouve pas d'algo de hash "blowfish" dans Debian Wheezy.

• les options de force de mot de passe wcs : min_length, max_length, count_uppercase (minimum de majuscules), count_lowercase, count_digit, count_special
• possibilité de dire une liste des hashs sous lesquels on veut stocker le mot de passe (aucun, sha1, sha256, md5, etc) dans l'optique de pouvoir les envoyer à des systèmes externes ensuite
  • la variable "password_raw" serait un dico : {'md5': ..., 'sha1': ...}
  • l'affichage restant toujours "*******"

(pour le coup de password_raw, je dis ça sans avoir regardé si c'est possible)

Frédéric Péters a écrit :

Pour le moment j'ai juste mis plain, md5 et sha1.

Ca suffira pour la première release.

On pourrait aussi se dire que si on a "plain", un changement au champ pourrait mettre tous les hashs à jour, je passe.

Pas important (on n'a pas d'effet rétro-actif dans wcs pour l'instant).

Ce n'est pas testé en stockage conventionnel.

Testé, marche sans problème.

En revanche pépin d'export, il faudrait ajouter :

    def get_csv_value(self, value, hint=None):
        return ['*'*8]

Ok, je continue avec les autres paramètres et ajoute le get_csv_value.

Pour le hint, tu peux juste faire hint = kwargs.pop('hint', None). La ligne self.count_special = kwargs.get('count_special', 0) est dupliquée. C'était déjà dans mon mon patch mais le readonly=self.attrs.get('readonly'), est inutile vu la condition posée juste au-dessus.