Gathering of Tweakers

skabouter

dummy@example.com (skabouter) — Sun, 30 Mar 2008 13:19:26 GMT

zondag 30 maart 2008 15:19
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:

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!

Tofu

dummy@example.com (Tofu) — Sun, 30 Mar 2008 13:32:39 GMT

zondag 30 maart 2008 15:32
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..

Cheatah

dummy@example.com (Cheatah) — Sun, 30 Mar 2008 13:40:31 GMT

zondag 30 maart 2008 15:40
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

dummy@example.com (Wiebbe) — Sun, 30 Mar 2008 13:59:48 GMT

zondag 30 maart 2008 15:59
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?

Cheatah

dummy@example.com (Cheatah) — Sun, 30 Mar 2008 14:02:06 GMT

zondag 30 maart 2008 16:02
Als een hash van een salt en het password natuurlijk. Wat is dat nou voor vraag?

apokalypse

dummy@example.com (apokalypse) — Sun, 30 Mar 2008 14:03:45 GMT

zondag 30 maart 2008 16:03
Challenge/response en hashing werken niet samen.

HTTPS en gehashed in de DB is meestal ok.

Sypher

dummy@example.com (Sypher) — Sun, 30 Mar 2008 14:08:59 GMT

zondag 30 maart 2008 16:08
Check deze site even

Wiebbe

dummy@example.com (Wiebbe) — Sun, 30 Mar 2008 14:10:45 GMT

zondag 30 maart 2008 16:10
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

dummy@example.com (Voutloos) — Sun, 30 Mar 2008 14:13:35 GMT

zondag 30 maart 2008 16:13
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.

Cheatah

dummy@example.com (Cheatah) — Sun, 30 Mar 2008 14:15:36 GMT

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.

Wiebbe

dummy@example.com (Wiebbe) — Sun, 30 Mar 2008 14:25:38 GMT

zondag 30 maart 2008 16:25

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)

apokalypse

dummy@example.com (apokalypse) — Sun, 30 Mar 2008 14:35:31 GMT

zondag 30 maart 2008 16:35

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

Wiebbe

dummy@example.com (Wiebbe) — Sun, 30 Mar 2008 14:41:42 GMT

zondag 30 maart 2008 16:41

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

skabouter

dummy@example.com (skabouter) — Sun, 30 Mar 2008 14:42:12 GMT

zondag 30 maart 2008 16:42

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

Cheatah

dummy@example.com (Cheatah) — Sun, 30 Mar 2008 14:47:08 GMT

zondag 30 maart 2008 16:47

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.

skabouter

dummy@example.com (skabouter) — Sun, 30 Mar 2008 14:51:40 GMT

zondag 30 maart 2008 16:51

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:

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.

Cheatah

dummy@example.com (Cheatah) — Sun, 30 Mar 2008 14:56:34 GMT

zondag 30 maart 2008 16:56
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

dummy@example.com (skabouter) — Sun, 30 Mar 2008 14:58:56 GMT

zondag 30 maart 2008 16:58
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

dummy@example.com (Voutloos) — Sun, 30 Mar 2008 15:01:44 GMT

zondag 30 maart 2008 17:01

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.

skabouter

dummy@example.com (skabouter) — Sun, 30 Mar 2008 15:03:23 GMT

zondag 30 maart 2008 17:03

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.

Die moet je even uitleggen of even je zin herschrijven

Wiebbe

dummy@example.com (Wiebbe) — Sun, 30 Mar 2008 15:05:08 GMT

zondag 30 maart 2008 17:05

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.

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

dummy@example.com (Voutloos) — Sun, 30 Mar 2008 15:05:11 GMT

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.

Wiebbe

dummy@example.com (Wiebbe) — Sun, 30 Mar 2008 15:07:40 GMT

zondag 30 maart 2008 17:07

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

Cheatah

dummy@example.com (Cheatah) — Sun, 30 Mar 2008 15:12:08 GMT

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)

Voutloos

dummy@example.com (Voutloos) — Sun, 30 Mar 2008 15:12:55 GMT

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.