“Les écoles publiques, les associations et les FabLab peuvent demander gratuitement une version Word de ce document, afin de l’adapter plus aisément à leurs besoins.”
Merci pour l'inscription. Le Courrier du hacker utilise les données librement accessibles du Journal pour en tirer les meilleurs liens, mais ce que je fais avec le Courrier est mon expression personnel et n'engage pas le Journal, qui est désormais un média bien implanté de la communauté du Logiciel Libre francophone :)
D'ailleurs, pourquoi tu as mis “Le courrier du hacker n'est pas affilié au Journal du hacker de quelque manière que ce soit.” ?
Je viens de m'inscrire :P
J'ai enfin réussi à choisir quel techno pour faire mon dev : Je ne voulais pas le faire en scala , trop lourd.
Finalement, je suis reparti sur du python3
Résultat : j'ai fait mon petit script (je vais le passer en daemon après) pour mettre à jour CachetHQ par rapport à l'état de services dans une base de service Consul
Le tout est sur framagit
Oui sauf que jusqu'à tout récemment, ma banque te bloque au bout de 3 accès et redonne l'accès à l'IP au bout de 30 minutes. Oui, l'IP. Je te laisse calculer le temps pour le forcer.
De la part des mêmes “‘spécialistes” qui m'ont forcé à prendre une carte à paiement NFC, on peut quand même les traiter de BRANQUIGNOLS.
Il y a quand même une très grande méconnaissance des mécanismes de sécurité que mettent en place les banques et de la sécurité d'une solution d'authentification.
Il fait mention du code pin à 4 chiffres, où il dit qu'il faut 15 millisecondes pour les avoir et recommande quelque chose de très long à la place. C'est vrai, seulement, encore faut-il pouvoir les tester toutes.
Premièrement, chaque banque met en place ses propres mécanismes de sécurité, il apparaît dés lors difficile de faire des généralités.
Deuxièmement, il faut posséder le login, qui lui peut-être extrêmement grand et reservé à cet usage ainsi que le mot de passe associé.
Troisièmement, même si l'on imagine qu'un pirate fasse une attaque par force brute sur un login random. Celui-ci sera bloqué au bout d'un nombre de tentative très court et d'un blocage du compte en ligne si dépassement d'un certain nombre de saisies de code erronées sur une période plus longue. Il apparaît tout de suite très difficile de tester un grand nombre de possibilités.
Dernièrement chose, certaines banques mettent en place des authentification forte avec possession d'un token RSA (ou assimilé) et utilisation d'un mot de passe banque propre à l'utilisateur et non modifiable. Il devient extrêmement difficile de trouver un login + mot de passe banque + mot de passe du token rsa générée ; sans compter les mécanismes de blocage en cas d'erreurs mis-en-place.
C'est pour cela que nos cartes bancaires ne nécessitent pas de mot de passe très long. Car au bout d'un très faible nombres d'erreurs, l'automate l'avale ou le compte est bloquée. Le mot de passe n'est pas le seul critère de sécurité à prendre en compte pour sécuriser un accès. ;)
A part ce petit bémol, c'est toujours intéressant d'avoir le pdv d'un pair sur la technologie.
“Les écoles publiques, les associations et les FabLab peuvent demander gratuitement une version Word de ce document, afin de l’adapter plus aisément à leurs besoins.”
Pourquoi Word… tristesse
“Il est donc approprié que la solution provienne d'une vieille entreprise fiable dans le domaine de la technologie : Microsoft.”
J ai arrêté la lecture la …
Le lien pour le site : http://rancher.com/rancher-os/
Un article en anglais qui le compare à d'autres : https://blog.codeship.com/container-os-comparison/
Merci pour l'inscription. Le Courrier du hacker utilise les données librement accessibles du Journal pour en tirer les meilleurs liens, mais ce que je fais avec le Courrier est mon expression personnel et n'engage pas le Journal, qui est désormais un média bien implanté de la communauté du Logiciel Libre francophone :)
Merci pour cet article dont l'analyse est édifiante !
D'ailleurs, pourquoi tu as mis “Le courrier du hacker n'est pas affilié au Journal du hacker de quelque manière que ce soit.” ? Je viens de m'inscrire :P
J'ai enfin réussi à choisir quel techno pour faire mon dev : Je ne voulais pas le faire en scala , trop lourd. Finalement, je suis reparti sur du python3
Résultat : j'ai fait mon petit script (je vais le passer en daemon après) pour mettre à jour CachetHQ par rapport à l'état de services dans une base de service Consul
Le tout est sur framagit
Se battre entre Varnish, Nginx et des infinis redirections entre différentes applis en PHP… haha. Puis un billet de blog quand même.
Voilà pour le lien. Après, on peut utiliser un service managé aussi, OVH propose du Graylog as a service.
Need lien pour Graylog ! Merci !
je vois ce type d'initiative se multiplier mais n'imagine pas une seconde participer à une seule. Vraiment.
C'est comment le code de BNP Paribas ne donne pas confiance ! Tiens, ça me rappelle mes 5mn de conf en 2012, ce qui ne nous rajeuni pas https://dascritch.net/post/2012/11/06/Live-at-Sud-Web-%3A-Testez-vos-recruteurs
parcours très très intéressant pour les entrepreneurs intéressés par le Libre
il est bien dommage que les politiques n'en n'aient pas plus conscience…
Et je m'en sers quasiment tous les jours !
avec du Journal du hacker dedans !
ouh mais je m'en vais vérifier ces 13 étapes sur mon blog moi :)
Oui sauf que jusqu'à tout récemment, ma banque te bloque au bout de 3 accès et redonne l'accès à l'IP au bout de 30 minutes. Oui, l'IP. Je te laisse calculer le temps pour le forcer. De la part des mêmes “‘spécialistes” qui m'ont forcé à prendre une carte à paiement NFC, on peut quand même les traiter de BRANQUIGNOLS.
Il y a quand même une très grande méconnaissance des mécanismes de sécurité que mettent en place les banques et de la sécurité d'une solution d'authentification.
Il fait mention du code pin à 4 chiffres, où il dit qu'il faut 15 millisecondes pour les avoir et recommande quelque chose de très long à la place. C'est vrai, seulement, encore faut-il pouvoir les tester toutes.
Premièrement, chaque banque met en place ses propres mécanismes de sécurité, il apparaît dés lors difficile de faire des généralités.
Deuxièmement, il faut posséder le login, qui lui peut-être extrêmement grand et reservé à cet usage ainsi que le mot de passe associé.
Troisièmement, même si l'on imagine qu'un pirate fasse une attaque par force brute sur un login random. Celui-ci sera bloqué au bout d'un nombre de tentative très court et d'un blocage du compte en ligne si dépassement d'un certain nombre de saisies de code erronées sur une période plus longue. Il apparaît tout de suite très difficile de tester un grand nombre de possibilités.
Dernièrement chose, certaines banques mettent en place des authentification forte avec possession d'un token RSA (ou assimilé) et utilisation d'un mot de passe banque propre à l'utilisateur et non modifiable. Il devient extrêmement difficile de trouver un login + mot de passe banque + mot de passe du token rsa générée ; sans compter les mécanismes de blocage en cas d'erreurs mis-en-place.
C'est pour cela que nos cartes bancaires ne nécessitent pas de mot de passe très long. Car au bout d'un très faible nombres d'erreurs, l'automate l'avale ou le compte est bloquée. Le mot de passe n'est pas le seul critère de sécurité à prendre en compte pour sécuriser un accès. ;)
A part ce petit bémol, c'est toujours intéressant d'avoir le pdv d'un pair sur la technologie.
Mirabellette