Wat is een cryptografische “ salt ”?

De reden dat salts worden gebruikt, is dat mensen de neiging hebben dezelfde wachtwoorden te kiezen, en helemaal niet willekeurig. Veel gebruikte wachtwoorden zijn er zijn korte echte woorden, om het gemakkelijk te onthouden te maken, maar dit maakt een aanval mogelijk.

Zoals u wellicht weet, worden wachtwoorden over het algemeen niet opgeslagen in leesbare tekst, maar eerder gehasht. Als u niet zeker weet wat het doel van een hash-functie is, lees dat dan eerst.

Wat de aanvallers nu kunnen doen, is gewoon een lijst met veelvoorkomende wachtwoorden en hun bijbehorende hashes genereren. door de hashes te gebruiken die een site bij de tabel heeft opgeslagen, worden de wachtwoorden aan de aanvaller onthuld als er algemene wachtwoorden worden gebruikt.

A salt wordt gewoon toegevoegd aan maak een wachtwoord-hash-uitvoer uniek zelfs voor gebruikers algemene wachtwoorden gebruiken . Het doel is om op pre-computation gebaseerde aanvallen niet nuttig te maken. Als uw wachtwoord is opgeslagen met een uniek salt, zal een vooraf berekende wachtwoord-hashtabel die zich richt op ongezouten wachtwoordhashes of op een account met een andere salt niet helpen bij het kraken van het wachtwoord van uw account. Een lange willekeurig gegenereerde salt (met /dev/urandom) is naar verwachting wereldwijd uniek . Zouten kunnen dus worden gebruikt om pre -computation-aanvallen totaal ineffectief.

De eenvoudigste manier om de salt en het wachtwoord te combineren, is door ze eenvoudig samen te voegen, dwz de opgeslagen hash-waarde is Hash(salt||password). wachtwoord password1 wordt nu op magische wijze bijv. 6$dK,3gCA%Jpassword1 die waarschijnlijk niet in de tabel van een wachtwoordkraker wordt gevonden.

De salt kan volledig onzichtbaar in de database worden opgeslagen, naast de gehashte waarde. Zodra de aanvaller de database heeft en de wachtwoorden wil vinden, moet hij de vooraf berekende tabel voor elke salt afzonderlijk genereren, een kostbare operatie.

Een andere manier om te helpen verdedigen tegen het offline kraken van wachtwoorden is door uit te voeren wachtwoord uitrekken, dwz. een wachtwoord-hash langzamer maken om te berekenen voor elke persoon, inclusief de inlogservice en wachtwoordkrakers. Een methode die wordt gebruikt om wachtwoorden uit te rekken, wordt bereikt door de hash-functie vele malen te herhalen, d.w.z. Hash(Hash(Hash(Hash…(Hash(salt||password)))…) opslaan.

Een ander algemeen idee met betrekking tot zouten wordt een peper genoemd. Dat wil zeggen, een andere willekeurige waarde die is samengevoegd met het wachtwoord, zodat de opgeslagen waarde Hash(pepper||salt||password) is. De peper wordt dan helemaal niet opgeslagen . Zowel de login-server als de wachtwoordcracker moeten de onbekende pepper-waarde brute kracht geven, waardoor de hash-vergelijking van wachtwoorden voor beide partijen wordt vertraagd.

Van 2013 tot 2015 een wachtwoordhashing wedstrijd werd gehouden om te zoeken naar een beter algoritme voor het uitrekken van wachtwoorden. De winnaar was het Argon2 algoritme. Programmeurs wordt aangeraden om Argon2 te gebruiken in plaats van hun eigen algoritme te implementeren.

Reacties

• Dus als je maar één of twee wachtwoorden in de database hebt opgeslagen, is het gebruik van salt eigenlijk nutteloos? Wat ik begrijp is dat dit alleen nuttig is als het aantal wachtwoorden dat in de database is opgeslagen niet klein is.
• @AbhinavChoudhury: Nee, het verdedigt zich tegen regenboogtabellen – d.w.z. vooraf berekende tabellen voor een specifieke hash. Een voorbeeld: neem een wachtwoord ” wachtwoord1 “. Als u ‘ t salt niet doet, ‘ slaat u HASH op (” wachtwoord1 “) in uw database. Als een aanvaller nu uw gegevens krijgt en HASH (*) voor alle wachtwoorden van 9 tekens heeft berekend, kan hij het wachtwoord herstellen. Als je in plaats daarvan het wachtwoord hebt gezouten, HASH (‘ somesaltforyou ‘ || ‘ wachtwoord1 ‘) zal NIET in de regenboogtabel van de aanvaller staan (aangezien deze ‘ meer dan 9 tekens bevat).
• ” De salt kan volledig in de clear in de database worden opgeslagen, naast de gehashte waarde ” – – dit deel is voor mij nooit echt logisch geweest; Ik vroeg me af of je dat zou kunnen uitbreiden.
• Het punt van het zout is om ervoor te zorgen dat de hasj niet in een vooraf berekende tabel wordt gevonden. Het moet worden opgeslagen om het wachtwoord te verifiëren (anders ‘ sa ” pepper “). De salt mag niet ” geheim ” zijn, alleen om het wachtwoord uniek te maken. Dit betekent natuurlijk dat elk opgeslagen wachtwoord zijn eigen, unieke (en willekeurige) salt moet hebben.

Kun je me helpen begrijpen wat een cryptografisch “zout” is?

In de context van een wachtwoord creatie is een “salt” gegevens (willekeurig of anderszins) die aan een hash-functie worden toegevoegd om de gehashte uitvoer van een wachtwoord moeilijker te kraken te maken.

Wanneer moet ik het misschien gebruiken?

Altijd.

Waarom zou ik het wel of niet moeten gebruiken?

Je moet altijd een salt-waarde gebruiken met je hash-functies, om redenen die hieronder worden uitgelegd.

Het is over het algemeen waar dat mensen zwakke wachtwoorden kiezen, en het is zeker waar dat er gigabytes aan publiekelijk beschikbare regenboogtabellen zijn, boordevol gehashte waarden die ze vertegenwoordigen. Dus wanneer iemand een account op uw service aanmaakt en een wachtwoord selecteert om zijn identiteit te beveiligen, kunt u er meestal zeker van zijn dat het wachtwoord dat hij kiest 1) algemeen, 2) onveilig en 3) beschikbaar is voor kruisverwijzing in opzoektabellen.

Het wachtwoord Nowayin1 wanneer gehasht via MD5 is bijvoorbeeld 6f367d65bc74b88e21fb9959487ffa3a en is duidelijk geen goede keuze. Zelfs als het er goed uitziet (en dat is het niet), maakt het feit dat de MD5-hash van het wachtwoord in open databases verschijnt het waardeloos.

Maar dat is slechts 128-bit MD5. Hoe zit het met iets? sterker, zoals SHA1 (160-bit) of zelfs Whirlpool (512-bit)?

Hetzelfde probleem.

Bijvoorbeeld P @ $$ word met SHA1 is 1e69e0a615e8cb813812ca797d75d4f08bdc2f56 en 1qazXSW @ gehashte met Whirlpool wil 0bf7545b784665d23b9c174ca03688a405f05b048e9d6c49bfc2721a1fa872bbd6576273d002e56d7c2a9c378efe607af36eea9d708a776e6f60ecb26e081cdf .

Het kernprobleem met al deze wachtwoorden, en miljarden meer zoals deze, is het feit dat hun veelgebruikte hashes algemeen bekend zijn geworden.

Een wachtwoord salt verandert dat.

Als een willekeurige waarde (de salt) werd toegevoegd aan het door de gebruiker geselecteerde wachtwoord, dan zou de SHA1-hash 1e69e0a615e8cb813812ca797d75d4f08bdc2f56 P @ $$ niet meer weergeven als het wachtwoord van de gebruiker, omdat de hash-waarde in de regenboogtabel er niet langer mee overeenkomt.

En er is niet veel voor nodig. Een kleine willekeurige waarde van 16 bits zou bijvoorbeeld 65.536 varianten opleveren van elke gehashte waarde in de opzoektabellen. Dus een database met 15 miljard ingangen zou nu meer dan 983 miljard hashes nodig hebben om het zout te verklaren.

Dus dat is het punt van het zouten van je hashes, om opzoekingen en regenboogtabellen te dwarsbomen. Maar don “Hang je hoed niet aan een gezouten hash, want hackers zullen” niet veel tijd verspillen aan het gebruik van regenboogtabellen om je wachtwoorden te achterhalen.

Ze “gebruiken een vijf-servers 25-GPU clustersysteem met Hashcat dat 350 miljard keer per seconde krakende hashes kan verbranden voor elk denkbaar wachtwoord van acht tekens dat hoofdletters en kleine letters, cijfers en speciale tekens bevat, in net onder zes uur. (En dat was in 2012.)

Technieken zoals key-stretching die ervoor zorgen dat hashes langzamer werken, kunnen worden gebruikt om de snelheid van dergelijke hardware te compenseren, waardoor woordenboek- en brute-force-aanvallen te traag worden om de moeite waard te zijn , maar hardware wordt steeds sneller en sneller.

UPDATE 2018:

Huidige best practices zijn onder meer het veilig hashen van uw wachtwoorden met Argon2i (voorkeur boven scrypt), een geheugen-harde functie die zeer veerkrachtig voor FPGAs, multiplecore GPUs en speciale ASIC-modules die worden gebruikt om gemakkelijk niet-uitgerekte wachtzinnen te kraken. In de PHP7 implementatie van Argon2, wordt de salt intern voor je afgehandeld.

Ik ga proberen een deel van je vraag te beantwoorden dat tot dusver is genegeerd:

wanneer ik het misschien moet gebruiken en waarom ik het wel / niet moet gebruiken.

Het korte antwoord is dat je als amateur geen cryptografie zou moeten gebruiken op een niveau waarbij je direct met salts moet omgaan.

Bijvoorbeeld de bcrypt wachtwoord-hash-algoritme maakt intern gebruik van salts. Maar het onthult dat feit niet aan ontwikkelaars die het gebruiken – je geeft het wachtwoord gewoon door aan bcrypt (en optioneel een parameter die het “niveau van CPU-inspanning “nodig om de hash te genereren) en het retourneert de hash. Als u moet valideren of een wachtwoord correct is, geeft u bcrypt zowel het wachtwoord als de eerder gegenereerde hash door. Het geeft aan of het wachtwoord al dan niet het wachtwoord was dat werd gebruikt om de hash te genereren.

niet volg het advies dat hier wordt gegeven en probeer je eigen wachtwoorden te hashen met een salt. Het is een implementatiedetail op laag niveau, en als je merkt dat je op een niveau werkt waar dit soort dingen nodig zijn, werk je op een veel te laag abstractieniveau. Cryptografie is erg moeilijk om correct uit te voeren, en het internet is absoluut bezaaid met goedbedoelende ontwikkelaars “volledig onveilige, zelfgekweekte wachtwoordhash-schemas.

Citeren ” Examen ref. 70-486 Ontwikkeling van ASP.NET MVC 4 webapplicaties (MCSD): ontwikkeling van ASP.NET MVC 4 webapplicaties “ door William Penberthy, Pearson Education, 15 september 2013:

Salting is een proces dat bestandscodering en hashes versterkt, waardoor ze moeilijker te doorbreken zijn. een willekeurige tekenreeks aan het begin of einde van de invoertekst voordat de waarde wordt gehasht of versleuteld. Bij het kraken van een lijst met wachtwoorden moeten hackers bijvoorbeeld rekening houden met de salt en met mogelijke wachtwoordinformatie voordat ze kunnen breken in de app. Als aan elke waarde die wordt gezouten een andere zoutwaarde wordt toegewezen, is het mogelijk om een tabel met mogelijke wachtwoordwaarden voor een pa ssword-cracking-programma wordt onpraktisch.

Een zout is een willekeurig getal dat nodig is om toegang te krijgen tot de gecodeerde gegevens, samen met het wachtwoord.

Als een aanvaller het wachtwoord niet kent en het probeert te raden met een brute-force-aanval, dan zal elk wachtwoord dat hij probeert moet bij elke zoutwaarde worden geprobeerd.

Dus voor een one-bit salt (0 of 1) maakt dit de versleuteling twee keer zo moeilijk om op deze manier te breken. Een twee bit salt maakt het vier keer zo hard, een drie bit salt acht keer zo hard, etc. Je kunt je voorstellen hoe moeilijk het is om wachtwoorden te kraken met encryptie die een 32-bit salt gebruikt!

Opmerkingen

• Nee. Meestal wordt aangenomen dat zout bekend is bij de aanvaller. In dit geval, voorbij een bepaalde lage drempel, verbetert salt de beveiliging niet.
• ” Salt wordt gewoonlijk verondersteld bekend te zijn bij de aanvaller ” – > Wie neemt dit aan?
• @Mike: Wie? Iemand zegt ” Je moet er altijd van uitgaan dat de aanvaller het zout kent. “. Mensen op een andere pagina zeggen ” Zouten zijn openbaar “, en zegt later ” de salts zijn bekend, omdat ‘ het industriestandaard gebruik van het woord salt is. ” Een andere zegt ” het zout is algemeen bekend, of moet in ieder geval als openbaar worden behandeld kennis. “.