Avant de commencer
La protection des données dans le domaine RH en mode Saas (Software As A Service) est primordiale. Nous avons adopté depuis plusieurs années un processus d’amélioration continue dans ce domaine.
Vous trouverez ci-dessous toutes les dernières évolutions que Lucca a appliqué à la plateforme et à ses applications.
La protection des mots de passe
Dans le domaine du hachage et du stockage des mots de passe, les bonnes pratiques sont les suivantes :
- Utiliser un algorithme de hachage irréversible et lent
- Rendre unique le hachage en salant les mots de passe
- Ne pas accepter les mots de passe « simples »
Nous avons choisi un algorithme de hachage éprouvé et connu pour le paramétrage de la lenteur de chiffrage. La non réversibilité des mots de passe signifie qu’à partir du mot de passe chiffré (empreinte ou hash) stocké sur notre plateforme, il est impossible de retrouver le mot de passe d’origine. Un vol de ces données est donc inexploitable directement.
Nous avons ajouté du sel dans le processus. Ajouter du sel, c’est ajouter une clé qui nous est propre. En effet, l’algorithme de hachage est certes éprouvé, mais sans sel, les empreintes de mots de passe seraient exploitables avec l’utilisation des tables « rainbow ». Ces tables permettent de comparer les empreintes de mots de passe volées avec des empreintes préalablement générées. Grâce au salage, nos empreintes de mots de passe sont uniques.
Enfin, nous avons durci nos exigences en matière de complexité de mot de passe. Plutôt que de simplement exiger un nombre et une variété de caractères, nous calculons la complexité du mot de passe grâce à une librairie embarquée dans Lucca. C’est ce système qui permet d’afficher la dureté du mot de passe choisi lors de la saisie. Ceci dit, un minimum de 8 caractères est tout de même exigé.
Le chiffrement des e-mails
Il existe une version sécurisée de chaque protocole. Certains mieux connus que d’autres.
- https pour le http : correspond à l’activité principale de votre navigateur internet
- ftps ou sftp pour le ftp : ce protocole est utilisé pour le transfert de fichiers à des fins d’import ou d’export automatisés
- smtps ou smtp TLS pour le smtp : c’est la version sécurisée du protocole utilisé pour émettre des mails.
Nous utilisons depuis plusieurs années les versions sécurisées des protocoles ftp et http. Par contre, la version sécurisée du protocole smtp est moins connue et certains de nos clients (4%) ne sont pas compatibles.
Nous avons changé de serveur smtp pour être capable de s’adapter à chacun, en fonction de son niveau d’exigence. En effet, notre nouveau serveur SMTP négocie avec le serveur mail du client le plus haut niveau de chiffrement commun. Une fois la communication établie, nous émettons les mails par ce canal sécurisé. Pour nos clients non équipés, les mails sont envoyés de façon non sécurisée.
À l’occasion de cette mise en place, nous avons aussi amélioré notre réputation auprès des systèmes anti-spam.
Mise en place d’un WAF (firewall applicatif)
Le firewall applicatif est une protection permettant de se prémunir des attaques de type injection SQL. Cette attaque est toujours au rang 1 du classement des vulnérabilités de l’organisation OWASP.
Le WAF permet d’analyser les requêtes entrantes et de bloquer les attaques. Le paramétrage du WAF a été assez long à affiner pour réduire le taux de faux positifs (le blocage d’un usage normal) tout en gardant une protection optimale. Le WAF est donc configuré en liste blanche.
Nous détectons une tentative d’attaque par injection SQL en moins de 5 minutes.
Transmission des cookies uniquement en https
Nous avons appliqué une recommandation du rapport d’un audit de sécurité réalisé sur notre plateforme : bloquer le transfert des cookies lorsque le transfert est non sécurisé. En effet, lors du premier appel, il est courant que l’utilisateur ne saisisse pas le “s” dans l’adresse httpS://client.ilucca.net
S’il a déjà visité le site, il est probable qu’il ait des cookies de session.
Un cookie de session est une information nécessaire au bon fonctionnement d’une application web. Cette information est stockée sur l’ordinateur de l’utilisateur par son navigateur et transmise à notre serveur à chaque échange.
Cet échange est sécurisé si le protocole https est utilisé. Par contre, lors du premier appel, le cookie était envoyé de façon non sécurisé. Désormais, les cookies sont absents des échanges non sécurisés.
Pour aller plus loin, voici le lien vers le problème décrit par OWASP
Protection contre le clickjacking
Le clickjacking est une attaque qui consiste à intégrer un site dans un autre, via une iframe, de façon à masquer l’adresse du sous site.
Pour protéger nos clients de ce type d’attaque, nous avons suivi les recommandations d’OWASP en interdisant l’intégration de nos applications dans des iframes. En amont, nous avons détecté puis contacté l’ensemble des clients concernés par une telle intégration.
Pour aller plus loin, voici le lien vers le problème décrit par OWASP