Comment nous protégeons vos mots de passe

Dans les articles précédents, nous avons exploré comment HTTPS protège le trajet entre votre application et notre serveur et comment SSH sécurise le serveur lui-même. Il est maintenant temps de regarder à l'intérieur du serveur — comment Splync sécurise votre mot de passe une fois qu'il est arrivé. Si quelqu'un pouvait obtenir votre mot de passe, il pourrait se connecter à votre compte et accéder à des informations sensibles, y compris vos relevés de dépenses. C'est pourquoi Splync ne stocke jamais les mots de passe en clair. À la place, chaque mot de passe est transformé en une version hachée avant d'être enregistré dans la base de données. Qu'est-ce que cela signifie exactement ? Le hachage est une conversion à sens unique — une fois transformé, il ne peut jamais être reconverti en mot de passe original. Cette méthode est un standard sur internet, des banques aux grands services cloud, bien que beaucoup ignorent son fonctionnement. Explorons cela à travers une analogie simple du quotidien.

Pour comprendre comment fonctionne la protection des mots de passe, commençons par une méthode de hachage simple appelée SHA-256. Pensez-y comme à un blender qui mélange toujours les ingrédients de la même manière. Si vous mettez le même mot de passe dans le blender et appuyez sur le bouton, vous obtiendrez toujours le même smoothie unique — un mélange brouillé de lettres et de chiffres. L'idée clé est que le processus ne peut pas être inversé. Tout comme vous ne pouvez pas prendre un smoothie et le séparer en banane et lait d'origine, vous ne pouvez pas prendre le hachage brouillé et récupérer le mot de passe original.

SHA-256 est l'un des algorithmes de hachage les plus courants. Par exemple, il hache le mot de passe "splync1234" en "9cdafa20d069ecfb202e5f0bc937c73071cc6cd85634cc2d95d30ddcf2a71d41". En quelques millisecondes, chaque fois qu'un utilisateur existant entre un mot de passe de connexion, SHA-256 produit toujours le même mot de passe haché. L'application hache simplement à nouveau le mot de passe saisi et vérifie s'il correspond au hachage stocké. À aucun moment le système ne connaît le mot de passe original de l'utilisateur. Mais que se passe-t-il si un attaquant pré-calculait une liste de mots de passe courants et leurs hachages (connue sous le nom d'attaque par table arc-en-ciel) pour deviner rapidement les mots de passe des utilisateurs ? Cette inquiétude est bien réelle. C'est pourquoi les systèmes modernes, y compris Splync, ne se fient pas uniquement à SHA-256.

Bcrypt utilise un sel aléatoire par utilisateur et encode ce sel (et le facteur de coût) directement dans la chaîne de hachage stockée. Pensez à bcrypt comme à un blender avec une épice secrète (le sel) et un moteur lent (le facteur de travail) — il rend chaque mélange unique et plus difficile à copier. Étant donné que le sel est de 128 bits (≈3×10³⁸ possibilités), le même mot de passe peut correspondre à un nombre astronomique de hachages stockés différents. Cela rend les tables arc-en-ciel pré-calculées inutiles à grande échelle. Lors de la connexion, Splync lit le sel et le coût de la chaîne bcrypt enregistrée, exécute à nouveau bcrypt sur le mot de passe saisi avec ces paramètres et compare le résultat au hachage stocké. S'ils correspondent, le mot de passe est correct — mais parce que bcrypt est intentionnellement lent et que les sels sont uniques, les attaques par force brute deviennent beaucoup plus coûteuses pour un attaquant.

Voyons comment cela fonctionne en pratique. Si vous hachez le mot de passe "splync1234" avec bcrypt (en utilisant un coût de 12), vous pourriez obtenir une chaîne comme celle-ci : `$2b$12$gBeouKYdue9uvvuV0HtGgeVPymnrojMqP/wcRw28HFlGEGIQbyw7O`. Dans cette chaîne bcrypt, `$2b` indique la version de l'algorithme, `$12` indique le facteur de coût (combien de fois le mot de passe est traité), `gBeouKYdue9uvvuV0HtGgeV` est le sel aléatoire unique, et `PymnrojMqP/wcRw28HFlGEGIQbyw7O` est le mot de passe final haché. Comme le hachage lui-même contient le sel et le coût, Splync peut reproduire le même processus de hachage pour la vérification en extrayant ces valeurs de la chaîne enregistrée et en comparant le résultat. En revanche, si un attaquant ne connaît pas le sel et le coût, il ne peut pas construire une table arc-en-ciel unique qui fonctionne pour chaque utilisateur.

Cette approche a un autre avantage important. Parce que Splync ne stocke jamais de mots de passe en clair, même si la base de données était divulguée ou volée, les utilisateurs ne sont pas immédiatement en danger. Les attaquants ne peuvent pas se connecter directement avec les données volées, car ce qu'ils ont ne sont que des chaînes brouillées. Ce design offre aux utilisateurs une couche de protection supplémentaire, en plus des mesures de sécurité déjà en place autour du serveur lui-même. Le hachage des mots de passe n'est pas unique à Splync ; c'est la norme dans l'industrie technologique, utilisée par des géants comme Google, Apple et Amazon. Splync a été construit de manière très sécurisée, et il deviendra encore plus sûr à mesure que nous continuerons d'améliorer la sécurité avec des fonctionnalités telles que la vérification par e-mail, la protection contre la force brute et la surveillance continue.