Passwords: plain-text opslaan een risico?

[bigtree]

In een ander topic kwam de vraag naar boven of het verstandig was om passwords plain op te slaan (niet gehashed / gecodeerd). Mijn stelling was dat het niet uitmaakt, omdat je toch in de database moet komen om wat aan dat password te hebben. Als je toch de database gehacked hebt, waarom zou je dan nog willen inloggen als user X? Je kan immers alles al omdat je in de database kan.

Hierop kreeg ik de volgende antwoorden:

Een database is niet onhackbaar.

Inderdaad, maar dat is een groter probleem dan dat er vervolgens passwords te vinden zijn. Men kan daar veel interessanter informatie uithalen, zoals emailadressen, creditcardgegevens etcetera.

Een administrator die kwaad wil, kan met een password van gebruiker X ook wellicht op website Y rottigheid uithalen.

Inderdaad. Maar stel nu dat de adminstrator niet de beschikking heeft over mijn plain-text wachtwoord, maar wel user X een hak wil zetten. Dan bouwt hij toch een scriptje die het password plain kopieert naar een mailtje zodra user X inlogt?

Een gebruiker met alleen SELECT-rechten kan een password uit de user-tabel vissen en vervolgens meer rechten krijgen door met dit wachtwoord in te loggen.

Is waar. Maar hoe veel websites maken gebruik van meerdere SQL-users met uiteenlopende rechten? Als je een 'standaard' hosting-accountje hebt, krijg je meestal maar één sql user toegewezen, mèt schrijfrechten.

Oftewel; de kans dat er misbruik gemaakt wordt van plain-text wachtwoorden acht ik zeer klein. Mits je weet hoe je de rest van je site moet beveiligen. Geen phpmyadmin zonder .htaccess openlaten, parse-errors uitsluiten, altijd addslashes voordat een query de database in gaat, etcetera. Het voorkomen van een 'open' database vind ik vele malen belangrijker dan het opslaan van gecodeerde wachtwoorden.

Dan hier nog een belangrijk argument van mij voor het opslaan van wachtwoorden in plain-text: Het e-mailen van een vergeten wachtwoord! Dat vind ik persoonlijk een goede service, zeker op sites waar je niet vaak komt. Gewoon je emailadres invullen en het wachtwoord wordt je toegezonden.

(Uiteraard is dit laatste ook vergelijkbaar uit te voeren met een gecodeerd wachtwoord. In het geval van gecodeerde wachtwoorden stuur je een emailtje met een link om het wachtwoord van een login te resetten. Het is alleen een stap extra.)

Op zich heb ik dus niets tegen het gecodeerd opslaan van wachtwoorden. Maar het gaat mij wat te ver om te zeggen dat het 'onveilig' is om wachtwoorden plain op te slaan. Een noob-webmaster die zijn wachtwoorden gecodeerd opslaat en vervolgens achterover leunt omdat-ie denkt dat zijn site veilig is, vind ik kwalijker dan iemand die bewust de passwords plain opslaan maar wel zorgt dat alles voldoende is dichtgetimmerd.

Subject open to discussion.

[gorgi_19]

Creditcardgegevens hoor je naar mijn idee ook niet op te slaan in een database. Afaik gebeurd dat normaliter ook niet (althans, dat hoort niet te gebeuren)

Een ander interessant punt vind ik ook dat je noemt: "Mits je weet hoe je je site moet beveiligen". Hoeveel prutsers lopen er hier bijvoorbeeld niet rond, welke er heilig van overtuigd zijn dat hun code goed in elkaar zit, maar het in werkelijkheid redelijk buggy is?

Daarnaast noemde ik ook nog het punt van exploits, welke nu nog niet ontdekt zijn, maar zeker gaan komen. De software, bijvoorbeeld MySQL of SQL Server, is niet bugvrij. Wie weet dat er over 3 maanden niet een methodiek naar voren komt, waarbij het kinderlijk eenvoudig is om een database te bereiken?

Tuurlijk bestaat er de mogelijkheid van het wachtwoord laten opsturen. Echter, wat is er mis mee om een nieuw wachtwoord te generen en deze op te sturen naar de gebruiker? De gebruiker wordt dan gedwongen om weer een wachtwoord te kiezen wat hij wil.

Het is niet per definitie onveilig om wachtwoorden ongecodeerd op te slaan. Wel wil ik het beduidend minder veilig noemen dan wachtwoorden gecodeerd op te slaan.

[ Voor 25% gewijzigd door gorgi_19 op 20-05-2003 15:45 ]

[Sn3akz]

Het probleem is dat een plain password dus ook plain over het net wordt verstuurd. Dit is geen probleem zolang je je website en d-base server op dezelfde machine heb staan. Heb je echter een aparte d-baser server, dan gaat je password dus plain-txt over het net. 1 simpele packet sniffer en tadaaaaa...

En trouwens.. Als je de mogelijkheden heb, waarom zou je hem dan in plain-txt opslaan als je ze met hetzelfde gemak kan encrypten?? Weer een stukje extra veiligheid...

[justmental]

Met wachtwoorden gecodeerd opslaan ben je er niet, maar plaintext gebruiken is wel degelijk minder veilig.
De impact van software security leaks is groter, misbruik door admins is eenvoudiger, je moet zwaar op je database exports letten etc.
Persoonlijk vertrouw ik een website niet echt meer als ie m'n password kan mailen.

[RRX]

bigtree schreef op 20 May 2003 @ 15:38:
Dan hier nog een belangrijk argument van mij voor het opslaan van wachtwoorden in plain-text: Het e-mailen van een vergeten wachtwoord! Dat vind ik persoonlijk een goede service, zeker op sites waar je niet vaak komt. Gewoon je emailadres invullen en het wachtwoord wordt je toegezonden.

Niet als je MD5 of een andere niet terug te berekenen codering gebruikt.

[Bosmonster]

Wachtwoorden niet plain-tekst opslaan... als je systeem ook maar ergens een klein foutje bevat kan dat direct zo gebruikt worden dat wachtwoorden achterhaald kunnen worden.

Knappe jongen als je kan garanderen dat je systeem 100% waterdicht is. Zo zorg je er in ieder geval voor dat niet de wachtwoorden van al je gebruikers op straat komen te liggen als er iets fout gaat.

Dat is simpelweg een service aan je gebruikers.

[Eijkb]

Let iedereen hier altijd op de beveiliging van exploits, databases, al dan niet plain passwords of pas als er een redelijke dreiging is van misbruik? Voor een aantal huis-tuin en keukensites welke ik gebouwd heb, heb nu niet echt bepaald moeite gestoken in het dichttimmeren van de beveiliging. Als het clienteel persé wilt dat het paswoord gemaild kan worden, wie ben ik om daar tegen in te gaan? Dus, maw, uit mijn ervaring kan ik melden dat ik niet zo veel doe met beveiliging, tenzij de "klant" dat wilt of last krijgt van misbruikers. Het ligt aan de site en de content ofdat er al dan niet extra moeite gestoken moet worden in de beveiliging. Soms gaat gebruiksgemak zelfs voor die beveiliging.

[bigtree]

gorgi_19 schreef op 20 May 2003 @ 15:43:
Creditcardgegevens hoor je naar mijn idee ook niet op te slaan in een database. Afaik gebeurd dat normaliter ook niet (althans, dat hoort niet te gebeuren)

Amazon doet het en daar ben ik blij mee! Hoef ik niet iedere keer mijn creditcard op te zoeken. Wel moet ik zeggen dat ik bij Amazon 101% vertrouw op hun kunde om mijn gegevens te beschermen.

Een ander interessant punt vind ik ook dat je noemt: "Mits je weet hoe je je site moet beveiligen". Hoeveel prutsers lopen er hier bijvoorbeeld niet rond, welke er heilig van overtuigd zijn dat hun code goed in elkaar zit, maar het in werkelijkheid redelijk buggy is?

Au, dat was een trap tegen de tere delen van velen die hier 'rondlopen'. Gelukkig zijn de financiele consequenties van fouten in de websites die zij beheren niet zo groot. En dus ook niet zo interressant voor hackers.

Daarnaast noemde ik ook nog het punt van exploits, welke nu nog niet ontdekt zijn, maar zeker gaan komen. De software, bijvoorbeeld MySQL of SQL Server, is niet bugvrij. Wie weet dat er over 3 maanden niet een methodiek naar voren komt, waarbij het kinderlijk eenvoudig is om een database te bereiken?

Dan is dat een risico van het gebruik van MySQL, niet een risico van het gebruik van plain-text wachtwoorden.

[crisp]

Sn3akz schreef op 20 May 2003 @ 15:44:
Het probleem is dat een plain password dus ook plain over het net wordt verstuurd. Dit is geen probleem zolang je je website en d-base server op dezelfde machine heb staan. Heb je echter een aparte d-baser server, dan gaat je password dus plain-txt over het net. 1 simpele packet sniffer en tadaaaaa...

En trouwens.. Als je de mogelijkheden heb, waarom zou je hem dan in plain-txt opslaan als je ze met hetzelfde gemak kan encrypten?? Weer een stukje extra veiligheid...

Bij de meeste sites die wachtwoorden gecodeerd opgeslagen hebben gaat het wachtwoord in eerste instantie ook plaintext over de lijn, en wordt op de server pas ge-MD5'ed waarna hij vergeleken wordt in de DB, dus ik kan dit niet echt een argument noemen.

[Woy]

Eijkb schreef op 20 May 2003 @ 15:53:
Let iedereen hier altijd op de beveiliging van exploits, databases, al dan niet plain passwords of pas als er een redelijke dreiging is van misbruik? Voor een aantal huis-tuin en keukensites welke ik gebouwd heb, heb nu niet echt bepaald moeite gestoken in het dichttimmeren van de beveiliging. Als het clienteel persé wilt dat het paswoord gemaild kan worden, wie ben ik om daar tegen in te gaan? Dus, maw, uit mijn ervaring kan ik melden dat ik niet zo veel doe met beveiliging, tenzij de "klant" dat wilt of last krijgt van misbruikers. Het ligt aan de site en de content ofdat er al dan niet extra moeite gestoken moet worden in de beveiliging. Soms gaat gebruiksgemak zelfs voor die beveiliging.

Dat vindt ik persoonlijk eigenlijk een slechte instelling. Als je een beetje goed nadenkt over je applicatie dan hoef je niet eens zo heel veel moeite te doen om hem veilig te houden. Zeker als je je niet echt bezig houdt met beveiliging van de site is het extra belangrijk om te zorgen dat je passwords md-5 gehashed zijn. Want meestal gebruiken gebruikers voor meerdere sites hetzelfde password en is het dus erg kwalijk dat een andere gebruiker dat password kan zien. Dit is natuurlijk nog veel erger dan dat er misbruik van wordt gemaakt op je eigen site

[Bosmonster]

bigtree schreef op 20 mei 2003 @ 15:55:
[...]
Amazon doet het en daar ben ik blij mee! Hoef ik niet iedere keer mijn creditcard op te zoeken. Wel moet ik zeggen dat ik bij Amazon 101% vertrouw op hun kunde om mijn gegevens te beschermen.

Amazon zal je creditcard gegevens echt wel encrypten hoor

Au, dat was een trap tegen de tere delen van velen die hier 'rondlopen'. Gelukkig zijn de financiele consequenties van fouten in de websites die zij beheren niet zo groot. En dus ook niet zo interressant voor hackers.

Dan is dat een risico van het gebruik van MySQL, niet een risico van het gebruik van plain-text wachtwoorden.

Zoals ik al zei.. het gaat om de service aan je gebruikers om niet hun wachtwoorden openbaar te maken, zelfs als er iets fout gaat. Wachtwoorden worden vaak vaker gebruikt en als je een lijst met emailadressen gekoppeld aan wachtwoorden kunt achterhalen van een site, gegarandeerd dat je die ergens anders wel kunt misbruiken.

[Freee!!]

De truc met passwords is het gecodeerd opslaan en bij aanmelden niet decoderen, maar het ingegeven password met het zelfde algoritme coderen en kijken of dat overeenkomt met het gecodeerd opgeslagen password. Er zijn voldoende algoritmes die moeilijk tot onmogelijk te decoderen codes opleveren en op deze manier is dat ook niet nodig

[JumpStart]

Dan moet ik denken aan het bekende Security through Obscurity: denken dat je veilig bent omdat je de boel afschermt. In dit geval denken "dat toch niemand in die database kan komen".

Als je toch vasthoudt aan het denkbeeld zou je ook kunnen zeggen dat een airbag niet nodig is. Immers, als je goed auto rijdt dan bots je toch niet? Maar ondertussen heb je zelf nooit 100% in de hand wat er met jou en je auto gebeurd. Misschien wordt je wel geschept, en dan is die airbag ineens erg fijn om te hebben.

Analoog: misschien wordt er wel een exploit ontdekt waarmee je database ineens open ligt. Ondanks alles wat jij als admin gedaan hebt kan dan de stront nog steeds de ventilator raken.

Versleutelen van passwords is als een airbag: implementeer het nou maar, kost wel iets meer moeite, maar dan krijg je achteraf tenminste geen spijt als blijkt dat je er een nodig had...

[bigtree]

Even een tussendoortje; ik hoor een aantal keer dat het 'moeilijk' of 'onmogelijk' is om bijv. md5-gecodeerde of zelfs gecrypte wachtwoorden te ontcijferen. Graag wil ik in dat verband melden dat ik vorige week voor de grap meedeed aan een hack-test die gemeld werd in deze draad. Er zat een opgave bij waar je een wachtwoord moest de-crypten. Nou ben ik geen hacker maar wel creatief. Ik bouwde in 1,5 uur in VB een tooltje dat het gecrypte wachtwoord kon achterhalen met behulp van een woordenlijst. Een woordenlijst gedownload en binnen 10 minuten was het wachtwoord gevonden. Sindsdien geef ik niet meer zo hoog op voor md5 of zelfs gecrypte wachtwoorden omdat ik weet hoe eenvoudig het kan zijn om een wachtwoord te vinden.

Oftewel; het gecodeerd opslaan van wachtwoorden vergroot alleen maar het 'gevoel' van veiligheid. En niets is zo gevaarlijk als het gevoel van veiligheid.

[Sn3akz]

crisp schreef op 20 May 2003 @ 15:58:
wordt op de server pas ge-MD5'ed waarna hij vergeleken wordt in de DB, dus ik kan dit niet echt een argument noemen.

Juist.. en als je mijn post gelezen had, had je gezien dat als hij wordt vergeleken in de db (De query wordt verzonden naar de DB server) en je heb je password niet geëncrypt hij dus plain over de lijn gaat in de query.. (Zoniet in de query, dan wel in de resultset)

Nogmaals: Dit is dus alleen van toepassing als je db server op een andere plek staat dan je webserver...

bigtree schreef op 20 mei 2003 @ 16:13:Oftewel; het gecodeerd opslaan van wachtwoorden vergroot alleen maar het 'gevoel' van veiligheid. En niets is zo gevaarlijk als het gevoel van veiligheid.

Ik weet zeker dat mijn wachtwoord niet in jouw woordenlijst voorkomt...

[ Voor 23% gewijzigd door Sn3akz op 20-05-2003 16:20 ]

[bigtree]

Sn3akz schreef op 20 May 2003 @ 16:19:
[...]


Juist.. en als je mijn post gelezen had, had je gezien dat als hij wordt vergeleken in de db (De query wordt verzonden naar de DB server) en je heb je password niet geëncrypt hij dus plain over de lijn gaat in de query.. (Zoniet in de query, dan wel in de resultset)

Nogmaals: Dit is dus alleen van toepassing als je db server op een andere plek staat dan je webserver...

Dan nog zal dit niet zo'n probleem zijn. Ten eerste kan je het verkeer tussen webserver en db via een beveiligde lijn laten lopen (mysql kan dit zelfs met standaard functionaliteit). En daarbij; hoe wil jij een sniffer zetten op een privaat netwerk?

Ik weet zeker dat mijn wachtwoord niet in jouw woordenlijst voorkomt...

Misschien niet jouw wachtwoord, maar wel een paar van de 10.000 andere wachtwoorden die je zou kunnen bemachtigen via een open database.

[Nielsz]

gorgi_19 schreef op 20 mei 2003 @ 15:43:
Tuurlijk bestaat er de mogelijkheid van het wachtwoord laten opsturen. Echter, wat is er mis mee om een nieuw wachtwoord te generen en deze op te sturen naar de gebruiker? De gebruiker wordt dan gedwongen om weer een wachtwoord te kiezen wat hij wil.

Ik word gedwongen om iets de doen wat ik wil Meestal als ik word gedwongen wil ik het niet

[crisp]

Sn3akz schreef op 20 mei 2003 @ 16:19:
[...]
Juist.. en als je mijn post gelezen had, had je gezien dat als hij wordt vergeleken in de db (De query wordt verzonden naar de DB server) en je heb je password niet geëncrypt hij dus plain over de lijn gaat in de query.. (Zoniet in de query, dan wel in de resultset)

Nogmaals: Dit is dus alleen van toepassing als je db server op een andere plek staat dan je webserver...

ik zat meer te denken aan een sniffer op de telefoonlijn van de buurman
Ik had het dus over de communicatie browser --> webserver, waar in de meeste gevallen het wachtwoord sowieso plaintext over een gewone HTTP verbinding gaat.
Ik ken maar weinig sites die het wachtwoord al client-side versleutelen.

[ Voor 6% gewijzigd door crisp op 20-05-2003 16:30 ]

[JumpStart]

bigtree schreef op 20 May 2003 @ 16:13:
[...]

Oftewel; het gecodeerd opslaan van wachtwoorden vergroot alleen maar het 'gevoel' van veiligheid. En niets is zo gevaarlijk als het gevoel van veiligheid.

Denk je maar een grote schuif in, die van "zeer bruikbaar" verschoven kan worden naar "zeer veilig".

Kwestie van een password checker gebruiken bij het opgeven van passwords. Iets als "Uw password dient te bestaan uit ten minste 8 karakters en er moeten zowel letters als cijfers instaan". Toegegeven, daarmee gaan de schuif verder van "bruikbaar" vandaan meer richting "veilig" en het is maar de vraag of dat voor de bewuste toepassing z'n nut heeft.

Ieder type wachtwoord is onveilig voor 'dictionary attacks' zodra de verificatie client-side gedaan wordt. Zie het welbekende L0phtcrack maar. Alleen als de verificatie server side gedaan wordt, en na een x-aantal foute pogingen gewoon niets meer mag voor x minuten, is een woordenboek benadering nutteloos.

[curry684]

Oftewel; het gecodeerd opslaan van wachtwoorden vergroot alleen maar het 'gevoel' van veiligheid. En niets is zo gevaarlijk als het gevoel van veiligheid.

Mensen die de naam van hun vrouw als password pakken blijven eikels. Doet echter niets eraan af dat je met alle computers op deze wereld nog steeds duizenden jaren bezig bent voordat je brute-force de hele MD5-namespace hebt uitgeprobeerd. Wat je min of meer zegt is dat security niet boeit omdat de meeste mensen stomme passwords hebben. Ik heb echter wel goede passwords en die wil ik nondeju gehashed opgeslagen zien.

[bigtree]

crisp schreef op 20 May 2003 @ 16:28:
[...]

ik zat meer te denken aan een sniffer op de telefoonlijn van de buurman
Ik had het dus over de communicatie browser --> webserver, waar in de meeste gevallen het wachtwoord sowieso plaintext over een gewone HTTP verbinding gaat.

Exact, dus maakt het voor dat geval niks uit of je het wachtwoord plain opslaat in je db of niet.

(Overigens gaat het niet helemaal plain-text, maar Base64 van je browser naar de webserver.)

[crisp]

JumpStart schreef op 20 mei 2003 @ 16:30:
[...]


Denk je maar een grote schuif in, die van "zeer bruikbaar" verschoven kan worden naar "zeer veilig".

Kwestie van een password checker gebruiken bij het opgeven van passwords. Iets als "Uw password dient te bestaan uit ten minste 8 karakters en er moeten zowel letters als cijfers instaan". Toegegeven, daarmee gaan de schuif verder van "bruikbaar" vandaan meer richting "veilig" en het is maar de vraag of dat voor de bewuste toepassing z'n nut heeft.
[...]

Tenzij je daar weer te ver in gaat, en wachtwoorden gaat eisen die mensen onmogelijk nog kunnen onthouden, waardoor ze het gaan opschrijven ergens... (de bekende post-it op de monitor)
Ook de verplichting om mensen om de zoveel maanden hun password te laten wijzigen levert meestal juist minder veiligheid op (mensen gaan doornummeren, namen van de maand gebruiken etc).

[DiedX]

bigtree schreef op 20 mei 2003 @ 16:13:
Even een tussendoortje; ik hoor een aantal keer dat het 'moeilijk' of 'onmogelijk' is om bijv. md5-gecodeerde of zelfs gecrypte wachtwoorden te ontcijferen. Graag wil ik in dat verband melden dat ik vorige week voor de grap meedeed aan een hack-test die gemeld werd in deze draad. Er zat een opgave bij waar je een wachtwoord moest de-crypten. Nou ben ik geen hacker maar wel creatief. Ik bouwde in 1,5 uur in VB een tooltje dat het gecrypte wachtwoord kon achterhalen met behulp van een woordenlijst. Een woordenlijst gedownload en binnen 10 minuten was het wachtwoord gevonden. Sindsdien geef ik niet meer zo hoog op voor md5 of zelfs gecrypte wachtwoorden omdat ik weet hoe eenvoudig het kan zijn om een wachtwoord te vinden.

Oftewel; het gecodeerd opslaan van wachtwoorden vergroot alleen maar het 'gevoel' van veiligheid. En niets is zo gevaarlijk als het gevoel van veiligheid.

Ik vind dit onzin. Dit ligt niet aan MD5, dit ligt aan de keuze van je wachtwoord. Standaard is bekend dat je overal een dictionary attack op los kan laten. Als je dat als admin niet afvangt (vermoedelijk random wachtwoorden als hond1022blauw!), dan ben je uberhaupt stom bezig.

Aan de TS: geen enkel systeem is veilig. Een webmaster KAN plaintext wachtwoorden toesturen, maar zoals dat eerder gezegd werd: als dat gedaan wordt, dan zijn ze MIJ kwijt als bezoeker...

[curry684]

en na een x-aantal foute pogingen gewoon niets meer mag voor x minuten

Geeneens minuten nodig, zodra je letters en cijfers in je password eist en je simpelweg 1 luttele seconde serverside wacht met antwoorden op iedere inlogpoging is het zelfs met een dictionarychecker al niet meer te doen (10.000 woorden * 10.000 numerieke mogelijkheden kost je dan al 76 jaar om brute-force te controleren).

[curry684]

Ook de verplichting om mensen om de zoveel maanden hun password te laten wijzigen levert meestal juist minder veiligheid op (mensen gaan doornummeren, namen van de maand gebruiken etc).

Genoeg algoritmes te vinden die 'likeness' percentages afgeven op teveel gelijkende passwords. Gewoon rejecten bij +75% likeness of zo.

[crisp]

curry684 schreef op 20 May 2003 @ 16:36:
[...]

Genoeg algoritmes te vinden die 'likeness' percentages afgeven op teveel gelijkende passwords. Gewoon rejecten bij +75% likeness of zo.

tsja, maar dan krijg je weer die post-its...
Ik gebruik een aantal wachtwoorden voor verschillende doeleinden; dit zijn wachtwoorden van het type 'in geen 100000 jaar te kraken', maar die ik wel in mijn hoofd heb zitten.
Ik heb er een bloedjehekel aan als ik dan verplicht wordt zelfs zo'n wachtwoord nog elke 2 maanden te wijzigen, dan vragen ze erom dat ik wat simpelers ga nemen anders kan ik het echt niet meer onthouden (en ik heb een redelijk goed geheugen).
Zolang ik ervan overtuigd ben dat niemand dit wachtwoord weet zie ik het nut er niet van in om het te veranderen voor een of andere doorgeslagen BOFH (en hack ik zijn account om mijn eigen wachtwoord weer te veranderen naar wat ik wil )

mmz, maar dit is zijdelings offtopic

ontopic: http://pajhome.org.uk/crypt/md5/
javascript MD5 implementatie waarmee je wachtwoorden al clientside kan hashen waardoor ze ook niet "plain" over de lijn hoeven

[ Voor 7% gewijzigd door crisp op 20-05-2003 16:50 ]

[Woy]

crisp schreef op 20 mei 2003 @ 16:48:
[...]

tsja, maar dan krijg je weer die post-its...
Ik gebruik een aantal wachtwoorden voor verschillende doeleinden; dit zijn wachtwoorden van het type 'in geen 100000 jaar te kraken', maar die ik wel in mijn hoofd heb zitten.
Ik heb er een bloedjehekel aan als ik dan verplicht wordt zelfs zo'n wachtwoord nog elke 2 maanden te wijzigen, dan vragen ze erom dat ik wat simpelers ga nemen anders kan ik het echt niet meer onthouden (en ik heb een redelijk goed geheugen).
Zolang ik ervan overtuigd ben dat niemand dit wachtwoord weet zie ik het nut er niet van in om het te veranderen voor een of andere doorgeslagen BOFH (en hack ik zijn account om mijn eigen wachtwoord weer te veranderen naar wat ik wil )

mmz, maar dit is zijdelings offtopic

ontopic: http://pajhome.org.uk/crypt/md5/
javascript MD5 implementatie waarmee je wachtwoorden al clientside kan hashen waardoor ze ook niet "plain" over de lijn hoeven

Inderdaad. Ik heb voor de meeste dingen ook een redelijk veilig wachtwoord met getallen en letters. Op mijn werk moet ik echter eens in de zoveel tijd mijn wachtwoord wijzigen. Het resultaat is dat ik op mijn werk nou relatief eenvoudige wachtwoorden heb. ( Ok deze zullen niet zo snel gekraakt worden omdat als je 3 keer verkeerd doet dat je dan gelocked wordt maar toch )

[Guru Evi]

Vraag maar eens aan deze van Wake Up On LAN lanparty's of password gehashed of niet moet worden. Op een dag was hun database gehacked en de hacker had nog een paar dagen access gewoon omdat de mensen dezelfde passes gebruikten en die gewoon uit de database gelezen werden.
Databases kunnen gehacked worden, alles kan gehacked worden en als je zo'n 1000 gebruikers hebt en er is niet gehashed geweest ... ;-)
Meestal kan een PHP/SQL samenwerking gewoon met MD5 beveiligd worden. Is het gemakkelijkste.
HASH ALTIJD JE PASSES, een foutje in je website of zo kan ervoor zorgen dat alles leesbaar wordt (voorbeeld zijn die betaalkaarten die niet-hashed in een database zaten)
Sniffers enzo om passes te onderscheppen zitten in een kleine timeframe te werken terwijl websites & db's 24/7 bereikbaar zijn.

[ Voor 23% gewijzigd door Guru Evi op 20-05-2003 17:01 ]

[Verwijderd]

en wat als je je wachtwoord md5 opslaat?
Stel dan dat er iemand zijn wachtwoord kwijt is, je kan het dan niet meer achterhalen dus moet er telkens een nieuw wachtwoord gegenereerd worden!
Dit vind ik eigenlijk wel een nadeel van md5... maar het is wel veilig!

[Bosmonster]

crisp schreef op 20 mei 2003 @ 16:48:
[...]

ontopic: http://pajhome.org.uk/crypt/md5/
javascript MD5 implementatie waarmee je wachtwoorden al clientside kan hashen waardoor ze ook niet "plain" over de lijn hoeven

Hehe dat maakt ook niks uit, want dan kan ik gewoon je formulier posten met mn 'afgeluisterde' MD5 string

Jammer dat niemand reageerde op mijn opmerkingen over de mogelijke beschikbaarheid van de passwords van je gebruikers als er iets fout gaat.. wat gewoon niet netjes is...

[curry684]

Stel dan dat er iemand zijn wachtwoord kwijt is, je kan het dan niet meer achterhalen dus moet er telkens een nieuw wachtwoord gegenereerd worden!

Uh ja, dan klikt user bewust op 'Mail me a new password' en kan ie het veranderen in eentje die hij wel kan onthouden ipv dat ie 'm de volgende dag weer vergeet?

Kzieut probleem niet. Nieuwe passwords genereren is juist een enorm goede security measure die het vertrouwen van mensen vergroot (ik bezoek ook geen sites die me m'n password via het lekste protocol ter wereld oftewel SMTP toe kunnen sturen).

[crisp]

Bosmonster schreef op 20 May 2003 @ 17:04:
[...]


Hehe dat maakt ook niks uit, want dan kan ik gewoon je formulier posten met mn 'afgeluisterde' MD5 string

Niet als die MD5 gemaakt wordt uit het wachtwoord + een door de server gegenereerde random string
Nadeel is dan dus wel dat je dan je wachtwoorden niet meer gehashed op kunt slaan omdat je anders serverside nooit meer de controle-hash kunt maken...

Jammer dat niemand reageerde op mijn opmerkingen over de mogelijke beschikbaarheid van de passwords van je gebruikers als er iets fout gaat.. wat gewoon niet netjes is...

Tsja, sommige gebruikers vinden dat inderdaad handig en netjes, anderen zijn er dus huiverig voor. Ik kan me in beide standpunten wel enigszins vinden.
In het geval van belangrijke applicaties zou ik het persoonlijk prettiger vinden te weten dat het wachtwoord versleuteld wordt opgeslagen, voor een klein forumpje ofzo vind ik dat wat minder belangrijk.

[curry684]

Hehe dat maakt ook niks uit, want dan kan ik gewoon je formulier posten met mn 'afgeluisterde' MD5 string

Hashen is dan ook nutteloos als er geen 'challenge' aan de 'response' vooraf gaat. Desnoods kun je in dat javascriptje (dat ik niet heb gelezen) zelfs de systeemtijd meehashen met het password en vervolgens zowel de hash als de tijdstring oversturen en je bent weer 100% safe voor afluisteraars.

[curry684]

Jammer dat niemand reageerde op mijn opmerkingen over de mogelijke beschikbaarheid van de passwords van je gebruikers als er iets fout gaat.. wat gewoon niet netjes is...

Was in vorige topic al om 14:32 door mij aangestipt

[Guru Evi]

Voor het sniffing bestaan er genoeg counter-dingen. Hier is de vraag aan db-side dacht ik. Maar anyway ;-) passes zijn altijd te onderscheppen (bij het intikken, het versturen of bij het ontvangen) maar zoals ik voordien al zei: dit gebeurt binnen een kort timeframe (en als je wilt kun je nog hashen met tijd incluis) maar de db staat wel 24/7 daar eh ;-)

[bigtree]

Bosmonster schreef op 20 May 2003 @ 17:04:
[...]


Hehe dat maakt ook niks uit, want dan kan ik gewoon je formulier posten met mn 'afgeluisterde' MD5 string

Ok, dan gaan we een session-id samen met het wachtwoord client-side md5-en. Dan gaat jouw methode niet op.

Jammer dat niemand reageerde op mijn opmerkingen over de mogelijke beschikbaarheid van de passwords van je gebruikers als er iets fout gaat.. wat gewoon niet netjes is...

Ik ben even naar de supermarkt geweest en heb er nog over nagedacht...

Er is nooit een reden om een password plain-text op te slaan, behalve luiheid van de programmeur en eventueel een mail-mij-mijn-password-mogelijkheid.

Het is inderdaad heel slordig als iemand de amazon-db kraakt en er vandoor gaat met alle data. Maar wat is erger; je privé-gegevens of het wachtwoord? (Ik ga er van uit dat mijn wachtwoord daar gecodeerd is opgeslagen.) Als die db ooit gekraakt wordt, denk ik echt niet van: "Goh, het is jammer van mijn privé gegevens die nu op straat liggen, maar gelukkig hebben ze mijn wachtwoord niet."

[ Voor 2% gewijzigd door bigtree op 20-05-2003 17:19 . Reden: typo ]

[curry684]

Nadeel is dan dus wel dat je dan je wachtwoorden niet meer gehashed op kunt slaan omdat je anders serverside nooit meer de controle-hash kunt maken...

Klopt ook niet, je kunt nl. dubbelhashen. Server slaat de hash op van username + password zodra user gemaakt is (voorkomt dubbele hashes bij identieke passwords). Client kan vervolgens uit username+password zelfde hash genereren, daar overheen de systemtime hashen en die dan meesturen, en de server kan dan hash trekken uit database en die combineren met systemtime alvorens te vergelijken.

* curry684 heeft zich wel eens met challenge-response coding beziggehouden

[crisp]

curry684 schreef op 20 May 2003 @ 17:12:
[...]

Hashen is dan ook nutteloos als er geen 'challenge' aan de 'response' vooraf gaat. Desnoods kun je in dat javascriptje (dat ik niet heb gelezen) zelfs de systeemtijd meehashen met het password en vervolgens zowel de hash als de tijdstring oversturen en je bent weer 100% safe voor afluisteraars.

dat is dus inderdaad wat ik bedoelde. voorbeeldje
(de random string wordt in de server ook in een sessie opgeslagen)

wat ik in mijn voorbeeld trouwens nog kan verbeteren is de meldingen 'Invalid username' en 'Invalid password' beiden wijzigen in 'Invalid login'
Verder zou ik er een limiet op aantal pogingen op kunnen zetten (gevolgd door een al dan niet tijdelijke ban)

[ Voor 15% gewijzigd door crisp op 20-05-2003 17:25 ]

[bigtree]

curry684 schreef op 20 May 2003 @ 17:18:
[...]

Klopt ook niet, je kunt nl. dubbelhashen. Server slaat de hash op van username + password zodra user gemaakt is (voorkomt dubbele hashes bij identieke passwords).

Hier is een hash niet voor bedoeld. Het kan in dit geval namelijk voorkomen dat twee verschillende gebruikers die een verschillend wachtwoord hebben en op een verschillende tijd zijn aangemeld, toch dezelfde hash hebben.

[ Voor 26% gewijzigd door bigtree op 20-05-2003 17:22 ]

[curry684]

Hier is een hash niet voor bedoeld. Het kan in dit geval namelijk voorkomen dat twee verschillende gebruikers die een verschillend wachtwoord hebben en op een verschillende tijd zijn aangemeld, toch dezelfde hash hebben.

En jij hebt niet goed gelezen, probeer nog eens

Sowieso is de kans astronomisch klein dat wat voor string dan ook identieke MD5's oplevert, check maar eens hoe eDonkey werkt par example

[ Voor 20% gewijzigd door curry684 op 20-05-2003 17:25 . Reden: Additie ]

[crisp]

curry684 schreef op 20 mei 2003 @ 17:24:
[...]

En jij hebt niet goed gelezen, probeer nog eens

Sowieso is de kans astronomisch klein dat wat voor string dan ook identieke MD5's oplevert, check maar eens hoe eDonkey werkt par example

dubbel hashen is dan inderdaad de manier
De gebruikersnaam meenemen om de hash te genereren lijkt me echter niet zo handig; dan kan je de gebruikersnaam niet meer wijzigen zonder dat de gebruiker opnieuw een wachtwoord moet aan (laten) maken.

[Bosmonster]

crisp schreef op 20 May 2003 @ 17:11:
[...]

Tsja, sommige gebruikers vinden dat inderdaad handig en netjes, anderen zijn er dus huiverig voor. Ik kan me in beide standpunten wel enigszins vinden.
In het geval van belangrijke applicaties zou ik het persoonlijk prettiger vinden te weten dat het wachtwoord versleuteld wordt opgeslagen, voor een klein forumpje ofzo vind ik dat wat minder belangrijk.

Ik bedoelde het dus omgekeerd. Als je wachtwoorden direct opslaat in de database en iemand komt door een beveiligingsfout in je DB, dan liggen de wachtwoorden van je gebruikers op straat. Combineer dit met bijvoorbeeld een emailadres en er zijn tig plekken waar je dit zou kunnen misbruiken, aangezien gebruikers vaak dezelfde wachtwoorden gebruiken.

Het direct opslaan is dus simpelweg niet netjes tegenover je gebruikers.

[curry684]

De gebruikersnaam meenemen om de hash te genereren lijkt me echter niet zo handig; dan kan je de gebruikersnaam niet meer wijzigen zonder dat de gebruiker opnieuw een wachtwoord moet aan (laten) maken.

Op zich ben ik tegen het kunnen wijzigen van usernames, maar je kunt indien gewenst de mogelijkheid idd openhouden door het userid mee te hashen (of een willekeurige andere primary key).

Nadeel is dat op het moment van inloggen clientside de userid nog niet bekend is, wat je een extra roundtrip kost.

[.oisyn]

Of je werkt met loginname/username combinaties... vind ik persoonlijk een veel mooiere oplossing. Je logt in met je loginnaam, maar als je naam ergens getoond wordt dan staat daar je username. Dan ben je ook vrij je username te veranderen, alleen je loginnaam (die toch niemand ziet) kun je niet wijzigen

[bigtree]

curry684 schreef op 20 mei 2003 @ 17:24:
[...]

En jij hebt niet goed gelezen, probeer nog eens

Ok; ik dacht dat je bedoelde:

PHP:

$hash = md5($username . $password);

maar dat begrijp ik verkeerd?

[LionO]

Door JumpStart

Dan moet ik denken aan het bekende Security through Obscurity: denken dat je veilig bent omdat je de boel afschermt.

Uhm, ik denk toch aan iets anders bij dat spreekwoord, misschien dat de poster zijn Engels wat moet bijschaven (of anders ik).

Security through obscurity:
Maak het systeem zo ondoorzichtig dat moeilijk is voor iemand anders om te achterhalen wat er gebeurt. Dit kan met rare programmeer constructies en/of door de code in zijn geheel geheim te houden.


Maar nu terug naar het topic:
Wachtwoorden in databases behoren gehashed te worden. Voor de goede orde hoort het formulier HTTPS te gebruiken voor het posten, zodat sniffer moeilijker wordt.

Het verzenden van het wachtwoord bij "wachtwoord vergeten" is uit de boze ! Het grootste argument hiertegen is dat de oorspronkelijke gebruiker niet perse weet dat iemand zijn wachtwoord opgevraagd heeft.
In het geval dat er een nieuw wachtwoord gemaakt wordt, wordt de gebruiker erop gewezen dat zijn wachtwoord niet meer geldig is, iets wat hem zeer achterdochtig moet maken. Dus het is of hacker weet het wachtwoord, of gebruiker weet het wachtwoord, nooit beide, indien de methode "nieuw wachtwoord bij vergeten" gebruikt wordt.

My 2 cents.

[eamelink]

Tja, het grootste probleem dat ik heb bij plaintext passwords, is de mogelijkheid dat anderen mijn password achterhalen.

Ik heb natuurlijk wel een aantal verschillende passwords, voornamelijk voor een aantal verschillende levels van importance, maar toch zou het klote zijn als iemand zo in een DB mijn pass kan lezen, en vervolgens bij allerlei diensten als mij kan inloggen.

Zo heb ik mij eens aangemeld bij een bepaald forum, en ik zag inene m'n password plain in m'n cookie staan. Dan zou zo iedereen die mijn comp weleens gebruikt, mijn paswoord al kunnen achterhalen. Dan ga je al twijfelen aan zo'n site. Toen ik een kleine securitycheck deed, zat ik ook zo in de database. Jahoor, allemaal plain passwords. Ik heb ze maar een vriendelijk mailtje gestuurd dat ik het ze hoogste kwalijk neem om zó onzorgvuldig met mijn gegevens om te springen.

Voor de belangrijkere dingen heb ik een password waarvan ik weet dat je op een enkele computer niet binnen een week een hash kan vinden op de normale manier. Dus een website hoeft voor mij alleen maar ff een md5 hash te trekken, en ik ben blij. Moeten ze die hash ook nog wel een beetje verstoppen het liefst, anders kan er nog ingelogd worden op andere sites, maar al veel minder gemakkelijk.

Overigens zijn er veel betere hashes dan MD5, dat gemaakt is met het oog op snelheid, terwijl je bij een password hash het liefst nou niet echt een efficient algoritme wilt hebben.

[curry684]

bigtree schreef op 20 mei 2003 @ 18:52:
[...]
Ok; ik dacht dat je bedoelde:

PHP:

$hash = md5($username . $password);

maar dat begrijp ik verkeerd?

Persoonlijk hou ik meer van concatenation voor de hash ipv doorhashen maar je had 'm dus wel goed door. En dan heb je dus iets gemist in het concept unieke hashes

Als je alleen een MD5 van je password trekt heeft iedereen die stomtoevallig een vriendin met dezelfde naam heeft dezelfde hash, en dus nog een potentieel lek. Als je de hash trekt van username + password heb je een uniekere hash. Op dezelfde manier weef je 'challenges' in je hashes mee zodat je altijd een andere hash over de lijn stuurt. Het leuke is dat je probleemloos de challenge mee kunt sturen omdat een hash toch niet terug te rekenen is.

[curry684]

eamelink schreef op 20 mei 2003 @ 19:39:
Overigens zijn er veel betere hashes dan MD5, dat gemaakt is met het oog op snelheid, terwijl je bij een password hash het liefst nou niet echt een efficient algoritme wilt hebben.

Zolang MD5 bewezen non-reversible is zonder enkele eeuwen brute-force stampen voldoet het perfect, als je maar als regel aanhoudt dat je altijd een nieuwe hash genereert dmv unieke challenges te combineren.