web-dev-qa-db-fra.com

Django SECRET_KEY, comment les méthodes sont-elles plus sécurisées

J'approche d'un point où je vais déployer mon Django application dans l'environnement hostile autrement connu comme "Internet" et j'essaie de mieux comprendre les ramifications du Django SECRET_KEY. L'une des procédures standard semble être de sécuriser la clé secrète dans le settings.py. C'est suffisant. Les docs vont jusqu'à dire de ne pas valider votre clé secrète sur SVN, CVS, etc ... Car cela permet d'accéder facilement à votre clé. Cependant, si quelqu'un était tenté de valider la clé secrète dans son référentiel, cela indiquerait-il que la clé secrète est statique (voir question # 4)?

Quoi qu'il en soit, voici mes questions:

  1. Comment le stockage de la clé secrète en tant que variable d'environnement est-il plus sûr que le stockage direct dans settings.py? Par exemple, si un attaquant peut lire settings.py, il peut très probablement simplement taper $ echo $Django_SECRET_KEY!
  2. Comment le stockage de la clé secrète dans un fichier est-il plus sûr que le stockage direct dans settings.py? S'il peut lire settings.py, il peut probablement lire Django_secret_key.txt.
  3. Si l'attaquant a compromis votre machine, ne peut-il pas simplement charger l'interpréteur python avec settings.py à > print settings.SECRET_KEY?
  4. Enfin, serait-ce une mauvaise pratique de générer aléatoirement la clé secrète à chaque redémarrage du processus du serveur Web? Cela peut être complètement aléatoire ou demander une entrée utilisateur pour la clé. Evidemment, ce dernier présente une sérieuse faiblesse si l'attaquant lui-même peut redémarrer le webservice et saisir la clé de son choix.
pythondjango
26
James

Une fois qu'un attaquant a déjà accès au système, il est déjà trop tard. La principale préoccupation pour ne pas divulguer la clé est qu'elle est souvent utilisée comme graine pour les sessions de hachage et de signature. L'idée est que votre production SECRET_KEY Doit être complètement différente de votre développement ou mise en scène SECRET_KEY. Vous pouvez en fait le générer de manière aléatoire à chaque redémarrage, bien que cela puisse avoir un impact sur l'expérience utilisateur (voir les détails ci-dessous).

Tant que vous adhérez au principe de changement de clé, il n'y a pas beaucoup de danger si vous vous engagez ou non (tant que vous vous assurez qu'il est changé une fois passé de dev à prod). Si vous ne le faites pas, une personne possédant la clé peut prédire le résultat des algorithmes de hachage (utilisés pour les sessions) ou même signer des sessions.

Si un attaquant a accédé à votre système, vous êtes déjà trop loin parce que ce n'est plus votre système. Une chose que vous devez vous assurer est que les autorisations de fichier sur votre fichier de paramètres ne sont lisibles que par l'utilisateur exécutant le serveur Web et par personne d'autre. Cela empêche une personne ayant obtenu illégalement un accès à un compte limité, différent du compte de serveur Web, de compromettre votre clé.

Il y a une bonne réponse ici sur Stack Overflow: Django SECRET_KEY écrit par sberder qui détaille à quoi il sert:

En réalité, la plupart des éléments répertoriés ici utilisent SECRET_KEY À Django.utils.crypt.get_random_string() qui l'utilise pour amorcer le moteur aléatoire. Cela ne sera pas affecté par un changement de valeur de SECRET_KEY.

L'expérience utilisateur directement impactée par un changement de valeur est:

  • sessions, le décodage des données sera interrompu, ce qui est valable pour tout backend de session (cookies, base de données, fichier ou cache).
  • le jeton de réinitialisation du mot de passe déjà envoyé ne fonctionnera pas, les utilisateurs devront en demander un nouveau.
  • le formulaire de commentaires (si vous utilisez Django.contrib.comments) ne validera pas s'il a été demandé avant le changement de valeur et soumis après le changement de valeur. Je pense que c'est très mineur mais peut être déroutant pour l'utilisateur.
  • les messages (de Django.contrib.messages) ne valideront pas côté serveur dans les mêmes conditions de temps que pour le formulaire de commentaires.
19
Lucas Kauffman