C# – formule de Luhn

La formule de Lhun permet de vérifier un numéro de carte bleue, un siret, un siren, … tellement utile pour les contrôles de formulaire que je me suis penché sur la question ne trouvant rien de probant sur Internet.

La partie front :

Juste un formulaire pour envoyer le chiffre, rien de bien palpitant 🙂

La partie programmée :

Quelques remarques :

  • Bien penser à ajouter le using regularExpressions qui permet de simplifier grandement les choses avec le Regex. Entre autre je m’en sers pour convertir un string en array de chiffres à 1 digit > « 123 » => [1][2][3], pas trouvé mieux pour la méthode !
  • J’ai coupé le traitement en deux parties que vous visualisiez bien le fonctionnement, cela peut bien entendu être simplifié mais en cas de souci ça permet de vérifier les deux tableaux, le premier avec les digits, le deuxième avec les multiples de deux pour les colonnes impaires sauf pour la première colonne.
  • Par rapport à Wikipedia, il existe un cas particulier par rapport au SIRET de la poste que je n’ai pas traité dans ce cas ! Je verrai avec le temps si j’en ai besoin …

Quelques liens utiles :

https://fr.wikipedia.org/wiki/Formule_de_Luhn

https://portal.hardis-group.com/pages/viewpage.action?pageId=120357227

JQuery – Json : compte nombre d’occurrences

Une petite méthode simple et rapide pour compter le nombre d’occurrences identiques dans un array multi dimensionnel :

Retourne :
Nombre d’occurrences de new wave = 2

CQFD 🙂

Expiration certificat root Let’s Encrypt’s

De nombreux supports arrivent nous indiquant que le HTTPS ne fonctionne pas et qu’il nous faut mettre à jour le certificat. Cependant, le problème est bien plus complexe et ne dépend pas de notre volonté.

En effet, la vérification d’un certificat est un processus où l’ont remonte une chaine de confiance. Nous livrons un certificat lui même pointant vers un autre certificat d’une plus haute autorité et cela jusqu’à une autorité que le client (Edge, Mozilla, Firefox, Safari, Openssl, etc) saura reconnaitre comme de confiance.

Il faut noter que le client, s’il n’est pas mis à jour ne sera pas à jour des certificats de confiance et ne pourra donc pas identifier les certificats plus « modernes ».

Or, les certificats let’s encrypt pointent vers plusieurs certificats root dont l’un d’eux est obsolète à la date du 30 septembre 2021. Voici une explication de letsencrypt.org eux même :

https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/

letsencrypt.org nous informe qu’il faut mettre à jour les clients vers une version supportée où alors une alerte de sécurité sera émise par le client. Cela n’est pas un problème pour l’absolue majorité des clients qui tiennent leurs machines et systèmes à jour mais le devient si on utilise de vieux appareils, voici la liste de compatibilité :

https://letsencrypt.org/docs/certificate-compatibility/

Nous invitons tous nos partenaires à mettre à jour leurs systèmes, cela est d’autant plus important qu’ils s’exposent à des risque de sécurité important s’ils utilisent des outils et navigateurs obsolètes !


Configurer un vrai cron pour WordPress

Bonjour,

Ce petit tutoriel a pour vocation de configurer les crons WordPress manuellement afin d’éviter leur empilement qui peut être du à plusieurs problèmes dont des modifications au niveau des timezones ou tout simplement le code de WordPress qui n’est pas « thread-safe ».

La première étape consiste à supprimer l’automatisation de ce cron dans le fichier wp-config.php

L’étape suivante consiste à créer un cron pour l’url dans notre console d’infogérance RD serveur pour lancer automatiquement le cron par URL à la fréquence souhaitée (attention à ne pas lancer le cron par fichier).

Piqûre de rappel cybersécurité : Pegasus

Salutations,

Nous profitons de l’actualité pour faire un rappel en matière de cybersécurité.

Tout d’abord, Pegasus n’invente rien en matière de cyberattaque, tout ce que fait Pegasus existe déjà et cela depuis l’aube de l’internet, expliquons :

  • Exploitation des failles zéro-day :
    Il s’agit de failles qui ne sont pas encore documentées ni patchées. La cybersécurité a toujours reposé sur la découverte précoce et la mise à jour des failles par les « gentils » contre les « méchants ».
  • Logiciels invisibles :
    Les keyloggers et autres « joyeusetés » ont toujours existé et existeront toujours. Précisons qu’il est même possible pour des logiciels d’être totalement invisibles du système car hors du système lui-même, et ce depuis des décennies.
  • Fishing :
    il s’agit de l’ancien vecteur d’attaque par envoi de faux mails, sms, etc … et qui ne devrait pas inquiéter un utilisateur averti tel que vous !

Cependant, Il faut être rassurant, les attaques zéro-day coûtent très cher. Les failles se négocient parfois pour plusieurs millions et une simple attaque peut coûter des dizaines de milliers d’euros. Vos données en valent-elles ce prix ? Pour un site standard, il est beaucoup plus probable, et certain, de faire face à des attaques concernant des bugs connus et pour lesquelles il suffit d’être à jour.

Dès l’instant où une machine est connectée à internet, la cybersécurité ne repose pas sur l’établissement d’un verrou inviolable – car impossible – mais sur des comportements réduisant les risques et les données volées. L’effort fourni par les parties concernées doit être proportionnel à la valeur des données à protéger. Concernant le détenteur d’un hébergement, nous attendons de celui-ci qu’il respecte des règles élémentaires :

  • vos sites et applications doivent utiliser les dernières versions supportées et à jours des logiciels et systèmes (Ubuntu, Window server, php, mysql, aspx, wordpress, etc)
  • les mots de passes doivent être stockés de façon cryptée et il ne doivent pas être décryptable.
  • vos données doivent être backuppées afin qu’elles soient recouvrables en cas de destruction ou altérations.
  • l’envoi d’un mot de passe devrait se faire via un formulaire en https pour éviter une interception.

Enfin, il est important d’avoir conscience qu’un site internet vieillit et périme ! Afin d’éviter cela, il vous faut le mettre à jour régulièrement : au moins une fois par an.

Chez RDmédias, la sécurité de nos clients est importante ainsi chaque hébergement est à minima :

  • protégé par un pare-feu physique – doté des dernière technologies d’IPS et de ARBOR –
  • mis à jour 24h après la parution d’une mise à jour système
  • sauvegardé sur 7 jours
  • Nous n’acceptons pas moins !

Win Pro: SSL / Https Rating A+

Pour tester la sécurisation de votre site vous pouvez utiliser ce site :
https://www.ssllabs.com/ssltest/
Afin que vos résultats soient privés, veuillez cocher la case « Do not show the results on the boards » .

Une explication du Rating ce trouve ici (anglais) :
https://github.com/ssllabs/research/wiki/SSL-Server-Rating-Guide

Ce qui dépend de votre IIS sera principalement les « protocoles » et les « ciphers ».
Un outil permet de configurer cela simplement (download > gui) :
https://www.nartac.com/Products/IISCrypto/

Concernant les protocoles,
Seul TLS 1.2 et 1.3 ne sont pas obsolètes.
Il est à noter que IIS ne supporte pas TLS 1.3.

Concernant les ciphers,
Diffie-Hellman est obsolète.

Une configuration correcte en 1.2 est la suivante :


Pour obtenir la note de A+, il faudra un certificat en RSA 4096 bits ou plus.
Les certificats « Let’s Encrypt » sont par défaut en RSA 2048 bits ou RSA 3072 bits ce qui limite la note de la clef respectivement à 80% ou 90%.
Plus la clef est grande plus le protocole HTTPS en sera ralenti. Ce qui est gagné en « sécurité » est perdu en rapidité.

Pour obtenir du TLS 1.3 tout en gardant votre site Asp sur du IIS, nous proposons des serveurs de reverse proxy sous Ubuntu + Apache.

Comment vérifier vos certificats SSL

Ce tutoriel concerne le système Ubuntu et tous les systèmes utilisant openssl.
Note importante, par défaut les commandes openssl ne traitent que le premier certificat d’une chaine.

Vérifier que le certificat match avec la clef

Vérifier un certificat pem « fullchain »

Vérifier que les dates sont valides