Hoofdcategorieën
Topicacties

[PHP] Login methode & password opslag

Pagina: 1 2 last

Reageer Nieuw Topic
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:
1
2
3
4
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:
1
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!

[ pwnd.nl | Dislect ]

Berichten: 692
Reg. datum: 31 maart 2003

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..
Lágrimas negras
Berichten: 17.227
Reg. datum: 31 mei 2001

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.

I finally found you, my personal slaughter. As an appetizer, I let you taste my daughter!
Call me sick but this is what I need. My only purpose here is for you to feed!

moeh?

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?

Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei

Lágrimas negras
Berichten: 17.227
Reg. datum: 31 mei 2001

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

I finally found you, my personal slaughter. As an appetizer, I let you taste my daughter!
Call me sick but this is what I need. My only purpose here is for you to feed!

Berichten: 84
Reg. datum: 31 augustus 2004

Challenge/response en hashing werken niet samen.

HTTPS en gehashed in de DB is meestal ok.
 
Berichten: 1.194
Reg. datum: 26 oktober 2002

Check deze site even :)

Asus P5W DH Deluxe | C2D 2.4 GHz | Logitech G15 + G7 (SE) | 2x 2048MB DDR800 | ATi Radeon HD2900XT 512 MB | SM-226BW TFT @ 1680x1050 | X-Fi XtremeGamer | 2x 320 GB WDC Raid Edition (SATA II) | 54mbit WLAN onboard | Linksys WRT54GS | SpeedTouch 546 ADSL2+

moeh?

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 ;)

Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei

Trees

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. ;)
Lágrimas negras
Berichten: 17.227
Reg. datum: 31 mei 2001

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.

I finally found you, my personal slaughter. As an appetizer, I let you taste my daughter!
Call me sick but this is what I need. My only purpose here is for you to feed!

moeh?

quote:
Cheatah 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)

Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei

Berichten: 84
Reg. datum: 31 augustus 2004

quote:
Cheatah 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...
 
moeh?

quote:
Cheatah 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 :P (als uitbreiding op boven ;p)

Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei

Skabouter

quote:
Cheatah 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.
quote:
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.
quote:
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!
quote:
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.
quote:
Een mooi voorbeeld van challenge/response, maar helaas zit hier geen salt in.

skabouter wijzigde dit bericht 30-03-2008 17:09 (61%)
Reden: Even gereageerd op wat voorgaande berichten

[ pwnd.nl | Dislect ]

Lágrimas negras
Berichten: 17.227
Reg. datum: 31 mei 2001

quote:
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?
quote:
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.
quote:
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.

Cheatah wijzigde dit bericht 30-03-2008 16:54 (40%)

I finally found you, my personal slaughter. As an appetizer, I let you taste my daughter!
Call me sick but this is what I need. My only purpose here is for you to feed!

Skabouter

quote:
Cheatah 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:
1
2
3
4
5
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.

skabouter wijzigde dit bericht 30-03-2008 16:53 (0%)
Reden: Salt vergeten

[ pwnd.nl | Dislect ]

Lágrimas negras
Berichten: 17.227
Reg. datum: 31 mei 2001

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

I finally found you, my personal slaughter. As an appetizer, I let you taste my daughter!
Call me sick but this is what I need. My only purpose here is for you to feed!

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.

[ pwnd.nl | Dislect ]

Trees

quote:
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. :Y)
Skabouter

quote:
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. :Y)
Die moet je even uitleggen of even je zin herschrijven :P

[ pwnd.nl | Dislect ]

moeh?

quote:
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. :Y)
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 :P

Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei

Trees

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. :)
moeh?

quote:
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..

Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei Woei

Lágrimas negras
Berichten: 17.227
Reg. datum: 31 mei 2001

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)

Cheatah wijzigde dit bericht 30-03-2008 17:16 (36%)

I finally found you, my personal slaughter. As an appetizer, I let you taste my daughter!
Call me sick but this is what I need. My only purpose here is for you to feed!

Trees

@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.

Pagina: 1 2 last



VNU Media logo Powered by True

© 1998 - 2008 Tweakers.net - Alle rechten voorbehouden

Uitgever van: