[alg] Wachtwoorden opslaan in plain-text

[Verwijderd]

Even een situatie waar ik vandaag tegenaan liep, waarvan ik nogal benieuwd ben naar de mening van anderen.

Ik had vandaag een discussie met een klant over een te ontwikkelen webapplicatie. Wens van hem is dat wachtwoorden in plain-text (dus zonder encryptie, hash o.i.d.) worden opgeslagen in de database, zodat hij op deze manier makkelijk mensen kan helpen die hun gegevens vergeten zijn. Nu druist dit tegen al mijn ideeën in wat betreft een veilig systeem, maar kon hem toch niet overtuigen van het nut ervan. Niemand heeft toegang tot de database, alleen hij kan er bij, dus dan maakt het niet zoveel uit, zegt ie.

Wat vinden jullie er van, en weet iemand hoe het zit wettelijk gezien? Is het verplicht deze gegevens te versleutelen?

[lennartkocken]

Bij SQL injectie zou het al mogelijk zijn heel de tabel Users uit te lezen. Wat interessanter is, is om bijv. de eerste en het laatste teken op te slaan, en dan de rest wel als hash. Dan is het wel veilig, en kan hij de gebruikers toch nog een beetje op het goede spoor helpen door het eerste en het laatste teken te geven.

[Snake]

Veel mensen gebruiken hetzelfde wachtwoord voor alles, dus dat zou heel dubieus zijn.

Beste is wachtwoord in md5/whatever... en een emailadres waarop ze een nieuw gegenereerd wachtwoord kunnen aanvragen.

[Gomez12]

Geef hem gewoon de mogelijkheid om het ww aan te passen ( een via admin aangepast ww moet bij volgende keer inloggen veranderd worden ).

Dan kan hij het zelf aanpassen naar een makkelijk wachtwoord en dan daarmee de klant nadoen.

Op deze manier weet de klant er altijd van...

[Verwijderd]

Snake schreef op woensdag 10 december 2008 @ 21:41:
Veel mensen gebruiken hetzelfde wachtwoord voor alles, dus dat zou heel dubieus zijn.

Beste is wachtwoord in md5/whatever... en een emailadres waarop ze een nieuw gegenereerd wachtwoord kunnen aanvragen.

Dat was inderdaad ook mijn belangrijkste argument, dat mensen vaak dezelfde wachtwoorden hebben. Het lijkt me toch een bepaalde schending van pricavy. Ik zou het ook niet fijn vinden als iemand van een systeem gewoon mijn wachtwoord kan zien! Ik gebruik altijd van die schunnige dingen!

@Gomez
Dat lijkt mij de beste methode. Kan hij doen wat ie wil. En dan kan de boel alsnog geencrypt worden.

[Verwijderd]

De juiste manier om het te doen zoals de klant het wil, is om unieke wachtwoorden voor gebruikers te genereren. Dan hoeven ze niet gehashed te worden.

Als een gebruiker dan zélf een wachtwoord wil instellen, zou het wachtwoord gehashed moeten worden met een salt én bijvoorbeeld zijn gebruikers-id zodat je geen collisions krijgt bij gelijke wachtwoorden. Voor deze wachtwoorden kan de klant dus niet het origineel zien, wel eventueel een nieuw wachtwoord instellen.

Best of both worlds. De klant hoort wachtwoorden die zijn klant zelf instellen niet te weten. Hij kan er eventueel nog wel eisen aan stellen, zoals minstens één cijfer, onderkast en hoofdletter en minimaal 6 tekens ofzo.

[Snake]

Imo moet de klant ook niet rechtstreeks operaties kunnen doen op de db. Zeker niet zulke operaties, hij moest maar eens iets verkeerd doen.

En ik denk niet dat veel klanten er mee opgezet zijn als je ze verplicht een gegenereerd wachtwoord te gebruiken!

[Verwijderd]

Ik vind het juist een GOED PLAN^® om automatisch een wachtwoord te genereren. Dat voorkomt dat een gebruiker iets onbenulligs invult om maar een wachtwoord te hebben. Als iemand niet tevreden is over zijn wachtwoord, moet er de mogelijkheid zijn dit te wijzigen.

Hoe dat precies gaat is zaak van de applicatie. Natuurlijk frot je niet alles direct in een database. De user interface hoort sowieso redelijk los te staan van achterliggende datastructuren.

[Snake]

Verwijderd schreef op woensdag 10 december 2008 @ 22:04:
Ik vind het juist een GOED PLAN^® om automatisch een wachtwoord te genereren. Dat voorkomt dat een gebruiker iets onbenulligs invult om maar een wachtwoord te hebben. Als iemand niet tevreden is over zijn wachtwoord, moet er de mogelijkheid zijn dit te wijzigen.

Hoe dat precies gaat is zaak van de applicatie. Natuurlijk frot je niet alles direct in een database. De user interface hoort sowieso redelijk los te staan van achterliggende datastructuren.

Ik vind dat alleen een goed plan als er degelijke tooltjes bestaan om wachtwoorden te onthouden... want ik ga niet voor iedere website iedere keer m'n mail doorzoeken met 'wat was m'n wachtwoord weer?'...

[The Eagle]

Wat vroeger meestal wel werkte is aangeven dat een accountant (in geval van een financieel systeem) of een auditor zo ongeveer gehakt maakt van een ww opslag in plain text. Als hij er bij kan kunnen ook anderen er bij.
Tuurlijk, beheer is nodig, maar een vergeten-ww app is net zo makkelijk in elkaar te klussen. En het beheerders-account hoort sowieso in een kluis te liggen en niet op een momoblaadje

[BCC]

Of een externe partij gebruiken zoals OpenId. Dan ben je van al het gezeur af http://openid.net/

Vanuit security oogpunt is wachtwoorden plaintext opslaan een hele grote no no. Elke website heeft wel ergens een SQL inject mogelijkheid waarmee je velden kan oplepelen uit de database. Als je dan een lijst met emailadressen en wachtwoorden uit je systeem kan vissen, dan kun je er donder op zeggen dat alle email accounts van al jouw gebruikers vervolgens ook gehacked zijn.

Ga dat maar eens uitleggen aan je klanten.

Wat je eventueel nog wel zou kunnen doen is de wachtwoorden encrypten met een public key, zodat je ze zelf (indien nodig) kan decrypten met een private key. Ik zie alleen niet in hoe dat een betere service oplevert dan een standaard "u bent u wachtwoord vergeten, klik hier om hem te resetten" mailtje.

[ Voor 90% gewijzigd door BCC op 10-12-2008 22:43 ]

[Osiris]

BCC schreef op woensdag 10 december 2008 @ 22:13:
Vanuit security oogpunt is wachtwoorden plaintext opslaan een hele grote no no. Elke website heeft wel ergens een SQL inject mogelijkheid waarmee je velden kan oplepen uit de database. Als je dan een lijst met emailadressen en wachtwoorden uit je systeem kan vissen, dan kun je er donder op zeggen dat alle email accounts van al jouw gebruikers vervolgens ook gehacked zijn.

Ga dat maar eens uitleggen aan je klanten.

Vertel dat dan maar eens aan T-Mobile. Als je je wachtwoord opvraagt van je "My T-Mobile", dan krijg je netjes een SMS-je met daarin het wachtwoord wat je ook daadwerkelijk opgegeven hebt en geen nieuwe random aangemaakte ofzo.

[BCC]

Ik weet het: Tele2, Easyjet, Marktplaats.. ik gebruik ze niet meer.

Tele2 vertelde mijn wachtwoord aan mij via de telefoon, toen ik ze mobiel belde voor een email storing.

"Gebruikt u wel het wachtwoord jantje31? Die staat hier namelijk in het systeem als uw email wachtwoord."

Dat is een van de redenen waarom ik mijn abbo destijds heb opgezegd.

offtopic:
Nee, mijn wachtwoord is niet jantje31. Dit is een fictief wachtwoord wat ik net heb verzonnen. Wil je mijn echte wachtwoord, dan denk ik dat je het beste even de Tele2 helpdesk kan bellen.

[ Voor 123% gewijzigd door BCC op 10-12-2008 22:22 ]

[Cruz]

Om het meteen helemaal goed te doen: Hash met een seed.
Stel het wachtwoord is 'fiets'.
Als je het dan alleen hasht krijg je '4dd60d4e5b16fcda74a7372f5edb5f5b51cea9c1'.
Maar... dit soort hashes zijn vaak gebruteforced, en kan je weer terugtoveren op bijv md5.rednoize.com.
Tenzij je dus een seed gebruikt. Je genereert een random string van zeg 10 karakters: 'nirdkcrgfh'
Deze sla je op bij het wachtwoord, de tabel heeft dan een kolom 'hash' en een kolom 'seed'.
Vervolgens plak je de seed en het wachtwoord aan elkaar: 'nirdkcrgfhfiets', en dit gebruik je om te hashen.
Je krijgt dan 'bc9a42ac35704988d21c798014431ebe506e4104', welke (nog ) niet in md5.rednoize.com staat.

Om een wachtwoord van de gebruiker te controleren doe je hetzelfde opnieuw:
1) Vraag om een wachtwoord
2) Plak de seed er weer aan
3) Hash seed + wachtwoord
4) Check of deze waarde overeenkomt met veld 'hash'.

[martennis]

Wachtwoorden en plain text.. in één zin? Hoe haal je het, anno 2008, nog in je hoofd!
Als je klantvriendelijk wilt zijn, zorg je ervoor dat je een veilig systeem ontwikkeld.
Mocht iemand nou een wachtwoord vergeten, laat je op een druk op de knop (in een admin gedeelte bijv.) een wachtwoord genereren en deze gehashed opslaan ter vervanging van het oude wachtwoord. Dit is nog niet een ideale situatie, want wie zegt dat je systeem zo veilig is dat niet een willekeurige hacker bij deze functie kan komen, maar het is een stuk veiliger dan totaal geen wachtwoordbeveiliging.

IMO zou dergelijke klanten gewoon verboden moeten worden ooit nog met wensen aan te komen.

@Cruz: wat ook kan: een deel van de gebruikersnaam. Ff algoritme schrijven die een aantal letters druit vist en deze als seed gebruiken.

[ Voor 9% gewijzigd door martennis op 10-12-2008 22:44 ]

[Osiris]

Cruz schreef op woensdag 10 december 2008 @ 22:37:
Om het meteen helemaal goed te doen: Hash met een seed.
Stel het wachtwoord is 'fiets'.
Als je het dan alleen hasht krijg je '4dd60d4e5b16fcda74a7372f5edb5f5b51cea9c1'.
Maar... dit soort hashes zijn vaak gebruteforced, en kan je weer terugtoveren op bijv md5.rednoize.com.
Tenzij je dus een seed gebruikt. Je genereert een random string van zeg 10 karakters: 'nirdkcrgfh'
Deze sla je op bij het wachtwoord, de tabel heeft dan een kolom 'hash' en een kolom 'seed'.
Vervolgens plak je de seed en het wachtwoord aan elkaar: 'nirdkcrgfhfiets', en dit gebruik je om te hashen.
Je krijgt dan 'bc9a42ac35704988d21c798014431ebe506e4104', welke (nog ) niet in md5.rednoize.com staat.

Om een wachtwoord van de gebruiker te controleren doe je hetzelfde opnieuw:
1) Vraag om een wachtwoord
2) Plak de seed er weer aan
3) Hash seed + wachtwoord
4) Check of deze waarde overeenkomt met veld 'hash'.

En nu brute-force je die seeded hash en krijg je netjes 'seedpassword' terug. Vervolgens haal je de seed eraf en heb je alsnog het wachtwoord?

[martennis]

Osiris schreef op woensdag 10 december 2008 @ 22:46:
[...]

En nu brute-force je die seeded hash en krijg je netjes 'seedpassword' terug. Vervolgens haal je de seed eraf en heb je alsnog het wachtwoord?

Maak je een hash van je hash

[Sebazzz]

martennis schreef op woensdag 10 december 2008 @ 22:46:
[...]


Maak je een hash van je hash

Ik weet niet waarom (graag uitleggen ) maar dat schijnt niet te helpen in veiligheid.

[BCC]

Meerder malen hashen is niet slim omdat je dan de oplossings ruimte verkleint, waardoor de kans op collisions toeneemt, wat concreet betekent dat het bruteforcen van je wachtwoorden simpeler wordt.

Een random gekozen Salt + Wachtwoord SHAen (niet MD5, dat is te eenvoudig te kraken) levert zowieso al een betere verdediging tegen dictionary attacks.

Daarnaast is het kraken (berekenen van een collision) van de Hash niet mogelijk als de salt onbekend is bij de aanvallende partij.

Tot slot gebruik je door lange wachtwoorden te gebruiken je oplossingsruimte maximaal, wat het berekenen van een collision weer moeilijker maakt.

Maar we raken zo wel erg offtopic. Het voorbeeld van Cruz klopt dus niet, ook al heeft hij wel gelijk .

[ Voor 48% gewijzigd door BCC op 10-12-2008 23:09 ]

[Luqq]

De grap is dus, als je de salt in een column zet in dezelfde row, heeft de hacker zijn MD5 pass en de salt ook meteen..

[BCC]

Dat ligt uiteraard aan de implementatie. Daarnaast blijven de andere punten dan natuurlijk staan, dus veiliger is het sowieso.

[ Voor 61% gewijzigd door BCC op 10-12-2008 23:20 ]

[Verwijderd]

Luqq schreef op woensdag 10 december 2008 @ 23:15:
De grap is dus, als je de salt in een column zet in dezelfde row, heeft de hacker zijn MD5 pass en de salt ook meteen..

Lekker boeiend. Het enige doel van die salt is om het kraken met rainbow tables onmogelijk te maken.

[Gomez12]

Verwijderd schreef op woensdag 10 december 2008 @ 23:31:
[...]

Lekker boeiend. Het enige doel van die salt is om het kraken met rainbow tables onmogelijk te maken.

Idd, wat de hash is dat is niet boeiend. Heel simpel gezegd gok ik dat er nergens ter wereld een rainbow table bestaat met "tweakers.net" als salt, ook al heb je dus de salt. Je hebt nog steeds geen rainbow tables om tegen te vergelijken...

[.oisyn]

Verwijderd schreef op woensdag 10 december 2008 @ 23:31:
[...]

Lekker boeiend. Het enige doel van die salt is om het kraken met rainbow tables onmogelijk te maken.

Nee, niet het enige doel. Ook multi-user dictionary attacks en precomputed hash attacks zijn daarmee nutteloos.

[ Voor 50% gewijzigd door .oisyn op 10-12-2008 23:49 ]

[lowfi]

Snake schreef op woensdag 10 december 2008 @ 22:10:
[...]

Ik vind dat alleen een goed plan als er degelijke tooltjes bestaan om wachtwoorden te onthouden... want ik ga niet voor iedere website iedere keer m'n mail doorzoeken met 'wat was m'n wachtwoord weer?'...

Die zijn er best wel veel. Ik gebruik altijd 1password en laat dat programma ook altijd mijn paswoorden genereren

[doeternietoe]

Een salt moet je bij voorkeur erg lang doen (10 karakters is echt niet genoeg). Het is trouwens niet zo dat je als de salt hebt en de MD5 dat je dan met gemak het wachtwoord terug kan vinden. Al heb je een salt van 10 000 tekens en je gebruikt die om 1 letter te hashen, dan nog is de enige manier om die letter terug te vinden door middel van brute-force. (correct me if I'm wrong, ik ken het MD5 algoritme niet goed genoeg om dit 100% zeker te weten)

In dit geval zou de oplossing heel goed kunnen liggen in het gebruiken van een (asymmetrische) omkeerbare encryptie. Je encrypt je wachtwoorden met behulp van de public-key en je gebruikt dit eigenlijk op de manier zoals je dat ook met MD5/SHA1 zou doen. Vervolgens heb je de private key waarmee je de wachtwoorden indien nodig weer terug kunt vinden. Deze leg je in de kluis(oid)

Zelfs als iemand de volledige applicatie heeft en de database-gegevens dan kan die nog niet de originele wachtwoorden terugvinden anders dan door middel van bruteforce. Voor jouw public key bestaan natuurlijk geen tabellen met alle mogelijke oplossingen en zal het risico van een bruteforce niet erg groot zijn.

Kijk bijvoorbeeld eens naar RSA: Wikipedia: RSA

[.oisyn]

BCC schreef op woensdag 10 december 2008 @ 23:01:
(niet MD5, dat is te eenvoudig te kraken)

Beetje kort door de bocht. Voor wachtwoorden voldoet MD5 prima. Waar MD5 niet (meer) goed voor is, is om aan te geven dat een bericht ongewijzigd is. Dit aangezien het heel simpel is om een collision te vinden, gegeven het originele bericht en zijn hash. Echter, in dit geval is het originele bericht (het wachtwoord) onbekend, waardoor je niets aan dat algoritme hebt. En de rest van de attacks (dictionary, rainbow tables) zijn net zo goed van toepassing op SHA-1.

[Gomez12]

doeternietoe schreef op woensdag 10 december 2008 @ 23:52:
Een salt moet je bij voorkeur erg lang doen (10 karakters is echt niet genoeg).

Wat maakt een salt van 10 tekens beter dan een salt van 1 teken? Afaik verstoort het alleen de originele invoer zodat dat niet meer met een rainbow table is terug te brengen naar de originele invoer.

Al heb je een salt van 10 000 tekens en je gebruikt die om 1 letter te hashen, dan nog is de enige manier om die letter terug te vinden door middel van brute-force. (correct me if I'm wrong, ik ken het MD5 algoritme niet goed genoeg om dit 100% zeker te weten)

Het nut van een salt van 10.000 tekens zie ik echt niet, je zit al met een harde limiet van 32 tekens. Alles wat je boven deze limiet gaat zitten heeft meer kans op doublures, je vertroebelt het water misschien iets meer, dat is het enige imho.

In dit geval zou de oplossing heel goed kunnen liggen in het gebruiken van een (asymmetrische) omkeerbare encryptie. Je encrypt je wachtwoorden met behulp van de public-key en je gebruikt dit eigenlijk op de manier zoals je dat ook met MD5/SHA1 zou doen. Vervolgens heb je de private key waarmee je de wachtwoorden indien nodig weer terug kunt vinden. Deze leg je in de kluis(oid)

Zelfs als iemand de volledige applicatie heeft en de database-gegevens dan kan die nog niet de originele wachtwoorden terugvinden anders dan door middel van bruteforce. Voor jouw public key bestaan natuurlijk geen tabellen met alle mogelijke oplossingen en zal het risico van een bruteforce niet erg groot zijn.

Simplistisch gezegd, je hebt nu een 2e mogelijke zwakheid geintroduceerd ( namelijk je public / private key ) en de vraag is en blijft, waarom? Als admin zijn er zat andere manieren om je als iemand anders te identificeren zonder het wachtwoord te hoeven weten...

[.oisyn]

Gomez12 schreef op donderdag 11 december 2008 @ 00:06:
[...]

Wat maakt een salt van 10 tekens beter dan een salt van 1 teken? Afaik verstoort het alleen de originele invoer zodat dat niet meer met een rainbow table is terug te brengen naar de originele invoer.

Bij een kleine salt is de kans dat een MD5 crack toevallig met de juiste salt begint veel groter dan bij een grote salt. Als we even uitgaan van een perfecte distributie dan colliden geen van de strings van minder dan 16 bytes met elkaar. Als we dan ook even aannemen dat het resultaat van een crack mbv een rainbow-table een zo kort mogelijke input oplevert voor die hash, dan levert het dus gegarandeerd je seed+password op. Nou is de distributie natuurlijk niet perfect, maar de kans op collisions is wel vrij klein voor alle mogelijke kleine inputs, dus als je seed+password klein is dan is de kans groot dat het resultaat dat uit de rainbow-table komt de juiste is. Dit kun je voorkomen door een lange salt te nemen, waardoor het resultaat uit de rainbow-table vrijwel altijd ongelijk is aan je originele seed+password.

Het nut van een salt van 10.000 tekens zie ik echt niet, je zit al met een harde limiet van 32 tekens. Alles wat je boven deze limiet gaat zitten heeft meer kans op doublures, je vertroebelt het water misschien iets meer, dat is het enige imho.

Dat is onzin. De kans dat twee strings van 100 tekens met elkaar colliden is net zo groot als die kans bij twee strings van 3 tekens. Je verwart het denk ik met dat het aantal collisions van alle mogelijke 3-teken strings veel kleiner is dan het aantal collisions tussen alle mogelijke 100-teken strings.

[Gomez12]

.oisyn schreef op donderdag 11 december 2008 @ 00:20:
[...]
Bij een kleine salt is de kans dat een MD5 crack toevallig met de juiste salt begint veel groter dan bij een grote salt. Als we even uitgaan van een perfecte distributie dan colliden geen van de strings van minder dan 16 bytes met elkaar. Als we dan ook even aannemen dat het resultaat van een crack mbv een rainbow-table een zo kort mogelijke input oplevert voor die hash, dan levert het dus gegarandeerd je seed+password op. Nou is de distributie natuurlijk niet perfect, maar de kans op collisions is wel vrij klein voor alle mogelijke kleine inputs, dus als je seed+password klein is dan is de kans groot dat het resultaat dat uit de rainbow-table komt de juiste is. Dit kun je voorkomen door een lange salt te nemen, waardoor het resultaat uit de rainbow-table vrijwel altijd ongelijk is aan je originele seed+password.

Ok, duidelijk... Maar denk ik dan verkeerd als ik zeg dat in theorie een salt van 32-tekens en daarachter nog een wachtwoord al niet meer terug te bruteforcen valt? Ik heb tenminste nooit gehoord van rainbow tables groter dan 32 tekens...

[...]
Dat is onzin. De kans dat twee strings van 100 tekens met elkaar colliden is net zo groot als die kans bij twee strings van 3 tekens. Je verwart het denk ik met dat het aantal collisions van alle mogelijke 3-teken strings veel kleiner is dan het aantal collisions tussen alle mogelijke 100-teken strings.

Ja en nee. De kans dat 2 string van 100 tekens met elkaar colliden is inderdaad net zo groot, maar de kans dat een char32 (md5 hadden we het toch over) representatie van die strings gaan colliden met zichzelf of met iets anders is volgens mij wel groter. Volgens mij was dit ook net je vorige puntje...

[.oisyn]

Gomez12 schreef op donderdag 11 december 2008 @ 00:36:
[...]

Ok, duidelijk... Maar denk ik dan verkeerd als ik zeg dat in theorie een salt van 32-tekens en daarachter nog een wachtwoord al niet meer terug te bruteforcen valt? Ik heb tenminste nooit gehoord van rainbow tables groter dan 32 tekens...

Exact, en ik vind de 10.000 tekens dan ook erg overdreven .

Ja en nee. De kans dat 2 string van 100 tekens met elkaar colliden is inderdaad net zo groot, maar de kans dat een char32 (md5 hadden we het toch over) representatie van die strings gaan colliden met zichzelf of met iets anders is volgens mij wel groter. Volgens mij was dit ook net je vorige puntje...

Nu heb je het over het hashen van hashes, maar dat werd niet aangehaald door doeterniettoe.

(Een MD5 is 128 bits oftewel 16 bytes. Als hexadecimale notatie heb je idd 32 tekens nodig, maar het blijven 2¹²⁸ mogelijke combinaties. En salts/wachtwoorden beperken zich niet tot 0-9a-z )

[doeternietoe]

doeternietoe schreef op woensdag 10 december 2008 @ 23:52:
Het is trouwens niet zo dat je als de salt hebt en de MD5 dat je dan met gemak het wachtwoord terug kan vinden. Al heb je een salt van 10 000 tekens en je gebruikt die om 1 letter te hashen, dan nog is de enige manier om die letter terug te vinden door middel van brute-force.

.oisyn schreef op donderdag 11 december 2008 @ 00:42:
[...]

Exact, en ik vind de 10.000 tekens dan ook erg overdreven .

twas maar een voorbeeld

Gomez12 schreef op donderdag 11 december 2008 @ 00:06:
Simplistisch gezegd, je hebt nu een 2e mogelijke zwakheid geintroduceerd ( namelijk je public / private key ) en de vraag is en blijft, waarom? Als admin zijn er zat andere manieren om je als iemand anders te identificeren zonder het wachtwoord te hoeven weten...

De TS wilde een manier om de wachtwoorden terug te kunnen vinden om ze te kunnen vertellen aan mensen die 'm kwijt zijn. We zijn al tot de conclusie gekomen dat plaintext duidelijk géén optie is. MD5 met hash is niet omkeerbaar en een symetrisch algoritme is net zo lek als plaintext als delen van je applicatie per ongeluk op straat terecht komen. RSA is niet de ideale oplossing, maar het is een betere optie dan plaintext en het voldoet aan de eisen die de TS stelt. Als de TS z'n opdrachtgever ervan kan overtuigen dat hashen toch beter is, dan lijkt me dat ook wel prima

[? ?]

..

[ Voor 100% gewijzigd door ? ? op 25-01-2013 09:51 ]

[? ?]

..

[ Voor 99% gewijzigd door ? ? op 25-01-2013 09:51 ]

[.oisyn]

era.zer schreef op donderdag 11 december 2008 @ 10:03:
md5(wachtwoord + 'ietsbvwebsitenaam') geeft je een veilige md5 hash (een die niet via rainbow tables terug opgezocht kan worden). Dat je zelf ziet dat wat je erachter plakt niet één letter lang mag zijn is vrij duidelijk.. Verder is al dat gedoe, ... euh, gedoe!

Jeej, multi-user attack galore. Omdat de seed overal hetzelfde is, en het niet onredelijk is om te denken dat je daar achter kunt komen, kun je lekker gaan bruteforcen, maar dan niet voor 1 wachtwoord, maar voor alle wachtwoorden tegelijk. Een unieke salt per user (bv. door gebruik te maken van het user-id) voorkomt dat.

[? ?]

..

[ Voor 102% gewijzigd door ? ? op 25-01-2013 09:51 ]

[.oisyn]

era.zer schreef op donderdag 11 december 2008 @ 11:51:
- je weet de seed niet

Ah, security by obscurity. Nice

- het userid weet je net wel, dus even goed te raden (als je toch de seed weet)

Dan snap je niet wat ik bedoel. Stel je hebt toegang tot de database, en daarmee dus de hashes van iedereen. Als iedereen dezelfde seed gebruikt, en je weet die, dan kun je dus een dictionary attack doen op alle gebruikers tegelijk, waardoor je veel sneller een wachtwoord achterhaalt (de kans dat je met een willekeurig woord uit het woordenboek het wachtwoord raad van een van de 1 miljoen gebruikers is een stuk groter dan dat je dat doet voor slechts 1 gebruiker). Als de seed voor iedereen uniek is, dan kan dat niet meer. Daarnaast werd eerder al gezegd dat een seed lang moest zijn, dus alleen een user-id is niet genoeg. Ik zei dan ook door gebruik te maken van het user-id (en niet: salt = user-id). Dus bijv. het user-id met daarachter een lange vaste tekenreeks. Heb je ook weer meteen je security by obscurity die je zo graag wilde hebben.

- het is de bedoeling om het wachtwoord niet zichtbaar op te slaan (anti-rainbow table truc dus)

Euh ja, hoe is dit in hemelsnaam een argument tegen het gebruiken van een per-user aparte seed?

- na 3 keer foutief aanmelden blokkeer je de gebruiker. (jaja misschien heb je wel kans met 1 miljoen gebruikers, maar je hebt ook kans om morgen de loterij te winnen..)

Zie vorig punt. En als je de hashes hebt ga je niet wachtwoorden raden via het inlog-systeem

Good-Enough noemen ze dat

Wie is ze? Security analysts noemen dat Prutswerk^TM

[ Voor 13% gewijzigd door .oisyn op 11-12-2008 13:21 ]

[? ?]

..

[ Voor 156% gewijzigd door ? ? op 25-01-2013 09:51 ]

[Voutloos]

era.zer schreef op donderdag 11 december 2008 @ 13:44:
Andere seed per gebruiker kost je extra aan opslag en berekening (alles kost).

Die extra kosten zijn vaak verwaarloosbaar tov de extra kosten vd persoon die alle rainbowtabellen wil. Een paar karakters meer hashen zorgt niet voor een meetbare vertraging, maar een paar extra rainbowtabellen moeten maken wel.

[.oisyn]

era.zer schreef op donderdag 11 december 2008 @ 13:44:
[...]

Tuurlijk snap ik je punt, maar wat heb je aan een willekeurige hack? Als ik iets zou wil hacken, heb ik een doel (één iemand dus). Wat proberen en dan zien dat er één van de miljoen werkt, so what. En hier was de eigenaar een n00b (anders zou hij 't zelf programmeren), dus voor hem is dat helemaal goed.
En "stel" moet je niet gebruiken.

Waarom doe je het dan zelf? Je zegt: "Als ik iets zou wil hacken, heb ik een doel (één iemand dus).". Daar maak je net zo goed een aanname.

Als er toegang is tot de db, kan ik net zogoed toegang hebben tot de source en eventjes net voor de registratie een andere db aanspreken waar het wachtwoord plaintext opgeslagen wordt

Ja dat kan, maar that's not the point. Je systeem is compromised, wat dat betreft is het kwaad al geschied. Maar je wilt dat de wachtwoorden van je gebruikers veilig blijven en niet op straat komen te liggen, omdat veel gebruikers 1 wachtwoord gebruiken voor heel veel dingen. Het gaat er helemaal niet om dat je het systeem kan hacken - die is al gehacked. Het gaat erom dat je met dat systeem niet andere gevoelige informatie kunt achterhalen.

oisyn, je bent een krak programmeur, dus je hebt natuurlijk een punt. Maar good-enough is geen prutswerk. Compromis maakt iedereen, the next guy in line zal jouw werk niet goed genoeg vinden.

Daar heb je gelijk in, maar jij gaat met je argumenten keihard in tegen alle adviezen over het opslaan van wachtwoorden die op internet te vinden zijn. Ik ben er niet van overtuigd dat jouw mening voldoende is omdat ik denk dat het beter moet, ik ben ervan overtuigd omdat alle experts er zo over denken, met steekhoudende argumenten.

met welke auto rijd je?

Geen, die heb ik maandag naar de sloop gebracht (seriously).
Maar je hele vergelijking gaat mank. Het gaat om je gebruikers. Als ik een vervoersbedrijf was die mensen moest vervoeren, dan ga ik geen kosten besparen door onveilige auto's te gebruiken. Als het echter alleen om mezelf gaat, dan kan ik het risico wel nemen. Het punt is alleen dat het niet om mezelf gaat in dit geval - het gaat om je gebruikers van je site. Die dienen beschermd te worden. Door de wachtwoorden niet sterk op te slaan maak je dingen als identity theft een stuk makkelijker.

Als je je gelukkig voelt met andere seeds, dan doe je dat maar? Er zijn 100 andere zaken die belangrijker zijn. Andere seed per gebruiker kost je extra aan opslag en berekening (alles kost).

User-id sla je toch al op. Berekening is niet duurder dan een vaste salt omdat je ervoor kunt zorgen dat de uiteindelijke salt net zo lang is.

[Pathogen]

Mij lijkt de beste optie nog steeds om ervoor te zorgen dat klantlief de passwords kan resetten, waarna de gebruiker in kwestie direct zijn wachtwoord moet veranderen.

Wachtwoorden in de hand van een ander leggen dan een gebruiker is in mijn ogen totaal ongepast, ook gezien het feit dat veel mensen dezelfde wachtwoorden over meerdere sites en accounts gebruiken.

[ari]

.oisyn schreef op donderdag 11 december 2008 @ 14:13:
Als ik een vervoersbedrijf was die mensen moest vervoeren, dan ga ik geen kosten besparen door onveilige auto's te gebruiken. Als het echter alleen om mezelf gaat, dan kan ik het risico wel nemen. Het punt is alleen dat het niet om mezelf gaat in dit geval - het gaat om je gebruikers van je site.

Jouw vervoersbedrijf gebruikt tanks om mensen te vervoeren? Uiteraard voorzien van die 28 airbags en alle mogelijke toeters en bellen?

era.zer heeft wel degelijk een punt. Je maakt altijd een compromis. Een vervoersbedrijf (om in je analogie te blijven) gebruikt nooit de allerbeste, allernieuwste, allerveiligste auto's met alle extra's. Dat is simpelweg veel te duur. Ze gebruiken auto's die voldoende veilig zijn voor hun toepassing.

Je moet altijd een compromis zien te vinden tussen security en usability. En een professional zal die afweging moeten maken,die nooit compleet aan één kant van de schaal zit.

[? ?]

..

[ Voor 105% gewijzigd door ? ? op 25-01-2013 09:51 ]

[.oisyn]

era.zer schreef op donderdag 11 december 2008 @ 14:38:
Je hebt sowieso meer opslag, iets berekend gebruiken is zinloos. of je er nu 123abc achterhangt of (100+23) + "abc" is hetzelfde. Dus moet je een échte niet-statische seed per gebruiker hebben die je opslaat in zijn tabel. Dus database toegang = weten welke seed. En dan begint het verhaaltje opnieuw. (voor de eigenaar)

Heb je gewoon een plaat voor je hoofd of leg ik het nou zo slecht uit? Als 1 miljoen users dezelfde salt gebruiken, dan kun je met 1 attack alle users aanvallen. Als elke user een eigen salt heeft (die best bekend mag zijn!), dan heb je 1 miljoen individuele attacks nodig. It's that simple. Het gaat er niet om of de salt moeilijk te achterhalen is of niet. Het gaat erom dat je niet simpelweg salt + dictionary_word kunt gebruiken om in een keer wachtwoorden van 1 miljoen mensen tegelijk kan proberen te achterhalen.

Dus in plaats van "abcdefghij" + wachtwoord, gebruik je user_id + "abcdef" + wachtwoord. Geen extra opslag, geen langere hash berekening. Nadelen: geen. Voordelen: multi-user attack niet meer mogelijk. Laten we de auto-analogie er weer bijpakken. Als je de keuze hebt tussen een auto zonder airbags, en een auto met airbags, die allebei evenveel kosten, dan ga jij voor de auto zonder airbags als jij dat good enough vindt, ookal kun je zonder er ook maar iets extra's voor te doen iets beters krijgen?

.edit: crap nou heb ik een alinea verwijderd uit m'n post bij het editten.

[ Voor 44% gewijzigd door .oisyn op 11-12-2008 15:10 ]

[? ?]

..

[ Voor 137% gewijzigd door ? ? op 25-01-2013 09:51 ]

[.oisyn]

Het wordt opgeblazen omdat jij gratis betere beveiliging aan de kant schuift om je originele post te verdedigen, terwijl je het ook meteen had kunnen afdoen met "dat is idd iets beter, maar vind ik onnodig", oftewel het standpunt dat je nu inneemt. Uit je vorige posts bleek niet dat je dit beter vond, maar juist onzin, waardoor ik er verder op inging om je ervan te overtuigen dat het vooral geen onzin is. Maar goed, we zijn eruit

[ Voor 15% gewijzigd door .oisyn op 11-12-2008 15:20 ]

[Mental]

Om nog even te bevestigen dan .oisyn niet de enige is die er zo over denkt:

1. Gratis
2. Implementatietijd verwaarloosbaar
3. Geen nadelen voor de gebruiker
4. Verbeterde beveiliging

Beveiligings maatregelen aan de kant schuiven die aan bovenstaande specificaties voldoen getuigt van het feit dat je geen idee hebt wat security is en dan ook maar beter uit dit topic kan blijven aangezien je geen nuttig antwoord kan geven.

Verwar overigens een mening niet met een feit.
'Voldoende beveiliging' is nogal een begrip wat op diverse plaatsen iets anders betekend.

Ontopic:

Een opdrachtgever / baas / manager die mij zo een opdracht zou geven krijgt echt geen plaintext wachtwoorden in de database, volgens mij kan dat zelfs aangemerkt worden als nalatigheid op moment dat er wel wat mis gaat.

[ Voor 30% gewijzigd door Mental op 11-12-2008 15:22 ]

[? ?]

..

[ Voor 110% gewijzigd door ? ? op 25-01-2013 09:51 ]

[Woy]

Tuurlijk heb je gelijk dat je een afweging moet maken tussen de kosten/baten.

Maar de kosten van het per user opslaan van een salt zijn zo goed als te verwaarlozen, terwijl de baten er wel degelijk zijn.

[steffex]

Heb in mijn professionele carriere nog nooit een klant meegemaakt die zijn eigen gemak boven veiligheid zet.

De klant komt toch naar jou toe voor een systeem/applicatie omdat jij de expert bent en goed bent in wat je doet? ik zou dit soort eisen direct van tafel vegen! gaat de klant niet akkoord, zoekt hij maar een andere malloot die het wel wil doen!

Op het moment dat je app gehacked is, komt de klant vervolgens wel zeuren dat de gegevens op straat liggen...

Wil hij niet overstag en wil je toch de opdracht aannemen kun je altijd nog zeggen dat vanuit je professionele standpunt je dit sterk afraad. Wil hij het toch, dan ondertekend hij maar een overeenkomst/contract/whatever waarin staat dat hij dit zelf wil en dat jij niet aansprakelijk gesteld kunt worden voor eventuele schade die hieruit voortkomt....

[ Voor 9% gewijzigd door steffex op 11-12-2008 18:18 ]

[Verwijderd]

stef-o schreef op donderdag 11 december 2008 @ 18:16:
Heb in mijn professionele carriere nog nooit een klant meegemaakt die zijn eigen gemak boven veiligheid zet.

Dan heb je nooit goed opgelet. Dat iemand in kan loggen vermindert de totale veiligheid al. Als iemand van zijn PC wegloopt kan iemand anders al de boel verstieren. Dat kan niet als bij elke actie een wachtwoord moet worden opgegeven. Maar omdat dat niet echt handig is, kwamen de mannen met het idee om iemand in te laten loggen. Voor de rest van de sessie hoefde iemand dan niet meer telkens zijn wachtwoord in te vullen.

Gebruikersgemak is de aartsvijand van veiligheid. Er zal altijd een balans gevonden moeten worden.

[doeternietoe]

Verwijderd schreef op donderdag 11 december 2008 @ 20:37:
[...]

Dan heb je nooit goed opgelet. Dat iemand in kan loggen vermindert de totale veiligheid al. Als iemand van zijn PC wegloopt kan iemand anders al de boel verstieren. Dat kan niet als bij elke actie een wachtwoord moet worden opgegeven. Maar omdat dat niet echt handig is, kwamen de mannen met het idee om iemand in te laten loggen. Voor de rest van de sessie hoefde iemand dan niet meer telkens zijn wachtwoord in te vullen.

Gebruikersgemak is de aartsvijand van veiligheid. Er zal altijd een balans gevonden moeten worden.

Op zichzelf heb je gelijk, maar soms is de verhouding tussen de hoeveelheid veiligheid en de hoeveelheid gebruiksgemak die substitueerbaar zijn zo ongelijk dat de balans gemakkelijk gevonden kan worden. In het geval van het mannetje dat wegloopt van achter zijn bureau moet worden afgewogen hoe groot de mogelijkheid is dat iemand in zijn afwezigheid schadelijke acties uitvoert. Is deze kans groot genoeg dan kan de persoon in kwestie het beste de gewoonte aannemen om de PC bij afwezigheid te locken. De toegevoegde waarde van het bij iedere actie een wachtwoord meesturen is zeer klein. Bij de optie van locken bestaat welliswaar de mogelijkheid dat de persoon onverwacht weg moet en vergeet om de computer te locken, maar de ballans is mijns inziens duidelijk.

Overigens zou je ook rekening moeten houden met de extra beveiligingsrisico's die meerdere malen inloggen per sessie met zich meebrengen. De kans dat iemand het wachtwoord afkijkt wordt aanmerkelijke groter. In veel gevallen zal het wachtwoord iedere keer over een onbeveiligde verbinding verstuurd worden. En er is vast nog meer te bedenken.

offtopic:
wij dwalen of van het onderwerp

Om terug te komen op het onderwerp:
Bij de keuze tussen het gebruiksgemak van het kunnen opvragen van een wachtwoord en het beveiligingsvoordeel van het gebruik van een hash slaat de balans wel heel erg door naar de optie van de hash. De compromis is de optie van encryptie met een publieke en een private sleutel, die inderdaad minder veilig is dan de hash en minder gebruiksvriendelijk dan de plaintext. (in verband met het uit de kluis moeten halen van de private key)

[ Voor 11% gewijzigd door doeternietoe op 11-12-2008 21:16 ]

[Gomez12]

doeternietoe schreef op donderdag 11 december 2008 @ 21:13:
[...]
Om terug te komen op het onderwerp:
Bij de keuze tussen het gebruiksgemak van het kunnen opvragen van een wachtwoord en het beveiligingsvoordeel van het gebruik van een hash slaat de balans wel heel erg door naar de optie van de hash. De compromis is de optie van encryptie met een publieke en een private sleutel, die inderdaad minder veilig is dan de hash en minder gebruiksvriendelijk dan de plaintext. (in verband met het uit de kluis moeten halen van de private key)

Oftewel een hash is veiliger, en ik heb nog steeds geen reden voorbij horen komen waarom iemand echt het wachtwoord moet weten en impersonating niet meer volstaat.

Simpelweg gezegd, op jouw eigen site mag je doen en inzien wat je wilt. Maar het wachtwoord van een normale gebruiker ( mits je geen bankinstantie bent ) reikt over het algemeen wel iets verder als jouw site.
Elke mogelijkheid om dat wachtwoord te kunnen terughalen reikt dus ook verder dan jouw site. Je hebt als gemiddelde sitebeheerder geen idee waar dat wachtwoord nog meer gebruikt wordt, je hebt er niets mee te maken. Dus wat moet je er mee?

Als je zo graag wilt impersonaten dan verander je het wachtwoord maar. Als een gebruiker hulp wenst te hebben op zijn account dan geeft hij jou zijn wachtwoord maar.

Het enige tijdstip dat ik kan verzinnen om iemands wachtwoord te hebben is bij initiele uitgifte door jezelf, biedt je de mogelijkheid aan om het wachtwoord te veranderen dan heb jij er niets meer mee te maken.

[doeternietoe]

* doeternietoe is het hier volledig mee eens.

De TS vraagt alleen om een veilige manier om een wachtwoord terug te kunnen vinden als iemand 'm vergeten is. Het antwoord: liever helemaal niet zo'n manier gebruiken

Indien toch: in geen geval plaintext.