Gegevens van 550.000 leden crackinggemeenschap Nulled liggen op straat

Vorige week blijkt de database met gebruikersinformatie van Nulled gehackt te zijn, waardoor de gegevens van bijna 550.000 gebruikers online staan. Nulled is een community waar leden cracks kunnen delen.

De website van Nulled, normaal gesproken bereikbaar via onder andere Nulled.io of Nulled.to, is onbereikbaar. De database die is buitgemaakt, wordt via verschillende hackfora, waaronder siph0n, verspreid. Het gaat om een gecomprimeerd bestand van 1,3GB en eenmaal uitgepakt neemt het sql-bestand 9,45GB in beslag.

In het bestand staan gebruikersgegevens als e-mailadressen en ip-adressen, maar ook honderdduizenden privéberichten van gebruikers, volgens Troy Hunts 'Have i been pwned'. Daarnaast zou het om md5-hashes van wachtwoorden gaan die gesalt zijn.

De hack wordt opgeëist door een Roemeense groep met de naam Smurfs.gg. Die blijkt op 24 april de website gedefaced te hebben en onder andere de tekst 'All your data belongs to Romania' geplaatst te hebben. Uit berichten op Nulled van die dag blijkt dat users dachten dat alleen de Shoutbox getroffen was en de database veilig was.

Reacties (116)

[Tiny]

"Daarnaast zou het om md5-hashes van wachtwoorden gaan die gesalt zijn."

Gesalt? wat houdt dat in?

Verder best lullig voor een Cracker Community om gecrackt te worden.... Karma?

[dehardstyler]

Gesalt kan je zien als een soort extra hash ( random bits ) over de wachtwoorden heen. Als er in een hele grote lijst met gehashde wachtwoorden buit gemaakt wordt zonder salt, en 10 mensen in die lijst hebben als wachtwoord "Qwerty12345", zal bij allemaal de password hash hetzelfde zijn. Het "salten" van wachtwoorden voorkomt dit, en zorgt ervoor dat er bij elk wachtwoord ( ook al zijn ze precies hetzelfde ), toch een andere hash gebruikt wordt.

[Verwijderd]

Niet per se. Als je statische salt (dus voor iedereen hetzelfde) toevoegt dan zullen alle gebruikers met wachtwoord Qwerty12345 alsnog dezelfde hash hebben. Zolang je de salt niet weet blijft de hash 'veilig'. Echter, als je ziet dat 10 mensen dezelfde hash hebben dan kan je er de donder op zeggen dat het niet een complex wachtwoord is. Je kan het wachtwoord niet per se decrypten maar weet wel dat het 1 van de 100 meest gebruikte wachtwoorden is. Een alternatief is inderdaad een dynamische salt, die is voor iedereen anders.

[Chrono]

Als je salt doe je het hopelijk ook met random salts. Anders heeft het gebruik alsnog weinig zin.

Vind het ook wel slecht dat er MD5 hashes gebruikt worden. Zeker voor een cracker community waar toch de kennis wel aanwezig moeten zijn om wachtwoorden op een fatsoenlijke manier te hashen.

[Verwijderd]

Ik denk dat een statische salt zeker nog enige zin heeft. Zonder salt kan de hash van een veelgebruikt wachtwoord simpelweg in een tabel worden opgezocht. Het wachtwoord Password123 geeft een bekende hash en kan zo worden uitgelezen.

Ik snap de voordelen van een random salt code, maar ik vraag me af hoe de verificatie van de gebruiker dan in z'n werk gaat. Als hij inlogt met zijn wachtwoord, levert dat een andere hash op dan op het moment dat hij zijn wachtwoord aanmaakte. Hoe verifieer je dit dan?

edit:
ik denk dat het antwoord te halen is uit het stuk van @iceblink hieronder. Er is dus geen sprake van eenmalige random salts. Deze zijn mogelijk aan de user gebonden, wellicht dan als (salted) hash van de username of email. Als aparte waarde in de database bij de user lijkt me het paard achter de wagen spannen.

Zit je alleen met het wijzigen van een gebruikersnaam of email adres.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 06:34]

[Belgar]

hash van (password + username)
hash van (password + timestamp van eerste login)
hash van (password + hash van password) (met ander hashing algoritme uiteraard)

Al deze feiten zijn redelijk uniek en kun je weer terugvinden uit andere informatie die je al hebt van een unieke user.

[Rafe]

Het is niet erg dat een salt bekend raakt bij het lekken van een database. In plaats van deze 'slimmigheden' is het beter om een random waarde te generen van voldoende lengte zodat je niet per ongeluk eenzelfde salt hergebruikt. Dan zou het brute forcen weer net even makkelijker maakt.

Een ander nadeel is dat je dit zelf zou moeten programmeren. Zelfs als je een expert bent is het aan te raden bestaande en bewezen tooling te gebruiken (bijv. PHP) die het salten en vergelijken van input met de opgeslagen hash (ooit gehoord van timing attacks?) goed voor je regelen.

[? ?]

De eerste die een timing attack kan uitvoeren via het internet, krijgt een koekje van mij...

Zonet in C# code getest (lokaal op mijn pc) en timing attacks ga je alvast niet uitvoeren tegen C# string compares. Misschien in andere talen, maar ik geloof er niks van.

Trouwens, in de praktijk maakt het niks uit: http://stackoverflow.com/...nerable-to-timing-attacks

[Reactie gewijzigd door ? ? op 23 juli 2024 06:34]

[Verwijderd]

Ik weet vrij zeker dat ook c# standaard string comparison vuln is voor timing attacks, een comparison kan namelijk bij de eerste bit die ongelijk is gewoon afgebroken worden omdat het resultaat dan bekend is. Waarom zou je meer werk doen dan dat nodig is? (optimalisatie) Vaak is de enige manier om veilig strings te vergelijken met een XOR-mask zodat je forceert dat elke comparison altijd alle bytes vergelijkt.

Also, timing attacks via internet zijn prima mogelijk, het kost je wel wat moeite en is vaak lokaal of op een LAN makkelijker, maar zeker niet onmogelijk: https://www.blackhat.com/...cks-Made-Practical-wp.pdf

[Reactie gewijzigd door Verwijderd op 23 juli 2024 06:34]

[? ?]

Ik heb het getest, de JIT compiler rekent vooraf. (ik testte niet met input, maar met string waarden, dat zou nog meer moeten opvallen.)
De ene keer duurt een ongelijke waarde langer, de andere keer een gelijke waarden, de volgende keer is het omgekeerd.
De foutenmarge was groter dan het te meten effect.
Kan je zelf makkelijk proberen. Meet gewoon de ticks dat een compare bewerking nodig heeft. Bij mij duurde het tussen de 10000 en 30000 ticks = (100-300 nanoseconden).
Er zat geen lijn in, dus totaal onbruikbaar voor C#/ASP.NET.
Edit
Uit je document:

Note that we did not include any string comparison operations in our research. This was
intentional, since previous researchers have made it clear that measuring these remotely is
almost certainly impractical in the vast majority of cases.

Ik zou het dus met MSSQL moeten uitproberen. Gewone string compares gaan je niet helpen.

[Reactie gewijzigd door ? ? op 23 juli 2024 06:34]

[robvanwijk]

De foutenmarge was groter dan het te meten effect. [..]
Er zat geen lijn in, dus totaal onbruikbaar

Nee, dat mag je niet zomaar zeggen!

Stel, ik geef jou twee dobbelstenen, eentje met de waarden 1, 2, 3, 4, 4, 4 en eentje met de waarden 1, 1, 1, 2, 3, 4. Het gemiddelde van die eerste (3) is hoger dan het gemiddelde van die tweede (2), maar de marge (1-4) is groter dan dat verschil (3-2=1).

Gooien met de eerste dobbelsteen staat voor een trage string compare (eerste teken komt overeen), gooien met de tweede dobbelsteen staat voor een snelle string compare (eerste teken komt niet overeen).

Als ik je honderd keer laat gooien, elke keer met dezelfde dobbelsteen (honderd keer hetzelfde password proberen), dan heb ik een zeer grote kans om goed te kunnen raden met welk van de twee stenen je aan het gooien was!

Voor de volledigheid, het is belangrijk dat op allebei dezelfde getallen staan. Als we één steen gebruiken met 1 t/m 6 en eentje met 2 t/m 7 dan is het veel makkelijker om te wachten op de eerste 1 of 7 en het meteen zeker te weten. De enigszins vreemde verdeling dient ervoor om die truc te voorkomen. Bij een string compare (plus network latency) zou zo'n aanpak immers ook niet werken.

[jaapzb]

Die random salt sla je gewoon op naast de hash in de database. Zo'n salt zorgt er alleen maar voor dat een hash niet opgezocht kan worden in een rainbow table. Het maakt niet zoveel uit dat de hacker weet wat de salt is.

[Chrono]

Een salt is helemaal niet bedoeld om geheim te zijn. Het doel van de salt is unieke hashes te krijgen voor dezelfde wachtwoorden. Hierdoor worden rainbow tables waardeloos omdat er per hash een nieuwe tabel zou moeten worden gemaakt.

Ik haal niet echt uit het stuk van iceblink dat er usernames of mail adressen worden gebruikt. Dat zouden dan trouwens geen salts zijn maar dat ik het toevoegen van Pepper aan de hash.

Een salt is random data. Niks meer, niks minder. Je gebruikt geen statische salt omdat het nauwelijks extra moeilijkheid toevoegt aan het kraken van het wachtwoord.
Ook is het niet nodig om de salt geheim te houden en kun je die gerust naast het wachtwoord plaatsen.

Als je pepper gebruikt is het makkelijk om wijzigingen in namen en adressen af te handelen. Je vraagt simpelweg het wachtwoord van de gebruiker op het moment dat deze de wijzigingen wil bewaren. Op dat moment kun je de oude gegevens controleren en direct een nieuwe hash genereren met de nieuwe.

[THA_ErAsEr]

Waarom zou een statische salt geen toegevoegd waarde hebben? Als ik aan jou paswoord 'Azerty' een salt toevoeg zoals 'MijnSterkPaswoordIs' -> 'MijnSterkPaswoordIsAzerty', dan zie ik niet in hoe jij een rainbow tabel gaat vinden die je kan gaan gebruiken.

Ook, waarom een salt niet geheim zou zijn is mij een raadsel. Als je uniek salt bekend is ga je veel simpeler een wachtwoord kunnen achterhalen dan bij een statisch salt dat onbekend is.

[Donool]

Aanvulling: er wordt in dit geval gebruik gemaakt van een unieke salt per user van 5 tot 7 karakters met speciale tekens.

[R-J_W]

Een bron is hierbij gewenst.

[Donool]

Begrijp ik, mag hier alleen niet linken naar de database dump denk ik..

[Verwijderd]

Dient om brute-forcen moeilijker te maken, er van uitgaande dat de salt voor elke user verschillend is natuurlijk

https://nl.wikipedia.org/wiki/Salt_(cryptografie)

[ACM]

Het is niet zozeer bedoeld om brute forcen moeilijker te maken. Puur het doorrekenen van een wachtwoord-hash zal er nauwelijks trager van worden.

Het is vooral bedoeld om ervoor te zorgen dat het resultaat van het brute forcen van die ene wachtwoord-hash niet bruikbaar is voor andere accounts die exact hetzelfde wachtwoord gebruiken.

Daarnaast heeft het nog wat bijkomstige voordelen, zoals dat je ook niet zonder een brute force kan herkennen dat meerdere personen hetzelfde wachtwoord hebben. Als je bijvoorbeeld bij ongesalte hashes ziet dat een bepaalde hash heel vaak voorkomt, dan is het interessant om te kijken of dat wellicht '123456' of 'qwerty' is
Het feit dat een brute forced resultaat niet herbruikbaar is, betekent automatisch ook dat rainbow tables onbruikbaar zijn.

Uiteindelijk zorgt een salt dus vooral dat het simultaan brute forcen van meerdere hashes - en het hergebruiken van eerdere resultaten (zoals rainbow tables) - moeilijker wordt.

[Patriot]

Het is vooral bedoeld om ervoor te zorgen dat het resultaat van het brute forcen van die ene wachtwoord-hash niet bruikbaar is voor andere accounts die exact hetzelfde wachtwoord gebruiken.

Doel je op de reeds gegenereerde hashes en bijbehorende plaintexts (dus een rainbow table), of is er nog een ander resultaat van de bruteforce waar ik geen weet van heb?

[ACM]

Ik weet iig twee manieren om resultaten van brute force te hergebruiken:
- In een bestand opslaan om die als rainbow-table te kunnen gebruiken
- Elke brute force hash tegen een hele reeks password hashes testen ipv slechts één

De brute force crackers die ik een keer geprobeerd heb ondersteunden zowel het uitvoeren van een brute force aanval op één hash tegelijk en juist op een hele reeks hashes.

Die laatste modus is uiteraard veel sneller als je uit een verzameling password hashes zoveel mogelijk wachtwoorden wilt kraken, maar het je eigenlijk niet kan schelen welke accounts dat dan precies zijn.
Maar dat werkt dus alleen als ze allemaal dezelfde of helemaal geen salt hebben. Zodra de salts uniek zijn is dat onbruikbaar en zal er een losse brute force aanval per hash uitgevoerd moeten worden.

[iceblink]

Normaal wordt je wachtwoord ge-encrypt en dan in de database opgeslagen:
password ---encryption-method--> encrypted_text

Bij een goede encryptie-methode is dit eenrichtingsverkeer, dus je kunt het password niet terughalen als je de encrypted text hebt. Dit noemt men "asymmetrische" encryptie, dit kan door onderweg wat informatie weg te gooien. Je kunt alleen een ingegeven password weer coderen en het resultaat vergelijken met wat in de database staat.

Het encrypten moet een redelijk dure berekening zijn, zodat het proberen van allerlei passwords een erg langdurige bezigheid is.

Toch kan je je voorstellen dat er mensen allerlei passwords gaan coderen met veelgebruikte encryptie-methodes, en op die manier tabellen aanleggen waardoor je toch vanuit de encrypted_text terug kan naar het password. Dat noemt men rainbow-tables. De voornaamste beperking hierbij is dat zo'n tabel erg groot kan worden, naarmate de passwords langer worden en meer bijzondere tekens bevatten. Maar als je een lijstje hebt van de meest-gebruikte passwords kom je al een heel eind.

Om dat te omzeilen wordt een salt gebruikt. Dit is een extra stukje tekst dat bij het password wordt gevoegd. Je krijgt dan:

"password+salt" ---encryption-method--> encrypted_text

De aanvaller is nu gedwongen om een nieuwe rainbow table te maken met het gebruikte salt, als hij passwords wil terugzoeken. Hij moet dan wel eerst het salt zien te achterhalen. Dat is lastig maar niet onmogelijk.

Om het de aanvaller nog lastiger te maken kan je het salt varieren voor elk opgeslagen password. Het salt wordt dan per gebruiker opgeslagen in de database. De aanvaller kan dan geen rainbow tables meer gebruiken, of hij moet voor elk salt (dus voor elke gebruiker) een nieuwe rainbow table maken. Niet onmogelijk, maar de grootte van zijn rainbow table zal dan dus niet erg groot kunnen zijn.

Eigenlijk is het dus net als bij het beveiligen van je huis: je moet het de inbrekers zo lastig mogelijk maken. Hoe langer hij er over doet, hoe eerder hij de moed op zal geven en op zoek zal gaan naar een makkelijkere prooi.

[Dutchy_]

Je verhaal klopt grotendeels, maar je maakt ook grote fouten:

1. Hashing is geen encryptie, het origineel is namelijk niet terug te halen
2. Asymmetric encryption is NIET hetzelfde als hashing: https://en.wikipedia.org/wiki/Public-key_cryptography

[iceblink]

Ik heb het woord hashing niet genoemd, maar na enig leeswerk begrijp ik dat encryptie altijd betekent dat decryptie mogelijk is, dus ik neem aan dat je valt over mijn gebruik van het woord encryptie? Mea culpa!

[Dutchy_]

Ja, je zegt ook dat wachtwoorden encrypted worden opgeslagen; ook daar bedoelde je gehasht.

[robvanwijk]

Naast de correcties van Dutchy_, nog wat extra aanvullingen.

Toch kan je je voorstellen dat er mensen allerlei passwords gaan coderen met veelgebruikte encryptie-methodes, en op die manier tabellen aanleggen waardoor je toch vanuit de encrypted_text terug kan naar het password. Dat noemt men rainbow-tables.

Je lijkt te suggereren dat voor alle mogelijke wachtwoorden de hash wordt opgeslagen. Dat is niet het geval; rainbow tables zijn veel slimmer (en daarmee, aanzienlijk kleiner) dan dat. Voor details: Google en Wikipedia zijn je vriend.

Om het de aanvaller nog lastiger te maken kan je het salt varieren voor elk opgeslagen password. Het salt wordt dan per gebruiker opgeslagen in de database. De aanvaller kan dan geen rainbow tables meer gebruiken, of hij moet voor elk salt (dus voor elke gebruiker) een nieuwe rainbow table maken.

Het genereren van een rainbow table kost enorm veel tijd; meer tijd dan het controleren van alle mogelijke wachtwoorden. Het doel van zo'n tabel is om de berekening alvast te kunnen doen (en het resultaat in een, relatief, ruimte-efficiënt formaat op te kunnen slaan) terwijl je nog bezig bent om het doelwit te hacken. Als je pas begint met het genereren als de database dump al op je schijf staat (want dan kun je de salt pas uitlezen), dan is het gebruik van een rainbow table volkomen zinloos; simpelweg de boel brute-forcen is veel sneller.
(En nee, het genereren van rainbow tables voor elke mogelijke salt zou niet haalbaar mogen zijn. Een salt hoeft immers niet ingetypt te worden, dus zelfs met vier tekens (en de "echt rare" zooi eruit gefilterd, voor het idee) geeft al snel iets van 200⁴ = 1.600.000.000 = 1,6 miljard mogelijkheden. Zelfs als je één rainbow table per seconde kunt genereren (hint: dat ga je nooit voor elkaar krijgen), dan nog zou het meer dan vijftig jaar kosten om ze allemaal te doen... En in een van de reacties werd geclaimed dat ze salts van vijf tot zeven tekens gebruiken, niet slechts vier.)

[iceblink]

Niet helemaal, ik verkeerde in de veronderstelling dat een rainbow table alle hashes bevatte, maar na te lezen in Wikipedia zie ik dat het nog veel slimmer werkt. Bedankt voor het daarop wijzen

Het genereren van rainbow tables voor elke mogelijke salt is als het goed is inderdaad niet praktisch, maar zoals in Wikipedia ook al staat: "For older Unix passwords which used a 12-bit salt this would require 4096 tables, a significant increase in cost for the attacker, but not impractical with terabyte hard drives.", dus niet onmogelijk voor korte salts.

[timselier]

Gesalt betekent dat er nog een stukje "text" wordt toegevoegd aan het wachtwoord alvorens het te hashen. (bij een goede implementatie is de salt voor iedere gebruiker uniek). Op die manier is het niet mogelijk een rainbow-table in te zetten om wachtwoorden te achterhalen.

[ro8in]

Ik wil hier graag aan toevoegen dat een standaard salt zo nutteloos is als niet salten. Hij moet wel voor elke user uniek zijn anders kan je het net zo goed niet doen.

[lukjah]

Dat is niet waar, als je salt 20 karakters heeft moet de rainbow table al bij minimaal 20 karakters zijn. Als je dan een wachtwoord van 6 karakters hebt is het pas te cracken bij 26 karakters, iets wat gigantisch veel is. Uniek is beter, zelfde is niet nutteloos.

Edit: of je moet de salt ook in handen hebben, dan is het inderdaad nutteloos. Maar als je al zo ver bent kon je het algoritme om de unieke salt te berekenen ook wel achterhalen.

[Reactie gewijzigd door lukjah op 23 juli 2024 06:34]

[Chrono]

Als je niet weet wat een aanvaller in handen gekregen heeft moet je er vanuit gaan dat ze alles weten, dus ook je hashing algoritme en daarmee je vaste salt.

Er is geen enkele reden om een vaste salt te gebruiken. Een salt is er niet voor om het wachtwoord moeilijk te kraken te maken. Daar heb je een traag hashing algoritme voor. Salts zijn er om rainbow tables buiten spel te zetten, wat met een vaste salt niet het geval is.

Het maakt trouwens niks uit of de aanvaller de salt weet. Je moet de salt ook zelf weer ergens vandaan weten te halen om iemand z'n wachtwoord te controleren.

[zenlord]

Als je niet weet wat een aanvaller in handen gekregen heeft moet je er vanuit gaan dat ze alles weten, dus ook je hashing algoritme en daarmee je vaste salt.

Euh, en als je een dynamische salt gebruikt, mag je er niet meer van uitgaan dat de aanvaller alles in bezit heeft? Die dynamische salt moet ook ergens bewaard worden, dus kan even goed gecomprommiteerd zijn als een statische salt.

In deze specifieke situatie is een hele database buit gemaakt, dus de kans is zeer groot dat ook de salt(s) zijn buitgemaakt, en dan maakt het geen zier uit of je een statische of dynamische salt gebruikt. Integendeel zelfs: als de hackers enkel de database in handen hebben, en de statische salt is niet in de database bewaard (maar bvb hardcoded in de applicatie), dan moet de aanvaller nog een extra horde overwinnen vooraleer de wachtwoorden gecompromitteerd zijn.

Afin: @wie ook tot die community behoort en hetzelfde wachtwoord ook elders gebruikt: wijzig je wachtwoorden maar.

[RGAT]

En dan heb je een db met bijv. 1 miljoen users. En 1 miljoen random salts...
En nou?
Verwacht je dat een hacker 1 miljoen keer een complete rainbow tabel gaat maken?
Met MD5 zou je als je je een middag verveelt nog wel zo'n tabel kunnen maken, om het wachtwoord van 1 gebruiker te raden, met kans dat het een collision is en je alsnog niet het juiste wachtwoord hebt, hoop moeite voor weinig...
Met 1 en dezelfde hash voor iedereen kan je net zo goed geen hash gebruiken, dat de hash misschien 'verborgen' staat in een php script en niet in de database zelf doet er ook weinig aan als aanvallers al je hele database kunnen krijgen, dan is de stap naar 1 hash bemachtigen ook niet zo groot en beveiliging door het half te verstoppen in een script is geen beveiliging (gevalletje script doorlezen en binnen een minuut of vijf heb je het alsnog).
Verder is er niet zoiets als 'dynamische' salts, zou het iig niet zo noemen aangezien dat aangeeft dat ze veranderen, ze zijn verschillend per wachtwoord maar blijven verder hetzelfde (totdat er een ander wachtwoord gekozen wordt)

[zenlord]

OK, daar heb je een punt. Als het echter over een KMO gaat met 50 accounts, dan zal zo'n 'unieke salt' (inderdaad beter dan 'dynamische salt') weinig bijbrengen.

[Chrono]

Euh, en als je een dynamische salt gebruikt, mag je er niet meer van uitgaan dat de aanvaller alles in bezit heeft? Die dynamische salt moet ook ergens bewaard worden, dus kan even goed gecomprommiteerd zijn als een statische salt.

Dat zeg ik niet. De aanvaller heeft alle informatie. Een salt mag je gerust naast je wachtwoord opslaan. Dus dat staat gewoon in de database. Dus die heeft de aanvaller ook.

@RGAT geeft al een antwoord op het tweede deel van je opmerking. Een statische salt bied simpelweg geen bescherming voor waar een salt voor bedoeld is.

[Patriot]

[...]

In deze specifieke situatie is een hele database buit gemaakt, dus de kans is zeer groot dat ook de salt(s) zijn buitgemaakt, en dan maakt het geen zier uit of je een statische of dynamische salt gebruikt.

Oef, dat maakt het wel zeker. Het enige doel van een salt (letterlijk het enige, enige andere waarde mag je er niet aan geven) is ervoor zorgen dat het niet mogelijk is om een rainbow table aan te leggen waarmee de wachtwoorden voor álle gebruikers te achterhalen zijn. Salts zijn er dus niet voor om het bruteforcen moeilijker te maken.

Bovendien is het ontzettend dom om de veiligheid van je systeem af te laten hangen van het feit dat een aanvaller niet altijd je code kan inzien. Dat is security through obscurity en dat is een zeer serieuze bad practice.

[PuzzleSolver]

Maar als je al zo ver bent kon je het algoritme om de unieke salt te berekenen ook wel achterhalen.

Maar een unieke salt per gebruiker betekend dan dat je in ieder geval niet dezelfde raindbow table kan gebruiken voor alle users, in die situatie is het gebruik van een raindbow table niet meer zinvol.

[ro8in]

Zie antwoord hieronder van timselier. Met een standaard salt kan je gewoon een nieuwe rainbow table maken met de salt en nog alles matchen. Met een unieke salt moet je dus de rainbow table maken keer het aantal unieke salts wat bijna niet te doen zou zijn, als deze voor elke user uniek is.

[Reactie gewijzigd door ro8in op 23 juli 2024 06:34]

[timselier]

Dat is een goede toevoeging.
Echter, er is wel een voordeel van "vaste" salt t.o.v. geen salt. Feit blijft dat een unieke salt beter (veel beter) is. Een "vaste" salt is in feite onacceptabel.

Toelichting:
Bij een "vaste" salt is het mogelijk om een nieuwe rainbow table op te bouwen, waarmee je alle gebruikers in feite tegelijk aanvalt. (bad practice dus). Je bent wel beschermt tegen bestaande rainbowtables die al opgebouwd zijn voor dat specifieke hashing algorithme.
Basically wat er gebeurt als je een salt toevoegt aan een hashing algoritme is dat er een nieuw hashing algorithme ontstaat. (met dezelfde "kracht"/moeilijkheid van het originele algorithme). Met een unieke salt per gebruiker, heeft elke gebruiker een unieke hashing algoritme. Met een generieke salt heeft slechts jouw systeem/website een uniek algoritme.

[Verwijderd]

Aan jouw wachtwoord word een reeks karakters toegevoegd en dat samen word gehashed en opgeslagen. Om in te loggen vul jij je wachtwoord in. De authenticatie software plakt de salt, de reeks karakters, toe, hashed dit geheel en kijkt of dit klopt met wat opgeslagen is.

Als je de database hebt, heb je de salt (wanneer goed geïmplementeerd) niet. Met een rainbow table kun je de hashes omzetten naar normale tekst. Je hebt hier alleen niks aan omdat de salt er bij in zit. Als je dit invult, word daarna de salt toegevoegd (je hebt nu dus twee keer een salt), gehashed en gecontroleerd. Dit klopt niet en je komt er dus nog niet in. Je moet dus eerst de salt weten om aan de wachtwoorden te komen.

[BugBoy]

Waar sla je de salt dan wel op? Aangezien het een cryptografisch random iets is zal je de salt ergens moeten opslaan. Veelal zal dat in hetzelfde record zijn waar ook je gehashde password is opgeslagen.

[Verwijderd]

Mits je per user een eigen salt hebt, kun je deze inderdaad gewoon in hetzelfde record zetten, rainbow tables hebben dan ook geen zin. Als je één salt voor alles gebruikt (wat toch al dom is, maar praktisch alle online tutorials doen het) zou ik de salt in mijn code plaatsen, niet in een db.

[Kurai Hoshi]

De salt sla je meestal op per gerbuiker naast het wachtwoord, daarnaast kan je nog een extra vaste salt toevoegen die gelijk is voor alle records die je buiten de database houd, deze noem dan meestal weer een pepper.

[hackerhater]

Zo doe ik het in mijn systeem.
user speficieke salt + statische salt uniek per installatie (pepper) + bcrypt.
cq, vergeet het maar.

[Reactie gewijzigd door hackerhater op 23 juli 2024 06:34]

[Bose321]

https://nl.wikipedia.org/wiki/Salt_(cryptografie)

[Zenety]

Even kort googlen?

https://en.wikipedia.org/wiki/Salt_(cryptography)
https://crackstation.net/hashing-security.htm

[ro8in]

Gesalt betekent dat de hash een combinatie is van het wachtwoord plus nog iets bijvoorbeeld de user ID. Hierdoor kan je niet gewoon de hashes tegen een rainbow table leggen.

https://nl.wikipedia.org/wiki/Salt_(cryptografie)

[Reactie gewijzigd door ro8in op 23 juli 2024 06:34]

[Tiny]

Dankjewel voor je antwoord...

[PuzzleSolver]

Dat er naast het wachtwoord ook nog een stuk willekeurige data (de salt) is gebruikt om de MD5 hash te berekenen. Hierdoor wordt het moeilijker om het wachtwoord te achterhalen met b.v. een rainbow table (tabel waar MD5's in staan met bijbehorend wachtwoord).

De salt kan van alles zijn, van gebruikers id tot een random nummer die ergens anders opgeslagen is.

[ApexAlpha]

Je kan een gehashd wachtwoord dus zonder salt, met alleen hash, niet zien. Het enige dat je ziet is dat de hash hetzelfde is.

Als bijvoorbeeld drie mensen de hash "8djeu379" hebben weet je alleen dat ze hetzelfde wachtwoord hebben. Niet wat het wachtwoord is. Een Hash is onomkeerbaar!

Maar als je de database met wachtwoorden steelt heb je meestal ook de wachtwoord hints, zoals:

- Amsterdam
- Griekse god
- Voetbal

Dan weet je natuurlijk al snel dat het wachtwoord Ajax is.

Ook zonder hints is het gevaarlijk. Als er namelijk 25 mensen met dezelfde hash zijn kun je gewoon alle simpele wachtwoorden proberen zoals "wachtwoord" of "123456". Want alleen die wachtwoorden zul je vaak tegen komen.

Daarom voeg je dus een random extra deel toe, de salt. Liefst een lang, random nummer. Dan zijn je wachtwoorden mischien hetzelfde, maar omdat je allemaal een andere salt hebt komen ze totaal anders uit te zien en zijn ze niet meer af te leiden.

[Reactie gewijzigd door ApexAlpha op 23 juli 2024 06:34]

[SilentLucidity]

Dat betekend in feite dat ze beter beveiligd zijn.

[Neyluzz]

http://lmgtfy.com/?q=Salt+cryptografie

[Awesomehobo]

Salting my steak

Ook;
https://en.wikipedia.org/wiki/Salt_(cryptography)
https://en.wikipedia.org/wiki/Hash_function

[slijkie]

Verbaast mij toch nog steeds dat al die user databases zulke zwakke encryptie voor pw's hebben. Dit had al jaren terug voorkomen kunnen worden met een update voor MySQL of iets dergelijks. Dan maar zwaardere servers om dat te handlen.

[Tribits]

Sowieso gaat het om hashing en niet om encryptie bij passwords. Daarnaast was die hashing volgens het artikel correct toegepast, dus in ieder geval met salt. Verder is dit iets dat vrijwel altijd door de applicatie af wordt gehandeld en niet door MySQL.

Persoonlijk vind ik overigens dat het belang van hashen en salten wordt overdreven. Het dient vooral om gebruikers te beschermen die hetzelfde wachtwoord op meerdere sites gebruiken. Die blijven echter ook met goede hashes een verhoogd risico lopen. Daarnaast is het zo dat het normaal gesproken niet mogelijk is in het bezit van de hashes te komen, het is echt een laatste 'line of defense', maar op dat moment ligt al je data al op straat. Je database beschermen is dus veel belangrijker dan je op password hashes concentreren.

Verder is het zo dat je zelfs met een goede password hash nog steeds je wachtwoord moet veranderen op alle sites waar je dat gebruikt na een hack als deze. Salting maakt brute forcen moeilijker, maar niet onmogelijk. Als je hetzelfde wachtwoord gebruikt op een site die je echt wat waard is dan wil je het risico niet lopen dat de hackers het na verloop van tijd toch achterhalen.

[Merethil]

Met een goed paswoord, een salt die lang genoeg is en een goed hashing-algorithme kan je echter ervoor zorgen dat het bruteforcen van één enkel wachtwoord zo lang duurt dat het al niet meer interessant is voor een gemiddelde hacker.
Ja, het is je "last line of defense", maar het is toch een vorm van bescherming die je zeker serieus moet nemen. Als iemand al heel veel moeite heeft moeten steken in je database lospeuteren waarna hij ook nog moet bruteforcen neemt per seconde die die persoon er extra in moet steken de winst van de "inbraak" af en derhalve "veiliger" voor de eindgebruiker.

Als jouw pc 10 jaar bezig moet zijn om één wachtwoord terug te vinden omdat hij flink gehashed is (overdreven, maar toch), haak jij dan niet ook af?

[Tribits]

Dat gaat sowieso uit van de aanname dat de passwords een belangrijk deel vormen van de buit van een hack. Die passwords zijn alleen interessant voor een bepaalde groep hackers die ze gebruiken om daarna Steam accounts door te verkopen of zo. Als het de hackers echt om wachtwoorden te doen is zouden ze niet overgaan tot defacement, maar de site voorzien van een password sniffer en dat zo lang mogelijk stil proberen te houden. Zeker op sites waar de client automatisch inlogt heb je dan na korte tijd het gros van de passwords te pakken. Ik heb echter nog nooit van een dergelijke hack gehoord.

Bovendien wordt het risico voor een gebruiker kleiner, maar kan die gebruiker er nog steeds niet op vertrouwen. Zoals eerder al aangegeven moet je na een dergelijke hack nog steeds je wachtwoord veranderen, ook op alle andere sites waar je dat gebruikt. Inderdaad ben je in de periode tussen het uitlekken van de database en het veranderen van je wachtwoorden dan iets veiliger. Aan de andere kant was je nog een stuk veiliger geweest als je overal een ander password had gebruikt. Dan had je bij het nieuws van deze hack gewoon je schouders op kunnen halen, zelfs als je password plaintext op straat had gelegen.

Als jouw pc 10 jaar bezig moet zijn om één wachtwoord terug te vinden omdat hij flink gehashed is (overdreven, maar toch), haak jij dan niet ook af?

Als het zo zeker was dat het onmogelijk was om te bruteforcen zouden we na een hack als deze niet het bericht krijgen dat ieder zijn wachtwoord aan moet passen. En ik neem aan dat jij je ook niet veilig zou voelen als de hash van een password dat je ook op andere sites gebruikt op straat ligt. Veiligheid draait om zekerheid en die is gewoon weg als de hashes op straat liggen. Misschien wordt er nooit meer iets mee gedaan, misschien heeft zojuist een hacking group zijn botnet aan het werk gezet en hebben ze morgen de eerste resultaten binnen.

[Reactie gewijzigd door Tribits op 23 juli 2024 06:34]

[Merethil]

Als iedereen echter een apart wachtwoord per website ging gebruiken hadden we sowieso erg weinig problemen gehad. Helaas is het internet op gaan niet gebonden aan een diploma dat je moet behalen dus moeten we er vanuit gaan dat de gemiddelde Jan van om de hoek toch echt voor elke website welkom123 gebruikt, behalve als er domme eisen gesteld worden zoals vreemde tekens, waarna het welkom123! wordt.

Aanegzien we dat niet kunnen voorkomen moeten we van het ergste uitgaan en heb je als developer naar mijn mening de plicht om te hashen. Al was het maar omdat het voor jou weinig moeite is, en voor de gebruiker een extra vorm van veiligheid geeft, zelfs als die maar tijdelijk is.

Het kunnen inzien van de database betekent trouwens niet dat je ook makkelijk nieuwe code kunt toevoegen, of zelfs maar code lezen. Daarom zal je ook vaak zien dat dit de "makkelijkere" (script-kiddie-niveau) manier van wachtwoorden vergaren is in plaats van een password sniffer eraan te hangen. Als je een password sniffer kan toevoegen is de website meer compromised dan "alleen de database".

[Tribits]

Het kunnen inzien van de database betekent trouwens niet dat je ook makkelijk nieuwe code kunt toevoegen, of zelfs maar code lezen. Daarom zal je ook vaak zien dat dit de "makkelijkere" (script-kiddie-niveau) manier van wachtwoorden vergaren is in plaats van een password sniffer eraan te hangen. Als je een password sniffer kan toevoegen is de website meer compromised dan "alleen de database".

Ik ben wel vaker die suggestie tegengekomen dat waarschijnlijk alleen de database is bemachtigd en de rest van de site veilig is gebleven. Vaak is het lastig te bepalen of dat inderdaad het geval is, maar in de beschrijving van de hacked team hack die laatst gepubliceerd is werd bijvoorbeeld duidelijk dat daar eerst root bemachtigd werd en vervolgens pas de database werd gedownload.

Bovendien biedt totale toegang tot de database doorgaans ook wel genoeg aanknopingspunten om de rest van het systeem in te komen. Passwords sniffen kan trouwens ook wel zonder de applicatiecode aan te passen. Tussen het decrypten van de SSL en het hashen staan ze plaintext in het geheugen, met de juiste tools zijn ze daar ook wel uit te lezen.

Aanegzien we dat niet kunnen voorkomen moeten we van het ergste uitgaan en heb je als developer naar mijn mening de plicht om te hashen. Al was het maar omdat het voor jou weinig moeite is, en voor de gebruiker een extra vorm van veiligheid geeft, zelfs als die maar tijdelijk is.

Hashen/salten is op zich een goed principe, het verhindert ook dat iemand een wachtwoord bemachtigd en bijvoorbeeld ongemerkt mee kan lezen op jouw email account. Het is alleen jammer dat er iedere keer als een dergelijk bericht naar buiten komt weer reacties komen in de trend van 'oh gelukkig mijn wachtwoord is nog veilig.' Niet dus en in dat opzicht wat mij betreft schijnveiligheid.

[slijkie]

Snap ik, maar anno 2016 moet er toch allang een oplossing hiervoor zijn, het wel encrypten? of een 200x zwaardere hash te gebruiken? Geen idee hoe dit precies te doen hoor. Maarja, dat probeerde ik ermee te zeggen.

[Verwijderd]

Security is ontzettend moeilijk en zelfs na decennia weten experts nog steeds niet hoe het precies moet. Lees http://schneier.com maar eens en uiteraard ook de artikelen waar hij naar linked.

Het probleem is dat A de algoritmes al lastig zijn. Vervolgens moet de implementatie daarvan foutloos zijn, en ook alle andere stappen van security moeten én foutloos zijn qua logica en qua implementatie. Daarbij komt dan ook nog social engineering, ingebouwde hardware hacks, systemen die altijd up to date moeten zijn.

Het probleem met defensie is: je moet ALLES goed doen en een aanvaller hoeft maar 1 gaatje te vinden.

Als er een 100% oplossing zou zijn, dan zouden we dat weten. Dus, jezelf eerst inlezen en vervolgens mag je zelf beoordelen of je je uitspraak "maar anno 2016 moet er toch allang een oplossing hiervoor zijn" wilt herhalen. Er is genoeg informatie te vinden.

[slijkie]

Eigenlijk zou 2FA al minstens overal beschikbaar moeten zijn.

[Verwijderd]

Sure, maar dat beschermt je niet tegen mensen die echt binnen willen komen. Iemand die echt wel en voldoende middelen heeft, komt binnen.

[Tribits]

Ik denk dat het belangrijk is om onderscheid te maken tussen het hacken van de database en het risico dat de wachtwoorden lopen. Het artikel vermeld niet hoe de database hack uit is gevoerd, maar de password hashes hebben daar hoogstwaarschijnlijk niets mee te maken. Een populaire methode om toegang tot de database te krijgen is SQL injectie en dat is in de praktijk dan ook een veel groter probleem dan slechte password hashes. Andere methode zijn het gebruiken van beveiligingsproblemen in de gebruikte hardware of software. Vandaar ook de focus bij bijvoorbeeld Google om dat soort problemen op te sporen. Blijft wel dat de beheerder van de site alles up to date moet houden om te voorkomen dat een verouderd lek alsnog misbruikt kan worden.

Wat betreft wachtwoorden ontkomen we denk ik alleen aan het uitlekken van salts als het wachtwoordbeheer over wordt gelaten en enkele grote professionele partijen. Je ziet nu dat iedere website zijn eigen lijstje met hashes heeft staan. Door in te loggen met Google of Facebook voorkom je dat en is het niet meer nodig om hashes in de database van je website te bewaren.

[Bacchus]

Sowieso gaat het om hashing en niet om encryptie bij passwords. Daarnaast was die hashing volgens het artikel correct toegepast, dus in ieder geval met salt.

Anno 2016 kan ik MD5 met salt echt met geen mogelijkheid als "correct" zien voor wachtwoord-opslag: Met een paar duizend euro aan GPU's test je tegen een biljoen* hashes per seconde. Het is zo makkelijk om zelfs maar honderdduizend ronden PBKDF2 toe te passen dat je dat wel als een barebone minimum mag aanwijzen.

* Duizend miljard oftewel 10¹² inderdaad.

[Tribits]

Daar heb je dan ook wel weer gelijk in, die (incorrecte) aanname van mij was puur op basis van de salt. Zou misschien wel goed zijn als het artikel dat zou vermelden. De gemiddelde gebruiker zal denken dat het wel goed zit als er hashing+salt gebruikt wordt, maar dat is hier dus niet echt het geval.

[robvanwijk]

Persoonlijk vind ik overigens dat het belang van hashen en salten wordt overdreven. Het dient vooral om gebruikers te beschermen die hetzelfde wachtwoord op meerdere sites gebruiken.

Er is een tweede belangrijke reden om te salten en hashen: jezelf de tijd geven om te merken dat je gehacked bent (en passwords te resetten) voordat de passwords gekraakt worden.

het is echt een laatste 'line of defense', maar op dat moment ligt al je data al op straat. Je database beschermen is dus veel belangrijker dan je op password hashes concentreren.

Het hebben van een "last line of defence" (of, meer in het algemeen, een "extra line of defence") is juist aan te raden! Natuurlijk zou het fijn zijn als niemand je database kan lezen... maar is het echt verstandig om alles toe te vertrouwen aan het waterdicht zijn van de beveiliging van je database? En niet alleen waterdicht zijn, ook waterdicht blijven; je kunt je alleen beschermen tegen fouten waarvan je weet dat ze bestaan. Als je begin jaren negentig een perfect beveiligde database had, dan was je toch mooi de sjaak op het moment dat iemand voor het eerst SQL-injectie verzon; toen was je perfecte beveiliging opeens zo lek als een mandje!

Verder is het zo dat je zelfs met een goede password hash nog steeds je wachtwoord moet veranderen op alle sites waar je dat gebruikt na een hack als deze. Salting maakt brute forcen moeilijker, maar niet onmogelijk.

Eigenlijk is "moeilijker" het verkeerde woord, iedereen die een heel klein beetje kan programmeren kan een brute forcer schrijven. Waar het eigenlijk om gaat is dat salting een brute force aanval langzamer maakt. Uiteindelijk (als de aanvaller genoeg geduld heeft) krijgt ie je password alsnog te pakken... maar pas nadat jij genoeg tijd hebt gehad om je password op alle andere sites te veranderen!

[Tribits]

maar is het echt verstandig om alles toe te vertrouwen aan het waterdicht zijn van de beveiliging van je database?

Ik heb nergens gezegd dat hashing overbodig is. De beveiliging van je database (en de rest van je systemen) moet echter absoluut de hoogste prioriteit hebben. Alle grote partijen op hosting gebied/cloud services etc. hebben dan ook alle prioriteit liggen bij het waterdicht krijgen van systemen en detecteren van breaches. Password hashing dient hooguit om de schade nog wat te beperken. Het is een makkelijke maatregel dus er is geen excuus om het niet te doen, maar ik wordt gewoon erg moe van die focus op password hashing. In tal van gevallen waar de volledige bedrijfsgegevens op straat zijn beland betekende dat het einde van de betreffende organisatie. Dat los je niet op met password hashes.

Er is een tweede belangrijke reden om te salten en hashen: jezelf de tijd geven om te merken dat je gehacked bent (en passwords te resetten) voordat de passwords gekraakt worden.

Op het moment dat een hacker volledige toegang heeft tot een site (en daar ga ik wel van uit als de complete database eenmaal bemachtigd is en er gesproken wordt van 'full ownage') kan ik me niet indenken dat het bemachtigen van de passwords nog veel nut heeft. En zoals eerder aangegeven zijn er na het bemachtigen van admin/root rechten ook wel andere mogelijkheden om wachtwoorden te bemachtigen.

maar pas nadat jij genoeg tijd hebt gehad om je password op alle andere sites te veranderen!

Klinkt weer als een argument om het gebruik van hetzelfde wachtwoord op meerdere sites goed te praten. Zoals vaker aangegeven zijn er meer manieren om een wachtwoord te bemachtigen (anders dan client side spyware), bovendien zal een hacker die op wachtwoorden uit is de hack geheimhouden dus kan het alsnog dat je password gevonden wordt voordat je het op andere sites gewijzigd hebt. Inderdaad, in dit specifieke scenario zal het de kans verkleinen dat je wachtwoord gevonden wordt voordat je kans hebt gekregen het te veranderen, maar de noodzaak om je wachtwoord te veranderen blijft.

[Reactie gewijzigd door Tribits op 23 juli 2024 06:34]

[robvanwijk]

Klinkt weer als een argument om het gebruik van hetzelfde wachtwoord op meerdere sites goed te praten.

Er is een groot verschil tussen "goedpraten" en "poging om 'minder verstandige gebruikers' zoveel mogelijk tegen hun eigen fouten te beschermen"! Ja, ik zou het fijn vinden als iedereen op elke site een ander, sterk wachtwoord zou gebruiken, dat ze af en toe aanpassen. Maar ik zou het ook fijn vinden om de loterij te winnen en wereldvrede nog mee te mogen maken... Sommige hele goede dingen gaan nou eenmaal niet gebeuren, hoe graag je het ook zou willen. Dan kun je wel benadrukken hoeveel beter het zou zijn als het toch werkelijkheid wordt, maar soms zul je gewoon moeten roeien met de riemen die je hebt: een groot deel van je gebruikers is een kluns op security gebied, deal with it!

[Tribits]

Ik deal er wel mee, maak je daar maar geen zorgen over. Met de gebruikers die het nooit leren door gebruik te maken van beproefde standaardoplossing voor authenticatie, net als de rest van de ontwikkelaars hier mag ik hopen. En met de gebruikers die iedere keer als een dergelijk bericht geplaatst wordt weer de vraag stellen of de hashes wel voldoende veilig waren door ze uit te leggen dat ze beter ervoor kunnen zorgen minder afhankelijk te zijn van die hashes

Dat de wereld nooit het ideaalbeeld zal bereiken betekent nog niet dat je geen moeite mag doen om de situatie te verbeteren, en dat is nu net wat ik probeer door erop te wijzen dat die focus op hashing vanuit de kant van de gebruiker ongepast is. Het zou nog enigszins te honoreren zijn als de reden is dat men zich zorgen maakt of er iets met de account op de site zelf is gedaan, maar je weet dat het gros van de gebruikers alleen maar die vraag stelt omdat ze hetzelfde password op tal van sites gebruiken en geen zin hebben om dat te veranderen.

Daarom vind ik het verstandiger om gebruikers erop te wijzen dat ze verkeerd bezig zijn dan weer een hele discussie te starten over de veiligheid van hashes en salts. Zoals al eerder gezegd: als je daadwerkelijk enige garantie af kon geven zou niet iedere site na een hack het complete wachtwoord bestand resetten, ook bij voldoende veilige hashes. Met gebruikers in discussie gaan over hashes maakt de discussie alleen maar nodeloos ingewikkeld en wekt de indruk dat er een sluitende technische oplossing is voor het probleem van gebruikers die hetzelfde wachtwoord op meerdere sites gebruiken.

[Merethil]

Het is niet de verantwoordelijkheid van de Database-vendor om de wachtwoorden op een juiste manier te hashen, dit is gewoon aan de developer vóór hij de data naar de Database verstuurt.
Hashing is al jaren snel genoeg om je site niet "in de weg te zitten" en er zijn genoeg hashing-algorithmes die nog "onkraakbaar" genoemd kunnen worden.

Het komt er gewoon op neer dat de developer van de website slecht omgegaan is met security of dit in ieder geval niet op een goed niveau heeft weten te houden. Zonde, maar zo zijn er duizenden lekke sites te vinden over het hele internet.

[ACM]

Het probleem van hashes is eigenlijk dat ze veel te snel zijn. Daarom bevatten alle moderne adviezen over wachtwoorden en alle goede technieken allerlei technieken om het juist expres trager te maken. Bijvoorbeeld door 'key stretching' en andere technieken die effectief vaak uit recursie bestaan.

Als je een wachtwoord domweg met sha1, sha256 of zelfs sha512 hashed gaat vooral op GPU's razendsnel. Dan heb je het over het uitproberen van miljoenen hashes per seconde.

Het is dan wel 'vervelend' als die wachtwoorden gehashed zijn, dan gaat het natuurlijk van enkele seconden tot minuten voor het hele wachtwoord-bestand naar dezelfde ordegrootte in tijd per wachtwoord.

[Merethil]

Op zich is het logisch dat als je 3000x kan hashen in twee seconden wanneer iemand's wachtwoord weggeschreven gaat worden naar de DB, dit ook heel simpel wordt wanneer je inderdaad probeert te bruteforcen.

Echter, juist door die langere salt en "zwaarste" hashes te gebruiken heb je toch dat iemand ten eerste moet weten dat 'ie 3000x moet hashen, en ten tweede moet weten hoe lang je salt is, en wat die salt is.

Ik wil niet zeggen dat het onmogelijk is, maar het is wel een stel obstakels die het gewoon lastiger maken voor de "hacker". Het komt helaas gewoon voor dat je database uitgelezen kan worden; niet elke provider of developer/systeembeheerder heeft altijd alle security op orde; houdt niet in dat hashen onbelangrijk zou zijn (en dat is ook de strekking van mijn pleidooi erin; het is een extra maar wel één die ten eerste makkelijk te doen is, en ten tweede gewoon een extra set obstakels opbouwt voor iets ongelofelijk belangrijks).

[ACM]

Ik probeerde je vooral nog wat aan te vullen

Het punt is dat 1x hashen niet goed genoeg is. Er zijn allerlei technieken om het wat zwaarder te maken. Waardoor je uiteindelijk niet meer miljoenen pogingen per seconde kan doen, maar bijvoorbeeld nog maar 10 per seconde.

Helaas zorgt dat er wel voor dat de bijbehorende wachtwoordvalidatie dan ook 0.1 seconde duurt (en al die tijd is je server aan het rekenen)

En inderdaad, als je database om wat voor reden dan ook toegankelijk is. Dan is het nuttig om belangrijke bepaalde gegevens gewoon alsnog onleesbaar te hebben. Voor wachtwoorden is geen hele goede reden om een leesbare versie te bewaren, dus die kan je dan het beste versleutelen.

Daarbij is het wel belangrijk om naar de moderne adviezen te kijken en af en toe te controleren of bijvoorbeeld 'zwaarte'-parameters ondertussen bijgesteld moeten worden.

[Tribits]

Helaas zorgt dat er wel voor dat de bijbehorende wachtwoordvalidatie dan ook 0.1 seconde duurt (en al die tijd is je server aan het rekenen)

Dat is ook nog wel een punt om mee te nemen in de keuze van het hashing algoritme. Als je algoritme 10 wachtwoorden per seconde kan valideren zal je dus voor iedere 10 gebruikers die je per seconde in wilt loggen een extra server moeten toevoegen. Nu lijkt tien gebruikers per seconde misschien veel, maar op sommige sites loggen grote aantal gebruikers tegelijk in, bijvoorbeeld aan het begin van de werkdag. Andere servers moeten regelmatig wachtwoorden valideren omdat de client geen verbinding in stand houdt.

Met een algoritme dat 1000 wachtwoorden kan valideren op een bepaalde server zal het allemaal een stuk minder kritisch worden, maar dan zit je alweer op het punt dat je eenvoudige wachtwoorden kan brute forcen, ook met salt.

[hackerhater]

Dit is inderdaad het grote nadeel van zwaardere hashing methodes, namelijk dat het een zwaardere belasting op je servers legt. Net als TLS dat doet. Evengoed hoort dit gewoon standaard praktijk te zijn.

[robvanwijk]

Verbaast mij toch nog steeds dat al die user databases zulke zwakke encryptie hashing [ftfy - RvW] voor pw's hebben. Dit had al jaren terug voorkomen kunnen worden met een update voor MySQL of iets dergelijks. Dan maar zwaardere servers om dat te handlen.

Je probeert het probleem op de verkeerde plaats op te lossen. Natuurlijk, SQL zou een kolom type "salted, hashed char" kunnen toevoegen. Maar dat betekent dat het onversleutelde wachtwoord naar de database gecommuniceerd moet worden. Dat wil je helemaal niet; je wil het plain text password zo snel mogelijk (overschrijven met random data en) weggooien: data die niet meer bestaat kan ook niet meer uitlekken. Met andere woorden: hoe eerder de boel gehashed wordt, hoe beter.

Dat programmeurs niet beter op de hoogte zijn van hoe ze met passwords om zouden moeten gaan is niet de schuld van SQL! De correcte plaats om dit op te lossen is bijvoorbeeld in PHP, die een prima kant-en-klare oplossing heeft; je hoeft letterlijk maar twee functies te gebruiken! Met password_hash($password) en password_verify($given_password, $correct_hash) ben je in één keer beschermd tegen een heleboel standaard aanvallen. En daarnaast is het gegarandeerd sneller dan zelf iets te ontwerpen en te implementeren.

[Reactie gewijzigd door robvanwijk op 23 juli 2024 06:34]

[WienerBlut]

Beetje offtopic, maar waarom ook niet:
Ik heb een oplossing voor ontwikkelaars die niets van security weten: MD5 uit alle ontwikkelingsplatformen halen!

Waarom zou je het er überhaupt nog in laten zitten? Natuurlijk wordt dit nooit realiteit, maar een soort kinderslot voor dit soort beginnersfouten?

[Verwijderd]

Dus jij wil alles en iedereen langslopen en dan MD5 uit bestaande paketten gaan slopen?
Je kan het wel uit nieuwe versies halen (voor zover niemand het meer nodig zou hebben) maar je blijft natuurlijk zitten met een groot aandeel van oude of niet goed onderhouden platformen.

[WienerBlut]

Natuurlijk heb je gelijk, er zit een nuance in en daarmee sla de spijker op z'n kop. MD5 vervangen waar mogelijk en diep wegstoppen...

[hackerhater]

Ontwikkelaars die zoiets niet weten horen ook niet hun eigen login systeem te bouwen maar netjes frameworks te gebruiken.

[qless]

MD5 hashes kun je nog wel gebruiken voor bijvoorbeeld file-compare. Dus eruit halen, nee, gebruiken voor passwords hashing: zeker niet

[WienerBlut]

Ja klopt, maar waarom geen SHA-2? Dat is robuuster! minder kans op collisions etc. Je wilt ook voor file hashing ook geen MD5 meer hebben...

[Chrono]

Wat me opvalt is dat hier het idee leeft dat een salt je wachtwoorden op een manier beter beschermt. Dat doet een salt niet.

Pakken we de tweede zin van de wiki er bij lezen we dit:

The primary function of salts is to defend against dictionary attacks versus a list of password hashes and against pre-computed rainbow table attacks.

Dat is het doel. Rainbow tables en dictionary attacks tegengaan. Om dit te doen moet de salt random zijn per wachtwoord. Anders is er nog steeds maar één rainbow table nodig om alle hashes te kraken. Dat de salt gewoon in de database, naast de wachtwoord hash, wordt opgeslagen is heel normaal. Het maakt niet uit of de aanvaller de salt heeft.

Waar eigenlijk helemaal niet over gesproken wordt is het gebruik van MD5 om de hashes te genereren. Het is aangetoond dat MD5 'broken' is. Er had eigenlijk al lang een ander hashing algoritme gebruikt moeten worden, maar daar is het nu te laat voor.

[Verwijderd]

Ik snap niet waar jij je idee van wat hier leeft vandaan haalt. Wat jij schrijft is namelijk slechts een herhaling van dergelijke reacties.
Hierboven is door diverse mensen al beschreven dat een wachtwoord met salt beter is dan eentje zonder. Ook is aangegeven dat een salt per wachtwoord beter is dan een algemene voor alle wachtwoorden.

[Chrono]

Wat ik veel zie is dat er beweerd wordt dat een statische salt ook goed is. Dat salts geheim horen te zijn. Eigenlijk over het algemeen dat er veel mensen zijn niet lijken te weten hoe je met wachtwoorden om moet gaan.

Hierboven is door diverse mensen al beschreven dat een wachtwoord met salt beter is dan eentje zonder. Ook is aangegeven dat een salt per wachtwoord beter is dan een algemene voor alle wachtwoorden.

En veel daar van zijn het die de klok horen luiden maar niet weten waar de klepel hangt. Dat iemand weet dat het beter is om een salt te gebruiken betekent nog niet dat het goed wordt toegepast, getuige de reacties over statische salts.

Wat ik vooral hoop is dat, in het geval je ook met bewaren van wachtwoorden te maken krijgt, niet de domme fouten maakt die je zoveel ziet wanneer de zoveelste database wordt gedumpt.

We zijn nog niet 4 uur verder en het volgende bericht over hashes is al geplaatst. Dit keer is de fout dat er nog SHA-1 hashes gebruikt worden.

Ik kan me niet herinneren dat er een database is gestolen waarbij scrypt of bcrypt gebruikt is om de wachtwoorden te hashen. Dus het kan me eigenlijk niet vaak genoeg herhaald worden dat je goed moet weten hoe je met wachtwoorden van je gebruikers om moet gaan.

[jerkitout]

imo is het best om website defacings niet te reporten. De hackers doen het voor attentie, en wij geven ze het... Natuurlijk moet de slachtoffers het weten, maar een nieuwsbericht van maken is een stap te ver.

[Reactie gewijzigd door jerkitout op 23 juli 2024 06:34]

[pim]

Dus gijzelingen en aanslagen mogen wat jou betreft ook niet in het nieuws komen?

[Thekilldevilhil]

Jammer dat je defacen van een website weer aangrijpt om te beginnen over "terrorisme" maar eigenlijk niet. Een meerderheid van de psychiaters roepen in ieder geval al jaren dat de overdreven berichtgeving over dit soort zaken nieuwe aanslagen en "school shootings" in de hand werkt. Als het aan hun ligt zou een landelijk een kort zakelijk bericht genoeg zijn en moet je het lokaal oplossen.

Dus hij is in ieder geval niet alleen in zijn wens.

[buckly]

Ik kan jouw bericht niet lezen zonder een zwaar engels accent te horen

[jerkitout]

Ik heb ook een vreselijk Engels accent

[HansvDr]

Lekker cracks delen en zelf de sjaak zijn.

Ironisch

[Verwijderd]

Dit is toch helemaal niet erg? Mensen die daar actief zijn geven toch niet om andermans spullen, dus waarom zouden wij om hun persoonlijke gegevens geven?

[MrXzombie]

Portie karma voor die lui

[Composed]

All your data are belongs to us Romania.

[Reactie gewijzigd door Composed op 23 juli 2024 06:34]

[Mirakel2]

Genoeg nu ....salt erover!