Tijden veranderen
Password_hash uitlezen!
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.
Kan iemand mij uitleggen hoe ik dit wil kan doen?
Mvg,
Nick
Ik denk dat je bedoelt of je het originele wachtwoord kunt tonen. Het antwoord is nee.
Oke dan weet ik genoeg Bedankt!
Dat is natuurlijk niet het antwoord waarop je zit te wachten.
De meeste wachtwoord hashes zijn niet reversible hetgeen wil zeggen dat je van 'Frank' wel '0df02da8548eeef2174c97c2ade67b4c5adc3160' kunt maken maar andersom niet.
Maar misschien is het handig als je je probleem wat meer uitlegt.
Echter dit is echt NIET bedoeld om passwords mee te gaan encrypten
Gewijzigd op 24/10/2017 17:49:13 door Frank Nietbelangrijk
Deze truc kan niet bij andere users: ze zullen doorhebben dat hun wachtwoord veranderd is.
Zijn hashes dan niet te kraken? Niet met een formule. Vergelijk het met een sinus of cosinus berekening: als je de output weet, kun je onmogelijk de input raden. Hetzelfde met restwaarde berekeningen: neem een getal in gedachte (tussen de 100 en de 999), en onthoud de rest bij een deling door 7. Dat getal is niet meer te herleiden naar het getal wat je in je hoofd had.
Een hash berekening is dus een soort controlegetal, en het is niet ondenkbaar dat er in theorie meerdere passwords zijn met dezelfde hash. Overigens is de berekening zo gekozen dat het veranderen van 1 letter in een password van 20 tekens tot een totaal verschillende hash leidt: niet één teken is gelijk... En bij het inloggen op een site zou het dus in theorie ook kunnen dat een ander password met dezelfde hash ook toegang biedt. Maar die kans is bijna net zo groot als zes keer de staatsloterij in een jaar winnen.
Een inlogfunctie genereert dus bij het inschrijven de hash van het password, en onthoudt deze. Bij een inlogpoging wordt hetzelfde trucje gedaan, waarna de hash vergeleken wordt met een opgeslagen hash. Op deze manier kan je op een veilige website (zonder overname users-sessie door admin) een goede logging bij houden: niemand kan elkaars rol overnemen, zelfs als hij toegang heeft tot de hashes. Je zult immers het wachtwoord moeten veranderen om je voor te doen als iemand anders, en dat gaat die persoon merken.
Maar zijn hashed helemaal onkraakbaar? Dat hangt er vanaf. De hash van "Welkom123" of "12345" of "datraadjenooit" is op heel veel servers aanwezig. In tegenstelling tot "*us1&*Skj09aUY". 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.
Rob Doemaarwat op 25/10/2017 07:53:04:
Rainbow tables gaan hier niet werken. Omdat er "zout" wordt toegevoegd zal hetzelfde wachtwoord (zonder kennis van het gebruikte "zout") steeds een andere hash genereren. Alleen als je inderdaad een "vrij standaard" wachtwoord hebt zou je nog een "woordenboek aanval" (= alle "bekende" wachtwoorden proberen) kunnen doen. Brute-force (= alle combinaties van alle karakters proberen) is niet te doen.
Ehhh... Waar lees jij dat? Ik zie in de info van de TS nergens een aanwijzing dat salting speelt.. En mocht hij wel gesalte hashes hebben: daar waarschuw ik in mijn post zelf ook al voor....
Quote:
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).
Thomas van den Heuvel op 26/10/2017 13:34:50:
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).
Quote:
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.
Rob Doemaarwat op 25/10/2017 23:06:23:
Hij heeft het over password_verify(), dan begin je bij password_hash(), en die voegt zelf zout toe: http://php.net/manual/en/function.password-hash.php
?
Lees nog eens wat hij schrijft? Dat was een term die hij op google vond.....
Toms Diner op 26/10/2017 23:09:45:
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 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.
Quote:
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.
Quote:
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.
Willem vp op 27/10/2017 18:20:58:
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.
Hoe zou jij dit oplossen?
Ward van der Put op 27/10/2017 18:33:37:
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?
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. :-/
Gewijzigd op 27/10/2017 18:47:12 door Willem vp
Willem vp op 27/10/2017 18:39:24:
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.
Eens, maar dit is een van hogerhand opgelegde vereiste.
Op het onveiliger hashen van een onveilig verklaard wachtwoord was ik zelf nooit gekomen.
Dank!! Dat sowieso zo op de vrijdagavond!
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.
Gewijzigd op 27/10/2017 19:50:44 door Thomas van den Heuvel
Ward van der Put op 27/10/2017 19:10:08:
Eens, maar dit is een van hogerhand opgelegde vereiste.
Tsja, hogerhand... dat bewijst maar weer eens dat you don't need a brain to be a boss.
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.
https://github.com/dropbox/zxcvbn