Zoals de titel al aangeeft is het mogelijk om een gehashed password te echoen?
ik heb geen idee hoe dit moet. Ik heb het al gegoogled en dan kom ik op password_verify maar dat is volgens mij alleen om in te loggen zodra er iets gepost word en niet om te echoen.
Er bestaan tabellen van veelvoorkomende wachtwoorden en hashes (zei iemand rainbow?) en websites als hashkiller. Deze vormen gelijk het bewijs dat een zwak wachtwoord geen goed idee is.
Ik dacht dat dat juist wilde zeggen dat de hashingmethode zelf zwak was. Natuurlijk is een sterk wachtwoord goed, maar als de hashingmethode zelf zwak is helpt een sterk wachtwoord niet echt (of liever gezegd, minder goed).
Hashes zijn, zoals @Frank zegt, niet omkeerbaar. Hashing moet je zien als invoer die je door de papierversnipperaar gooit en wat er uitkomt opvangt in verschillende emmers. Deze "rest na deling" (waar @Toms Diner het over had), of de "emmer configuratie" is je hash. Wanneer iemand inlogt met een wachtwoord gooi je deze invoer door dezelfde papierversnipperaar en kijk je of deze "rest na deling" overeenkomt met de eerder opgeslagen hash.
Dit maakt het dus effectief onmogelijk om een wachtwoord te herleiden. Wanneer iemand zijn/haar wachtwoord kwijt is geraakt zal deze persoon via een "lost password" routine deze moeten (kunnen) resetten. Dit gebeurt meestal via e-mail en een unieke hyperlink (ook weer met een hash :)) die een tijdelijke geldigheid heeft.
Iets doet mij vermoeden dat daar mogelijk het probleem zit (het ontbreken van een dergelijke routine).
Er bestaan tabellen van veelvoorkomende wachtwoorden en hashes (zei iemand rainbow?) en websites als hashkiller. Deze vormen gelijk het bewijs dat een zwak wachtwoord geen goed idee is.
Ik dacht dat dat juist wilde zeggen dat de hashingmethode zelf zwak was. Natuurlijk is een sterk wachtwoord goed, maar als de hashingmethode zelf zwak is helpt een sterk wachtwoord niet echt (of liever gezegd, minder goed).
Mijn interpretatie is dat de hashing niet zwak is, maar het feit dat de hash al in teveel tabellen voorkomt. (de rainbows en andere hash-databases bevatten de hashes van de meest voorkomende wachtwoorden) En dus "herkend worden", als een reeds eerder gehashte waarde.
Een zwakke hash zou te kraken zijn, en bij mijn weten is een hash niet kraakbaar.
Toch heb ik in custom code voor de zorgsector er bewust voor gekozen om een variabele salt te kiezen. Bij elke user is wel een tweede var te vinden die nooit meer wijzigt, maar wel per persoon verschillend is. Denk aan usernumber, username, UTS of registration, enzovoort. Dit was de salt, en levert een tweetraps login op: eerst de username controleren, en de tweede var uit de database halen. Dan die als salt voor het wachtwoord gebruiken, en de hash controleren met de database.
Wat ik overigens lastig vind, is dat het niet ondenkbaar is dat we binnen enkele jaren met een (te) grote onveiligheid in het systeem geconfronteerd worden. De kans is groot dat die uit de hoek van de steeds sneller wordende computers gaat komen, waardoor brute forcen opeens wèl regelmatig tot resultaat leidt. (was geloof ik vorige maand al in het nieuws, dat de rekensnelheid van computers ervoor zorgt dat 5-10 jaar oude beveiligingssystemen te onveilig beginnen te worden).
In bovenstaande situatie zou je graag de boel beter beveiligen, maar omdat je een hash niet om kan draaien, zou je hooguit de hash met een verbeterde hash kunnen behandelen om het gevaar te keren. Om die reden past een kennis van mij AES256 encryptietoe ipv hashing. Dat zou je wel compleet om kunnen zetten naar wat nieuws. Overigens vind ik dit niet kunnen: het is in strijd met de basisbeginselen van veiligheid. De admin kan elk wachtwoord decrypten en zich voordoen als iemand anders.
Mijn interpretatie is dat de hashing niet zwak is, maar het feit dat de hash al in teveel tabellen voorkomt. (de rainbows en andere hash-databases bevatten de hashes van de meest voorkomende wachtwoorden) En dus "herkend worden", als een reeds eerder gehashte waarde.
Een zwakke hash zou te kraken zijn, en bij mijn weten is een hash niet kraakbaar.
Een hash is niet terug te rekenen naar het origineel, maar bij een zwakke hash is het wel mogelijk om collisions te krijgen, oftewel meerdere input-strings die dezelfde hash geven. De zwakte van MD5 en SHA1 is dan ook dat het té eenvoudig is geworden om dergelijke collisions te vinden.
Toch heb ik in custom code voor de zorgsector er bewust voor gekozen om een variabele salt te kiezen. Bij elke user is wel een tweede var te vinden die nooit meer wijzigt, maar wel per persoon verschillend is. Denk aan usernumber, username, UTS of registration, enzovoort. Dit was de salt,
Toegegeven, het is beter dan niets, maar het is nog steeds suboptimaal. Het beste is om elke keer dat een gebruiker zijn wachtwoord wijzigt een volledig willekeurige string te genereren en die als salt te gebruiken. In de oplossing die je nu hebt gekozen wijzigt de salt niet als de gebruiker zijn wachtwoord wijzigt, en ook dat is een zwak punt.
Wat ik overigens lastig vind, is dat het niet ondenkbaar is dat we binnen enkele jaren met een (te) grote onveiligheid in het systeem geconfronteerd worden. De kans is groot dat die uit de hoek van de steeds sneller wordende computers gaat komen, waardoor brute forcen opeens wèl regelmatig tot resultaat leidt.
Om die reden moet je bcrypt gebruiken voor het genereren van password-hashes. Bcrypt (ook wel Blowfish genoemd, maar dat is niet volledig correct) voegt naast de salt een cost-parameter toe, waarmee je ervoor zorgt dat het hashen langer duurt. Worden de computers sneller, dan verhoog je simpelweg de cost. Elke hash begint met een identifier waaraan je kunt zien met welke cost die gegenereerd is; gebruikers met een te lage cost kun je vervolgens dwingen hun wachtwoord te veranderen.
Momenteel gebruik ik een cost van 14; bcrypt gebruikt dan 2^14 expansierondes, wat op mijn server ongeveer een seconde duurt. Voor het checken van een wachtwoord vind ik dat acceptabel.
Momenteel gebruik ik een cost van 14; bcrypt gebruikt dan 2^14 expansierondes, wat op mijn server ongeveer een seconde duurt. Voor het checken van een wachtwoord vind ik dat acceptabel.
Willem, hoe ga je dan om met een aanvullende vereiste: als de gebruiker het wachtwoord wijzigt (per 90 dagen bijvoorbeeld), mag het nieuwe wachtwoord niet gelijk zijn aan een eerder gebruikt wachtwoord.
Bij een hoge work factor / cost is dat een bijna onoplosbaar probleem: je moet namelijk de hash berekenen van het huidige wachtwoord, van het nieuwe wachtwoord én van alle vorige wachtwoorden. De serverbelasting daarvan is hoog, heel hoog.
Wij hebben het opgelost door steekproefsgewijs, in leeglooptijd als een serverfarm nauwelijks belast is, de nieuwe wachtwoorden te controleren. Dat is een werkbare situatie voor adminaccounts, maar ik moet er niet aan denken dit op grotere schaal in te zetten voor reguliere gebruikersaccounts.
Willem, hoe ga je dan om met een aanvullende vereiste: als de gebruiker het wachtwoord wijzigt (per 90 dagen bijvoorbeeld), mag het nieuwe wachtwoord niet gelijk zijn aan een eerder gebruikt wachtwoord.
Hoe zou jij dit oplossen?
Niet, want ik vind dat een belachelijke vereiste.
Maar het is volgens mij wel oplosbaar. Bij het wijzigen van een wachtwoord moet je meestal ook je oude wachtwoord opgeven. Dat oude wachtwoord zou je met een simpele SHA-512 of zo kunnen hashen en opslaan in de tabel met niet meer toegestane wachtwoorden.
Edit:
De reden dat ik het een belachelijke vereiste vind, is omdat je met dat soort maatregelen vaak het tegenovergestelde bereikt van wat je zou willen. Je wilt een veilig systeem waar niemand zomaar een wachtwoord kan kraken, maar je werkt ermee in de hand dat mensen hun wachtwoord gaan bewaren op een briefje onder hun toetsenbord, omdat ze het anders vergeten.
Ik heb ooit gewerkt bij een organisatie waar je elke 6 weken een nieuw wachtwoord moest kiezen. Daar word ik recalcitrant van. Mijn wachtwoord veranderde van Welkom01 naar Welkom02 naar Welkom03, etc. En dat alles in het kader van veiligheid. :-/
Los hiervan, alles is een tradeoff (bijvoorbeeld veiligheid <--> gebruikersgemak).
Daarnaast, als je met veiligheid bezig bent lijkt het mij dat je met lagen moet werken, en niet met een enkele oplossing die alles wat niet goed is tegenhoudt. Ben je die barriere voorbij, dan zou dat in dat geval inhouden dat iemand vrij spel heeft?
Los van het feit hoe snel iets uitgerekend kan worden zou je bijvoorbeeld ook een restrictie op kunnen leggen hoe vaak iemand in een bepaald tijdsbestek kan inloggen? Zelfs al maak je dan gebruik van MD5 of SHA1 (misschien niet aan te raden, maar illustreert wel goed wat ik probeer te zeggen) dan wordt je login al aanzienlijk "veiliger". Al je geld op één oplossing inzetten is sowieso niet verstandig.
En elke oplossing staat of valt toch met de eindgebruiker. Je systeem kan dan nog zo'n goed loginmechanisme hebben, als iemand besluit een memo aan zijn/haar monitor te plakken, hier is geen kruid tegen gewassen.
In eerste instantie kwam het op mij over als een workaround. En inderdaad. De vereiste is dat het wachtwoord minimaal 7 alfanumerieke tekens bevat. En zelf geven ze al aan dat dat gekraakt kan worden in de tijd die nodig is om een diepvriespizza op te warmen. In dat kader vind ik het eigenlijk nog best soepel dat je zo'n wachtwoord 90 dagen mag gebruiken.
En tsja, die beperking dat je de laatste 4 wachtwoorden niet mag hergebruiken is eenvoudig te omzeilen door op 'password changing day' gewoon je wachtwoord 4x te veranderen. Dat zou je weer kunnen ondervangen door in te stellen dat je pas na drie dagen of zo je wachtwoord meer mag veranderen (de organisatie waar ik in een eerdere post over sprak hanteerde zelfs een periode van een week), maar dat lees ik niet terug in de requirements. Zou trouwens ook dom zijn, want als dan na een dag blijkt dat je nieuwe wachtwoord gecompromitteerd is, kun je het de eerste paar dagen niet eens veranderen. ;-)
Wat me een veel werkbaarder compromis zou lijken, is dat de sterkte van je wachtwoord bepaalt hoelang je dat wachtwoord mag gebruiken. Een wachtwoord van 8 tekens moet na uiterlijk een week worden veranderd, een wachtwoord van 9 letters en cijfers na 2 weken, of na 4 weken als er ook andere tekens worden gebruikt, een wachtwoord van 10 tekens na 6 maanden, etc. Op die manier moedig je mensen aan om sterkere wachtwoorden te gebruiken. Afhankelijk van de rechten die een gebruiker heeft zou je een strenger regime kunnen toepassen.
