Hoe lang duurt het voo..
Password_hash uitlezen!
Willem vp op 27/10/2017 18:20:58:
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.
Toms Diner op 26/10/2017 23:09:45:
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,
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.
Ik bewaar geen oude wachtwoorden (de 90 dagen geldt hier kennelijk niet), dus er is telkens maar 1 hash waarvoor deze salt geldt. Dit risico lijkt mij acceptabel, mede ook omdat de genoemde salting niet gedocumenteerd is. Zeg maar een dat alles in één ongedocumenteerde functie gebeurt, die ook even een per gebruiker statische var binnenhaalt. Een random salt per gebruiker zal ik ook ergens op moeten slaan, wat misschien meer opvalt.
En hash collisions spelen toch niet zozeer bij passwords als wel bij zaken als certificaten? Het risico dat iemand wachtwoord geraden kan worden omdat !(@&dh87 dezelfde hash oplevert als &!sdg981-0 is nauwelijks interessant. Wel als ik een fake certificaat voor echt door kan laten gaan...
Toms Diner op 27/10/2017 22:59:57:
Ik bewaar geen oude wachtwoorden (de 90 dagen geldt hier kennelijk niet), dus er is telkens maar 1 hash waarvoor deze salt geldt. Dit risico lijkt mij acceptabel, mede ook omdat de genoemde salting niet gedocumenteerd is. Zeg maar een dat alles in één ongedocumenteerde functie gebeurt, die ook even een per gebruiker statische var binnenhaalt. Een random salt per gebruiker zal ik ook ergens op moeten slaan, wat misschien meer opvalt.
Ga er niet vanuit dat je veiliger bent omdat er het een en ander niet is gedocumenteerd. Al meer dan 150 jaar geleden is de vloer grondig aangeveegd met het fenomeen 'security by obscurity'. Om die reden hoeft een salt ook helemaal niet geheim te zijn. Een algoritme als bcrypt slaat de salt zelfs op in de hash, zodat je daar geen extra veld voor hoeft aan te maken in je database.
Het idee achter een salt is dat het niet loont om een rainbow table te maken, omdat de salt steeds wijzigt. Als je voor elke gebruiker dezelfde salt gebruikt, zaag je voor een deel de poten onder dat principe weg. Er kan dan in ieder geval per gebruiker een rainbow table worden aangemaakt.
Ga bij beveiliging altijd uit van voor jou ongemakkelijke scenario's: iemand is ongemerkt je systeem binnengedrongen en zit al een tijdje mee te kijken. Hij heeft toegang tot je database en je sourcecode en kan op zijn gemak uitzoeken van welke gebruiker het interessant is een wachtwoord te weten. Als hij in je sourcecode -ook al is die ongedocumenteerd; zal hem boeien- ziet dat je per gebruiker altijd dezelfde salt gebruikt, kan hij op zijn gemak een rainbow table laten genereren. Met een beetje geluk wijzigt de betreffende gebruiker een paar dagen later zijn wachtwoord naar iets waarvoor in de tabel al een hash is gegenereerd.
Quote:
En hash collisions spelen toch niet zozeer bij passwords als wel bij zaken als certificaten? Het risico dat iemand wachtwoord geraden kan worden omdat !(@&dh87 dezelfde hash oplevert als &!sdg981-0 is nauwelijks interessant. Wel als ik een fake certificaat voor echt door kan laten gaan...
Ach, als je op die manier het wachtwoord van een gebruiker met veel rechten kunt achterhalen... Dan kun je certificaatjes aanmaken zoveel je wilt. ;-) En wellicht in de database hier en daar een bankrekeningnummer veranderen in dat van je katvanger. De mogelijkheden zijn oneindig. Een certificaat is niet meer dan dat. User accounts zijn veel interessanter.
Willem vp op 28/10/2017 02:00:18:
Met certificaten bedoel ik digital signatures, zoals bij SSL certificaten.
Zie ook wikipediawikipedia: "Digital signature schemes are often vulnerable to hash collisions"
Daarom bedoel ik dat een hash-collision voor passwords niet zo interessant is. Als ik een hash raad met "welkom567" die eigenlijk een collision is van "ditraadjenooit123", was ik gewoon bezig met het raden van wachtwoorden. Ik zal zelfs niet eens weten of het een collision is, of dat ik het echte password geraden heb. Bij digital signatures gaat het er juist om te misleiden door het gebruik van een collision. En ik gok dat de impact vele malen groter kan zijn.
Toms Diner op 27/10/2017 22:59:57:
Ach, als je op die manier het wachtwoord van een gebruiker met veel rechten kunt achterhalen... Dan kun je certificaatjes aanmaken zoveel je wilt. ;-) En wellicht in de database hier en daar een bankrekeningnummer veranderen in dat van je katvanger. De mogelijkheden zijn oneindig. Een certificaat is niet meer dan dat. User accounts zijn veel interessanter.
Met certificaten bedoel ik digital signatures, zoals bij SSL certificaten.
Zie ook wikipediawikipedia: "Digital signature schemes are often vulnerable to hash collisions"
Daarom bedoel ik dat een hash-collision voor passwords niet zo interessant is. Als ik een hash raad met "welkom567" die eigenlijk een collision is van "ditraadjenooit123", was ik gewoon bezig met het raden van wachtwoorden. Ik zal zelfs niet eens weten of het een collision is, of dat ik het echte password geraden heb. Bij digital signatures gaat het er juist om te misleiden door het gebruik van een collision. En ik gok dat de impact vele malen groter kan zijn.
Toms Diner op 28/10/2017 23:15:25:
Met certificaten bedoel ik digital signatures, zoals bij SSL certificaten.
Ik ook. ;-)
Quote:
Daarom bedoel ik dat een hash-collision voor passwords niet zo interessant is. Als ik een hash raad met "welkom567" die eigenlijk een collision is van "ditraadjenooit123", was ik gewoon bezig met het raden van wachtwoorden. Ik zal zelfs niet eens weten of het een collision is, of dat ik het echte password geraden heb. Bij digital signatures gaat het er juist om te misleiden door het gebruik van een collision. En ik gok dat de impact vele malen groter kan zijn.
Waarom zou een collision voor wachtwoorden minder interessant zijn? In wezen in een certificaat niets anders dan een wachtwoord. (Sterker nog: ik gebruik een certificaat ter vervanging van mijn wachtwoord voor SSH-sessies.) Hooguit is bij een certificaat de hash langer, waardoor hij minder snel te kraken is.
En dan wordt het wachtwoord toch weer interessant. Als je het wachtwoord weet van een gebruiker met de juiste systeemrechten, kun je de private key in handen krijgen, het bestaande certificaat re-issuen en/of een stel nieuwe certificaten aanvragen, waardoor je pogingen om gebruikers te misleiden er nog veel echter uit kunnen zien dan wanneer je alleen een gecompromitteerd certificaat tot je beschikking hebt. En dan laat ik een heleboel andere stoute dingetjes nog buiten beschouwing. Zoals gezegd: het is leuk als je een collision hebt gevonden op een certificaathash, maar een collision op een passwordhash is oneindig veel leuker.
Willem vp op 29/10/2017 10:42:15:
Ik ook. ;-)
Waarom zou een collision voor wachtwoorden minder interessant zijn? In wezen in een certificaat niets anders dan een wachtwoord. (Sterker nog: ik gebruik een certificaat ter vervanging van mijn wachtwoord voor SSH-sessies.) Hooguit is bij een certificaat de hash langer, waardoor hij minder snel te kraken is.
En dan wordt het wachtwoord toch weer interessant. Als je het wachtwoord weet van een gebruiker met de juiste systeemrechten, kun je de private key in handen krijgen, het bestaande certificaat re-issuen en/of een stel nieuwe certificaten aanvragen, waardoor je pogingen om gebruikers te misleiden er nog veel echter uit kunnen zien dan wanneer je alleen een gecompromitteerd certificaat tot je beschikking hebt. En dan laat ik een heleboel andere stoute dingetjes nog buiten beschouwing. Zoals gezegd: het is leuk als je een collision hebt gevonden op een certificaathash, maar een collision op een passwordhash is oneindig veel leuker.
Toms Diner op 28/10/2017 23:15:25:
Met certificaten bedoel ik digital signatures, zoals bij SSL certificaten.
Ik ook. ;-)
Quote:
Daarom bedoel ik dat een hash-collision voor passwords niet zo interessant is. Als ik een hash raad met "welkom567" die eigenlijk een collision is van "ditraadjenooit123", was ik gewoon bezig met het raden van wachtwoorden. Ik zal zelfs niet eens weten of het een collision is, of dat ik het echte password geraden heb. Bij digital signatures gaat het er juist om te misleiden door het gebruik van een collision. En ik gok dat de impact vele malen groter kan zijn.
Waarom zou een collision voor wachtwoorden minder interessant zijn? In wezen in een certificaat niets anders dan een wachtwoord. (Sterker nog: ik gebruik een certificaat ter vervanging van mijn wachtwoord voor SSH-sessies.) Hooguit is bij een certificaat de hash langer, waardoor hij minder snel te kraken is.
En dan wordt het wachtwoord toch weer interessant. Als je het wachtwoord weet van een gebruiker met de juiste systeemrechten, kun je de private key in handen krijgen, het bestaande certificaat re-issuen en/of een stel nieuwe certificaten aanvragen, waardoor je pogingen om gebruikers te misleiden er nog veel echter uit kunnen zien dan wanneer je alleen een gecompromitteerd certificaat tot je beschikking hebt. En dan laat ik een heleboel andere stoute dingetjes nog buiten beschouwing. Zoals gezegd: het is leuk als je een collision hebt gevonden op een certificaathash, maar een collision op een passwordhash is oneindig veel leuker.
Wij kijken hier echt verschillend tegenaan. In het eerste geval (user pass) neem je iemands rechten over, in het tweede geval (een certificaat met dezelfde hash) niet. Maar je kunt zonder dat die server beinvloed wordt, wel de clients in de waan laten dat je daar vandaan komt... Dat je namens die server spreekt, enzovoort. (Zie ook die wiki link die ik postte) Je reactie daarop is dat je met een gejat userpassword hetzelfde kan, maar ik kan geen situatie bedenken waarin dat kan. Je zal algauw 3-6 wachtwoorden moet kraken, want voor een certificaat zul je ook de mail van die persoon over moeten nemen, en met mijn admin wachtwoorden kom je ook weer niet op de server... Het gaat hier om iets groters dan "stout" doen op een website. Ik zou een groen slotje kunnen tonen op "mijnd1gid.nl", betalingen kunnen vervalsen, zelf certificaten uitgeven, enzovoort. Ik zie jou redenatie niet zo.