[PHP] Login methode & password opslag

[skabouter]

Beste Tweakers,

Ik ben voor mijn CMS bezig met de beveiliging, hiervoor wil ik een systeem ontwikkelen dat zowel veilig is qua login data die verzonden wordt als wel de opslag van wachtwoorden van gebruikers.

Om de login data veilig te stellen maak ik gebruik van een challenge/response voor elke request ism client side md5 hashing. Wat ik doe is het volgende;

code:

Alice -> Server : request login pagina
Server -> Alice : login pagina + challenge
Alice -> Server : gebruikersnaam + md5(challenge + md5(password)) ("response")
Server -> alice : if(response ==  md5(challenge + db_password)){ $login =true; }else{ $login = false; }

Dit zorgt er voor dat de wachtwoorden niet in plain text over de lijn gaan en dat een response maar één keer gebruikt kan worden.

Nu komt echter het probleem, om het achterhalen van de wachtwoorden uit de database tegen te gaan (mocht deze in verkeerde handen vallen) sla ik de wachtwoorden in mijn db op met behulp van een salt.

code:

db_password = md5(salt + md5(password))

echter, het wachtwoord uit de database kan ik nu niet meer vergelijken met de challenge, aangezien deze laatste niet beschikt over de salt.

Nu had ik al een opzet gemaakt waarbij de gebruiker eerst zijn gebruikersnaam moest invoeren, waarna de salt van de server werd opgehaald en gebruikt werd bij het opstellen van de response, maar samen met een vriend van me kwamen we er al achter dat een dergelijk systeem geen meerwaarde had (aangezien het wachtwoord op die manier nog af te leiden viel)

Ik heb uiteraard de nodige security guides gelezen, het probleem is alleen dat ze of wel een veilig login script geven, of het hebben over password salting, maar niet echt over een combinatie van deze twee

Mijn vraag is of er mensen zijn die dit probleem vaker zijn tegen gekomen en of zij hiervoor een oplossing weten.

Bronnen;
http://phpsec.org/articles/2005/password-hashing.html
http://blogs.msdn.com/eri...r-challenge-response.aspx
http://blog.alfbox.net/in...thentication-without-ssl/

*note* Uiteraard is het niet nodig om de wachtwoorden te versleutelen bij het inloggen als er gebruik wordt gemaakt van SSL, het systeem moet echter ook veilig zijn als er geen gebruik wordt gemaakt van SSL!

[Tofu]

Kan je niet het paswoord in de database opslaan met een lossless algoritme, eventueel in combinatie met een sleutel? Dan moet een hacker alsnog toegang hebben tot de data, én de database. Een lossy algoritme vergelijken met een ander lossy algoritme lijkt mij theoretisch tamelijk onmogelijk..

[Verwijderd]

Je weet dat het énige doel van hashen en salt is dat het originele wachtwoord niet kan worden achterhaald? Verder biedt het geen toegevoegde waarde betreft het al dan niet kunnen inloggen.

Als de gebruiker zelf zijn wachtwoord kan instellen is het hashen van die gegevens pas nodig. De salt is om te voorkomen dat heel eenvoudig hashes kunnen worden vergeleken met bestaande databases van bekende wachtwoorden die gehasht zijn. Als de gebruiker toch niet zelf zijn wachtwoord kan instellen maakt het allemaal niets uit als je gewoon sterke wachtwoorden uitdeelt.

Jouw eigen systeem zal nooit beter beveiligd worden als je de wachtwoorden hasht. Je biedt alleen een beetje extra veiligheid voor gebruikers die hetzelfde wachtwoord voor verschillende doeleinden gebruiken.

[Wiebbe]

Maar hij wil toch in het systeem de wachtwoorden hashen. Ik zit met hetzelfde probleem. ik wil gewoon grote zekerheid hebben dat als mijn database open ligt om wat voor reden dan ook dat een hacker achter bijna geen enkel wachtwoord kan komen.

Maar ik wil uiteraard ook kunnen garanderen dat de gebruiker die inlogt zijn gegevens tijdens het versturen kan versleutelen. Volgens mij gebruikt Tweakers een zelfde soort systeem, maar hoe zullen zij dan het wachtwoord op slaan?

[Verwijderd]

Als een hash van een salt en het password natuurlijk. Wat is dat nou voor vraag?

[apokalypse]

Challenge/response en hashing werken niet samen.

HTTPS en gehashed in de DB is meestal ok.

[Sypher]

Check deze site even

[Wiebbe]

omdat er dan hetzelfde probleem staat als wat de poster heeft

Het punt is dus dat als je een versleuteling met javascript doet, je een hash + challenge krijgt. Je kan dus nooit de orginele invoer van de gebruiker meer terug krijgen.

Maar om de hash terug te kunnen berekenen heb je wel de orginele invoer nodig.

Aangezien tweakers het doet, kan het dus wel

[Voutloos]

Nee, de uitkomst van de hash is een password equivalent, je kan er mee inloggen. Het origineel boeit de server niet.

Lees Cheatah zijn post nogmaals, want volgens mij snap je hem nog niet helemaal.

[Verwijderd]

Ongelofelijk hoe weinig inzicht sommige mensen hebben in bepaalde dingen.

Als je client-side al een hash maakt van het password + salt, zowel bij het instellen van het wachtwoord als bij het authenticeren, hoeft de server toch helemaal niet te weten wat het originele wachtwoord is? Als bij authenticatie blijkt dat de client over informatie beschikt die bij het instellen van het wachtwoord bekend was (client en server kunnen allebei bepalen welke response moet volgen op een challenge), weet je als server genoeg.

[Wiebbe]

Verwijderd schreef op zondag 30 maart 2008 @ 16:15:
Ongelofelijk hoe weinig inzicht sommige mensen hebben in bepaalde dingen.

Als je client-side al een hash maakt van het password + salt, zowel bij het instellen van het wachtwoord als bij het authenticeren, hoeft de server toch helemaal niet te weten wat het originele wachtwoord is? Als bij authenticatie blijkt dat de client over informatie beschikt die bij het instellen van het wachtwoord bekend was (client en server kunnen allebei bepalen welke response moet volgen op een challenge), weet je als server genoeg.

Punt is als volgt, je kan de vergelijking niet maken:

Bij aanmaken van de gebruiker:

md5(usersalt + password + server salt)

bij invoeren van password:

md5(challenge + md5(password))

Nu moet ik beide hashes gaan vergelijken, hoe kan ik deze nou vergelijken? als ik de bovenste vergelijking niet kan maken..

Ik kan van md5(challenge + md5(password)) nooit hier toe komen:

md5(usersalt + password + server salt)

[apokalypse]

Verwijderd schreef op zondag 30 maart 2008 @ 16:15:
Ongelofelijk hoe weinig inzicht sommige mensen hebben in bepaalde dingen.

Als je client-side al een hash maakt van het password + salt, zowel bij het instellen van het wachtwoord als bij het authenticeren, hoeft de server toch helemaal niet te weten wat het originele wachtwoord is? Als bij authenticatie blijkt dat de client over informatie beschikt die bij het instellen van het wachtwoord bekend was (client en server kunnen allebei bepalen welke response moet volgen op een challenge), weet je als server genoeg.

Wat is de challenge/response dan...

[Wiebbe]

Verwijderd schreef op zondag 30 maart 2008 @ 16:15:
Ongelofelijk hoe weinig inzicht sommige mensen hebben in bepaalde dingen.

Als je client-side al een hash maakt van het password + salt, zowel bij het instellen van het wachtwoord als bij het authenticeren, hoeft de server toch helemaal niet te weten wat het originele wachtwoord is? Als bij authenticatie blijkt dat de client over informatie beschikt die bij het instellen van het wachtwoord bekend was (client en server kunnen allebei bepalen welke response moet volgen op een challenge), weet je als server genoeg.

Dus als ik die hash rechtstreeks op stuur kan ik ook inloggen, en laat dat nou net het punt zijn van een challenge/response systeem (als uitbreiding op boven ;p)

[skabouter]

Verwijderd schreef op zondag 30 maart 2008 @ 16:15:
Ongelofelijk hoe weinig inzicht sommige mensen hebben in bepaalde dingen.

Ho ho, ik geloof dat jullie elkaar (en in jou geval jij mij) niet helemaal snappen, dus niet meteen zo reageren he

Waar het dus inderdaad om gaat is dat je aan de client kan niet de salt hebt als de gebruiker zijn login gegevens invoert, je kunt dus nooidt een hash maken waar de salt in staat en deze dus ook niet evrgelijken met de hash uit de database, aangezien hier wel de salt in zit.

Je weet dat het énige doel van hashen en salt is dat het originele wachtwoord niet kan worden achterhaald? Verder biedt het geen toegevoegde waarde betreft het al dan niet kunnen inloggen.

Ja dat snap ik.

Als de gebruiker zelf zijn wachtwoord kan instellen is het hashen van die gegevens pas nodig. De salt is om te voorkomen dat heel eenvoudig hashes kunnen worden vergeleken met bestaande databases van bekende wachtwoorden die gehasht zijn. Als de gebruiker toch niet zelf zijn wachtwoord kan instellen maakt het allemaal niets uit als je gewoon sterke wachtwoorden uitdeelt.

Gebruikers kunnen inderdaad zelf de wachtwoorden instellen, maar ook al was dat niet het geval dan is het natuurlijk nog verstandig om de hash van het wachtwoord + salt in je db te zetten en niet het wachtwoord in plain-text!

Jouw eigen systeem zal nooit beter beveiligd worden als je de wachtwoorden hasht. Je biedt alleen een beetje extra veiligheid voor gebruikers die hetzelfde wachtwoord voor verschillende doeleinden gebruiken.

Dat zie ik anders, als ik mijn CMS helemaal dicht timmer qua login, en iemand kan toch bij de database komen (via andere exploits oid) dan zou hij toch de data kunnen gebruiken om in het CMS systeem in te loggen? En daarnaast is het nog zo dat zoals je zegt veel gebruikers wachtwoorden voor allerhande systemen gelijk houden.

Sypher schreef op zondag 30 maart 2008 @ 16:08:
Check deze site even

Een mooi voorbeeld van challenge/response, maar helaas zit hier geen salt in.

[ Voor 61% gewijzigd door skabouter op 30-03-2008 17:09 . Reden: Even gereageerd op wat voorgaande berichten ]

[Verwijderd]

skabouter schreef op zondag 30 maart 2008 @ 16:42:

Ho ho, ik geloof dat jullie elkaar (en in jou geval jij mij) niet helemaal snappen, dus niet meteen zo reageren he

Waar het dus inderdaad om gaat is dat je aan de client kan niet de salt hebt als de gebruiker zijn login gegevens invoert, je kunt dus nooidt een hash maken waar de salt in staat en deze dus ook niet evrgelijken met de hash uit de database, aangezien hier wel de salt in zit.

Waarom zou je volgens jou de salt niet aan de client geven?

Dat zie ik anders, als ik mijn CMS helemaal dicht timmer qua login, en iemand kan toch bij de database komen (via andere exploits oid) dan zou hij toch de data kunnen gebruiken om in het CMS systeem in te loggen?

Op een compromised server kun je sowieso niets meer vertrouwen. Als de user in de database kan, kan hij daar wellicht direct de gegevens wijzigen, inclusief wachtwoorden. Het maakt op dat moment niet meer uit.

En daarnaast is het nog zo dat zoals je zegt veel gebruikers wachtwoorden voor allerhande systemen gelijk houden.

Daarom de hash + salt. Dat is dan ook de énige reden om dit te doen. Zelfs bij gegenereerde wachtwoorden is het een idee, want misschien gaan de gebruikers dat wachtwoord ook wel voor andere doeleinden gebruiken.

[ Voor 40% gewijzigd door Verwijderd op 30-03-2008 16:54 ]

[skabouter]

Verwijderd schreef op zondag 30 maart 2008 @ 16:47:
[...]

Waarom zou je volgens jou de salt niet aan de client geven?

Omdat ik de salt niet weet aangezien die gebruiker specifiek is. Of ik zou eerst naar de gebruikersnaam moeten vragen, zo een dergelijk systeem had ik eerst gebouwd (zoals ik al aangaf in mijn startpost) maar deze was al lek geschoten door een vriend van me.

Voorbeeldje:

code:

A -> S : request login pagina
S -> A : login pagina (vraagt om username)
A -> S : username
S -> A : login pagina + challenge (vraagt om wachtwoord) + salt
A -> S : md5(challenge + md5(salt + md5(password)))

Alleen weet ik zo niet meer hoe hij het ook alweer kon kraken, dat zal ik even navragen.

[ Voor 0% gewijzigd door skabouter op 30-03-2008 16:53 . Reden: Salt vergeten ]

[Verwijderd]

Dan kan elke gebruiker de salt opvragen van elke andere gebruiker, en is een verschillende salt per user zinloos, en alleen maar extra rompslomp.

[skabouter]

niet helemaal, die salt dient er ook voor om mensen met hetzelfde wachtwoord te "verbergen" in de database en om dictionary attacks op de db moeilijker te maken.

[Voutloos]

skabouter schreef op zondag 30 maart 2008 @ 16:58:
niet helemaal, die salt dient er ook voor om mensen met hetzelfde wachtwoord te "verbergen"

Als je dat wil, kan de server dat ook in z'n eentje door gewoon helemaal aan het einde met de userspecifieke salt te hashen.

[skabouter]

Voutloos schreef op zondag 30 maart 2008 @ 17:01:
[...]
Als je dat wil, kan de server ook in z'n eentje door gewoon helemaal aan het einde met de userspecifieke salt te hashen.

Die moet je even uitleggen of even je zin herschrijven

[Wiebbe]

Voutloos schreef op zondag 30 maart 2008 @ 17:01:
[...]
Als je dat wil, kan de server dat ook in z'n eentje door gewoon helemaal aan het einde met de userspecifieke salt te hashen.

Het gene wat juist het probleem is dat je dus de hash opslaat van de combinatie salt + password, als je de password niet doorkrijgt maar een hash van een challenge dan kan je daar nooit een nieuwe hash van maken

Zeker omdat de challange elke keer random is

[Voutloos]

Je hebt je login danwel registratie protocol. Aan het einde daarvan heeft de server een string als resultaat ontvangen. Dat resultaat hash je met een user specifiek gegeven en die uitkomst sla je pas op.

[Wiebbe]

Voutloos schreef op zondag 30 maart 2008 @ 17:05:
Je hebt je login danwel registratie protocol. Aan het einde daarvan heeft de server een string als resultaat ontvangen. Dat resultaat hash je met een user specifiek gegeven en die uitkomst sla je pas op.

Ja maar dat kan dus niet, vergeet niet dat die challenge random is, dus een hash die je maakt is elke keer anders! Je kan dus niet zomaar de string "opnieuw" hashen met de hash aangezien je elke keer als je inlogt een andere hash mee stuurt..

[Verwijderd]

Andere vraag dan: Waarom is de salt waarmee de client het wachtwoord moet hashen niet voor iedereen gelijk? (hash gewoon de gebruikersnaam erbij, en dan is elke hash sowieso uniek, ook als 2 gebruikers hetzelfde wachtwoord hebben)

[ Voor 36% gewijzigd door Verwijderd op 30-03-2008 17:16 ]

[Voutloos]

@Wiebbe: Ja, daaag. Bij het opslaan van een wachtwoord wil je ook niet dat daar een eenmalige random challenge in verwerkt zit. Hier worden meerdere protocollen door elkaar heen besproken, maar het gaat mij (en Cheatah) vooral om de denkwijze.

Bij het stuk dat je quote laat ik express in het midden van het login/registratie protocol is, maar als daar iets volledig willekeurigs in zit, kan je op je klompen aanvoelen dat je dat ook nog moet meenemen.

[ChessSpider]

Als je gebruiker bij de database kan komen, kan hij wellicht ook gegevens veranderen zodat hij zelf admin rechten krijgt. Daar kan je je nooit 100% effectief op beveiligen..

Ik heb het zo opgelost;

challengekey = md5 hash van microtime(), opgeslagen in sessie en verstuurd naar browser

Gebruiker heeft een JS implementatie van SHA256. Die pakt het ingevulde wachtwoord, de challengekey en hashed het.

De server ontvangt de hash, controleerd of echte wachtwoord+challengekey (die in sessie opgeslagen zit) in SHA256 matchen, en zo ja istie ingelogd.

Voordeel is dus dat de challenge elke x anders is, en eigenlijk niet te voorspellen is. Mocht er ooit toegang komen in de database waar de (al dan niet geencrypte) wachtwoorden staan, ben je sowieso aardig dood.
Houd er dus ook rekening mee dat voor dit script dus niet uitmaakt of de originele wachtwoorden erin staan of een hash ervan.

[Wiebbe]

Dat heeft geen nut? Je hashed dan met een vaste waarde, je krijgt wel een mooie hash, maar als iemand de string oppakt kan hij gewoon dezelfde string opsturen via een eigen geschreven pagina.

Een challenge is juist bedoeld om elke keer random te zijn als je de login pagina hebt, iemand kan dan niet zomaar het wachtwoord onderscheppen en die rechtstreeks posten naar de server.. aangezien de challenge van de server dan niet overeen komt met die van de client/hash.

[Voutloos]

ChessSpider schreef op zondag 30 maart 2008 @ 17:14:
Houd er dus ook rekening mee dat voor dit script dus niet uitmaakt of de originele wachtwoorden erin staan of een hash ervan.

Precies. Gebruik daar lekker een hash, met publiek bekende salt en er is niets aan de hand.

[Wiebbe]

ChessSpider schreef op zondag 30 maart 2008 @ 17:14:
Als je gebruiker bij de database kan komen, kan hij wellicht ook gegevens veranderen zodat hij zelf admin rechten krijgt. Daar kan je je nooit 100% effectief op beveiligen..

Ik heb het zo opgelost;

challengekey = md5 hash van microtime(), opgeslagen in sessie en verstuurd naar browser

Gebruiker heeft een JS implementatie van SHA256. Die pakt het ingevulde wachtwoord, de challengekey en hashed het.

De server ontvangt de hash, controleerd of echte wachtwoord+challengekey (die in sessie opgeslagen zit) in SHA256 matchen, en zo ja istie ingelogd.

Voordeel is dus dat de challenge elke x anders is, en eigenlijk niet te voorspellen is. Mocht er ooit toegang komen in de database waar de (al dan niet geencrypte) wachtwoorden staan, ben je sowieso aardig dood.
Houd er dus ook rekening mee dat voor dit script dus niet uitmaakt of de originele wachtwoorden erin staan of een hash ervan.

Dus basicly stuur je de challenge key naar de user toe, en stuurt daarna het wachtwoord en challenge 2x op naar de server. 1x via een post en een keer via de sessie? Maar hoe krijg jij het password en challenge key veilige naar de server toe om hem in de sessie op te slaan?

Voutloos schreef op zondag 30 maart 2008 @ 17:12:
@Wiebbe: Ja, daaag. Bij het opslaan van een wachtwoord wil je ook niet dat daar een eenmalige random challenge in verwerkt zit. Hier worden meerdere protocollen door elkaar heen besproken, maar het gaat mij (en Cheatah) vooral om de denkwijze.

Bij het stuk dat je quote laat ik express in het midden van het login/registratie protocol is, maar als daar iets volledig willekeurigs in zit, kan je op je klompen aanvoelen dat je dat ook nog moet meenemen.

Ja, nogal logisch dat ik je aanspreek op wat er in je post staat, ik weet toch niet meteen wat je er mee bedoeld

Het gaat mij ook om de denk wijze, het punt is dat er dus een challenge/response systeem moet komen van een database waarin hashbased wachtwoorden opgeslagen worden. En dat is dus iets wat niet werkt..

[skabouter]

Verwijderd schreef op zondag 30 maart 2008 @ 17:12:
Andere vraag dan: Waarom is de salt waarmee de client het wachtwoord moet hashen niet voor iedereen gelijk? (hash gewoon de gebruikersnaam erbij, en dan is elke hash sowieso uniek, ook als 2 gebruikers hetzelfde wachtwoord hebben)

Hmm daar had ik nog niet aan gedacht, dat moet voldoende zijn! Per gebruiker is de salt dan uniek (als je alleen unieke registratie namen verplicht steld) en je hoeft geen aparte salt te sturen.

Voutloos schreef op zondag 30 maart 2008 @ 17:12:
@Wiebbe: Ja, daaag. Bij het opslaan van een wachtwoord wil je ook niet dat daar een eenmalige random challenge in verwerkt zit. Hier worden meerdere protocollen door elkaar heen besproken, maar het gaat mij (en Cheatah) vooral om de denkwijze.

Inderdaad, bij het registreren en/of wijzigen van het wachtwoord kan er geen gebruik gemaakt worden van de challenge/response die je gebruikt, of je moet de challenge op slaat in de database als 2e salt (maar dan werkt de suggestie die Cheatah gaf helaas niet meer)

ChessSpider schreef op zondag 30 maart 2008 @ 17:14:
Als je gebruiker bij de database kan komen, kan hij wellicht ook gegevens veranderen zodat hij zelf admin rechten krijgt. Daar kan je je nooit 100% effectief op beveiligen..

Dat klopt, maar dat is weer een heel ander verhaal.

[ Voor 12% gewijzigd door skabouter op 30-03-2008 17:25 ]

[Verwijderd]

Wiebbe schreef op zondag 30 maart 2008 @ 17:21:

Dus basicly stuur je de challenge key naar de user toe, en stuurt daarna het wachtwoord en challenge 2x op naar de server. 1x via een post en een keer via de sessie?

Nee, de sessie wordt niet opgestuurd. Alle sessiegegevens staan altijd op de server.
Hoe je het doet maakt niet uit. Wat mij betreft stuur je de challenge en de response samen weer terug. Als de server met de challenge en de hash op dezelfde response komt, weet de server dat de client over de juiste gegevens beschikt. Geklooi met een sessie levert niet zoveel op.

Maar hoe krijg jij het password en challenge key veilige naar de server toe om hem in de sessie op te slaan?

De server genereert de challenge. Bij registratie is het wachtwoord ooit een keer alleen als hash van wachtwoord+salt naar de server gestuurd. Verder hoeft het nooit meer.

Ja, nogal logisch dat ik je aanspreek op wat er in je post staat, ik weet toch niet meteen wat je er mee bedoeld

Het gaat mij ook om de denk wijze, het punt is dat er dus een challenge/response systeem moet komen van een database waarin hashbased wachtwoorden opgeslagen worden. En dat is dus iets wat niet werkt..

Challenge/response staat volledig los van het wel of niet hashen van wachtwoorden. Zie dat dan ook als twee verschillende dingen.

Doel van hash
Zorgen dat het originele wachtwoord niet eenvoudig kan worden afgeleid.

Doel van hash(password+salt)
Zorgen dat hashes niet eenvoudig kunnen worden teruggezocht in rainbow tables. Denk erom dat dit voor zwakke wachtwoorden niet zo opschiet, omdat met een dictionary attack ook vlug veel hashes bepaald kunnen worden.

Doel van hash(password+salt+userspecifiek iets)
Zorgen dat er geen gelijke hashes in de database staan, want daaruit zou iemand kunnen afleiden dat iemand anders hetzelfde wachtwoord heeft.

Doel van challenge/response
Zorgen dat met informatie over een transactie (door bijvoorbeeld packet sniffing) niet nog een transactie kan worden gedaan. Er hoeft geen informatie als het wachtwoord of hash(salt+wachtwoord) te worden overgestuurd.

[Wiebbe]

skabouter schreef op zondag 30 maart 2008 @ 17:21:
[...]


Hmm daar had ik nog niet aan gedacht, dat moet voldoende zijn! Per gebruiker is de salt dan uniek (als je alleen unieke registratie namen verplicht steld) en je hoeft geen aparte salt te sturen.


[...]


Inderdaad, bij het registreren en/of wijzigen van het wachtwoord kan er geen gebruik gemaakt worden van de challenge/response die je gebruikt, of je moet de challenge op slaat in de database als 2e salt (maar dan werkt de suggestie die Cheatah gaf helaas niet meer)


[...]


Dat klopt, maar dat is weer een heel ander verhaal.

Wat ik dus heb bij mijn login systeem, is een gebruikers salt en een server salt. De server salt is een unieke code die alleen in de php is opgeslagen, de user salt is opgeslagen bij de hash in de database zelf.

Met de usersalt wil ik inderdaad voorkomen dat gebruikers geen zelfde wachtwoord hebben, maar opzich zou de gebruikers naam daar inderdaad ook voor kunnen dienen.

Maar de server salt wil ik wel graag behouden, deze zorgt voor een een extra stap in het bruteforcen van het wachtwoord. Met alleen de hash en de gebruikers naam kan je "makkelijk" de wachtwoorden bruteforcen. Maar zonder de serversalt zal dit nooit mogelijk worden.

Ik ga me denk ik even afvragen of ik wel of niet die server salt behoudt. Want met die server salt kan je nooit een challenge/response system maken zonder de salt bekend te maken aan de gebruiker zelf (en dat moet dus juist NIET gebeuren )

[Verwijderd]

Wiebbe schreef op zondag 30 maart 2008 @ 17:34:

Ik ga me denk ik even afvragen of ik wel of niet die server salt behoudt. Want met die server salt kan je nooit een challenge/response system maken zonder de salt bekend te maken aan de gebruiker zelf (en dat moet dus juist NIET gebeuren )

Waarom mag een gebruiker een salt niet weten? Als de server gecompromised is, mag je aannemen dat de hacker over de salt beschikt, en dat je challenge/response systeem niet meer deugt. Het enige doel van dat hashen is dan nog de wachtwoorden beschermen. En die heb je dan beschermd doordat er (bij een sterk wachtwoord) een brute force techniek aan te pas moet komen om het wachtwoord te kraken. Bij een 128-bit md5 hash wens ik de kraker alvast veel succes.

[Wiebbe]

Verwijderd schreef op zondag 30 maart 2008 @ 17:31:
[...]

Nee, de sessie wordt niet opgestuurd. Alle sessiegegevens staan altijd op de server.
Hoe je het doet maakt niet uit. Wat mij betreft stuur je de challenge en de response samen weer terug. Als de server met de challenge en de hash op dezelfde response komt, weet de server dat de client over de juiste gegevens beschikt. Geklooi met een sessie levert niet zoveel op.

Waar het mij daar om ging was dat dus dat je dus wel de hash van het wachtwoord + challenge op de server moet kunnen maken. Dat was voor mij dus vanaf het begin af aan al het probleem. Ik heb geen password in mijn database staan (alleen hash(usersalt + password + server salt)) dus ik kan die hash nooit maken.

Challenge/response staat volledig los van het wel of niet hashen van wachtwoorden. Zie dat dan ook als twee verschillende dingen.

Doel van hash
Zorgen dat het originele wachtwoord niet eenvoudig kan worden afgeleid.

Doel van hash(password+salt)
Zorgen dat hashes niet eenvoudig kunnen worden teruggezocht in rainbow tables. Denk erom dat dit voor zwakke wachtwoorden niet zo opschiet, omdat met een dictionary attack ook vlug veel hashes bepaald kunnen worden.

Doel van hash(password+salt+userspecifiek iets)
Zorgen dat er geen gelijke hashes in de database staan, want daaruit zou iemand kunnen afleiden dat iemand anders hetzelfde wachtwoord heeft.

Doel van challenge/response
Zorgen dat met informatie over een transactie (door bijvoorbeeld packet sniffing) niet nog een transactie kan worden gedaan. Er hoeft geen informatie als het wachtwoord of hash(salt+wachtwoord) te worden overgestuurd.

dit begrijp ik zeer zeker. Mijn probleem (en zo ver ik weet van de TS dus ook) is dat er dus geen challenge/response gedaan kan worden omdat de hash niet op de server vergeleken kan worden. Met een salt van de gebruikersnaam, die je uiteraard ook al hebt op de client, zou dat wel kunnen.

[Voutloos]

Wiebbe schreef op zondag 30 maart 2008 @ 17:41:
Waar het mij daar om ging was dat dus dat je dus wel de hash van het wachtwoord + challenge op de server moet kunnen maken. Dat was voor mij dus vanaf het begin af aan al het probleem. Ik heb geen password in mijn database staan (alleen hash(usersalt + password + server salt)) dus ik kan die hash nooit maken.

Server slaat tijdens registratie op:
H_pw = hash(usersalt + password + server salt)
waar in het midden gelaten kan worden of de client of server heeft moeten hashen.

Vervolgens kan je in de rest van het protocol prima hash(H_pw + challenge) gebruiken, want beide kanten kunnen die formule invullen. Waar het omgaat is dat overal waar 'wachtwoord' staat, net zo goed hash van wachtwoord kan staan, als het maar consistent gebeurt.

[b19a]

Verwijderd schreef op zondag 30 maart 2008 @ 17:31:
Nee, de sessie wordt niet opgestuurd. Alle sessiegegevens staan altijd op de server.
Hoe je het doet maakt niet uit. Wat mij betreft stuur je de challenge en de response samen weer terug. Als de server met de challenge en de hash op dezelfde response komt, weet de server dat de client over de juiste gegevens beschikt. Geklooi met een sessie levert niet zoveel op.

Zoals ik je post nu lees zou een aanvaller zo een replay-attack kunnen uitvoeren. Je wilt immers de challenge bij de server verzinnen waarna de server en client een response berekenen. Als je de challenge ook weer meestuurt en de server gebruikt de meegestuurde challenge, dan is je systeem per definitie al lek. Als ik dan ga packet-sniffen en de user/challenge/response-gegevens weet te onderscheppen, post ik die zelf ook een keer waarna ik ben ingelogd.

Na het doornemen van deze thread wordt het me niet duidelijk waarom ik de serversalt niet bekend zou mogen maken aan de client. De reden voor het gebruik van deze salt is het bemoeilijken van het opzoeken van het wachtwoord/dubbele wachtwoorden verbergen. Wat is er zo kwalijk aan dat dat niet mag?

[skabouter]

dit begrijp ik zeer zeker. Mijn probleem (en zo ver ik weet van de TS dus ook) is dat er dus geen challenge/response gedaan kan worden omdat de hash niet op de server vergeleken kan worden. Met een salt van de gebruikersnaam, die je uiteraard ook al hebt op de client, zou dat wel kunnen.

Ik heb hier eigenlijk geen last van aangezien ik geen server side salt gebruik. Mijn probleem is nu verhlopen doordat ik de gebruikersnaam als salt ga gebruiken.

[Wiebbe]

Voutloos schreef op zondag 30 maart 2008 @ 17:47:
[...]
Server slaat tijdens registratie op:
H_pw = hash(usersalt + password + server salt)
waar in het midden gelaten kan worden of de client of server heeft moeten hashen.

Vervolgens kan je in de rest van het protocol prima hash(H_pw + challenge) gebruiken, want beide kanten kunnen die formule invullen. Waar het omgaat is dat overal waar 'wachtwoord' staat, net zo goed hash van wachtwoord kan staan, als het maar consistent gebeurt.

Ja, dan zou het inderdaad prima kunnen werken. Mijn "probleem" is dus dat ik een serverside hash heb die "geheim" moet blijven. De vraag of dat ook echt nodig is, is er nu dus een die ik probeer te beantwoorden.

ik had ooit een erg goed idee om twee soorten salts te gebruiken, ik ga nu even terug kijken wat de reden was, en of die uberhaupt wel geldig was

Maar dan nog geld uiteraard wel dat de hash op de client side te maken moet zijn. Dus de salt moet wel beschikbaar zijn op de client zelf. (wat bij een algemene icm username niet uit zou maken)

skabouter schreef op zondag 30 maart 2008 @ 18:01:
[...]


Ik heb hier eigenlijk geen last van aangezien ik geen server side salt gebruik. Mijn probleem is nu verhlopen doordat ik de gebruikersnaam als salt ga gebruiken.

Nou ja, het probleem begon hetzelfde natuurlijk, beide hadden we last dat we geen hash kon maken op de client doordat er een salt gebruikt werd op de server die niet op de client bekend was.

[ Voor 17% gewijzigd door Wiebbe op 30-03-2008 18:19 ]

[Verwijderd]

BoukeHaarsma schreef op zondag 30 maart 2008 @ 17:51:

Zoals ik je post nu lees zou een aanvaller zo een replay-attack kunnen uitvoeren.

Je hebt helemaal gelijk. Ik ga er zelf raar van praten als ik het zo begrijpelijk mogelijk moet uitleggen. Maar inderdaad, je moet wel de challenge in de sessie stoppen, of bij het user account opslaan als je geen simultane logins wilt toestaan.

[ChessSpider]

Wiebbe schreef op zondag 30 maart 2008 @ 17:15:
Dat heeft geen nut? Je hashed dan met een vaste waarde, je krijgt wel een mooie hash, maar als iemand de string oppakt kan hij gewoon dezelfde string opsturen via een eigen geschreven pagina.

Een challenge is juist bedoeld om elke keer random te zijn als je de login pagina hebt, iemand kan dan niet zomaar het wachtwoord onderscheppen en die rechtstreeks posten naar de server.. aangezien de challenge van de server dan niet overeen komt met die van de client/hash.

Nee, je hashed met een md5 hash van de microtime. Elke miliseconde dat je refreshed is de hash/salt anders. En omdat in de sessie word onthouden welke salt er naar de browser gestuurd is, kan je niet zomaar je eigen salt invullen.

Dus basicly stuur je de challenge key naar de user toe, en stuurt daarna het wachtwoord en challenge 2x op naar de server. 1x via een post en een keer via de sessie? Maar hoe krijg jij het password en challenge key veilige naar de server toe om hem in de sessie op te slaan?

De server bepaald de challengekey, oftewel salt. De salt word naar de browser gestuurd en opgeslagen in de sessie. De browser stuurt de sha256 hash terug van de salt en ingevulde wachtwoord. De server gebruikt de - in de sessie opgeslagen - salt en correcte wachtwoord, en controleerd of die matched met de gePOSTe hash.

Sterker nog, doormiddel van javascript maak ik de hiden challengekey veld zelfs leeg voordat hij word verstuurd. Zo kan je alleen achter de challengekey komen als hij verstuurd word naar de browser, in plaats van ook naar de server. Natuurlijk schijnveiligheid.

Code:

PHP:

<?php
session_start();

$wachtwoord = "blowfish";

if($_SERVER['REQUEST_METHOD'] == "POST")
{
    $password = $_POST['password'];

    if( $password == hash('sha256',$_SESSION['salt']."enmijn".$wachtwoord) )
    {
        echo "ingelogd";
    }
}

$_SESSION['salt'] = md5(microtime());
 
?>

<script>
hashmeplease()
{
    salt = document.form[0].salt.value;
    password = document.form[0].password.value;
    
    document.form[0].salt.value = "";
    
    document.form[0].password.value = sha256(salt + "enmijn" + password)
    return true;
}
</script>

<form method='post' onsubmit='return hashmeplease()'>
<input type='hidden' name='salt' value='<?php echo $_SESSION['salt']; ?>' />
<input type='password' name='password' value=' ' />
<input type='submit' name='submit' value='submit' />
</form>

Bovenstaande code is niet getest, maar geeft je een goed idee denk ik. Note, sha256() is geen functie van javascript, maar je hebt implementaties die je kan downloaden voor javascript.

[ Voor 23% gewijzigd door ChessSpider op 30-03-2008 22:43 ]

[Wiebbe]

Ja, het challenge/response systeem heb ik al een langere tijd geleden gebruikt. Het ging mij om een challenge/response systeem en een hashed password in de database met een userbased salt die dus niet bij de client bekend is op het moment dat hij wil inloggen.

[ChessSpider]

Wiebbe schreef op zondag 30 maart 2008 @ 22:52:
Ja, het challenge/response systeem heb ik al een langere tijd geleden gebruikt. Het ging mij om een challenge/response systeem en een hashed password in de database met een userbased salt die dus niet bij de client bekend is op het moment dat hij wil inloggen.

Sorry, dat haalde ik niet uit je vraag.