[cross-post sur fr.comp.os.linux.configuration et fr.comp.securite.
Fu2 sur fcs, parce qu'il faut bien en choisir un...]
Bonjour,
Au bureau, j'ai un serveur-à-tout-faire-sauf-le-café sous Linux.
Et, bien évidemment, je fais des backups réguliers, notamment sur
DVD-R, que je "distribue" un peu beaucoup (j'en garde certains, j'en
donne d'autres à mon patron et à un collègue).
L'idée est que quoi qu'il arrive, les données ne soient pas perdues.
J'en viens à ma question : ces backups doivent-ils comprendre les
fichiers contenant des mots de passe, comme /etc/shadow ou
/etc/samba/smbpasswd ?
L'argument pour : en ayant un backup de l'intégralité des fichiers, on
peut réduire le downtime en cas de panne.
L'argument contre : ça fait des mots de passe qui se "baladent", et se
retrouvent sur pas mal de DVD-R.
Qu'en pensez-vous ? Quelle est votre politique sur ce sujet ?
[cross-post sur fr.comp.os.linux.configuration et fr.comp.securite. Fu2 sur fcs, parce qu'il faut bien en choisir un...]
Bonjour,
Au bureau, j'ai un serveur-à-tout-faire-sauf-le-café sous Linux.
Et, bien évidemment, je fais des backups réguliers, notamment sur DVD-R, que je "distribue" un peu beaucoup (j'en garde certains, j'en donne d'autres à mon patron et à un collègue). L'idée est que quoi qu'il arrive, les données ne soient pas perdues.
J'en viens à ma question : ces backups doivent-ils comprendre les fichiers contenant des mots de passe, comme /etc/shadow ou /etc/samba/smbpasswd ?
L'argument pour : en ayant un backup de l'intégralité des fichiers, on peut réduire le downtime en cas de panne. L'argument contre : ça fait des mots de passe qui se "baladent", et se retrouvent sur pas mal de DVD-R.
Qu'en pensez-vous ? Quelle est votre politique sur ce sujet ?
Merci d'avance...
1) conserver les attributs de fichiers sur les sauvegardes 2) chiffrer les fichiers "sensibles" = les fichiers contenant les mots de passe
en sachant que c'est quand même de la parano, because les passwords sont enregistrés déjà chiffrés ...
A+
Fabien LE LEZ wrote:
[cross-post sur fr.comp.os.linux.configuration et fr.comp.securite.
Fu2 sur fcs, parce qu'il faut bien en choisir un...]
Bonjour,
Au bureau, j'ai un serveur-à-tout-faire-sauf-le-café sous Linux.
Et, bien évidemment, je fais des backups réguliers, notamment sur
DVD-R, que je "distribue" un peu beaucoup (j'en garde certains, j'en
donne d'autres à mon patron et à un collègue).
L'idée est que quoi qu'il arrive, les données ne soient pas perdues.
J'en viens à ma question : ces backups doivent-ils comprendre les
fichiers contenant des mots de passe, comme /etc/shadow ou
/etc/samba/smbpasswd ?
L'argument pour : en ayant un backup de l'intégralité des fichiers, on
peut réduire le downtime en cas de panne.
L'argument contre : ça fait des mots de passe qui se "baladent", et se
retrouvent sur pas mal de DVD-R.
Qu'en pensez-vous ? Quelle est votre politique sur ce sujet ?
Merci d'avance...
1) conserver les attributs de fichiers sur les sauvegardes
2) chiffrer les fichiers "sensibles" = les fichiers contenant les mots de
passe
en sachant que c'est quand même de la parano, because les passwords sont
enregistrés déjà chiffrés ...
[cross-post sur fr.comp.os.linux.configuration et fr.comp.securite. Fu2 sur fcs, parce qu'il faut bien en choisir un...]
Bonjour,
Au bureau, j'ai un serveur-à-tout-faire-sauf-le-café sous Linux.
Et, bien évidemment, je fais des backups réguliers, notamment sur DVD-R, que je "distribue" un peu beaucoup (j'en garde certains, j'en donne d'autres à mon patron et à un collègue). L'idée est que quoi qu'il arrive, les données ne soient pas perdues.
J'en viens à ma question : ces backups doivent-ils comprendre les fichiers contenant des mots de passe, comme /etc/shadow ou /etc/samba/smbpasswd ?
L'argument pour : en ayant un backup de l'intégralité des fichiers, on peut réduire le downtime en cas de panne. L'argument contre : ça fait des mots de passe qui se "baladent", et se retrouvent sur pas mal de DVD-R.
Qu'en pensez-vous ? Quelle est votre politique sur ce sujet ?
Merci d'avance...
1) conserver les attributs de fichiers sur les sauvegardes 2) chiffrer les fichiers "sensibles" = les fichiers contenant les mots de passe
en sachant que c'est quand même de la parano, because les passwords sont enregistrés déjà chiffrés ...
A+
moi-meme
Fabien LE LEZ wrote:
[cross-post sur fr.comp.os.linux.configuration et fr.comp.securite. Fu2 sur fcs, parce qu'il faut bien en choisir un...]
Bonjour,
Au bureau, j'ai un serveur-à-tout-faire-sauf-le-café sous Linux.
Et, bien évidemment, je fais des backups réguliers, notamment sur DVD-R, que je "distribue" un peu beaucoup (j'en garde certains, j'en donne d'autres à mon patron et à un collègue). L'idée est que quoi qu'il arrive, les données ne soient pas perdues.
J'en viens à ma question : ces backups doivent-ils comprendre les fichiers contenant des mots de passe, comme /etc/shadow ou /etc/samba/smbpasswd ?
L'argument pour : en ayant un backup de l'intégralité des fichiers, on peut réduire le downtime en cas de panne. L'argument contre : ça fait des mots de passe qui se "baladent", et se retrouvent sur pas mal de DVD-R.
Qu'en pensez-vous ? Quelle est votre politique sur ce sujet ?
Merci d'avance...
une idée de neuneu : sauvegarder les mots de passe en crypté ?
C Hiebel
Fabien LE LEZ wrote:
[cross-post sur fr.comp.os.linux.configuration et fr.comp.securite.
Fu2 sur fcs, parce qu'il faut bien en choisir un...]
Bonjour,
Au bureau, j'ai un serveur-à-tout-faire-sauf-le-café sous Linux.
Et, bien évidemment, je fais des backups réguliers, notamment sur
DVD-R, que je "distribue" un peu beaucoup (j'en garde certains, j'en
donne d'autres à mon patron et à un collègue).
L'idée est que quoi qu'il arrive, les données ne soient pas perdues.
J'en viens à ma question : ces backups doivent-ils comprendre les
fichiers contenant des mots de passe, comme /etc/shadow ou
/etc/samba/smbpasswd ?
L'argument pour : en ayant un backup de l'intégralité des fichiers, on
peut réduire le downtime en cas de panne.
L'argument contre : ça fait des mots de passe qui se "baladent", et se
retrouvent sur pas mal de DVD-R.
Qu'en pensez-vous ? Quelle est votre politique sur ce sujet ?
Merci d'avance...
une idée de neuneu : sauvegarder les mots de passe en crypté ?
[cross-post sur fr.comp.os.linux.configuration et fr.comp.securite. Fu2 sur fcs, parce qu'il faut bien en choisir un...]
Bonjour,
Au bureau, j'ai un serveur-à-tout-faire-sauf-le-café sous Linux.
Et, bien évidemment, je fais des backups réguliers, notamment sur DVD-R, que je "distribue" un peu beaucoup (j'en garde certains, j'en donne d'autres à mon patron et à un collègue). L'idée est que quoi qu'il arrive, les données ne soient pas perdues.
J'en viens à ma question : ces backups doivent-ils comprendre les fichiers contenant des mots de passe, comme /etc/shadow ou /etc/samba/smbpasswd ?
L'argument pour : en ayant un backup de l'intégralité des fichiers, on peut réduire le downtime en cas de panne. L'argument contre : ça fait des mots de passe qui se "baladent", et se retrouvent sur pas mal de DVD-R.
Qu'en pensez-vous ? Quelle est votre politique sur ce sujet ?
Merci d'avance...
une idée de neuneu : sauvegarder les mots de passe en crypté ?
C Hiebel
Emmanuel Florac
Le Tue, 23 May 2006 08:24:53 +0000, Fabien LE LEZ a écrit :
Qu'en pensez-vous ? Quelle est votre politique sur ce sujet ?
Tu peux éventuellement crypter les sauvegardes.
-- Writing about music is like dancing about architecture. Frank Zappa
Le Tue, 23 May 2006 08:24:53 +0000, Fabien LE LEZ a écrit :
Qu'en pensez-vous ? Quelle est votre politique sur ce sujet ?
Tu peux éventuellement crypter les sauvegardes.
--
Writing about music is like dancing about architecture.
Frank Zappa
en sachant que c'est quand même de la parano, because les passwords sont enregistrés déjà chiffrés ...
Non, ils sont hachés (et éventuellement "salés" pour limiter les attaques).
Xavier Roche
Fabien LE LEZ wrote:
Et, bien évidemment, je fais des backups réguliers, notamment sur DVD-R, que je "distribue" un peu beaucoup (j'en garde certains, j'en donne d'autres à mon patron et à un collègue). L'idée est que quoi qu'il arrive, les données ne soient pas perdues.
Si les DVD doivent se ballader, il serait peut être mieux de: - faire le backup complet sur un filesystem cloop chiffré en AES - dumper le fichier cloop sur CD
Parce que les CD que le patron va ballader chez lui, il seront potentiellement sensibles aussi à cause du reste (contrats dans les attachments des mails de /var/mail, informations confidentielles..), et un cambiolage est si vite arrivé (ou le "merde, j'ai laissé tomber le DVD quelque part")
modprobe loop cryptoloop aes cd /tmp mkdir cd # créer une image de 4GB dd if=/dev/zero of=/tmp/iso count00000 # attacher loop aes losetup -e aes /dev/loop0 /tmp/iso <...entrer une passphrase ici> # "formatter" le pseudo disque chiffré mkfs -t ext2 /dev/loop0 # et le monter mount /dev/loop0 -t ext2 /tmp/cd # copier les fichiers.. rsync ... /tmp/cd/ # démonter umount /tmp/cd losetup -d /dev/loop0 # puis graver /tmp/iso ..
Fabien LE LEZ wrote:
Et, bien évidemment, je fais des backups réguliers, notamment sur
DVD-R, que je "distribue" un peu beaucoup (j'en garde certains, j'en
donne d'autres à mon patron et à un collègue).
L'idée est que quoi qu'il arrive, les données ne soient pas perdues.
Si les DVD doivent se ballader, il serait peut être mieux de:
- faire le backup complet sur un filesystem cloop chiffré en AES
- dumper le fichier cloop sur CD
Parce que les CD que le patron va ballader chez lui, il seront
potentiellement sensibles aussi à cause du reste (contrats dans les
attachments des mails de /var/mail, informations confidentielles..), et
un cambiolage est si vite arrivé (ou le "merde, j'ai laissé tomber le
DVD quelque part")
modprobe loop cryptoloop aes
cd /tmp
mkdir cd
# créer une image de 4GB
dd if=/dev/zero of=/tmp/iso count00000
# attacher loop aes
losetup -e aes /dev/loop0 /tmp/iso
<...entrer une passphrase ici>
# "formatter" le pseudo disque chiffré
mkfs -t ext2 /dev/loop0
# et le monter
mount /dev/loop0 -t ext2 /tmp/cd
# copier les fichiers..
rsync ... /tmp/cd/
# démonter
umount /tmp/cd
losetup -d /dev/loop0
# puis graver /tmp/iso ..
Et, bien évidemment, je fais des backups réguliers, notamment sur DVD-R, que je "distribue" un peu beaucoup (j'en garde certains, j'en donne d'autres à mon patron et à un collègue). L'idée est que quoi qu'il arrive, les données ne soient pas perdues.
Si les DVD doivent se ballader, il serait peut être mieux de: - faire le backup complet sur un filesystem cloop chiffré en AES - dumper le fichier cloop sur CD
Parce que les CD que le patron va ballader chez lui, il seront potentiellement sensibles aussi à cause du reste (contrats dans les attachments des mails de /var/mail, informations confidentielles..), et un cambiolage est si vite arrivé (ou le "merde, j'ai laissé tomber le DVD quelque part")
modprobe loop cryptoloop aes cd /tmp mkdir cd # créer une image de 4GB dd if=/dev/zero of=/tmp/iso count00000 # attacher loop aes losetup -e aes /dev/loop0 /tmp/iso <...entrer une passphrase ici> # "formatter" le pseudo disque chiffré mkfs -t ext2 /dev/loop0 # et le monter mount /dev/loop0 -t ext2 /tmp/cd # copier les fichiers.. rsync ... /tmp/cd/ # démonter umount /tmp/cd losetup -d /dev/loop0 # puis graver /tmp/iso ..
moinsdespam
Dans <4472ce4c$0$7018$,
2) chiffrer les fichiers "sensibles" = les fichiers contenant les mots de passe
en sachant que c'est quand même de la parano, because les passwords sont enregistrés déjà chiffrés ...
La raison d'être de /etc/shadow est de n'être lisible que par root afin d'éviter la recherche de mot de passe par force brute. Dans ce cas, il n'est pas parano du tout de chiffrer la sauvegarde.
-- Frédéric Bleu,e adj. et n. m. Qui est d'une couleur voisine du rouge, mais pas très : un ciel bleu, des yeux bleus, les flots bleus [..]. Fig. Bouch. : un steak bleu ; s'emploie pour désigner un steak rouge. (Pierre Desproges : D.S.U.É (et des BN))
Dans <4472ce4c$0$7018$636a55ce@news.free.fr>,
2) chiffrer les fichiers "sensibles" = les fichiers contenant les mots de
passe
en sachant que c'est quand même de la parano, because les passwords sont
enregistrés déjà chiffrés ...
La raison d'être de /etc/shadow est de n'être lisible que par root afin
d'éviter la recherche de mot de passe par force brute. Dans ce cas, il
n'est pas parano du tout de chiffrer la sauvegarde.
--
Frédéric
Bleu,e adj. et n. m. Qui est d'une couleur voisine du rouge, mais pas très : un
ciel bleu, des yeux bleus, les flots bleus [..]. Fig. Bouch. : un steak bleu ;
s'emploie pour désigner un steak rouge. (Pierre Desproges : D.S.U.É (et des BN))
2) chiffrer les fichiers "sensibles" = les fichiers contenant les mots de passe
en sachant que c'est quand même de la parano, because les passwords sont enregistrés déjà chiffrés ...
La raison d'être de /etc/shadow est de n'être lisible que par root afin d'éviter la recherche de mot de passe par force brute. Dans ce cas, il n'est pas parano du tout de chiffrer la sauvegarde.
-- Frédéric Bleu,e adj. et n. m. Qui est d'une couleur voisine du rouge, mais pas très : un ciel bleu, des yeux bleus, les flots bleus [..]. Fig. Bouch. : un steak bleu ; s'emploie pour désigner un steak rouge. (Pierre Desproges : D.S.U.É (et des BN))
Gilles Berger Sabbatel
On Tue, 23 May 2006 08:24:53 +0000, Fabien LE LEZ wrote:
J'en viens à ma question : ces backups doivent-ils comprendre les fichiers contenant des mots de passe, comme /etc/shadow ou /etc/samba/smbpasswd ?
L'argument pour : en ayant un backup de l'intégralité des fichiers, on peut réduire le downtime en cas de panne. L'argument contre : ça fait des mots de passe qui se "baladent", et se retrouvent sur pas mal de DVD-R.
Qu'en pensez-vous ? Quelle est votre politique sur ce sujet ?
Quelques remarques préliminaires :
- la sécurité repose plus sur la robustesse des mots de passe que sur la protection de /etc/shadow... - la robustesse des mots de passe repose sur les utilisateurs, c'est là le point faible. D'où l'intérêt de protéger /etc/shadow... - en quelques dizaines d'années, avec un nombre conséquent de machines et d'utilisateurs que j'ai fréquentés, j'ai rarement vu de problème grave entraîné par la perte d'un fichier de mot de passe. Je ne crois pas avoir jamais vu un tel fichier perdu ou corrompu en dehors de la perte du disque qui le contient, et dans ce cas, la reconstitution d'un fichier de mots de passe est anecdotique par rapport à ce qu'il y a à faire pour remettre en route... Encore qu'au delà d'une centaine d'utilisateurs, ça se discute... - en revanche, j'ai vu plusieurs fois la nécessité d'invalider tous les comptes utilisateurs et de changer les mots de passe, suite à une compromission d'une machine du réseau...
Ceci étant dit, le reconstitution des mots de passe est une opération dont on se passe volontiers en cas de problème! Il existe forcément 2 ou 3 personnes à qui vous faites suffisamment confiance pour leur donner le mot de passe et la phrase de passe gpg de root... et à qui vous devriez pouvoir confier une copie de la sauvegarde!
Vous pouvez également chiffrer le fichier des mots de passe sauvegardé : théoriquement, cela n'augmente pas la sécurité, sauf que casser un chiffrement gpg avec une clef suffisamment longue prend autrement plus de temps que de rechercher quelques mots de passe faibles avec John the Ripper! Autre solution, utiliser la stéganographie pour camoufler les fichiers critiques dans des fichiers anodins (images, sons...).
Enfin, vous devez être en mesure de détecter la perte d'un CD dans un laps de temps limité : dans ce cas, vous devrez invalider et changer tous les mots de passe!
Bref, tout ça, c'est une question d'équilibre entre sécurité, disponibilité, et moyens (matériels et humains) que vous êtes prêts à consacrer à la prévention d'événements qui ont de fortes chances de ne jamais se produire!
On Tue, 23 May 2006 08:24:53 +0000, Fabien LE LEZ wrote:
J'en viens à ma question : ces backups doivent-ils comprendre les fichiers
contenant des mots de passe, comme /etc/shadow ou /etc/samba/smbpasswd ?
L'argument pour : en ayant un backup de l'intégralité des fichiers, on
peut réduire le downtime en cas de panne. L'argument contre : ça fait des
mots de passe qui se "baladent", et se retrouvent sur pas mal de DVD-R.
Qu'en pensez-vous ? Quelle est votre politique sur ce sujet ?
Quelques remarques préliminaires :
- la sécurité repose plus sur la robustesse des mots de passe que sur la
protection de /etc/shadow...
- la robustesse des mots de passe repose sur les utilisateurs, c'est là le
point faible. D'où l'intérêt de protéger /etc/shadow...
- en quelques dizaines d'années, avec un nombre conséquent de machines et
d'utilisateurs que j'ai fréquentés, j'ai rarement vu de problème grave
entraîné par la perte d'un fichier de mot de passe. Je ne crois pas avoir
jamais vu un tel fichier perdu ou corrompu en dehors de la perte du disque
qui le contient, et dans ce cas, la reconstitution d'un fichier de mots de
passe est anecdotique par rapport à ce qu'il y a à faire pour remettre en
route... Encore qu'au delà d'une centaine d'utilisateurs, ça se
discute...
- en revanche, j'ai vu plusieurs fois la nécessité d'invalider
tous les comptes utilisateurs et de changer les mots de passe, suite à une
compromission d'une machine du réseau...
Ceci étant dit, le reconstitution des mots de passe est une opération dont
on se passe volontiers en cas de problème! Il existe forcément 2 ou 3
personnes à qui vous faites suffisamment confiance pour leur donner le mot
de passe et la phrase de passe gpg de root... et à qui vous devriez
pouvoir confier une copie de la sauvegarde!
Vous pouvez également chiffrer le fichier des mots de passe sauvegardé :
théoriquement, cela n'augmente pas la sécurité, sauf que casser un
chiffrement gpg avec une clef suffisamment longue prend autrement plus de
temps que de rechercher quelques mots de passe faibles avec John the
Ripper! Autre solution, utiliser la stéganographie pour camoufler les
fichiers critiques dans des fichiers anodins (images, sons...).
Enfin, vous devez être en mesure de détecter la perte d'un CD dans un laps
de temps limité : dans ce cas, vous devrez invalider et changer tous les
mots de passe!
Bref, tout ça, c'est une question d'équilibre entre sécurité,
disponibilité, et moyens (matériels et humains) que vous êtes prêts à
consacrer à la prévention d'événements qui ont de fortes chances de ne
jamais se produire!
On Tue, 23 May 2006 08:24:53 +0000, Fabien LE LEZ wrote:
J'en viens à ma question : ces backups doivent-ils comprendre les fichiers contenant des mots de passe, comme /etc/shadow ou /etc/samba/smbpasswd ?
L'argument pour : en ayant un backup de l'intégralité des fichiers, on peut réduire le downtime en cas de panne. L'argument contre : ça fait des mots de passe qui se "baladent", et se retrouvent sur pas mal de DVD-R.
Qu'en pensez-vous ? Quelle est votre politique sur ce sujet ?
Quelques remarques préliminaires :
- la sécurité repose plus sur la robustesse des mots de passe que sur la protection de /etc/shadow... - la robustesse des mots de passe repose sur les utilisateurs, c'est là le point faible. D'où l'intérêt de protéger /etc/shadow... - en quelques dizaines d'années, avec un nombre conséquent de machines et d'utilisateurs que j'ai fréquentés, j'ai rarement vu de problème grave entraîné par la perte d'un fichier de mot de passe. Je ne crois pas avoir jamais vu un tel fichier perdu ou corrompu en dehors de la perte du disque qui le contient, et dans ce cas, la reconstitution d'un fichier de mots de passe est anecdotique par rapport à ce qu'il y a à faire pour remettre en route... Encore qu'au delà d'une centaine d'utilisateurs, ça se discute... - en revanche, j'ai vu plusieurs fois la nécessité d'invalider tous les comptes utilisateurs et de changer les mots de passe, suite à une compromission d'une machine du réseau...
Ceci étant dit, le reconstitution des mots de passe est une opération dont on se passe volontiers en cas de problème! Il existe forcément 2 ou 3 personnes à qui vous faites suffisamment confiance pour leur donner le mot de passe et la phrase de passe gpg de root... et à qui vous devriez pouvoir confier une copie de la sauvegarde!
Vous pouvez également chiffrer le fichier des mots de passe sauvegardé : théoriquement, cela n'augmente pas la sécurité, sauf que casser un chiffrement gpg avec une clef suffisamment longue prend autrement plus de temps que de rechercher quelques mots de passe faibles avec John the Ripper! Autre solution, utiliser la stéganographie pour camoufler les fichiers critiques dans des fichiers anodins (images, sons...).
Enfin, vous devez être en mesure de détecter la perte d'un CD dans un laps de temps limité : dans ce cas, vous devrez invalider et changer tous les mots de passe!
Bref, tout ça, c'est une question d'équilibre entre sécurité, disponibilité, et moyens (matériels et humains) que vous êtes prêts à consacrer à la prévention d'événements qui ont de fortes chances de ne jamais se produire!
Gilles Berger Sabbatel
On Tue, 23 May 2006 12:20:42 +0000, sansflotusspam wrote:
1) conserver les attributs de fichiers sur les sauvegardes 2) chiffrer les fichiers "sensibles" = les fichiers contenant les mots de passe
en sachant que c'est quand même de la parano, because les passwords sont enregistrés déjà chiffrés ...
Oui et non... S'il y a quelques mots de passe faibles dans un fichier, John the Ripper mettra au plus quelques minutes à les trouver sur une bonne machine... En revanche, casser un cryptage gpg avec une clef suffisamment longue, c'est autre chose!
Mais pour faire dans la parano, le recours à la stéganographie (en plus, ou à la place du chiffrement, selon le degré de parano...) est encore mieux : le pirate éventuel ne sait même pas s'il y a quelque chose d'intéressant à rechercher!
A part ça, en toute rigueur, les mots de passe ne sont pas chiffrés, mais hashés (MD5 en l'occurrence). Contrairement au chiffrement, le haschage n'est pas inversable, et ne peut être attaqué que par force brute (essai de toutes les possibilités).
On Tue, 23 May 2006 12:20:42 +0000, sansflotusspam wrote:
1) conserver les attributs de fichiers sur les sauvegardes 2) chiffrer les
fichiers "sensibles" = les fichiers contenant les mots de passe
en sachant que c'est quand même de la parano, because les passwords sont
enregistrés déjà chiffrés ...
Oui et non... S'il y a quelques mots de passe faibles dans un fichier,
John the Ripper mettra au plus quelques minutes à les trouver sur une
bonne machine... En revanche, casser un cryptage gpg avec une clef
suffisamment longue, c'est autre chose!
Mais pour faire dans la parano, le recours à la stéganographie (en
plus, ou à la place du chiffrement, selon le degré de parano...) est
encore mieux : le pirate éventuel ne sait même pas s'il y a quelque chose
d'intéressant à rechercher!
A part ça, en toute rigueur, les mots de passe ne sont pas chiffrés, mais
hashés (MD5 en l'occurrence). Contrairement au chiffrement, le haschage
n'est pas inversable, et ne peut être attaqué que par force brute (essai
de toutes les possibilités).
On Tue, 23 May 2006 12:20:42 +0000, sansflotusspam wrote:
1) conserver les attributs de fichiers sur les sauvegardes 2) chiffrer les fichiers "sensibles" = les fichiers contenant les mots de passe
en sachant que c'est quand même de la parano, because les passwords sont enregistrés déjà chiffrés ...
Oui et non... S'il y a quelques mots de passe faibles dans un fichier, John the Ripper mettra au plus quelques minutes à les trouver sur une bonne machine... En revanche, casser un cryptage gpg avec une clef suffisamment longue, c'est autre chose!
Mais pour faire dans la parano, le recours à la stéganographie (en plus, ou à la place du chiffrement, selon le degré de parano...) est encore mieux : le pirate éventuel ne sait même pas s'il y a quelque chose d'intéressant à rechercher!
A part ça, en toute rigueur, les mots de passe ne sont pas chiffrés, mais hashés (MD5 en l'occurrence). Contrairement au chiffrement, le haschage n'est pas inversable, et ne peut être attaqué que par force brute (essai de toutes les possibilités).
