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... ?
j'ajouterai que j'ai le même code de CB depuis 1999, et que ma nouvelle carte est valable jusqu'en 2014... ça fait quand même 15 ans...
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Baton Rouge
On Wed, 02 Mar 2011 23:05:05 +0100, Bruno Tréguier wrote:
6) récupérer le hash ou le mot de passe crypté et tenter de le cracker "offline".
Cloner, blanchir le mot de passe (SAM par exemple), donner les droit complet à un autre utilisateur, remettre le mot de passe par une restauration du clone.
7) debrancher le disque dur, le monter sur une autre machine, se donner les droits dans un repertoire y coller une salopperie qui se lance une fois en admin et qui s'efface
-- 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 Wed, 02 Mar 2011 23:05:05 +0100, Bruno Tréguier
<bruno.treguier_at_shom.fr@nullepart.invalid> wrote:
6) récupérer le hash ou le mot de passe crypté et tenter de le cracker
"offline".
Cloner, blanchir le mot de passe (SAM par exemple), donner les droit
complet à un autre utilisateur, remettre le mot de passe par une
restauration du clone.
7) debrancher le disque dur, le monter sur une autre machine, se
donner les droits dans un repertoire y coller une salopperie qui se
lance une fois en admin et qui s'efface
--
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 Wed, 02 Mar 2011 23:05:05 +0100, Bruno Tréguier wrote:
6) récupérer le hash ou le mot de passe crypté et tenter de le cracker "offline".
Cloner, blanchir le mot de passe (SAM par exemple), donner les droit complet à un autre utilisateur, remettre le mot de passe par une restauration du clone.
7) debrancher le disque dur, le monter sur une autre machine, se donner les droits dans un repertoire y coller une salopperie qui se lance une fois en admin et qui s'efface
-- 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 ?
Baton Rouge
On Wed, 02 Mar 2011 23:05:05 +0100, Bruno Tréguier wrote:
6) récupérer le hash ou le mot de passe crypté et tenter de le cracker "offline".
8) Activer la webcam sur le portable qui film le clavier... -- 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 Wed, 02 Mar 2011 23:05:05 +0100, Bruno Tréguier
<bruno.treguier_at_shom.fr@nullepart.invalid> wrote:
6) récupérer le hash ou le mot de passe crypté et tenter de le cracker
"offline".
8) Activer la webcam sur le portable qui film le clavier...
--
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 Wed, 02 Mar 2011 23:05:05 +0100, Bruno Tréguier wrote:
6) récupérer le hash ou le mot de passe crypté et tenter de le cracker "offline".
8) Activer la webcam sur le portable qui film le clavier... -- 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 ?
Bruno Tréguier
Le 02/03/2011 à 23:40, Baton Rouge a écrit :
On Wed, 02 Mar 2011 23:05:05 +0100, Bruno Tréguier wrote:
6) récupérer le hash ou le mot de passe crypté et tenter de le cracker "offline".
8) Activer la webcam sur le portable qui film le clavier...
Je n'ai pas dit que j'avais été exhaustif ! :-)
Cordialement,
Bruno Tréguier
Le 02/03/2011 à 23:40, Baton Rouge a écrit :
On Wed, 02 Mar 2011 23:05:05 +0100, Bruno Tréguier
<bruno.treguier_at_shom.fr@nullepart.invalid> wrote:
6) récupérer le hash ou le mot de passe crypté et tenter de le cracker
"offline".
8) Activer la webcam sur le portable qui film le clavier...
On Wed, 02 Mar 2011 23:05:05 +0100, Bruno Tréguier wrote:
6) récupérer le hash ou le mot de passe crypté et tenter de le cracker "offline".
8) Activer la webcam sur le portable qui film le clavier...
Je n'ai pas dit que j'avais été exhaustif ! :-)
Cordialement,
Bruno Tréguier
Bruno Tréguier
Le 02/03/2011 à 23:27, Aeris a écrit :
Je ne peux que +1 à tout ça
Pour moi, une gestion par mot de passe est obsolète aujourd'hui, et toutes les pseudo-politiques de sécurité sont soit très mal appliquées, soit inutiles (voire affaiblissent les mots de passe), et bien souvent un peu de tout ça en même temps.
Je suis tout à fait d'accord: un mdp ne suffit plus pour assurer une sécurité correcte, dans beaucoup de cas.
C'est pour ça que je préconise dorénavant des systèmes plus fiables de sécurisation. Au minimum du 2-factor-auth avec si possible au moins un 2 en strong-auth: Connexion par mot de passe + au choix - - OTP
Oui, on en a, mais c'est un peu lourd. On a utilisé des trucs avec OPIE pendant un temps, puis des calculettes, mais bon.
- - Token USB (une Yubikey par exemple, très peu chère et opensource!)
Merci de l'info ! Je ne connaissais pas.
- - Clé privée (SSH ou autre) - - Certificat X.509/PKCS12 - - Empreinte digitale (encore difficile et coûteux à mettre en œuvre)
Certes, certains argumenteront qu'on peut toujours refiler le vecteur physique à quelqu'un d'autre, mais à l'inverse d'un mot de passe, le détenteur ne peut alors plus se connecter et donc le prêt n'a que très rarement lieu.
Pour la clef privée ou le certificat, tout dépend du support, mais je vous suis...
Le seul défaut de la strong-auth est de nécessiter le support physique. Si le token n'est pas accessible, pas d'authentification! Alors qu'avec juste un mot de passe la connexion est possible tout le temps.
Merci encore de votre message, qui me conforte dans l'opinion que j'ai de la (faible) sécurité par mot de passe. Si vous jetez un oeil à mon adresse email, vous verrez que je travaille dans un milieu où une position telle que la mienne est plutôt considérée comme hérétique, pour l'instant tout au moins. ;-)
Cordialement,
Bruno Tréguier
Le 02/03/2011 à 23:27, Aeris a écrit :
Je ne peux que +1 à tout ça
Pour moi, une gestion par mot de passe est obsolète aujourd'hui, et toutes
les pseudo-politiques de sécurité sont soit très mal appliquées, soit
inutiles (voire affaiblissent les mots de passe), et bien souvent un peu de
tout ça en même temps.
Je suis tout à fait d'accord: un mdp ne suffit plus pour assurer une
sécurité correcte, dans beaucoup de cas.
C'est pour ça que je préconise dorénavant des systèmes plus fiables de
sécurisation. Au minimum du 2-factor-auth avec si possible au moins un 2 en
strong-auth:
Connexion par mot de passe + au choix
- - OTP
Oui, on en a, mais c'est un peu lourd. On a utilisé des trucs avec OPIE
pendant un temps, puis des calculettes, mais bon.
- - Token USB (une Yubikey par exemple, très peu chère et opensource!)
Merci de l'info ! Je ne connaissais pas.
- - Clé privée (SSH ou autre)
- - Certificat X.509/PKCS12
- - Empreinte digitale (encore difficile et coûteux à mettre en œuvre)
Certes, certains argumenteront qu'on peut toujours refiler le vecteur
physique à quelqu'un d'autre, mais à l'inverse d'un mot de passe, le
détenteur ne peut alors plus se connecter et donc le prêt n'a que très
rarement lieu.
Pour la clef privée ou le certificat, tout dépend du support, mais je
vous suis...
Le seul défaut de la strong-auth est de nécessiter le support physique. Si
le token n'est pas accessible, pas d'authentification! Alors qu'avec juste
un mot de passe la connexion est possible tout le temps.
Merci encore de votre message, qui me conforte dans l'opinion que j'ai
de la (faible) sécurité par mot de passe. Si vous jetez un oeil à mon
adresse email, vous verrez que je travaille dans un milieu où une
position telle que la mienne est plutôt considérée comme hérétique, pour
l'instant tout au moins. ;-)
Pour moi, une gestion par mot de passe est obsolète aujourd'hui, et toutes les pseudo-politiques de sécurité sont soit très mal appliquées, soit inutiles (voire affaiblissent les mots de passe), et bien souvent un peu de tout ça en même temps.
Je suis tout à fait d'accord: un mdp ne suffit plus pour assurer une sécurité correcte, dans beaucoup de cas.
C'est pour ça que je préconise dorénavant des systèmes plus fiables de sécurisation. Au minimum du 2-factor-auth avec si possible au moins un 2 en strong-auth: Connexion par mot de passe + au choix - - OTP
Oui, on en a, mais c'est un peu lourd. On a utilisé des trucs avec OPIE pendant un temps, puis des calculettes, mais bon.
- - Token USB (une Yubikey par exemple, très peu chère et opensource!)
Merci de l'info ! Je ne connaissais pas.
- - Clé privée (SSH ou autre) - - Certificat X.509/PKCS12 - - Empreinte digitale (encore difficile et coûteux à mettre en œuvre)
Certes, certains argumenteront qu'on peut toujours refiler le vecteur physique à quelqu'un d'autre, mais à l'inverse d'un mot de passe, le détenteur ne peut alors plus se connecter et donc le prêt n'a que très rarement lieu.
Pour la clef privée ou le certificat, tout dépend du support, mais je vous suis...
Le seul défaut de la strong-auth est de nécessiter le support physique. Si le token n'est pas accessible, pas d'authentification! Alors qu'avec juste un mot de passe la connexion est possible tout le temps.
Merci encore de votre message, qui me conforte dans l'opinion que j'ai de la (faible) sécurité par mot de passe. Si vous jetez un oeil à mon adresse email, vous verrez que je travaille dans un milieu où une position telle que la mienne est plutôt considérée comme hérétique, pour l'instant tout au moins. ;-)
Cordialement,
Bruno Tréguier
Fabien LE LEZ
On Wed, 02 Mar 2011 23:27:01 +0100, Aeris :
Empreinte digitale (encore difficile et coûteux à mettre en œuvre)
En revanche, facile à copier, et impossible à révoquer.
Ce qui me fait marrer, c'est les PC portables avec lecteur d'empreintes digitales. Si je pique un portable, je suis presque sûr de trouver les empreintes digitales du propriétaire dessus. C'est donc à peu près aussi sécurisé que le mot de passe collé sous le clavier.
On Wed, 02 Mar 2011 23:27:01 +0100, Aeris <aeris@imirhil.fr>:
Empreinte digitale (encore difficile et coûteux à mettre en œuvre)
En revanche, facile à copier, et impossible à révoquer.
Ce qui me fait marrer, c'est les PC portables avec lecteur
d'empreintes digitales. Si je pique un portable, je suis presque sûr
de trouver les empreintes digitales du propriétaire dessus.
C'est donc à peu près aussi sécurisé que le mot de passe collé sous le
clavier.
Empreinte digitale (encore difficile et coûteux à mettre en œuvre)
En revanche, facile à copier, et impossible à révoquer.
Ce qui me fait marrer, c'est les PC portables avec lecteur d'empreintes digitales. Si je pique un portable, je suis presque sûr de trouver les empreintes digitales du propriétaire dessus. C'est donc à peu près aussi sécurisé que le mot de passe collé sous le clavier.
Stephane Catteau
Bruno Tréguier n'était pas loin de dire :
Alors, évidemment, tout ce qui précède doit être modulé en fonction de l'importance des données à protéger dans le compte ou l'application protégée par un mot de passe, mais dans beaucoup de cas, il semble que les inconvénients apportés par une politique de changement fréquent de mot de passe sont de plus en plus considérés comme étant plus importants que les avantages... En d'autres termes: le mieux est l'ennemi du bien.
A mon sens une politique de changement des mots de passe ne doit pas être prise comme une mesure visant à élever le niveau de sécurité de l'accès au système, mais comme une mesure visant à augmenter le niveau de sécurité global. Cette politique s'inscrit alors comme un rappel régulier à la vigilance individuelle. Cependant elle doit être accompagnée d'une bonne dose de pédagogie, sinon on obtient l'effet inverse et un certain raz le bol face à toutes ces contraintes de [beep] qui compliquent la vie plus qu'autre chose. Quoi qu'il en soit, il ne faut pas oublier que la sécurité de l'accès ne se résume pas au simple mot de passe en lui-même. Comme tu le disais là aussi, pour se protéger contre une attaque dictionnaire ou brute force, il suffit le plus souvent de bloquer l'accès au bout de x erreurs, avec réinitialisation manuelle par l'admin lorsque c'est possible. Pour se protéger d'une attaque contre la base de mots de passe elle-même, il faut sécuriser l'accès à la base elle-même. Récupérer le /etc/master.passwd de ma passerelle, par exemple, ne peut se faire qu'en ayant accès à la machine ou bien en exploitant une faille cgi ou assimilée. Mais c'est là qu'apparaît le revers de la médaille. Une politique de changement des mots de passe peut distraire l'attention. Il ne faut pas croire que, parce que les mots de passe sont changés tous les mois, l'on ne doit pas s'alarmer parce qu'il est possible qu'éventuellement la base qui les contient ait été récupérée ; tout comme l'on ne doit pas arrêter de surveiller les logs pour regarder s'il y a eu des blocages suites à une attaque dictionnaire. Même chose pour les attaques plus élémentaires, une politique de changement des mots de passe ne doit pas se substituer à la pédagogie ; ce n'est pas la parade face à la secrétaire qui marque son mot de passe sur son écran. Or, sauf environnement à haut risque, c'est bien souvent pour décharger l'admin d'une partie de son travail que l'on instaure une telle politique, ce qui au final affaiblie le niveau de sécurité globale plus qu'autre chose.
-- 17/06/1969 - 18/01/2011
Repose en paix mon amour :'(
Bruno Tréguier n'était pas loin de dire :
Alors, évidemment, tout ce qui précède doit être modulé en fonction de
l'importance des données à protéger dans le compte ou l'application
protégée par un mot de passe, mais dans beaucoup de cas, il semble que
les inconvénients apportés par une politique de changement fréquent de
mot de passe sont de plus en plus considérés comme étant plus importants
que les avantages... En d'autres termes: le mieux est l'ennemi du bien.
A mon sens une politique de changement des mots de passe ne doit pas
être prise comme une mesure visant à élever le niveau de sécurité de
l'accès au système, mais comme une mesure visant à augmenter le niveau
de sécurité global. Cette politique s'inscrit alors comme un rappel
régulier à la vigilance individuelle. Cependant elle doit être
accompagnée d'une bonne dose de pédagogie, sinon on obtient l'effet
inverse et un certain raz le bol face à toutes ces contraintes de
[beep] qui compliquent la vie plus qu'autre chose.
Quoi qu'il en soit, il ne faut pas oublier que la sécurité de l'accès
ne se résume pas au simple mot de passe en lui-même. Comme tu le disais
là aussi, pour se protéger contre une attaque dictionnaire ou brute
force, il suffit le plus souvent de bloquer l'accès au bout de x
erreurs, avec réinitialisation manuelle par l'admin lorsque c'est
possible. Pour se protéger d'une attaque contre la base de mots de
passe elle-même, il faut sécuriser l'accès à la base elle-même.
Récupérer le /etc/master.passwd de ma passerelle, par exemple, ne peut
se faire qu'en ayant accès à la machine ou bien en exploitant une
faille cgi ou assimilée.
Mais c'est là qu'apparaît le revers de la médaille. Une politique de
changement des mots de passe peut distraire l'attention. Il ne faut pas
croire que, parce que les mots de passe sont changés tous les mois,
l'on ne doit pas s'alarmer parce qu'il est possible qu'éventuellement
la base qui les contient ait été récupérée ; tout comme l'on ne doit
pas arrêter de surveiller les logs pour regarder s'il y a eu des
blocages suites à une attaque dictionnaire. Même chose pour les
attaques plus élémentaires, une politique de changement des mots de
passe ne doit pas se substituer à la pédagogie ; ce n'est pas la parade
face à la secrétaire qui marque son mot de passe sur son écran.
Or, sauf environnement à haut risque, c'est bien souvent pour
décharger l'admin d'une partie de son travail que l'on instaure une
telle politique, ce qui au final affaiblie le niveau de sécurité
globale plus qu'autre chose.
Alors, évidemment, tout ce qui précède doit être modulé en fonction de l'importance des données à protéger dans le compte ou l'application protégée par un mot de passe, mais dans beaucoup de cas, il semble que les inconvénients apportés par une politique de changement fréquent de mot de passe sont de plus en plus considérés comme étant plus importants que les avantages... En d'autres termes: le mieux est l'ennemi du bien.
A mon sens une politique de changement des mots de passe ne doit pas être prise comme une mesure visant à élever le niveau de sécurité de l'accès au système, mais comme une mesure visant à augmenter le niveau de sécurité global. Cette politique s'inscrit alors comme un rappel régulier à la vigilance individuelle. Cependant elle doit être accompagnée d'une bonne dose de pédagogie, sinon on obtient l'effet inverse et un certain raz le bol face à toutes ces contraintes de [beep] qui compliquent la vie plus qu'autre chose. Quoi qu'il en soit, il ne faut pas oublier que la sécurité de l'accès ne se résume pas au simple mot de passe en lui-même. Comme tu le disais là aussi, pour se protéger contre une attaque dictionnaire ou brute force, il suffit le plus souvent de bloquer l'accès au bout de x erreurs, avec réinitialisation manuelle par l'admin lorsque c'est possible. Pour se protéger d'une attaque contre la base de mots de passe elle-même, il faut sécuriser l'accès à la base elle-même. Récupérer le /etc/master.passwd de ma passerelle, par exemple, ne peut se faire qu'en ayant accès à la machine ou bien en exploitant une faille cgi ou assimilée. Mais c'est là qu'apparaît le revers de la médaille. Une politique de changement des mots de passe peut distraire l'attention. Il ne faut pas croire que, parce que les mots de passe sont changés tous les mois, l'on ne doit pas s'alarmer parce qu'il est possible qu'éventuellement la base qui les contient ait été récupérée ; tout comme l'on ne doit pas arrêter de surveiller les logs pour regarder s'il y a eu des blocages suites à une attaque dictionnaire. Même chose pour les attaques plus élémentaires, une politique de changement des mots de passe ne doit pas se substituer à la pédagogie ; ce n'est pas la parade face à la secrétaire qui marque son mot de passe sur son écran. Or, sauf environnement à haut risque, c'est bien souvent pour décharger l'admin d'une partie de son travail que l'on instaure une telle politique, ce qui au final affaiblie le niveau de sécurité globale plus qu'autre chose.
-- 17/06/1969 - 18/01/2011
Repose en paix mon amour :'(
Stephane Catteau
Baton Rouge devait dire quelque chose comme ceci :
7) debrancher le disque dur, le monter sur une autre machine, se donner les droits dans un repertoire y coller une salopperie qui se lance une fois en admin et qui s'efface
Oui, mais bon quelqu'un qui arrive à faire ça n'a probablement pas besoin de se casser la tête à ce point. Si un admin/service informatique laisse à quelqu'un la possibilité de débrancher le disque dur, le brancher sur une machine qu'il aurait amené, y rajouter quelque chose, puis rebrancher le disque dur, autant lui demander directement le mot de passe en lui racontant une bonne grosse annerie, il le donnera. D'un autre côté cela soulève un problème rarement, si ce n'est jamais, pris en compte pour les particuliers. Lorsqu'ils renvoient la machine au SAV, ils le font tel quel... ce qui est loin d'être quelque chose de sur.
-- 17/06/1969 - 18/01/2011
Repose en paix mon amour :'(
Baton Rouge devait dire quelque chose comme ceci :
7) debrancher le disque dur, le monter sur une autre machine, se
donner les droits dans un repertoire y coller une salopperie qui se
lance une fois en admin et qui s'efface
Oui, mais bon quelqu'un qui arrive à faire ça n'a probablement pas
besoin de se casser la tête à ce point. Si un admin/service
informatique laisse à quelqu'un la possibilité de débrancher le disque
dur, le brancher sur une machine qu'il aurait amené, y rajouter quelque
chose, puis rebrancher le disque dur, autant lui demander directement
le mot de passe en lui racontant une bonne grosse annerie, il le
donnera.
D'un autre côté cela soulève un problème rarement, si ce n'est jamais,
pris en compte pour les particuliers. Lorsqu'ils renvoient la machine
au SAV, ils le font tel quel... ce qui est loin d'être quelque chose de
sur.
Baton Rouge devait dire quelque chose comme ceci :
7) debrancher le disque dur, le monter sur une autre machine, se donner les droits dans un repertoire y coller une salopperie qui se lance une fois en admin et qui s'efface
Oui, mais bon quelqu'un qui arrive à faire ça n'a probablement pas besoin de se casser la tête à ce point. Si un admin/service informatique laisse à quelqu'un la possibilité de débrancher le disque dur, le brancher sur une machine qu'il aurait amené, y rajouter quelque chose, puis rebrancher le disque dur, autant lui demander directement le mot de passe en lui racontant une bonne grosse annerie, il le donnera. D'un autre côté cela soulève un problème rarement, si ce n'est jamais, pris en compte pour les particuliers. Lorsqu'ils renvoient la machine au SAV, ils le font tel quel... ce qui est loin d'être quelque chose de sur.
-- 17/06/1969 - 18/01/2011
Repose en paix mon amour :'(
Erwan David
Bruno Tréguier écrivait :
Le 02/03/2011 à 23:37, Erwan David a écrit :
j'ajouterai que j'ai le même code de CB depuis 1999, et que ma nouvelle carte est valable jusqu'en 2014... ça fait quand même 15 ans...
Oui, j'avais pensé à cet exemple aussi effectivement. En plus on ne peut pas dire qu'un code de CB réponde (même de loin) à la plus laxiste des politiques de sécurité concernant l'entropie des mots de passe...
Cordialement,
Bruno Tréguier
Par contre la carte se bloque après 3 essais infructueux.
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Bruno Tréguier <bruno.treguier_at_shom.fr@nullepart.invalid> écrivait :
Le 02/03/2011 à 23:37, Erwan David a écrit :
j'ajouterai que j'ai le même code de CB depuis 1999, et que ma
nouvelle carte est valable jusqu'en 2014... ça fait quand même 15 ans...
Oui, j'avais pensé à cet exemple aussi effectivement. En plus on ne
peut pas dire qu'un code de CB réponde (même de loin) à la plus
laxiste des politiques de sécurité concernant l'entropie des mots de
passe...
Cordialement,
Bruno Tréguier
Par contre la carte se bloque après 3 essais infructueux.
--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé
j'ajouterai que j'ai le même code de CB depuis 1999, et que ma nouvelle carte est valable jusqu'en 2014... ça fait quand même 15 ans...
Oui, j'avais pensé à cet exemple aussi effectivement. En plus on ne peut pas dire qu'un code de CB réponde (même de loin) à la plus laxiste des politiques de sécurité concernant l'entropie des mots de passe...
Cordialement,
Bruno Tréguier
Par contre la carte se bloque après 3 essais infructueux.
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Bruno Tréguier
Stephane Catteau wrote:
[plein de trucs de bon sens]
Or, sauf environnement à haut risque, c'est bien souvent pour décharger l'admin d'une partie de son travail que l'on instaure une telle politique, ce qui au final affaiblie le niveau de sécurité globale plus qu'autre chose.
Tout à fait. J'irais même plus loin: tu dis que c'est souvent pour décharger l'admin d'une partie de son travail... Je connais des endroits où c'est plutôt pour décharger l'admin de ses *responsabilités* !
Cordialement,
-- Bruno Tréguier
Stephane Catteau wrote:
[plein de trucs de bon sens]
Or, sauf environnement à haut risque, c'est bien souvent pour
décharger l'admin d'une partie de son travail que l'on instaure une
telle politique, ce qui au final affaiblie le niveau de sécurité
globale plus qu'autre chose.
Tout à fait. J'irais même plus loin: tu dis que c'est souvent pour
décharger l'admin d'une partie de son travail... Je connais des endroits
où c'est plutôt pour décharger l'admin de ses *responsabilités* !
Or, sauf environnement à haut risque, c'est bien souvent pour décharger l'admin d'une partie de son travail que l'on instaure une telle politique, ce qui au final affaiblie le niveau de sécurité globale plus qu'autre chose.
Tout à fait. J'irais même plus loin: tu dis que c'est souvent pour décharger l'admin d'une partie de son travail... Je connais des endroits où c'est plutôt pour décharger l'admin de ses *responsabilités* !
