[privacy] Wachtwoord ongecodeerd opslaan toegestaan?

[Verwijderd]

Zie de titel. Weet niet of ik hier goed zit maar goed.

Ik heb een situatie (niet zelf gecreerd ) waarbij wachtwoorden van derden ongecodeerd in een mysql database worden opgeslagen. Nu rees bij mij de vraag, oa na het lezen van dit topic en ook deze, of dit wettelijk is toegestaan?

Het gaat mij dus niet zozeer om het feit of gecodeerd of ongecodeerd opslaan beter is. Daar zijn genoeg topics over. Het gaat mij meer om de vraag of het ongecodeerd opslaan van wachtwoordgegevens, wat redelijk vertrouwelijk is lijkt mij, wettelijk is toegestaan (wet bescherming persoonsgegevens, wet persoonsregistratie oid).

[ Voor 4% gewijzigd door Verwijderd op 17-05-2004 15:11 ]

[NMe]

Volgens mij zijn daar geen wettelijke bepalingen over. Maar ik vind het wel een principekwestie, als goeie programmeur codeer je paswoorden als extra beveiliging.

[ripexx]

Het ligt een beetje aan de branche waar je in zit. Als jij verantwoordelijk en/of aansprakelijk kan worden gesteld dan kan je er niet om heen. Ik weet niet wat de WBP er van zegt maar die is toch wel ergens op het internet te vinden?

[Dutchmega]

Tja.. Hier kan een leuke discussie uit ontstaan... Want als je netjes bent sla je het gecodeerd op maar je kan het anders zien: als iemand toegang heeft tot de db, heeft hij/zij waarschijnlijk ook de rechten om te wijzigen/verwijderen.
Dan is het een koud kunstje om de wachtwoord te verwijderen tenzij je niet weet welke codering het is... (Meestal md5 )

[ Voor 2% gewijzigd door Dutchmega op 17-05-2004 15:25 . Reden: typefouten ]

[Erkens]

Dutchmega schreef op 17 mei 2004 @ 15:25:
Tja.. Hier kan een leuke discussie uit ontstaan... Want als je netjes bent sla je het gecodeerd op maar je kan het anders zien: als iemand toegang heeft tot de db, heeft hij/zij waarschijnlijk ook de rechten om te wijzigen/verwijderen.
Dan is het een koud kunstje om de wachtwoord te verwijderen tenzij je niet weet welke codering het is... (Meestal md5 )

helemaal waar, echter wat vaak gebeurd is dat mensen overal dezelfde passwords gebruiken, en dan is het voor iemand een koud kunstje om dezelfde username/pass overal te proberen.
Tuurlijk moet je je db admin vertrouwen, echter er kan altijd iemand op zijn scherm meekijken

[Markieman]

Hoe jij een wachtwoord, of welke gegevens dan ook, opslaat in een database is geheel jouw zaak.

Qua wetgeving gaat het er alleen om dat je voorzichting om moet gaan met gegevens die herleidbaar zijn tot een individuele natuurlijke persoon.

Dit houdt in dat je zulke gegevens alleen mag bewaren/gebruiken als het echt noodzakelijk is voor het goed functioneren van je website/bedrijf/etc. Verspreiding aan derden heb je dacht ik toestemming van de betreffende persoon nodig. Dit houdt dus in dat je verantwoordelijk bent voor het in andere handen vallen van die gegevens.

Echter het wachtwoord in de DB encrypten heeft geen enkele zin, als iemand in de DB komt dan kan hij ook bij de persoonlijke gegevens

[ Voor 20% gewijzigd door Markieman op 17-05-2004 15:31 ]

[NMe]

Erkens schreef op 17 mei 2004 @ 15:27:
[...]

helemaal waar, echter wat vaak gebeurd is dat mensen overal dezelfde passwords gebruiken, en dan is het voor iemand een koud kunstje om dezelfde username/pass overal te proberen.
Tuurlijk moet je je db admin vertrouwen, echter er kan altijd iemand op zijn scherm meekijken

DB admin zomaar vertrouwen? Slecht idee hoor. Ik vertrouw niemand mijn wachtwoord zomaar toe. Ik gebruik voor belangrijke dingen altijd hetzelfde wachtwoord, maar alleen als ik denk die site/applicatie te kunnen vertrouwen.

offtopic:
Mensen gebruiken inderdaad vaak overal hetzelfde wachtwoord. Ik moest een keer iemands CU2 aanpassen, dus ik kreeg haar wachtwoord. Ff gekeken of ik daarmee ook in haar email kwam, en jawel hoor....

[Verwijderd]

ripexx schreef op 17 mei 2004 @ 15:20:
Het ligt een beetje aan de branche waar je in zit. Als jij verantwoordelijk en/of aansprakelijk kan worden gesteld dan kan je er niet om heen. Ik weet niet wat de WBP er van zegt maar die is toch wel ergens op het internet te vinden?

Ja deze WBP is wel op Inet te vinden hier bijvoorbeeld, maar die schrijft dus niet over het hoe of wat betreffende het opslaan van gegevens. Wel dat je het alleen voor een bepaald aantoonbaar doel mag gebruiken, niet te lang mag bewaren enz enz. Maar over de wijze waarop gegevens en dan met name dergelijke belangrijke gegevens, worden opgeslagen wordt niet besproken.


De opmerking dat gebruikers vaak overal dezelfde wachtwoorden gebruiken is ook zinnig. Wil je kwaad, dan moet je alleen nog achterhalen waar je die gegevens zou kunnen toepassen. Dus vanuit dat oogpunt zou je al zeggen: Alleen gecodeerd opslaan.

[Erkens]

NMe84 schreef op 17 mei 2004 @ 15:31:
[...]

DB admin zomaar vertrouwen? Slecht idee hoor. Ik vertrouw niemand mijn wachtwoord zomaar toe. Ik gebruik voor belangrijke dingen altijd hetzelfde wachtwoord, maar alleen als ik denk die site/applicatie te kunnen vertrouwen.

ehm, als je je DB admin niet vertrouwt dan zou ik als ik jou was dat of zelf doen of snel een ander gaan zoeken [/ot]

[Verwijderd]

NMe84 schreef op 17 mei 2004 @ 15:31:
[...]

DB admin zomaar vertrouwen? Slecht idee hoor. Ik vertrouw niemand mijn wachtwoord zomaar toe. Ik gebruik voor belangrijke dingen altijd hetzelfde wachtwoord, maar alleen als ik denk die site/applicatie te kunnen vertrouwen.

Een DB admin van een bedrijf waar je werkt vertrouw je niet en een site/applicatie wel ?

[tofus]

Wachtwoorden ongecodeerd opslaan is vanuit wettelijk oogpunt absoluut niet illegaal.

Wat wel een juridisch probleem kan opleveren, is wanneer je je klanten WEL wijsmaakt dat je zeer zorgvuldig met 'gevoelige' informatie omspringt...want dat is dus niet het geval. Klanten zouden je op deze manier dus achteraf (bij problemen i.v.m. 'gelekte' wachtwoorden) kunnen aanklagen, omdat je niet het product hebt geleverd wat je beloofd/toegezegd hebt (en waarvoor de klant dus betaald heeft).

Als je echter geheel niet pretendeert een 'secure' of 'veilig' systeem te hebben, lijken juridische problemen me redelijk uitgesloten.

Je moet jezelf echter wel erg afvragen WAAROM je onencrypted passwords wil opslaan. Passwords zijn gewoon veel te gevoelig om unencrypted te bewaren. Zelfs in een database waar slechts enkele personen toegang toe hebben.

Als je niet echt een hele goede reden hebt om passwords unencrypted op te slaan, zou ik gewoon de raad van security experts volgen; en die beweren allemaal dat unencrypted passwords 'bad practice' zijn.

[ Voor 14% gewijzigd door tofus op 17-05-2004 15:40 ]

[TRON]

Gecodeerd opslaan is een 'must' vind ik. Zelf sla ik ook alles gecodeerd op. Ten eerste omdat ik met regelmaat via phpMyAdmin kijk in de databases en niet de wachtwoorden wil kunnen zien. Omdat wachtwoorden veelal hetzelfde zijn.

En stel je voor dat iemand anders je database kan bekijken. Dan staan de wachtwoorden open en bloot. Denk hierbij nog eens aan die bug in Yabbse, daar kon je door een fout dmv een LEFT JOIN en een UNION alle gecodeerde wachtwoorden zien. Stel je voor dat die wachtwoorden niet gecodeerd zouden zijn.

Nog een probleem is, dat als ik een siteadmin ben van mijn eigen domein. Dan kunnen andere gebruikers die ik aanmaak ook de database volledig bekijken via FTP/SSH. Het gaat hier dan wel over een kleine fout door Ensim, maar 'k bedoel maar. Stel dat je eigen wachtwoord ook in de database zou staan en Pietje die ook een account heeft bij je, die gaat die database eens doorneuzen.

[Dutchmega]

NMe84 schreef op 17 mei 2004 @ 15:31:
[...]

DB admin zomaar vertrouwen? Slecht idee hoor. Ik vertrouw niemand mijn wachtwoord zomaar toe. Ik gebruik voor belangrijke dingen altijd hetzelfde wachtwoord, maar alleen als ik denk die site/applicatie te kunnen vertrouwen.

offtopic:
Mensen gebruiken inderdaad vaak overal hetzelfde wachtwoord. Ik moest een keer iemands CU2 aanpassen, dus ik kreeg haar wachtwoord. Ff gekeken of ik daarmee ook in haar email kwam, en jawel hoor....

Meerdere dezlefde wachtwoorden zijn wel handig maar gevaarlijk. Ik gebruik zelf voor alle belangrijke dingen een apart wachtwoord. Dus ik gebruik eigenlijk maar 2/3 wachtwoorden (die ik bepaal naar mate de veiligheid en belangrijkheid van de site).

Erkens schreef op 17 mei 2004 @ 15:27:
[...]

helemaal waar, echter wat vaak gebeurd is dat mensen overal dezelfde passwords gebruiken, en dan is het voor iemand een koud kunstje om dezelfde username/pass overal te proberen.
Tuurlijk moet je je db admin vertrouwen, echter er kan altijd iemand op zijn scherm meekijken

Tja, als je dit feit meetelt, dan zou je eigenlijk gewoon het ge-encodeerd moeten opslaan. Het heeft vrijwel geen nadelen op klein beetje werk na

Markieman schreef op 17 mei 2004 @ 15:30:
Hoe jij een wachtwoord, of welke gegevens dan ook, opslaat in een database is geheel jouw zaak.

Qua wetgeving gaat het er alleen om dat je voorzichting om moet gaan met gegevens die herleidbaar zijn tot een individuele natuurlijke persoon.

Dit houdt in dat je zulke gegevens alleen mag bewaren/gebruiken als het echt noodzakelijk is voor het goed functioneren van je website/bedrijf/etc. Verspreiding aan derden heb je dacht ik toestemming van de betreffende persoon nodig. Dit houdt dus in dat je verantwoordelijk bent voor het in andere handen vallen van die gegevens.

Echter het wachtwoord in de DB encrypten heeft geen enkele zin, als iemand in de DB komt dan kan hij ook bij de persoonlijke gegevens

Ligt eraan waar je zit.. Als je op een eenvoudig forumpje bent aangemeld, achter de gegevens komt en inlogt op een site waar alle gegevens van jezelf staat.....

offtopic:
Volgens mij is niet alles goed Nederlands maargoed

[Erkens]

Dutchmega schreef op 17 mei 2004 @ 15:45:
Tja, als je dit feit meetelt, dan zou je eigenlijk gewoon het ge-encodeerd moeten opslaan. Het heeft vrijwel geen nadelen op klein beetje werk na

mja, je moet iets meer dev werk verrichten als een user zijn password kwijt is. unencrypted stuur je "gewoon" het password op
encrypted zou je dus kunnen kiezen voor een systeem dat een user zijn mail adres opgeeft en dat je dan een nieuwe maakt, echter dat moet je wel beveiligen, want anders iedereen andere users pesten door nieuwe passwords aan te vragen etc.

[TRON]

Erkens, dat heb ik ooit opgelost door men dan met beide wachtwoorden in te kunnen laten loggen. Als men met het oude password inlogde, dan verviel het nieuwe automagisch. Logde men in met het nieuwe wachtwoord, dan verving het nieuwe wachtwoord het oude. Maar goed dat lijkt me allemaal vanzelf sprekend enzo

[Verwijderd]

tofus schreef op 17 mei 2004 @ 15:38:

Wat wel een juridisch probleem kan opleveren, is wanneer je je klanten WEL wijsmaakt dat je zeer zorgvuldig met 'gevoelige' informatie omspringt...want dat is dus niet het geval. Klanten zouden je op deze manier dus achteraf (bij problemen i.v.m. 'gelekte' wachtwoorden) kunnen aanklagen, omdat je niet het product hebt geleverd wat je beloofd/toegezegd hebt (en waarvoor de klant dus betaald heeft).

Als je echter geheel niet pretendeert een 'secure' of 'veilig' systeem te hebben, lijken juridische problemen me redelijk uitgesloten.

...

En dan vraag ik me nu af: Als er niet is bepaald hoe gegevens opgeslagen dienen te worden (gecodeerd, ongecodeerd). Hoe kun je dan bepalen dat je onzorgvuldig met 'gevoelige' informatie omspringt? Er bestaan immers geen richtlijnen voor. Of is dit te zifterig?

offtopic:
Ben je dan ook verplicht een disclaimer / algemene voorwaarden op je site te plaatsen?

[Erkens]

TRON schreef op 17 mei 2004 @ 15:53:
Erkens, dat heb ik ooit opgelost door men dan met beide wachtwoorden in te kunnen laten loggen. Als men met het oude password inlogde, dan verviel het nieuwe automagisch. Logde men in met het nieuwe wachtwoord, dan verving het nieuwe wachtwoord het oude. Maar goed dat lijkt me allemaal vanzelf sprekend enzo

yup, en dus is het meer dev-werk

offtopic:
en er zijn tig andere manieren om _dat_ probleem op te lossen uiteraard

[tofus]

Verwijderd schreef op 17 mei 2004 @ 15:56:
[...]


En dan vraag ik me nu af: Als er niet is bepaald hoe gegevens opgeslagen dienen te worden (gecodeerd, ongecodeerd). Hoe kun je dan bepalen dat je onzorgvuldig met 'gevoelige' informatie omspringt? Er bestaan immers geen richtlijnen voor. Of is dit te zifterig?

offtopic:
Ben je dan ook verplicht een disclaimer / algemene voorwaarden op je site te plaatsen?

Je bent inderdaad verplicht om zorg te dragen voor persoons-gerelateerde informatie. Maar hiermee worden voornamelijk persoonsgegevens bedoelt, en met 'zorgvuldig' wordt bedoeld dat deze gegevens niet voor jan en alleman benaderbaar of opvraagbaar zijn (tenzij dit expliciet in een disclaimer aan de gebruiker wordt vermeld).

Losse password-gegevens vallen (voor zover bij mij bekend) niet direkt onder de Wet Persoonsregistratie.

Maar als je er echt 't fijne van wilt weten, adviseer ik je om contact op te nemen met een juridisch adviesburo (of een informatieve website van de overheid over persoonregistratie te bezoeken).

[ Voor 5% gewijzigd door tofus op 17-05-2004 16:05 ]

[Verwijderd]

.

[ Voor 99% gewijzigd door Verwijderd op 31-10-2023 22:28 ]

[Verwijderd]

Verwijderd schreef op 17 mei 2004 @ 16:14:
...
Laat je gezond verstand ook voldoende meewegen! Hub: beveiligen dat ding! Dat is vast niet heel veel werk!

Veel werk niet denk ik idd. Maar nu nog de verantwoordelijken overtuigen. Ik had ze graag een juridisch 'zwaard' boven het hoofd gehangen als extra motivatie

[Verwijderd]

.

[ Voor 99% gewijzigd door Verwijderd op 31-10-2023 22:29 ]

[Verwijderd]

@hasse_m You're right. Een juridische inzet was echter niet mijn eerste, enige en laatste invalshoek. Ik bedoel eigenlijk meer dat het mogelijk wel de doorslaggevende invalshoek had kunnen zijn.

[ Voor 17% gewijzigd door Verwijderd op 17-05-2004 16:45 ]

[Verwijderd]

Wet Bescherming Persoonsgegevens:

Artikel 10

1. Persoonsgegevens worden niet langer bewaard in een vorm die het mogelijk maakt de betrokkene te identificeren, dan noodzakelijk is voor de verwerkelijking van de doeleinden waarvoor zij worden verzameld of vervolgens worden verwerkt.

Met een wachtwoord kun je een persoon identificeren (nouwja, bijna dan, misschien zijn er wel 2 mensen met hetzelfde wachtwoord). Een hash is onomkeerbaar en hiermee weet je dus zeker dat iemand niet meer kan identificeren.

Het is nog steeds niet zwart/wit, maar de toon lijkt me gezet. Je moet je gegevens 'redelijkerwijs' goed beveiligen. Een hash lijkt me hieraan te voldoen.

[tofus]

Verwijderd schreef op 17 mei 2004 @ 17:24:
Wet Bescherming Persoonsgegevens:

[...]


Met een wachtwoord kun je een persoon identificeren (nouwja, bijna dan, misschien zijn er wel 2 mensen met hetzelfde wachtwoord). Een hash is onomkeerbaar en hiermee weet je dus zeker dat iemand niet meer kan identificeren.

Dan daag ik jou bij deze uit om mij aan de hand van mijn wachtwoord te identificeren. Mijn (unencrypted) wachtwoord is: 'K03iEn%'...

...ik zie je ansichtkaartje met spanning tegemoet ;p

[TRON]

Verwijderd schreef op 17 mei 2004 @ 17:24:
Wet Bescherming Persoonsgegevens:

[...]


Met een wachtwoord kun je een persoon identificeren (nouwja, bijna dan, misschien zijn er wel 2 mensen met hetzelfde wachtwoord). Een hash is onomkeerbaar en hiermee weet je dus zeker dat iemand niet meer kan identificeren.

Het is nog steeds niet zwart/wit, maar de toon lijkt me gezet. Je moet je gegevens 'redelijkerwijs' goed beveiligen. Een hash lijkt me hieraan te voldoen.

Een hash is onomkeerbaar ja, maar MD5('hallo') == MD5('hallo'). Dus ehh, je kan elkaar dan als nog 'identificeren'. Want iedereen heeft een eigen hash, omdat vrijwel iedereen een ander wachtwoord heeft.

[Tomatoman]

Het is een beetje kort door de bocht om te zeggen dat het volgens de Wet Bescherming Persoonsgegevens niet is toegestaan om wachtwoorden ongecodeerd op te slaan. De beveiliging om de wachtwoorden ontoegankelijk te maken voor onbevoegden kan namelijk ook op allerlei andere manieren worden geïmplementeerd. Als de server waar de wachtwoorden op staan goed is beveiligd, kan dat op zichzelf al genoeg zijn.

Omgekeerd heeft het weinig zin om wachtwoorden te versleutelen als de wachtwoorden gemakkelijk te raden zijn (bijvoorbeeld als gebruikers hun wachtwoord op een post-it op de monitor plakken). In zo'n geval leidt wachtwoordcodering tot geen enkele extra bescherming van de persoonsgegevens en is derhalve irrelevant.

De kern van de zaak ligt erin dat je de persoonsgegevens beschermt, niet zozeer hoe je dat doet. Wachtwoorden al dan niet coderen is slechts een kwestie van implementatie.

[Verwijderd]

Het is misschien verstandig in te zien dat als jij je aanmeld op een site, die site van jou niet verwacht 'jouw eigen persoonlijk wachtwoord' in te voeren. De site vraagt aan jou of jij een code wilt bedenken waarmee jij je 'op dat systeem' kunt identificeren. Het princiepe achter dit systeem is dus dat er een stricte wederzijdse afhankelijkheid is tussen dat wachtwoord en de desbetreffende site.

Een wachtwoord is dus geen 'persoonsgegeven'.

Uitgaande van dat idee is het encrypten van ww's een leuk extraatje, maar geen extra beveiliging. De user moet hier echter zelf wel bewust van zijn.

[Erkens]

tomatoman schreef op 17 mei 2004 @ 21:24:
Omgekeerd heeft het weinig zin om wachtwoorden te versleutelen als de wachtwoorden gemakkelijk te raden zijn (bijvoorbeeld als gebruikers hun wachtwoord op een post-it op de monitor plakken). In zo'n geval leidt wachtwoordcodering tot geen enkele extra bescherming van de persoonsgegevens en is derhalve irrelevant.

In dat geval ligt de verantwoordelijkheid bij de gebruiker.

Zelf zie ik een wachtwoord niet als een persoonsgegeven, getuige het feit dat een wachtwoord vaak (kan) veranderen, ik zie een wachtwoord ook als een sleutel waarmee je toegang krijgt tot het systeem en het is dus een hulpmiddel om personen te identificeren in combinatie met de gebruikersnaam, maar daarmee geeft een wachtwoord geen informatie over deze user, iets wat een gebruikersnaam wel doet, en daarom valt een wachtwoord buiten deze wet volgens mij.
Echter een wachtwoord is de beveiliging van de gegevens welke wel iets vertellen over een gebruiker, dus dit wachtwoord dient gewoon zorgvuldig mee om gegaan te worden.

[Verwijderd]

Het maakt geen bal uit of je je wachtwoorden met MD5 opslaat of niet. Een Hash is snel te kraken, ik geloofde het eerst ook niet, maar een tijd geleden beweerde iemand op tweakers elke hash binnen korte tijd te kunnen kraken, ik gaf hem een samengestelde hash en binnen een uur had hij hem
Bovendien, wanneer iemand in je DB kan rommelen, dan update hij gewoon het wachtwoord naar één naar eigen keuze.
Gecodeerd opslaan is echt een schijnbeveiliging.

[Verwijderd]

Verwijderd schreef op 17 mei 2004 @ 22:34:
Het maakt geen bal uit of je je wachtwoorden met MD5 opslaat of niet. Een Hash is snel te kraken, ik geloofde het eerst ook niet, maar een tijd geleden beweerde iemand op tweakers elke hash binnen korte tijd te kunnen kraken, ik gaf hem een samengestelde hash en binnen een uur had hij hem
Bovendien, wanneer iemand in je DB kan rommelen, dan update hij gewoon het wachtwoord naar één naar eigen keuze.
Gecodeerd opslaan is echt een schijnbeveiliging.

Niet helemaal. Je applicatie zelf wordt er op zich niet veiliger van. Maar de gegevens (het wachtwoord) van de gebruiker is wel veel beter beveiligd als in: je weet het wachtwoord nog niet dus je kunt niet bijvoorbeeld ook meteen iemands mail bekijken omdat hij hetzelfde wachtwoord gebruikt, of inloggen op zijn PC, of iets dergelijks.

En dat hashes te kraken zijn, dat is min of meer waar. Maar ik voel me er best veilig bij als ik weet dat dat veel langer duurt dan een uurtje. Of wilde je beweren dat je zo even 2^128 strings hebt geprobeerd?

[Erkens]

Verwijderd schreef op 17 mei 2004 @ 22:34:
Het maakt geen bal uit of je je wachtwoorden met MD5 opslaat of niet. Een Hash is snel te kraken, ik geloofde het eerst ook niet, maar een tijd geleden beweerde iemand op tweakers elke hash binnen korte tijd te kunnen kraken, ik gaf hem een samengestelde hash en binnen een uur had hij hem

mag ik hier bewijs voor zien?

Bovendien, wanneer iemand in je DB kan rommelen, dan update hij gewoon het wachtwoord naar één naar eigen keuze.

True, maar daarom vermelde ik eerst ook dat als je je DB admin al niet vertrouwt...
Echter het punt is dat veel mensen vaak dezelfde passwords gebruiken, en derhalve wil je niet dat passwords direct zijn.

Gecodeerd opslaan is echt een schijnbeveiliging.

Lekker als er een bug in je applicatie zit waarbij er passwords lekken, dan liever het gecodeerde password wat lekt dan de real passwords
En ook wat ik al eerder zei, wat als iemand mee kijkt op je scherm wanneer je bezig bent met onderhoud aan de database? Dus ja het is wel een beveiliging. Zelfs al zou dat md5 omkeerbaar zijn (wat het niet is)

[Verwijderd]

Ik weet dat er databases zijn, opgebouwd door crackers waarin letterlijk miljoenen hashes staan. Hash invoeren en hij spuugt wel een wachtwoord uit.
Die databases zijn opgebouwd door servercapaciteit van anderen te gebruiken en de boel snel weer over hevelen naar een andere server...
Maar goed, 't is wel waar als je zegt: beter iets dan niets...

Gecodeerd opslaan is echt een schijnbeveiliging.

Er had beter kunnen staan:

Gecodeerd opslaan kan een schijnbeveiliging zijn.


Ik zie vaak mensen die wachtwoorden gecodeerd opslaan en dan denken dat het veilig is. Kwam ooit iemand tegen die via JS aan de client side het wachtwoord al versleutelde; dan kan een hacker nooit het wachtwoord onderscheppen.
Aan de server-side gebeurde er niets meer met de hash, alleen een simpele vergelijking.
Het onderscheppen van de hash had dus hetzelfde resultaat aangezien de cracker gewoon de platte hash kon versturen.
Zo bedoel ik maar, gecodeerd opslaan, hoeft niet veilig te zijn, en dan bedoel ik, veilig in dat specifieke systeem.

[ Voor 51% gewijzigd door Verwijderd op 17-05-2004 22:49 ]

[Verwijderd]

Verwijderd schreef op 17 mei 2004 @ 22:46:
Ik weet dat er databases zijn, opgebouwd door crackers waarin letterlijk miljoenen hashes staan. Hash invoeren en hij spuugt wel een wachtwoord uit.
Die databases zijn opgebouwd door servercapaciteit van anderen te gebruiken en de boel snel weer over hevelen naar een andere server...
Maar goed, 't is wel waar als je zegt: beter iets dan niets...

En stel je eens voor dat van alle strings korter dan 50 tekens die hashes bekend waren. Duurt het dan minder lang voor je het wachtwoord erbij gevonden hebt? Als iemand een verdomd eenvoudig wachtwoord bedenkt, dan is dat in ieder geval niet jouw fout.

[Verwijderd]

Ik kan me vergissen hoor (maar dat denk ik niet), maar bij verschillende sleutels kan dezelfde hash horen... Zolang je dus niet héél goed weet hoe je een goede beveiliging met gecodeerde wachtwoorden moet maken, heeft het geen enkel nut om ze gecodeerd op te slaan. (behalve het feit dat mensen lui zijn en overal hetzelfde wachtwoord voor nemen)

[.oisyn]

Ok, leuk rekensommetje. Er bestaan 2¹²⁸ verschillende hashes, in decimale notatie is dat iets meer dan 3.40282 * 10³⁸.

Stel dat je per hash de kleinst mogelijke string gaat opslaan die bij die hash hoort. En stel dat de gemiddelde lengte van al die strings 6 tekens is (deze schatting is eigenlijk veel te laag).

De hash zelf is 128 bits, wat neer komt op 16 tekens. In totaal moeten er dus (16 + 6) * 3.40282 * 10³⁸ = 7.48621 * 10³⁹ bytes opgeslagen worden. Dat is 6.80867²⁷ terabyte aan data.

Als je alle schijfruimte op deze aardbol bij elkaar voegt kom je nog niet eens op zoveel

Stel je slaat slechts een miljard hashes op, dan is dat nog altijd ongeveer 1/3³⁰e deel. Ik durf al mijn bezittingen er wel op in te zetten dat mijn password daar niet tussen staat

In principe is het opslaan van hashes niet effectiever dan een dictionary attack. Als de mensen gewoon zorgen dat ze geen woorden en namen gebruiken als wachtwoorden is er niets aan de hand

[ Voor 3% gewijzigd door .oisyn op 17-05-2004 23:14 ]

[Verwijderd]

Het grappige van MD5 is dat het een ad-hocalgoritme is en de werkwijze is te vergelijken met die van symmetrische encryptiealgoritmen. Door het gebrek aan structuur is er over de veiligheid van de functies weinig te bewijzen.
Zelfde geldt trouwens voor SHA (hash 160 bits).
De veiligheid is niet te bewijzen en iedereen gebruikt het... Of heb ik mijn boek over cryptografie verkeerd gelezen?

[.oisyn]

En wat is nou precies het punt dat je met die opmerking probeert te maken

[curry684]

Verwijderd schreef op 17 mei 2004 @ 22:46:
Ik weet dat er databases zijn, opgebouwd door crackers waarin letterlijk miljoenen hashes staan. Hash invoeren en hij spuugt wel een wachtwoord uit.

Lekker boeiend, daarom trek je ook nooit een hash van alleen het password maar van een custom combinatie van username en password naar eigen keuze (concat met of zonder random tussenvullingen e.d.). Als je dat niet doet hebben 2 gebruikers met hetzelfde password dezelfde hash, wat een securityleak is, en is een dictionary of andere brute force attack inderdaad mogelijk.

Ik heb hier een stuk over in de P&W FAQ geschreven fyi inclusief het obligate challenge-response verhaal, leef je uit

Verwijderd schreef op 17 mei 2004 @ 23:27:
De veiligheid is niet te bewijzen en iedereen gebruikt het... Of heb ik mijn boek over cryptografie verkeerd gelezen?

Ik denk dat je 'm te vroeg hebt dichtgeslagen... je kent de concepten en de theorieen, nu nog de praktische toepassing

[ Voor 19% gewijzigd door curry684 op 18-05-2004 00:33 ]

[ACM]

Verwijderd schreef op 17 mei 2004 @ 23:27:
Het grappige van MD5 is dat het een ad-hocalgoritme is en de werkwijze is te vergelijken met die van symmetrische encryptiealgoritmen. Door het gebrek aan structuur is er over de veiligheid van de functies weinig te bewijzen.
Zelfde geldt trouwens voor SHA (hash 160 bits).
De veiligheid is niet te bewijzen en iedereen gebruikt het... Of heb ik mijn boek over cryptografie verkeerd gelezen?

't Is inderdaad een foute keuze om md5 of sha1 als "wachtwoord encryptie" te gebruiken, simpelweg omdat het daar niet voor bedoeld is. Maar anderzijds is het wel een van de makkelijkere oplossingen om het een "beetje lastiger" opgeslagen te houden

Het bewijzen van veiligheid van een functie is sowieso onmogelijk volgens mij, want een functie is alleen maar een functie. Het enige wat je kan proberen te bewijzen is dat het eindresultaat niet als invoer van een andere functie bruikbaar is om op de originele invoer terecht te komen. Doordat een hash-functie allerlei gegevens weglaat is dat trouwens al bijna inherent aan het algoritme zelf

curry684 schreef op 18 mei 2004 @ 00:32:
Lekker boeiend, daarom trek je ook nooit een hash van alleen het password maar van een custom combinatie van username en password naar eigen keuze (concat met of zonder random tussenvullingen e.d.). Als je dat niet doet hebben 2 gebruikers met hetzelfde password dezelfde hash, wat een securityleak is, en is een dictionary of andere brute force attack inderdaad mogelijk.

Als je weet wat er ge"codeerd" is, dan is een brute force attack mogelijk, sterker nog, doordat je weet welk algoritme gebruikt heb je dat niet eens nodig. Of je nou gaat zoeken naar een moeilijk password of naar "iets"+moeilijk password, das precies hetzelfde.
Het zal alleen wat langer duren om te achterhalen, maar een beetje handige hacker zal zijn eigen password proberen te kraken en ontdekken dat er bijvoorbeeld username+password staat, ipv slechts password.

Ik denk dat je 'm te vroeg hebt dichtgeslagen... je kent de concepten en de theorieen, nu nog de praktische toepassing

Ik denk het niet. Sha1 en md5 (en alle andere hashes) zijn bedoeld voor integriteitscontrole, dus voor het bepalen of de inhoud van een bericht (of een file of whatever) veranderd is of niet. Niet om als versleuteling van het een of ander te gebruiken.

Dat het daar toevallig ook redelijk voor te gebruiken is, is aardig, maar niet het originele doel van de ontwikkelaars van hashing algoritmen. Eigenlijk zou men beter de (unix) crypt-functies en aanverwanten kunnen gebruiken.
Een van de simpelste extraatjes die (md5)crypt standaard gebruikt is het gebruiken van een zgn salt, die random gekozen wordt per password en dus al voor je doet wat jij hier boven over een concattenatie zegt

[curry684]

ACM schreef op 18 mei 2004 @ 09:56:
[...]

't Is inderdaad een foute keuze om md5 of sha1 als "wachtwoord encryptie" te gebruiken, simpelweg omdat het daar niet voor bedoeld is. Maar anderzijds is het wel een van de makkelijkere oplossingen om het een "beetje lastiger" opgeslagen te houden

Encryptie is per definitie reversable, dus daar hebben we sowieso niets mee te maken in dezelfde zin als sha en md5

Als je weet wat er ge"codeerd" is, dan is een brute force attack mogelijk, sterker nog, doordat je weet welk algoritme gebruikt heb je dat niet eens nodig. Of je nou gaat zoeken naar een moeilijk password of naar "iets"+moeilijk password, das precies hetzelfde.

Maar iemand die het algoritme niet heeft (alleen DB gehacked en geen toegang tot de PHP/C#/C++/whatever) moet een veel grotere brute-force doen, en iemand die dat algoritme *ook* heeft (ergo je server gewoon fysiek naar huis heeft meegenomen in de praktijk) moet nog immer net zo'n grote dictionary-attack uithalen. Het aantal mogelijke passwords vermindert niet door de combinatieopslag.

Het zal alleen wat langer duren om te achterhalen, maar een beetje handige hacker zal zijn eigen password proberen te kraken en ontdekken dat er bijvoorbeeld username+password staat, ipv slechts password.

Da's de MSN-standaard manier, en zo is MSN afaik ook gereversed. Maar zodra je exotische combinaties gaat doen als de username 2 keer achter mekaar plakken en daar het omgekeerde ROT-13 password rear-aligned overheen XOR'en wens ik je veel succes

Ik denk het niet. Sha1 en md5 (en alle andere hashes) zijn bedoeld voor integriteitscontrole, dus voor het bepalen of de inhoud van een bericht (of een file of whatever) veranderd is of niet. Niet om als versleuteling van het een of ander te gebruiken.

Dat is absoluut waar. Maar puristisch gezien is het wel extreem handig dat je bij authenticatiemechanismes (waar reversability niet boeit of juist ongewenst is) kunt bepalen dat de inhoud van een bericht niet veranderd is. MD5 is bedacht voor iets anders, maar wel verdomd praktisch voor dit doel. Veel veiliger ga je het niet krijgen zonder public/private keys en trusted certificates.

Een van de simpelste extraatjes die (md5)crypt standaard gebruikt is het gebruiken van een zgn salt, die random gekozen wordt per password en dus al voor je doet wat jij hier boven over een concattenatie zegt

Uh, maar als ie random gekozen wordt per password moet ie iedere keer voor hetzelfde password dezelfde salt kiezen, en maakt het dus op een brute-force of dictionary niet uit. Ik zie het nut er dus niet echt van, die concat kun je iig nog inkleden zoals je zelf wilt....

[Verwijderd]

curry684 schreef op 18 mei 2004 @ 10:09:
[...]

Maar zodra je exotische combinaties gaat doen als de username 2 keer achter mekaar plakken en daar het omgekeerde ROT-13 password rear-aligned overheen XOR'en wens ik je veel succes

[...]

Klinkt leuk, tenzij de cracker de beschikking heeft over deze informatie. Als je zo'n kunstgreep toepast dan moet je er wel héél zeker van zijn dat niemand de methode weet en ooit zal weten.

Kerckhoffs' principe: Oscar kent het cryptosysteem dat door Alice en Bob wordt gebruikt; alleen de sleutel is hem onbekend.

Motivaties:
- sleutel is makkelijker te vernieuwen
- bij veel communicatie wordt gebruik gemaakt van gestandaardiseerde software. De sleutel geheim houden is dan haast onmogelijk
- veelgebruikte algoritmes kan je op den duur toch niet geheim houden.
- veiligheid berust zo op de geheimhouding van zo min mogelijk informatie; hoe minder je geheim hoeft te houden, hoe gemakkelijker.

[curry684]

Verwijderd schreef op 18 mei 2004 @ 14:01:
[...]

Klinkt leuk, tenzij de cracker de beschikking heeft over deze informatie. Als je zo'n kunstgreep toepast dan moet je er wel héél zeker van zijn dat niemand de methode weet en ooit zal weten.

Dat zei ik

Maar iemand die het algoritme niet heeft (alleen DB gehacked en geen toegang tot de PHP/C#/C++/whatever) moet een veel grotere brute-force doen, en iemand die dat algoritme *ook* heeft (ergo je server gewoon fysiek naar huis heeft meegenomen in de praktijk) moet nog immer net zo'n grote dictionary-attack uithalen. Het aantal mogelijke passwords vermindert niet door de combinatieopslag.

Alle veiligheid is schijnveiligheid. Beste manier om brute-force hackers tegen te gaan is om je database achter een goede firewall te hangen en de webserver automatisch te laten IP-bannen voor een uur na 3 foute logins.

Zodra iemand de mogelijkheid heeft om in alle rust 1 miljard passwords uit te proberen ben je toch wel verloren, strong passwords en strong encryption of niet.

[Janoz]

Verwijderd schreef op 18 mei 2004 @ 14:01:
...
.- bij veel communicatie wordt gebruik gemaakt van gestandaardiseerde software. De sleutel Het algoritme geheim houden is dan haast onmogelijk

Ik neem aan dat je dat bedoeld

[Verwijderd]

Typo idd, bedankt voor je opmerking