Si l'admin fait les choses correctement, oui ça ne pose pas de problème.
Si il ne le fait pas, ça peut entrainer de grave problèmes.
Voici un exemple véridique:
Un admin débutant, pas très au courant des problèmes de sécu, à lancé un daemon teamspeak en root.
La version de teamspeak installée permettait à un attaquant de récupérer n'importe quel fichier local sur le serveur, avec donc les droits root.
Le mot de passe dans le fichier .p à donc donné un accès direct au root à l'attaquant, au lieu d’essayer de cracker le /etc/shadow en espérant que le mot de passe ne soit pas trop complexe.
C'est clairement une erreur grave de l'admin, mais la présence du .p facilite grandement le travail de piratage de la machine dans un cas comme celui-ci.
[^] # Re: Pourquoi attendre que la clef soit compromise ?
Posté par lay . En réponse au journal Compromission de clé SSH chez OVH. Évalué à 1.
Si l'admin fait les choses correctement, oui ça ne pose pas de problème.
Si il ne le fait pas, ça peut entrainer de grave problèmes.
Voici un exemple véridique:
Un admin débutant, pas très au courant des problèmes de sécu, à lancé un daemon teamspeak en root.
La version de teamspeak installée permettait à un attaquant de récupérer n'importe quel fichier local sur le serveur, avec donc les droits root.
Le mot de passe dans le fichier .p à donc donné un accès direct au root à l'attaquant, au lieu d’essayer de cracker le /etc/shadow en espérant que le mot de passe ne soit pas trop complexe.
C'est clairement une erreur grave de l'admin, mais la présence du .p facilite grandement le travail de piratage de la machine dans un cas comme celui-ci.