Comme le note @RobW, restreindre le mot de passe à un nombre fixe de caractères comme le propose le schéma OP est une mauvaise idée . Mais pire, les réponses qui proposent un code basé sur Math.random
sont, eh bien, un très mauvaise idée .
Commençons par le mauvaise idée . Le code OP consiste à sélectionner de façon aléatoire une chaîne de 8 caractères parmi un ensemble de 62. En limitant la chaîne aléatoire à 5 lettres et 3 chiffres, les mots de passe résultants auront , au mieux L'entropie est de 28,5 bits (contre un potentiel de 47,6 bits si la restriction de distribution de 5 lettres et 3 chiffres était supprimée). Ce n'est pas très bon. Mais en réalité, la situation est encore pire. Le site au mieux de l'aspect du code est détruit par l'utilisation de Math.random
comme moyen de générer de l'entropie pour les mots de passe. Math.random
est un générateur de nombres pseudo-aléatoires . En raison de la nature déterministe des générateurs de nombres pseudo aléatoires, l'entropie des mots de passe résultants est de vraiment mauvais ce qui fait que toute solution proposée est une très mauvaise idée . En supposant que ces mots de passe soient distribués aux utilisateurs finaux (o/w what's the point), un adversaire actif qui reçoit un tel mot de passe a de très bonnes chances de prédire les futurs mots de passe distribués aux autres utilisateurs, et ce n'est probablement pas une bonne chose.
Mais revenons au juste mauvaise idée . Supposons qu'un générateur de nombres pseudo-aléatoires cryptographiquement fort soit utilisé au lieu de Math.random
. Pourquoi limiter les mots de passe à 28,5 bits ? Comme indiqué, ce n'est pas très bon. On peut supposer que le schéma 5 lettres, 3 chiffres est destiné à aider les utilisateurs à gérer les mots de passe distribués de manière aléatoire. Mais regardons les choses en face, vous devez équilibrer la facilité d'utilisation contre valeur d'usage et 28,5 bits d'entropie n'ont pas une grande valeur pour se défendre contre un adversaire actif.
Mais assez de mauvaises choses. Proposons une voie à suivre. Je vais utiliser le JavaScript Chaîne d'entropie qui "génère efficacement des chaînes aléatoires cryptographiquement fortes d'une entropie spécifiée à partir de divers jeux de caractères". Plutôt que les 62 caractères de l'OP, j'utiliserai un jeu de caractères de 32 caractères choisis pour réduire l'utilisation de caractères facilement confus ou la formation de mots anglais. Et plutôt que le schéma 5 lettres, 3 chiffres (qui a trop peu d'entropie), je vais proclamer que le mot de passe aura 60 bits d'entropie (c'est l'équilibre entre la facilité et la valeur).
import { Entropy, charSet32 } from 'entropy-string'
const random = new Entropy({ bits: 60, charset: charset32 })
const string = random.string()
"Q7LfR8Jn7RDp"
Notez les arguments de Entropy
spécifier les bits d'entropie souhaités, par opposition aux solutions les plus courantes pour la génération de chaînes aléatoires qui consistent à indiquer une longueur de chaîne (ce qui est à la fois malavisé et généralement non spécifié, mais c'est une autre histoire).
7 votes
S'il répond à votre exigence, quelle est la question alors ? En outre, votre exigence de mot de passe forcé est une mauvaise idée.
8 votes
xkcd.com/936
4 votes
new Array(12).fill().map(() => String.fromCharCode(Math.random()*86+40)).join("")
Une solution astucieuse pour produire un mot de passe de 12 caractères avec des caractères spéciaux, des chiffres supérieurs et inférieurs, dans une approche très légère.0 votes
@RobW Pourquoi est-ce une mauvaise idée ? Veuillez vous expliquer !