web-dev-qa-db-fra.com

Les sels par défaut sont-ils sécurisés?

Lors de l'installation d'une nouvelle wordpress, vous devez notamment mettre à jour les sels dans wp-config.php.

La section ressemble à ceci

define('AUTH_KEY',         'put your unique phrase here');
define('SECURE_AUTH_KEY',  'put your unique phrase here');
define('LOGGED_IN_KEY',    'put your unique phrase here');
define('NONCE_KEY',        'put your unique phrase here');
define('AUTH_SALT',        'put your unique phrase here');
define('SECURE_AUTH_SALT', 'put your unique phrase here');
define('LOGGED_IN_SALT',   'put your unique phrase here');
define('NONCE_SALT',       'put your unique phrase here');

Si le client change ces sels ou si les constantes sont manquantes, wordpress enregistre ces valeurs dans la base de données.

Pour générer les sels qu’il utilise wp_generate_password(64, true, true) Le code permettant de le faire peut être trouvé dans pluggable à partir de la ligne 1993.

Maintenant la question est:

  • Est-ce que wp_generate_password est aussi sûr que les sels générés par le https://api.wordpress.org/secret-key/1.1/salt/ recommandé?

  • Existe-t-il une dégradation de la sécurité liée à la présence des sels dans la base de données, car cette méthode a recours à cette méthode?.

  • Est-ce que cela a des implications sur la sécurité de ne pas définir les valeurs et de les laisser être générées aléatoirement à la volée vers la base de données?

securityencryption
6
Ronni Skansing
  1. wp_generate_password() est-il aussi sûr que les sels générés par le https://api.wordpress.org/secret-key/1.1/salt/ recommandé?

On ne peut pas répondre à ces détails car, pour des raisons évidentes, les internautes sont inconnus du public. Si nous pouvions répondre à cette question, nous disposerions alors des détails permettant le reverse engineering du processus. Ceci pourrait conduire à une diminution de la sécurité. Notez que quelqu'un pourrait toujours essayer de définir un nombre de requêtes dans cette URL, puis d'essayer de désosser le processus en surveillant les bulles à la surface.

  1. Existe-t-il une dégradation de la sécurité liée à la présence des sels dans la base de données car cette méthode y revient?

Oui. Vous ne voulez pas que les détails de sécurité/les identifiants d’authentification soient sauvegardés n’importe où où ils pourraient être accessibles. Ceci comprend:

  • Contrôle de version
  • Historique de la ligne de commande
  • Sauvegardes de bases de données ou de fichiers
  • …

Conservez vos informations d’authentification et les données associées (par exemple, "salt") dans des fichiers .env (voir paquet Dotenv ), dans votre refuge sécurisé de services de déploiement, dans des fichiers de configuration distincts (par exemple, le fichier d’authentification AWS) et dans un seul endroit.

  1. Est-ce que cela a des implications sur la sécurité de ne pas définir les valeurs et de les laisser être générées aléatoirement à la volée à la db?

Oui. Comme les constantes d'authentification sont également utilisées dans les cookies, vous devez invalider les sessions de connexion de vos utilisateurs en invalidant les cookies de vos utilisateurs. Ce sont des constantes pour une raison: elles devraient rester et ne pas changer à la demande.

Edit: Comme @gmazzap me l'indiquait, j'étais pas parler des valeurs enregistrées dans la base de données, mais de "généré à la volée" constantes. Si vous l’enregistrez dans la base de données, veuillez vous reporter au point 2 concernant la sécurité.

Pour d'autres ajouts, veuillez suivre le lien de @Mark Kaplun et lire la réponse de @gmazzap en détail (et les inviter à la hausse).

Remarque/rappel supplémentaire: Ajoutez toujours des propres caractères pseudo aléatoires aux données extraites des serveurs de l'API. Et ne donnez jamais vos identifiants ou votre base de données hors de portée des mains. Vous ne croirez pas ce que les gens ont tendance à envoyer par courrier électronique, économisez sur des clés USB, leurs comptes privés Dropbox ou sur des disques durs sur des ordinateurs portables sans mot de passe…

Edit: Comme @stephenharris l'a souligné dans [chat], il existe un blog intéressant autour de ce sujet qui va beaucoup plus en détail que nos réponses ici.

4
kaiser

  1. Cela dépend du caractère aléatoire que vous pouvez obtenir sur votre machine. Je ne remebmer pas les détails exacts, mais l'API wordpress.org est là si le caractère aléatoire de votre machine n'est pas assez bon.

  2. Probablement pas. Si quelqu'un a ce type d'accès à votre base de données ou à votre code, vous êtes de toute façon porté à rôtir et obtenir le sel est le problème le moins important auquel vous êtes confronté.

  3. Quelle serait une raison de faire cela? obtenir ces 8 valeurs à partir de la base de données ralentira légèrement le traitement de chaque page sans ajouter de valeur à votre sécurité.

Edit: Pourquoi le hasard (entropie) est important

d'abord, peut-être que ceci https://security.stackexchange.com/questions/61676/why-do-wordpress-installations-retrieve-the-crypto-secrets-remotely-on-installat l'expliquera mieux que moi

Le problème est que les sels ne doivent pas être devinés, ils sont donc générés en relayant sur un générateur de nombres aléatoires, dont dispose la plupart des systèmes d'exploitation. Mais tous les générateurs aléatoires ne sont pas créés égaux et si, par exemple, votre générateur ne prend pas en entrée certaines valeurs de l'environnement, il génère la même séquence de nombres. Ainsi, quiconque inspecte le comportement du système d'exploitation peut en déduire le premier. 1000 numéros qui vont être générés, utilisez-les en tant que sels et devinez plus facilement votre mot de passe.

Cela est particulièrement problématique dans un environnement d’hébergement partagé où tous les sites utilisent le même générateur aléatoire et ont donc accès à la séquence des nombres générés aléatoirement. En se basant sur la connaissance du système d’exploitation et sur l’algorithme aléatoire utilisé, il peut deviner le prochain et le suivant. numéros précédemment générés.

note latérale: c'est la raison pour laquelle smartphone et autres logiciels vous demandent de faire des entrées aléatoires lors de l'initialisation des périphériques/logiciels. Cette entrée aléatoire sert de base à la génération de nombres aléatoires et garantit que chaque appareil génère une séquence de nombres différente.

L’utilisation de wordpress.org en tant que générateur de nombres aléatoires présente l’avantage de savoir qu’il est impossible de deviner les nombres générés sans accès aux serveurs, car vous ne savez pas quel algorithme est utilisé, comment il a été initialisé et où. dans l'ordre que vous vous trouvez actuellement.

Mais comme le dit la question à laquelle je me suis associé, le recours à un service externe est également un problème de sécurité. Je trouve que cela limite la paranoïa, car ce genre d’attaque exige une sophistication qui manque à la plupart des attaquants (dans le contexte d’attaques sur des sites wordpress), et je ne voudrais pas me soucier de la qualité du générateur aléatoire, mais si vous le faites, vous n’avez qu’à faire. est de générer vous-même les sels, peut-être en utilisant un logiciel de générateur aléatoire qui n’est pas lié au serveur, et mettez à jour le fichier de configuration.

3
Mark Kaplun

Is wp_generate_password() aussi sûr que les sels générés par le recommandé https://api.wordpress.org/secret-key/1.1/salt/

Comme @kaiser dit , les détails internes de la génération de sel de l'API ne sont pas connus, mais -honnêtement- l'API renvoie une chaîne de 64 caractères dans laquelle chaque caractère correspond à l'un des 92 glyphes possibles utilisés par wp_generate_password() .

Notez que si le serveur a PHP 7, les entiers aléatoires utilisés pour sélectionner l'un des 92 glyphes sont générés à l'aide de PHP 7 CSPRNG et je doute que l'API ait quelque chose de plus plus fort que ça. Dans les anciennes versions de PHP, les valeurs aléatoires sont fournies par mt_Rand .

Compte tenu de cela, et compte tenu du fait que la force d'un mot de passe réside beaucoup plus dans l'algorithme de chiffrement que sur le sel utilisé, je peux dire que, oui, wp_generate_password est très probablement aussi sûr que les sels générés par l'API.

Existe-t-il une dégradation de la sécurité liée à la présence des sels dans la base de données, car cette méthode a recours à cette méthode?.

Pour ce point, je suis d’accord avec @kaiser .

Supposons que quelqu'un reçoive une copie de votre vidage de base de données pour une sauvegarde. Dans cette copie de base de données, ils peuvent voir les mots de passe de vos utilisateurs, mais chiffrés.

S'ils ont accès aux sels, il leur est plus facile de pirater votre site Web.

De plus, en connaissant le sel utilisé, les ID utilisateur et les métas utilisateur (où les jetons de session sont stockés), il est très facile de reproduire les valeurs de nonce pour tous les utilisateurs, sans avoir à connaître le mot de passe "décrypté".

Bien sûr, si un utilisateur malveillant obtient une copie de votre base de données, votre sécurité est quand même très compromise, mais en stockant les sels dans la base de données, vous simplifiez la vie de cet utilisateur malveillant.

Est-ce que cela a des implications sur la sécurité de ne pas définir les valeurs et de les laisser être générées aléatoirement à la volée vers la base de données?

Si les sels ne sont pas du tout définis, ils sont générés avec wp_generate_password() uniquement la première fois que WP tente d'y accéder, puis sont stockés dans la base de données et, lors des demandes suivantes, ils sont extraits de là.

Comme mentionné précédemment, les sels générés par wp_generate_password() ne sont pas mauvais en soi, mais comme ils sont stockés dans la base de données, les implications en termes de sécurité sont les mêmes que celles énoncées au point précédent: si quelqu'un a accès à une copie de votre base de données, il est plus dangereux la copie contient les sels.

Cependant, les réelles implications sur la sécurité se produisent lorsque des valeurs non sécurisées sont utilisées pour les sels. En fait, si des valeurs faibles sont définies dans la configuration, WP ne générera aucune valeur, mais utilisera ces valeurs faibles. En bref, si le choix est entre aucun sel dans la configuration et des sels faibles, l'ancien est sûrement mieux.

Notez que dans récente versions de WP (pas sûr de quelle version exacte) la valeur par défaut 'put your unique phrase here' est ignorée, donc si wp-config.php contient cette valeur pour n'importe quel sel, WordPress l'ignorera et utilisera une valeur générée avec wp_generate_password() qui est meilleure qu'une valeur faible, mais pire qu'une valeur forte stockée dans la configuration (car stocker les sels dans la base de données ...). Les valeurs générées automatiquement sont utilisées même si la même valeur de sel est utilisée plusieurs fois.

Remarques

  • Un changement de sels déconnectera tout utilisateur connecté à votre site avant le changement, y compris les utilisateurs qui ne sont pas connectés au moment où vous modifiez, mais qui ont choisi l'option "se souvenir de moi" lorsqu'ils étaient connectés avant le changement.

  • Lorsque WordPress est installé à l'aide de "l'installateur" (sans création manuelle de wp-config.php), les valeurs de sels générées sont extraites de l'API.

3
gmazzap