Je suis en phase avec toi sur l’idée.
Le souci est que les checks entropiques sont souvent coûteux en ressource, et je ne suis pas certain que ce soit simple à implémenter à l’échelle.
Par contre, il est clair qu’il faut simplifier et donner plus de liberté aux utilisateurs sur le choix de leurs mots de passe :)
Ne pas oublier non plus que la longueur du mot de passe peut compenser la complexité : tant de formulaires réclament quand même un chiffre ou un caractère spécial quand on propose un mot de passe de 128 caractères… l’idéal serait d’exiger une entropie minimale, mais c’est utopique. Il n’empêche que cela permettrait à chacun de proposer des mots de passe forts, avec moins de contraintes (complexité ou longueur).
Chez nous, ou l’on gère un parc conséquent de machines (Plusieurs milliers sur presque des centaines de clients) on est obligé de faire simple et efficace pour s’y retrouver :
PAYS_REGION_ROLE_NUMEROINCREMENTAL
Par exemple pour un hyperv : CHGEHYV01
Pour un DC / FS : CHGEDC01
Pour un applicatif générique : CHLSAP01
Pour un backup : SGBCK01
CHGE (Suisse, Genève)
CHLS (Suisse, Lausanne)
SG (Singapour, on ne regarde pas la région, car on ne s’y déplace pas physiquement tous les 4 matins).
etc …
Parfois, on met le nom de l’applicatif directement dans le serveur, par exemple, dans un abacus en cluster :
CHLSABA01 et CHLSABA02
Je voulais vraiment un truc super simple à mettre en place et sans maintenance, du coup j’ai préféré aller vers Stacks.
Une mise à jour majeur ça doit pas arriver tout les 4 matins, généralement ça dure plusieurs années. Donc bon, ça me parait carrément raisonnable comme prix ;)
À partir d’un certain nombre de serveurs c’est totalement contre-productif d’utiliser des noms de dieux/héros/pays/others, qui va se souvenir que les dieux sont les serveurs PostgreSQL, les héros les serveurs web, etc.
On cherche tous à nommer les serveurs en précisant leur(s) fonction(s), il ne faut donc pas hésiter à faire simple : postgresql7, dns1, vpn2, dhcp1, ntp1… Le souci c’est qu’on peut avoir plusieurs applications/services sur un serveur, on perd le côté propre/logique dans le nommage. Bah ouais rien n’est parfait, il faut juste chercher à être le plus propre/logique pour le nommage et puis on fera avec.
Un S-L-T-BDD-PG01 serait chez moi TEST-PG01 parce que a/ On sait que c’est un serveur (implicite) donc je garde pas le S b/ Serveurs Linux la norme chez moi donc je garde pas le L c/ T (pour test) je garde, je garde pas PROD car c’est la norme d/ BDD je garde pas car PG01 donne l’info implicitement.
Vouloir préciser trop de choses dans le nom est une mauvaise idée d’après mon expérience, trop de changements possibles lors du cycle de vie d’un serveur. Par exemple foutre le nom de l’application ou du service genre GLPI, CIEL part du principe que ça ne changera pas. Je préfère COMPTA, RH…
Pour plus de lisibilité, je commence par les abréviations.
J’ai horreur d’une seule lettre comme abréviation, je n’ai pas souvenir avoir vu des serveurs avec des abréviations sur une seule lettre. J’ai aussi une mauvaise mémoire et mon cerveau est pas très rapide, quand je vois S-L-T-WEB01 je dois faire un effort intellectuel car je n’arrive pas à “lire” directement.
Les abréviations que je préfère : PST pour poste, PRT pour portable, SRV pour serveur, LN pour Linux, NT pour Windows, VM pour machine virtuelle, SB pour sandbox (machine de tests en général pour les devs), HY pour hypervisor, BDD pour bases de données, WEB pour serveurs web, PROD, TEST.
La plupart du temps utiliser SRV est inutile car souvent on le sait, c’est implicite, SRV-DC01 serait DC01 chez moi. Souvent il y a une majorité de serveurs Windows ou Linux pourquoi leur mettre une abréviation ? Je ne mets une abréviation qu’à ceux qui ne sont pas de la majorité de serveurs ainsi si la majorité est du Windows je ne préfixe que les serveurs Linux. Pareil pour PROD je ne le mets pas car c’est la norme chez moi, je ne mets que TEST.
Pour info dernière release du 31/03/2021 et “PROJECT ON BREAK I’m looking forward to continue development some time in the future, but there will not be updates for the next few months” (https://github.com/jliljebl/flowblade).
Tiens. Perso, je fais différement et ça fonctionne aussi :
Dans le menu “Sécurité” de mon compte GMail, du fait d’avoir activé la 2FA, créer un pass par application et dans TB (ou autres clients mails), je remplis les infos SMTP, IMAP de Gmail, et dans le champ password lié à mon compte utilisateur, je mets celui relatif au “pass par application”, créé précédemment.
Le seul truc “casse-pied” est de devoir valider quasiment tous les jours le certificat TLS de Gmail.
Je peux me tromper, mais la dernière fois que j’ai regardé il n’était justement pas possible d’auto-héberger l’équivalent de dwservice.net, si?
D’ailleurs, la première fois que j’ai entendu parler de RustDesk, il me semble bien que le relais auto-hébergeable n’était PAS opensource, me trompé-je? ou bien ça a changé?
Autre solution alternative est DWagent, fourni par dwservice.net, gratuit, open source, multi-OS.
solution méconnue mais pratique et surtout très légère, ne reste pas en mémoire, une fois le client fermé, etc.
(je ne suis en rien affilé à… j’ai simplement découvert ce logiciel libre, bien pratique)
J ai utilisé quelque chose de similaire longtemps.
Mais au final, il failait aussi retenir l’url, bah oui ca fini par changer pour de petit site et puis le compteur par site, bah oui, il y a toujours un moment ou il faut changer le pwd.
Je ne recommande pas du tout. De nos jour on a de chouette gestionnaire comme http://passwordstore.org/ qui peuvent etre sur ses propres serveurs.
Oui et dans le cas où on utilise ce système parce que les applis qui tournent dessus ne sont pas encore migrées et qu’on a besoin d’outils à installer, ça peut toujours être utile.
Après dans le monde entreprise il y a plein de cas où des systèmes obsolètes tournent encore, le cloisonnement réseau via VLAN, parefeu, ou WAF dans le cas d’un applicatif rendent moins vulnérables des systèmes qui peut être complexes à migrer (soit techniquement, soit logiciellement, soit au niveau des moyens humains)
Je vois qu’il y a bien des h2 dans le code et tout mais visuellement il n’y a pas trop de formattage.
Les titres ne ressortent pas du texte, il n’y a d’espace entre les paragraphes. Là c’est plus niveau CSS qu’il faudrait trifouiller ;-)
Merci pour ton retour. Effectivement c’est pas super niveau visuel. Je ne suis pas très à l’aise avec le markdown, solution que nous avons choisi pour poster nos articles. J’ai essayé de remettre un peu en forme mais je reste très limité.
Hello,
Je suis en phase avec toi sur l’idée. Le souci est que les checks entropiques sont souvent coûteux en ressource, et je ne suis pas certain que ce soit simple à implémenter à l’échelle.
Par contre, il est clair qu’il faut simplifier et donner plus de liberté aux utilisateurs sur le choix de leurs mots de passe :)
Ne pas oublier non plus que la longueur du mot de passe peut compenser la complexité : tant de formulaires réclament quand même un chiffre ou un caractère spécial quand on propose un mot de passe de 128 caractères… l’idéal serait d’exiger une entropie minimale, mais c’est utopique. Il n’empêche que cela permettrait à chacun de proposer des mots de passe forts, avec moins de contraintes (complexité ou longueur).
Bonjour,
Chez nous, ou l’on gère un parc conséquent de machines (Plusieurs milliers sur presque des centaines de clients) on est obligé de faire simple et efficace pour s’y retrouver :
PAYS_REGION_ROLE_NUMEROINCREMENTAL
Par exemple pour un hyperv : CHGEHYV01 Pour un DC / FS : CHGEDC01 Pour un applicatif générique : CHLSAP01 Pour un backup : SGBCK01
CHGE (Suisse, Genève) CHLS (Suisse, Lausanne) SG (Singapour, on ne regarde pas la région, car on ne s’y déplace pas physiquement tous les 4 matins).
etc …
Parfois, on met le nom de l’applicatif directement dans le serveur, par exemple, dans un abacus en cluster : CHLSABA01 et CHLSABA02
Je voulais vraiment un truc super simple à mettre en place et sans maintenance, du coup j’ai préféré aller vers Stacks.
Une mise à jour majeur ça doit pas arriver tout les 4 matins, généralement ça dure plusieurs années. Donc bon, ça me parait carrément raisonnable comme prix ;)
Je l’ai rapidement testé, mais j’ai pas trop aimé l’ergonomie perso ^^
Ou sinon Wekan aussi opensource et très facilement déployable https://github.com/wekan/wekan
Mais payer 49€ pour CHAQUE mise à jour majeur, je trouve ça abusé de la part de Stacks !!!!
Sinon, y a Taiga https://www.taiga.io/ en licence MPL
Le nommage.
À partir d’un certain nombre de serveurs c’est totalement contre-productif d’utiliser des noms de dieux/héros/pays/others, qui va se souvenir que les dieux sont les serveurs PostgreSQL, les héros les serveurs web, etc.
On cherche tous à nommer les serveurs en précisant leur(s) fonction(s), il ne faut donc pas hésiter à faire simple : postgresql7, dns1, vpn2, dhcp1, ntp1… Le souci c’est qu’on peut avoir plusieurs applications/services sur un serveur, on perd le côté propre/logique dans le nommage. Bah ouais rien n’est parfait, il faut juste chercher à être le plus propre/logique pour le nommage et puis on fera avec.
Un S-L-T-BDD-PG01 serait chez moi TEST-PG01 parce que a/ On sait que c’est un serveur (implicite) donc je garde pas le S b/ Serveurs Linux la norme chez moi donc je garde pas le L c/ T (pour test) je garde, je garde pas PROD car c’est la norme d/ BDD je garde pas car PG01 donne l’info implicitement.
Vouloir préciser trop de choses dans le nom est une mauvaise idée d’après mon expérience, trop de changements possibles lors du cycle de vie d’un serveur. Par exemple foutre le nom de l’application ou du service genre GLPI, CIEL part du principe que ça ne changera pas. Je préfère COMPTA, RH…
Pour résumer : PST123, PRT456, TEST-WEB1, WEB1, DNS1, HY3, MYSQL8, POSTGRESQL4, SB-LTORVALDS (sandbox Linus Torvalds)…
Tcho !
Salute,
Pour plus de lisibilité, je commence par les abréviations.
J’ai horreur d’une seule lettre comme abréviation, je n’ai pas souvenir avoir vu des serveurs avec des abréviations sur une seule lettre. J’ai aussi une mauvaise mémoire et mon cerveau est pas très rapide, quand je vois S-L-T-WEB01 je dois faire un effort intellectuel car je n’arrive pas à “lire” directement.
Les abréviations que je préfère : PST pour poste, PRT pour portable, SRV pour serveur, LN pour Linux, NT pour Windows, VM pour machine virtuelle, SB pour sandbox (machine de tests en général pour les devs), HY pour hypervisor, BDD pour bases de données, WEB pour serveurs web, PROD, TEST.
La plupart du temps utiliser SRV est inutile car souvent on le sait, c’est implicite, SRV-DC01 serait DC01 chez moi. Souvent il y a une majorité de serveurs Windows ou Linux pourquoi leur mettre une abréviation ? Je ne mets une abréviation qu’à ceux qui ne sont pas de la majorité de serveurs ainsi si la majorité est du Windows je ne préfixe que les serveurs Linux. Pareil pour PROD je ne le mets pas car c’est la norme chez moi, je ne mets que TEST.
Tcho !
Pour info dernière release du 31/03/2021 et “PROJECT ON BREAK I’m looking forward to continue development some time in the future, but there will not be updates for the next few months” (https://github.com/jliljebl/flowblade).
Tcho !
Tiens. Perso, je fais différement et ça fonctionne aussi :
Dans le menu “Sécurité” de mon compte GMail, du fait d’avoir activé la 2FA, créer un pass par application et dans TB (ou autres clients mails), je remplis les infos SMTP, IMAP de Gmail, et dans le champ password lié à mon compte utilisateur, je mets celui relatif au “pass par application”, créé précédemment.
Le seul truc “casse-pied” est de devoir valider quasiment tous les jours le certificat TLS de Gmail.
Et, je n’ai pas configuré OAuth2.
Je peux me tromper, mais la dernière fois que j’ai regardé il n’était justement pas possible d’auto-héberger l’équivalent de dwservice.net, si?
D’ailleurs, la première fois que j’ai entendu parler de RustDesk, il me semble bien que le relais auto-hébergeable n’était PAS opensource, me trompé-je? ou bien ça a changé?
Autre solution alternative est DWagent, fourni par dwservice.net, gratuit, open source, multi-OS. solution méconnue mais pratique et surtout très légère, ne reste pas en mémoire, une fois le client fermé, etc.
(je ne suis en rien affilé à… j’ai simplement découvert ce logiciel libre, bien pratique)
Encore mieux. On va sur la page de release du dépôt voulu. On rajoute “.atom” à la fin de l’URL, et on a un flux RSS :) –> https://github.com/prometheus/prometheus/releases.atom
Un flux RSS VS des emails quand il s’agit d’infos du genre, je trouve ça beaucoup plus simple à gérer !
Merci, corrigé.
Tcho !
Mauvais lien ! Le bon: https://www.youtube.com/watch?v=yr0QkMXW1ZE
J ai utilisé quelque chose de similaire longtemps.
Mais au final, il failait aussi retenir l’url, bah oui ca fini par changer pour de petit site et puis le compteur par site, bah oui, il y a toujours un moment ou il faut changer le pwd.
Je ne recommande pas du tout. De nos jour on a de chouette gestionnaire comme http://passwordstore.org/ qui peuvent etre sur ses propres serveurs.
Oui et dans le cas où on utilise ce système parce que les applis qui tournent dessus ne sont pas encore migrées et qu’on a besoin d’outils à installer, ça peut toujours être utile. Après dans le monde entreprise il y a plein de cas où des systèmes obsolètes tournent encore, le cloisonnement réseau via VLAN, parefeu, ou WAF dans le cas d’un applicatif rendent moins vulnérables des systèmes qui peut être complexes à migrer (soit techniquement, soit logiciellement, soit au niveau des moyens humains)
Je vois qu’il y a bien des h2 dans le code et tout mais visuellement il n’y a pas trop de formattage. Les titres ne ressortent pas du texte, il n’y a d’espace entre les paragraphes. Là c’est plus niveau CSS qu’il faudrait trifouiller ;-)
Merci pour ton retour. Effectivement c’est pas super niveau visuel. Je ne suis pas très à l’aise avec le markdown, solution que nous avons choisi pour poster nos articles. J’ai essayé de remettre un peu en forme mais je reste très limité.