J'accepte la critique d'autodidaxie. Cela dit, on reste sur un système qui n'est utilisé que par moi et qui n'engage que moi, pas quelque chose que j'utiliserais dans une Web-application grand public (tiens, je devrais mettre un avertissement sur la page password.html).
C'est vrai que j'aurais pu mettre un sel, c'est un peu bête de ma part. Cela dit, le mot de passe maître est plutôt long (20 caractères aléatoires), ce qui compense un peu. L'intérêt du sel est multiple, mais il permet en particulier d'éviter que les hashs ne soient matchés contre une base de données de mots de passe courants, et en l'occurrence ça ne va pas y être. Un autre intérêt, c'est d'éviter les collisions entre mots de passe qui se trouveraient être égaux, pour répartir le risque, mais tous mes mots de passe sont différents par construction (à cause de l'apex). Et il y a une question d'échelle qui joue aussi : si j'étais Facebook, il serait clairement essentiel d'associer à différents mots de passe des sels différents, parce qu'il y a tellement de mots de passe dans la DB et tellement de valeur à retirer d'un craquage — donc tellement d'enjeu — qu'il y a un risque évident, si on prend le même sel à chaque fois, que des gens investissent des ressources de calcul importantes pour créer une table géante des hashes des mots de passe courants concaténés avec ce sel particulier. Mais là, on parle d'une personne dans le monde avec cent pauvre mots de passe, et qui n'est pas non plus ciblée par la NSA. Je ne crois pas que changer le sel à chaque fois soit essentiel dans ce cas de figure.
Et j'accepte aussi la critique d'avoir utilisé SHA256 et pas une fonction de hachage un peu dure à calculer. Mais l'API window.crypto.subtle.digest des navigateurs n'a que le SHA1 (pas sécurisé), le SHA256, le SHA384 et le SHA512. Je ne voulais pas introduire des dépendances JavaScript, d'abord je n'y connais rien au développement Web, et ça fait de la maintenance (et, paradoxalement, un risque de vulnérabilités si j'oublie de mettre à jour la dépendance...).
[^] # Re: Mauvaise idée
Posté par jeanas (site web personnel, Mastodon) . En réponse au journal Mon gestionnaire de mots de passe, en 50 lignes de HTML. Évalué à 4.
J'accepte la critique d'autodidaxie. Cela dit, on reste sur un système qui n'est utilisé que par moi et qui n'engage que moi, pas quelque chose que j'utiliserais dans une Web-application grand public (tiens, je devrais mettre un avertissement sur la page
password.html).C'est vrai que j'aurais pu mettre un sel, c'est un peu bête de ma part. Cela dit, le mot de passe maître est plutôt long (20 caractères aléatoires), ce qui compense un peu. L'intérêt du sel est multiple, mais il permet en particulier d'éviter que les hashs ne soient matchés contre une base de données de mots de passe courants, et en l'occurrence ça ne va pas y être. Un autre intérêt, c'est d'éviter les collisions entre mots de passe qui se trouveraient être égaux, pour répartir le risque, mais tous mes mots de passe sont différents par construction (à cause de l'apex). Et il y a une question d'échelle qui joue aussi : si j'étais Facebook, il serait clairement essentiel d'associer à différents mots de passe des sels différents, parce qu'il y a tellement de mots de passe dans la DB et tellement de valeur à retirer d'un craquage — donc tellement d'enjeu — qu'il y a un risque évident, si on prend le même sel à chaque fois, que des gens investissent des ressources de calcul importantes pour créer une table géante des hashes des mots de passe courants concaténés avec ce sel particulier. Mais là, on parle d'une personne dans le monde avec cent pauvre mots de passe, et qui n'est pas non plus ciblée par la NSA. Je ne crois pas que changer le sel à chaque fois soit essentiel dans ce cas de figure.
Et j'accepte aussi la critique d'avoir utilisé SHA256 et pas une fonction de hachage un peu dure à calculer. Mais l'API
window.crypto.subtle.digestdes navigateurs n'a que le SHA1 (pas sécurisé), le SHA256, le SHA384 et le SHA512. Je ne voulais pas introduire des dépendances JavaScript, d'abord je n'y connais rien au développement Web, et ça fait de la maintenance (et, paradoxalement, un risque de vulnérabilités si j'oublie de mettre à jour la dépendance...).