Pourquoi est-il mauvais d'avoir un mot de passe utilisateur mysql faible?

On m'a présenté un argument à hauteur de "vous n'avez pas besoin d'un mot de passe utilisateur mysql fort car pour l'utiliser, ils auraient déjà accès à votre serveur". Nous parlons d'un mot de passe à 4 chiffres qui est un mot du dictionnaire anglais standard sur un site Web d'entreprise en direct.

Sans influencer les réponses avec mes propres connaissances et expériences, je voudrais leur montrer quelques réponses d'une source tierce désintéressée. Quelqu'un veut-il sonner sur celui-ci? Des réponses programmatiques / pratiques seraient appréciées.

Celui qui a fait cet argument semble dire "Une fois que quelqu'un a le pied dans la porte, vous pourriez aussi bien lui donner un accès complet". Selon cette logique, un pare-feu annule la nécessité de tous les mots de passe sur votre réseau interne.

Des mots de passe forts sont une étape vers la limitation des dommages causés par une intrusion réseau. Il n'y a aucune raison de mettre la main en échec juste parce qu'une petite partie de votre réseau a été compromise.

Cela remonte vraiment à l'idée de « Défense en profondeur », donc au moins un mot de passe fort pourrait les ralentir afin que vous puissiez les découvrir et les bloquer. J'aime l'analogie d'avoir une seule clé pour une communauté fermée par rapport à une clé à la porte de chaque maison.

Cela dépend beaucoup de la configuration de votre serveur MySQL. S'il n'accepte que les requêtes hors de l'IP domestique (127.0.0.1), cela le rend modérément plus sécurisé.

Dans un scénario où vous autorisez des adresses IP distantes, cela devient beaucoup plus important.

En plus de cela, il est toujours bon d'avoir une forte sécurité en cas d'intrusion - mieux qu'ils s'en éloignent le moins possible.

Y a-t-il un verrou sur la petite caisse en comptabilité? Si oui, pourquoi? Le bâtiment n'a-t-il pas de sécurité physique?

vous n'avez pas besoin d'un mot de passe utilisateur mysql fort car pour l'utiliser, ils auraient déjà accès à votre serveur

Ce n'est pas vrai, car mysql peut également être utilisé dans un environnement client-serveur inter-réseaux, et par défaut, la seule chose dont vous avez besoin est user / pass pour accéder à la base de données (offcourse, avec le port 3306 ouvert et le serveur visible publiquement) ).

En effet, cela peut être l'inverse: s'ils ont accès à mysql, ils pourraient accéder au système d'exploitation du serveur lui-même.

1. Les requêtes MySQL LOAD_FILE et SELECT ... INTO OUTFILE permettent aux utilisateurs de mysql de lire et d'écrire des fichiers sur le système de fichiers sous-jacent. Tout fichier auquel l'utilisateur mysql a également accès (votre MySQL fonctionne-t-il en tant que root?). Si sous linux / UNIX, il suffit d'interroger SELECT LOAD_FILE ('/ etc / passwd') et de les voir sourire. Si mysqld fonctionne en tant que root, vous pouvez essayer SELECT LOAD_FILE ('/ etc / shadow') et regarder votre cri d'administrateur système.
2. Plusieurs fois sous linux, l'utilisateur mysql "root" a le même mot de passe que l'utilisateur "mysql" du serveur (celui qui exécute mysqld). Ensuite, si ce mot de passe est trivial (ou détectable par des outils automatisés tels que medusa / hydra), vous pouvez simplement SSH / telnet directement sur le serveur de base de données et faire le tour.

Si quelqu'un obtient un accès root à votre serveur, il n'aura pas besoin de mot de passe MySQL. Mais s'ils ne peuvent exécuter des applications sur votre serveur qu'en tant qu'utilisateur non root et non Web, un mot de passe MySQL fort peut toujours enregistrer vos données. Mais oui, la plupart des hacks viennent du Web, cela signifie que le pirate aura accès à votre compte Web et peut donc extraire le mot de passe de la base de données des fichiers PHP.

Tout cela en supposant que votre serveur MySQL n'accepte pas les connexions de n'importe où mais de l'hôte local. Si c'est le cas, vous avez besoin d'un PW fort.

Quelque chose qui semble avoir été négligé ici est, faites-vous confiance à vos utilisateurs sur le réseau de confiance?

Franchement, je ne le sais pas, parce que je sais à quoi je ressemblais lorsque je débutais en informatique. Je piquerais et produirais dans des domaines auxquels je n'avais pas droit, et franchement, un mot de passe MySQL faible aurait été un plaisir pour moi car j'aurais pris une chance au hasard et je serais entré et j'aurais pu faire un havock (par accident, bien sûr).

Et si quelqu'un utilise l'ingénierie sociale pour accéder à votre réseau de confiance? Alors tu fais quoi? S'ils sont sur une machine derrière le pare-feu, blammo, votre sécurité pare-feu solide comme le roc est ruinée et ils sont directement dans la machine.

Les mots de passe forts sont si simples à faire et il existe de nombreux outils de gestion des mots de passe pour faciliter la sécurisation des mots de passe, il n'y a donc vraiment aucune excuse pour ne pas le faire.

Eh. Si votre serveur est verrouillé IP et que votre utilisateur est limité à SELECT sur un ensemble de tables où vous ne vous souciez pas des informations, ce n'est pas énorme.

D'autre part, j'ai défini mes mots de passe MySQL en tapant sur le clavier pendant une minute et copié en collant le charabia résultant dans un fichier protégé, que je référence dans mon code chaque fois que je dois me connecter. Voilà comment cela devrait fonctionner.

Pourquoi le rendre facile? Si le mot de passe est associé à un compte local limité (comme ils devraient tous l'être), alors pourquoi le saisissez-vous? Si ce n'est pas le cas, il doit avoir un mot de passe dont la force est relative à la valeur des données que vous protégez.

Les informations de compte / d'accès mySQL sont stockées dans un fichier distinct des bases de données réelles. Ainsi, vous pouvez simplement faire glisser et déposer un fichier différent à sa place. Avec mySQL, s'ils ont un accès en écriture à la partie pertinente de votre système de fichiers, le jeu est terminé.

Parce que les exigences changent ...

Ainsi, le serveur qui se limite aujourd'hui à n'accepter les connexions MySQL qu'à la machine locale, pourra être ouvert demain afin qu'un outil externe puisse être utilisé pour gérer la base de données. La personne qui effectue cette configuration ne sait peut-être pas que des mots de passe extrêmement faibles sont utilisés.

Si votre utilisateur est gêné de devoir se souvenir d'un bon mot de passe fort (par exemple: long, aléatoire), envisagez de le rendre très fort, puis de le stocker dans le .my.cnf- encore plus pratique que d'avoir un mot de passe faible qu'il doit taper. Bien sûr, cela a également des implications sur la sécurité, mais vous devrez stocker votre mot de passe quelque part, par exemple les applications qui y accèdent, vous sécurisez donc déjà des copies du mot de passe.

Mais lisez aussi ce que @meagar a dit.

La prémisse qu'ils auraient déjà accès n'est pas vraie. Cependant, s'ils y ont accès et qu'ils ont un compte non privilégié, ils pourraient toujours facilement pirater le mot de passe mysql.

De plus, si le serveur est un serveur de production en direct, vous vous annoncez sur Internet. Cela signifie que à un moment donné, quelqu'un FERA essayer une attaque de force brute sur ce serveur, y compris MySQL, le port et le compte utilisateur.

si vous vous souciez des données, les étapes de base consistent à avoir un mot de passe root différent pour la base de données que pour l'utilisateur root. d'autres ont déclaré que vous devriez également disposer des autorisations les plus faibles possibles pour les utilisateurs et les programmes.

un mot de passe à 4 caractères peut être piraté en quelques minutes, sur un ordinateur assez bon marché.

Je répète peut-être ce que d'autres ont dit, mais plus vous avez de munitions pour votre manager, mieux c'est.

La plupart des raisons du scénario réel ont été couvertes par des articles avant, donc j'ajouterai la "philosophie". Utiliser des mots de passe forts et prendre des précautions pour renforcer votre sécurité est une philosophie de travail. Une façon de penser.

Utiliser un mot de passe faible maintenant parce que vous êtes mysql ne fonctionne que sur 127.0.0.1 et seul l'utilisateur root y a accès montre que vous ne pensez pas à l'avance. Que se passe-t-il si un jour vous devez accorder un accès par réseau à votre mysql. Vous souviendrez-vous de couvrir tous les éléments de sécurité que vous avez laissés?

Un bon administrateur met le pire des scénarios en premier au point de la paranoïa.

Cela dépend des droits de l'utilisateur, vous devez toujours verrouiller les choses à plusieurs niveaux. Cela dépend également des données que vous stockez dans votre base de données. Dites également hypothétiquement qu'il existe une vulnérabilité dans MySQL qui leur permet de prendre en charge toute la base de données, mais ils avaient juste besoin de se connecter à n'importe quel compte d'utilisateur. Si votre mot de passe était fort, cela rendrait cette vulnérabilité muette. Mais cela dépend vraiment de votre cas spécifique.

Il est très facile de se faire passer pour quelqu'un d'autre dans mysql. Étant donné un ID utilisateur sans mot de passe (la sécurité la plus faible), utilisez simplement mysql -u userid. S'il a un mot de passe, c'est un peu plus difficile, mais un mot de passe faible le rend facile. Si root n'a pas de mot de passe, je peux accéder à root en tant que mysql -u root. Je peux alors faire n'importe quoi dans la base de données que root peut.

L'utilisation des spécifications de l'hôte dans la sécurité est également une bonne idée, surtout si l'accès à distance est ou peut être disponible.

Les mots de passe dans les fichiers peuvent et doivent être quelque peu sécurisés par des autorisations. L'accès par root ou par le propriétaire du fichier de mots de passe est trivial. Si possible, le cryptage du mot de passe sur le disque doit être utilisé. Cela le rend un peu plus difficile d'accès, mais toujours vulnérable.

Eh bien, si vous n'hébergez pas vous-même la base de données MySQL, mais que c'est sur un service d'hébergement et que quelqu'un accède à l'adresse IP de votre serveur, le nom d'utilisateur et le mot de passe sont votre dernière ligne de défense. Il est toujours bon d'avoir un nom d'utilisateur / mot de passe sécurisé.