Pour un bon mot de passe, il est d'usage de dire qu'il faut au moins
une minuscule, une majuscule, un chiffre et un caractère spécial.
Ça semble logique, mais finalement peut-être pas : un logiciel qui
cherche un mot de passe ne sais pas comment il est conçu, il ignore si
ce ne sont que des lettres minuscules par exemple, donc il cherche sur
la totalité des possibilités, non ?
Ou alors c'est parce que la recherche se fait dans un ordre ? Par
exemple d'abord les minuscules, puis les majuscules, puis les chiffres,
puis un mélange de 2, puis un mélange de 3... ?
On Thu, 03 Mar 2011 11:12:47 +0100, Fabien LE LEZ wrote:
On 03 Mar 2011 10:02:34 GMT, siger :
Si le mot de passe protège l'accès à l'ordinateur, je suppose qu'avec une distribution Linux sur CD ou clé USB on contourne le problème.
On peut accéder aux données qui se trouvent sur le disque dur du PC, s'il n'est pas crypté. Si les données sont sur un serveur central, le pirate se retrouve avec pas grand-chose.
Si, un acces permanant à distance, par exemple.
-- Travailler plus pour gagner plus pour quoi faire ? Pour finir par divorcer parce qu'on est pas souvent à la maison ou faire un malaise vagal et creuser le trou de la sécu ?
On Thu, 03 Mar 2011 11:12:47 +0100, Fabien LE LEZ
<gramster@gramster.com> wrote:
On 03 Mar 2011 10:02:34 GMT, siger <guinness@hic.invalid>:
Si le mot de passe protège l'accès à l'ordinateur, je suppose qu'avec
une distribution Linux sur CD ou clé USB on contourne le problème.
On peut accéder aux données qui se trouvent sur le disque dur du PC,
s'il n'est pas crypté. Si les données sont sur un serveur central, le
pirate se retrouve avec pas grand-chose.
Si, un acces permanant à distance, par exemple.
--
Travailler plus pour gagner plus pour quoi faire ?
Pour finir par divorcer parce qu'on est pas souvent à la maison ou faire un malaise vagal et creuser le trou de la sécu ?
On Thu, 03 Mar 2011 11:12:47 +0100, Fabien LE LEZ wrote:
On 03 Mar 2011 10:02:34 GMT, siger :
Si le mot de passe protège l'accès à l'ordinateur, je suppose qu'avec une distribution Linux sur CD ou clé USB on contourne le problème.
On peut accéder aux données qui se trouvent sur le disque dur du PC, s'il n'est pas crypté. Si les données sont sur un serveur central, le pirate se retrouve avec pas grand-chose.
Si, un acces permanant à distance, par exemple.
-- Travailler plus pour gagner plus pour quoi faire ? Pour finir par divorcer parce qu'on est pas souvent à la maison ou faire un malaise vagal et creuser le trou de la sécu ?
Benoit Izac
Bonjour,
le 02/03/2011 à 23:05, Bruno Tréguier a écrit dans le message <ikmeuj$k8o$ :
A ce propos (ce qui suit n'est *pas* un troll, c'est sérieux): que pensez-vous des politiques de gestion des mots de passe imposant un changement régulier de ce dernier ?
Ma boite demande un changement tous les 42 jours et que le nouveau mot de passe soit différent des deux derniers ; j'en utilise donc trois différents (pas si différents que ça), les mêmes depuis plus de six ans. Des discussions que j'ai pu avoir avec mes collègues à ce sujet, tout le monde fait pareil... donc au final, je vois vraiment pas l'intérêt (à part faire c***r le monde).
-- Benoit Izac
Bonjour,
le 02/03/2011 à 23:05, Bruno Tréguier a écrit dans le message
<ikmeuj$k8o$1@typhon.shom.fr> :
A ce propos (ce qui suit n'est *pas* un troll, c'est sérieux): que
pensez-vous des politiques de gestion des mots de passe imposant un
changement régulier de ce dernier ?
Ma boite demande un changement tous les 42 jours et que le nouveau mot
de passe soit différent des deux derniers ; j'en utilise donc trois
différents (pas si différents que ça), les mêmes depuis plus de six ans.
Des discussions que j'ai pu avoir avec mes collègues à ce sujet, tout le
monde fait pareil... donc au final, je vois vraiment pas l'intérêt (à
part faire c***r le monde).
le 02/03/2011 à 23:05, Bruno Tréguier a écrit dans le message <ikmeuj$k8o$ :
A ce propos (ce qui suit n'est *pas* un troll, c'est sérieux): que pensez-vous des politiques de gestion des mots de passe imposant un changement régulier de ce dernier ?
Ma boite demande un changement tous les 42 jours et que le nouveau mot de passe soit différent des deux derniers ; j'en utilise donc trois différents (pas si différents que ça), les mêmes depuis plus de six ans. Des discussions que j'ai pu avoir avec mes collègues à ce sujet, tout le monde fait pareil... donc au final, je vois vraiment pas l'intérêt (à part faire c***r le monde).
-- Benoit Izac
Fabien LE LEZ
On Wed, 02 Mar 2011 23:05:05 +0100, Bruno Tréguier :
que pensez-vous des politiques de gestion des mots de passe imposant un changement régulier de ce dernier ?
Pour moi, ça fait partie des habitudes dont plus personne ne connaît la source. En anglais, ça s'appelle "cargo cult", mais je ne sais pas s'il y a un équivalent en français.
Autres trucs du même style :
- On ne doit pas se connecter via SSH sous le compte "root" ; il faut se connecter en tant qu'utilisateur puis utiliser "su". - La taille de la partition de swap doit être égale à deux fois la taille de la RAM.
On Wed, 02 Mar 2011 23:05:05 +0100, Bruno Tréguier
<bruno.treguier_at_shom.fr@nullepart.invalid>:
que
pensez-vous des politiques de gestion des mots de passe imposant un
changement régulier de ce dernier ?
Pour moi, ça fait partie des habitudes dont plus personne ne connaît
la source. En anglais, ça s'appelle "cargo cult", mais je ne sais pas
s'il y a un équivalent en français.
Autres trucs du même style :
- On ne doit pas se connecter via SSH sous le compte "root" ; il faut
se connecter en tant qu'utilisateur puis utiliser "su".
- La taille de la partition de swap doit être égale à deux fois la
taille de la RAM.
On Wed, 02 Mar 2011 23:05:05 +0100, Bruno Tréguier :
que pensez-vous des politiques de gestion des mots de passe imposant un changement régulier de ce dernier ?
Pour moi, ça fait partie des habitudes dont plus personne ne connaît la source. En anglais, ça s'appelle "cargo cult", mais je ne sais pas s'il y a un équivalent en français.
Autres trucs du même style :
- On ne doit pas se connecter via SSH sous le compte "root" ; il faut se connecter en tant qu'utilisateur puis utiliser "su". - La taille de la partition de swap doit être égale à deux fois la taille de la RAM.
Eric Demeester
dans (in) fr.comp.securite, Fabien LE LEZ ecrivait (wrote) :
Bonsoir Fabien,
- On ne doit pas se connecter via SSH sous le compte "root" ; il faut se connecter en tant qu'utilisateur puis utiliser "su".
Ou calife.
Sur ce point (connexion ssh), ça ne me semble pas idiot de se connecter sur un autre compte que root, pas particulièrement pour des raisons de sécurité par rapport à d'hypothétiques attaques, mais juste pour éviter de faire des bétises par inadvertance quand on bricole sur telle ou telle machine.
-- Eric Demeester - http://www.galacsys.net
dans (in) fr.comp.securite, Fabien LE LEZ <gramster@gramster.com>
ecrivait (wrote) :
Bonsoir Fabien,
- On ne doit pas se connecter via SSH sous le compte "root" ; il faut
se connecter en tant qu'utilisateur puis utiliser "su".
Ou calife.
Sur ce point (connexion ssh), ça ne me semble pas idiot de se connecter
sur un autre compte que root, pas particulièrement pour des raisons de
sécurité par rapport à d'hypothétiques attaques, mais juste pour éviter
de faire des bétises par inadvertance quand on bricole sur telle ou
telle machine.
dans (in) fr.comp.securite, Fabien LE LEZ ecrivait (wrote) :
Bonsoir Fabien,
- On ne doit pas se connecter via SSH sous le compte "root" ; il faut se connecter en tant qu'utilisateur puis utiliser "su".
Ou calife.
Sur ce point (connexion ssh), ça ne me semble pas idiot de se connecter sur un autre compte que root, pas particulièrement pour des raisons de sécurité par rapport à d'hypothétiques attaques, mais juste pour éviter de faire des bétises par inadvertance quand on bricole sur telle ou telle machine.
-- Eric Demeester - http://www.galacsys.net
Fabien LE LEZ
On Fri, 04 Mar 2011 04:42:59 +0100, Eric Demeester <eric+:
mais juste pour éviter de faire des bétises par inadvertance quand on bricole sur telle ou telle machine.
Certes. Mais bon, quand il s'agit juste de se connecter pour redémarrer Apache, ou d'uploader un nouveau fichier de config dans /etc/ via scp, je ne vois pas l'intérêt de tourner autour du pot.
On Fri, 04 Mar 2011 04:42:59 +0100, Eric Demeester
<eric+usenet@galacsys.net>:
mais juste pour éviter
de faire des bétises par inadvertance quand on bricole sur telle ou
telle machine.
Certes. Mais bon, quand il s'agit juste de se connecter pour
redémarrer Apache, ou d'uploader un nouveau fichier de config dans
/etc/ via scp, je ne vois pas l'intérêt de tourner autour du pot.
On Fri, 04 Mar 2011 04:42:59 +0100, Eric Demeester <eric+:
mais juste pour éviter de faire des bétises par inadvertance quand on bricole sur telle ou telle machine.
Certes. Mais bon, quand il s'agit juste de se connecter pour redémarrer Apache, ou d'uploader un nouveau fichier de config dans /etc/ via scp, je ne vois pas l'intérêt de tourner autour du pot.
Fabien LE LEZ
On Fri, 04 Mar 2011 04:42:59 +0100, Eric Demeester :
- On ne doit pas se connecter via SSH sous le compte "root" ; il faut se connecter en tant qu'utilisateur puis utiliser "su".
pas particulièrement pour des raisons de sécurité par rapport à d'hypothétiques attaques,
Note que j'ai entendu beaucoup d'administrateurs système dire explicitement qu'ils ont mis ça en place pour se protéger contre d'éventuelles attaques.
Quand j'ai voulu prendre un serveur dédié (managé/infogéré) chez un hébergeur dont je tairai le nom, on m'a bien dit qu'il ne fallait pas se connecter en root directement, mais passer par su. Quelques heures après la mise en place du serveur, il s'est trouvé compromis car leur technicien avait créé un compte de test avec un mot de passe bateau ("password", je suppose). Grr...
On Fri, 04 Mar 2011 04:42:59 +0100, Eric Demeester :
- On ne doit pas se connecter via SSH sous le compte "root" ; il faut
se connecter en tant qu'utilisateur puis utiliser "su".
pas particulièrement pour des raisons de
sécurité par rapport à d'hypothétiques attaques,
Note que j'ai entendu beaucoup d'administrateurs système dire
explicitement qu'ils ont mis ça en place pour se protéger contre
d'éventuelles attaques.
Quand j'ai voulu prendre un serveur dédié (managé/infogéré) chez un
hébergeur dont je tairai le nom, on m'a bien dit qu'il ne fallait pas
se connecter en root directement, mais passer par su. Quelques heures
après la mise en place du serveur, il s'est trouvé compromis car leur
technicien avait créé un compte de test avec un mot de passe bateau
("password", je suppose). Grr...
On Fri, 04 Mar 2011 04:42:59 +0100, Eric Demeester :
- On ne doit pas se connecter via SSH sous le compte "root" ; il faut se connecter en tant qu'utilisateur puis utiliser "su".
pas particulièrement pour des raisons de sécurité par rapport à d'hypothétiques attaques,
Note que j'ai entendu beaucoup d'administrateurs système dire explicitement qu'ils ont mis ça en place pour se protéger contre d'éventuelles attaques.
Quand j'ai voulu prendre un serveur dédié (managé/infogéré) chez un hébergeur dont je tairai le nom, on m'a bien dit qu'il ne fallait pas se connecter en root directement, mais passer par su. Quelques heures après la mise en place du serveur, il s'est trouvé compromis car leur technicien avait créé un compte de test avec un mot de passe bateau ("password", je suppose). Grr...
Nicolas George
Eric Demeester , dans le message , a écrit :
Sur ce point (connexion ssh), ça ne me semble pas idiot de se connecter sur un autre compte que root, pas particulièrement pour des raisons de sécurité par rapport à d'hypothétiques attaques, mais juste pour éviter de faire des bétises par inadvertance quand on bricole sur telle ou telle machine.
Dans ce cas, se connecter au compte root ou utiliser su, c'est un peu bonnet blanc et blanc bonnet, dans les deux cas on a un shell root avec exactement les mêmes droits.
Eric Demeester , dans le message
<3dn0n6d2hag8ctca4n159e7ossng1s6t0o@4ax.com>, a écrit :
Sur ce point (connexion ssh), ça ne me semble pas idiot de se connecter
sur un autre compte que root, pas particulièrement pour des raisons de
sécurité par rapport à d'hypothétiques attaques, mais juste pour éviter
de faire des bétises par inadvertance quand on bricole sur telle ou
telle machine.
Dans ce cas, se connecter au compte root ou utiliser su, c'est un peu bonnet
blanc et blanc bonnet, dans les deux cas on a un shell root avec exactement
les mêmes droits.
Sur ce point (connexion ssh), ça ne me semble pas idiot de se connecter sur un autre compte que root, pas particulièrement pour des raisons de sécurité par rapport à d'hypothétiques attaques, mais juste pour éviter de faire des bétises par inadvertance quand on bricole sur telle ou telle machine.
Dans ce cas, se connecter au compte root ou utiliser su, c'est un peu bonnet blanc et blanc bonnet, dans les deux cas on a un shell root avec exactement les mêmes droits.
Jean-Francois BILLAUD
Eric Demeester écrivait:
- On ne doit pas se connecter via SSH sous le compte "root" ; il faut se connecter en tant qu'utilisateur puis utiliser "su".
Sur ce point (connexion ssh), ça ne me semble pas idiot de se connecter sur un autre compte que root, pas particulièrement pour des raisons de sécurité par rapport à d'hypothétiques attaques, mais juste pour éviter de faire des bétises par inadvertance quand on bricole sur telle ou telle machine.
Quand il y a plusieurs administrateurs, ça permet de savoir plus rapidement lequel a fait des âneries.
JFB
-- Les mises à jour servent à trois choses : rajouter de nouveaux bugs, apporter de nouvelles fonctions inutiles, et corriger des erreurs que personne n'avait remarquées.
Eric Demeester écrivait:
- On ne doit pas se connecter via SSH sous le compte "root" ; il faut
se connecter en tant qu'utilisateur puis utiliser "su".
Sur ce point (connexion ssh), ça ne me semble pas idiot de se connecter
sur un autre compte que root, pas particulièrement pour des raisons de
sécurité par rapport à d'hypothétiques attaques, mais juste pour éviter
de faire des bétises par inadvertance quand on bricole sur telle ou
telle machine.
Quand il y a plusieurs administrateurs, ça permet de savoir plus rapidement
lequel a fait des âneries.
JFB
--
Les mises à jour servent à trois choses : rajouter de nouveaux bugs,
apporter de nouvelles fonctions inutiles, et corriger des erreurs
que personne n'avait remarquées.
- On ne doit pas se connecter via SSH sous le compte "root" ; il faut se connecter en tant qu'utilisateur puis utiliser "su".
Sur ce point (connexion ssh), ça ne me semble pas idiot de se connecter sur un autre compte que root, pas particulièrement pour des raisons de sécurité par rapport à d'hypothétiques attaques, mais juste pour éviter de faire des bétises par inadvertance quand on bricole sur telle ou telle machine.
Quand il y a plusieurs administrateurs, ça permet de savoir plus rapidement lequel a fait des âneries.
JFB
-- Les mises à jour servent à trois choses : rajouter de nouveaux bugs, apporter de nouvelles fonctions inutiles, et corriger des erreurs que personne n'avait remarquées.
yamo'
Fabien LE LEZ a tapoté, le 04/03/2011 05:20:
il s'est trouvé compromis car leur technicien avait créé un compte de test avec un mot de passe bateau ("password", je suppose). Grr...
On peut aussi définir une liste de comptes qui ont le droit de se connecter et donc laisser un user quelconque prendre un mauvais mot de passe pour se connecter en local ou sur le réseau local mais lui interdire de se connecter par SSH à distance.
-- Stéphane
<http://pasdenom.info/fortune/>
Quelque bien qu'on nous dise de nous, on ne nous apprend rien de nouveau. -+- François de La Rochefoucauld (1613-1680), Maximes 303 -+-
Fabien LE LEZ a tapoté, le 04/03/2011 05:20:
il s'est trouvé compromis car leur
technicien avait créé un compte de test avec un mot de passe bateau
("password", je suppose). Grr...
On peut aussi définir une liste de comptes qui ont le droit de se
connecter et donc laisser un user quelconque prendre un mauvais mot de
passe pour se connecter en local ou sur le réseau local mais lui
interdire de se connecter par SSH à distance.
--
Stéphane
<http://pasdenom.info/fortune/>
Quelque bien qu'on nous dise de nous, on ne nous apprend rien de
nouveau.
-+- François de La Rochefoucauld (1613-1680), Maximes 303 -+-
il s'est trouvé compromis car leur technicien avait créé un compte de test avec un mot de passe bateau ("password", je suppose). Grr...
On peut aussi définir une liste de comptes qui ont le droit de se connecter et donc laisser un user quelconque prendre un mauvais mot de passe pour se connecter en local ou sur le réseau local mais lui interdire de se connecter par SSH à distance.
-- Stéphane
<http://pasdenom.info/fortune/>
Quelque bien qu'on nous dise de nous, on ne nous apprend rien de nouveau. -+- François de La Rochefoucauld (1613-1680), Maximes 303 -+-
Kevin Denis
Le 04-03-2011, Fabien LE LEZ a écrit :
mais juste pour éviter de faire des bétises par inadvertance quand on bricole sur telle ou telle machine.
Certes. Mais bon, quand il s'agit juste de se connecter pour redémarrer Apache,
un compte utilisateur appelé www-admin qui a le droit, via sudo, de réaliser des tâches de maintenance web de ce genre.
ou d'uploader un nouveau fichier de config dans /etc/ via scp, je ne vois pas l'intérêt de tourner autour du pot.
Ca n'est pas censé arriver tous les quatre matins, donc devoir passer par su n'est pas une sinécure non plus. (je me fais un peu l'avocat du diable, je ne suis pas contre autoriser root à se loguer).
Ceci dit, je pense que cela c'est sans doute plus global, dans le sens défense en profondeur. On interdit le login root via ssh, ça n'est clairement pas la seule barrière à mettre en place, mais ça va décourager les bots qui lancent du bruteforce ssh sur le login root. Gain en sécurité mineur, sans que cela ne pose trop de problèmes.
Il reste à placer d'autres politiques ssh: vérification obligatoire[1] des clés hôtes, interdiction de login par mot de passe, changement du port par défaut de ssh (uniquement pour la lisibilité des logs), des clés de taille suffisante et surtout, protégez vos clés!
[1]putty permet de se loguer sur un hôte ayant modifié sa clé en un clic, ce qui est un problème, selon moi. -- Kevin
Le 04-03-2011, Fabien LE LEZ <gramster@gramster.com> a écrit :
mais juste pour éviter
de faire des bétises par inadvertance quand on bricole sur telle ou
telle machine.
Certes. Mais bon, quand il s'agit juste de se connecter pour
redémarrer Apache,
un compte utilisateur appelé www-admin qui a le droit, via sudo,
de réaliser des tâches de maintenance web de ce genre.
ou d'uploader un nouveau fichier de config dans
/etc/ via scp, je ne vois pas l'intérêt de tourner autour du pot.
Ca n'est pas censé arriver tous les quatre matins, donc devoir passer
par su n'est pas une sinécure non plus. (je me fais un peu l'avocat
du diable, je ne suis pas contre autoriser root à se loguer).
Ceci dit, je pense que cela c'est sans doute plus global, dans le
sens défense en profondeur. On interdit le login root via ssh, ça
n'est clairement pas la seule barrière à mettre en place, mais
ça va décourager les bots qui lancent du bruteforce ssh sur le
login root. Gain en sécurité mineur, sans que cela ne pose trop
de problèmes.
Il reste à placer d'autres politiques ssh: vérification obligatoire[1]
des clés hôtes, interdiction de login par mot de passe, changement
du port par défaut de ssh (uniquement pour la lisibilité des logs),
des clés de taille suffisante et surtout, protégez vos clés!
[1]putty permet de se loguer sur un hôte ayant modifié sa clé en
un clic, ce qui est un problème, selon moi.
--
Kevin
mais juste pour éviter de faire des bétises par inadvertance quand on bricole sur telle ou telle machine.
Certes. Mais bon, quand il s'agit juste de se connecter pour redémarrer Apache,
un compte utilisateur appelé www-admin qui a le droit, via sudo, de réaliser des tâches de maintenance web de ce genre.
ou d'uploader un nouveau fichier de config dans /etc/ via scp, je ne vois pas l'intérêt de tourner autour du pot.
Ca n'est pas censé arriver tous les quatre matins, donc devoir passer par su n'est pas une sinécure non plus. (je me fais un peu l'avocat du diable, je ne suis pas contre autoriser root à se loguer).
Ceci dit, je pense que cela c'est sans doute plus global, dans le sens défense en profondeur. On interdit le login root via ssh, ça n'est clairement pas la seule barrière à mettre en place, mais ça va décourager les bots qui lancent du bruteforce ssh sur le login root. Gain en sécurité mineur, sans que cela ne pose trop de problèmes.
Il reste à placer d'autres politiques ssh: vérification obligatoire[1] des clés hôtes, interdiction de login par mot de passe, changement du port par défaut de ssh (uniquement pour la lisibilité des logs), des clés de taille suffisante et surtout, protégez vos clés!
[1]putty permet de se loguer sur un hôte ayant modifié sa clé en un clic, ce qui est un problème, selon moi. -- Kevin
