Hoe we uw wachtwoorden beschermen

In eerdere artikelen hebben we besproken hoe HTTPS de verbinding tussen uw app en onze server beschermt, en hoe SSH de server zelf beveiligt. Nu is het tijd om binnenin de server te kijken — hoe Splync uw wachtwoord veilig houdt zodra het daar aankomt. Als iemand uw wachtwoord zou bemachtigen, zou die persoon kunnen inloggen op uw account en toegang krijgen tot gevoelige informatie, waaronder uw uitgavenoverzichten. Daarom slaat Splync wachtwoorden nooit in platte tekst op. In plaats daarvan wordt elk wachtwoord omgezet in een gehashte versie voordat het in de database wordt opgeslagen. Wat betekent dat precies? Hashen is een eenrichtingsconversie — eenmaal omgezet kan het nooit meer worden teruggezet naar het oorspronkelijke wachtwoord. Deze methode is standaard op het internet, van banken tot grote cloudservices, maar veel mensen weten niet hoe het eigenlijk werkt. Laten we het verkennen aan de hand van een eenvoudige dagelijkse analogie.

Om te begrijpen hoe wachtwoordbescherming werkt, beginnen we met een eenvoudige hashmethode genaamd SHA-256. Zie het als een blender die ingrediënten altijd op precies dezelfde manier mengt. Als u hetzelfde wachtwoord in de blender doet en op de knop drukt, krijgt u altijd dezelfde unieke smoothie — een rommelige mix van letters en cijfers. Het belangrijkste idee is dat het proces niet kan worden teruggedraaid. Net zoals je van een smoothie niet terug naar de originele banaan en melk kunt, kun je van de verwarde hash niet terug naar het oorspronkelijke wachtwoord.

SHA-256 is een van de meest voorkomende hashalgoritmen. Zo wordt het wachtwoord "splync1234" gehasht tot “9cdafa20d069ecfb202e5f0bc937c73071cc6cd85634cc2d95d30ddcf2a71d41”. In milliseconden levert elke keer dat een bestaande gebruiker een inlogwachtwoord invoert, SHA-256 altijd hetzelfde gehashte wachtwoord op. De app hasht simpelweg het ingevoerde wachtwoord opnieuw en controleert of het overeenkomt met de opgeslagen hash. Op geen enkel moment kent het systeem het originele wachtwoord van de gebruiker. Maar wat als een aanvaller een lijst met veelvoorkomende wachtwoorden en hun hashes vooraf berekent (bekend als een rainbow table-aanval) om snel wachtwoorden van gebruikers te raden? Die zorg is zeer reëel. Daarom vertrouwen moderne systemen, inclusief Splync, niet op simpele SHA-256.

Bcrypt gebruikt een willekeurige salt per gebruiker en codeert die salt (en de kostfactor) direct in de opgeslagen hashreeks. Denk aan bcrypt als een blender met een geheime specerij (zout) en een langzame motor (werkfactor) — het maakt elke mix uniek en moeilijker te kopiëren. Omdat de salt 128 bits is (≈3×10³⁸ mogelijkheden), kan hetzelfde wachtwoord worden gekoppeld aan een astronomisch groot aantal verschillende opgeslagen hashes. Dat maakt vooraf berekende rainbow tables op grote schaal nutteloos. Tijdens het inloggen leest Splync de salt en kosten uit de opgeslagen bcrypt-reeks, voert bcrypt opnieuw uit op het ingevoerde wachtwoord met die parameters en vergelijkt het resultaat met de opgeslagen hash. Als ze overeenkomen, is het wachtwoord correct — maar omdat bcrypt opzettelijk traag is en salts uniek zijn, worden brute-force aanvallen veel duurder voor een aanvaller.

Laten we eens kijken hoe dit er in de praktijk uitziet. Als u het wachtwoord "splync1234" hash met bcrypt (met kosten 12), krijgt u mogelijk een reeks zoals deze: `$2b$12$gBeouKYdue9uvvuV0HtGgeVPymnrojMqP/wcRw28HFlGEGIQbyw7O`. In deze bcrypt-reeks markeert `$2b` de algoritmeversie, `$12` toont de kostfactor (hoe vaak het wachtwoord wordt verwerkt), `gBeouKYdue9uvvuV0HtGgeV` is de unieke willekeurige salt, en `PymnrojMqP/wcRw28HFlGEGIQbyw7O` is het uiteindelijke gehashte wachtwoord. Omdat de hash zelf de salt en kosten bevat, kan Splync hetzelfde hashproces voor verificatie reproduceren door die waarden uit de opgeslagen reeks te halen en het resultaat te vergelijken. Aan de andere kant, als een aanvaller de salt en kosten niet kent, kunnen ze geen enkele rainbow table maken die voor elke gebruiker werkt.

Deze aanpak heeft nog een belangrijk voordeel. Omdat Splync nooit platte wachtwoorden opslaat, zijn gebruikers zelfs bij een gelekte of gestolen database niet onmiddellijk in gevaar. Aanvallers kunnen niet direct inloggen met de gestolen gegevens, omdat ze alleen verwarde reeksen hebben. Dit ontwerp biedt gebruikers een extra beveiligingslaag, bovenop de beschermingen die al rond de server bestaan. Wachtwoord hashen is niet uniek voor Splync; het is de norm in de technologie-industrie, gebruikt door giganten als Google, Apple en Amazon. Splync is zeer veilig opgebouwd en zal alleen maar veiliger worden naarmate we de beveiliging blijven verbeteren met functies als e-mailverificatie, brute-force bescherming en voortdurende monitoring.