[Encryptie/md5] Salted hashes

[Arcane Apex]

Ik vroeg mij af of het bij hashes zoals die van md5 welke gesalt zijn een probleem is wanneer de salt publiekelijk bekend is.

Voorbeeld:

code:

//Javascript code

//Maak een hash van het wachtwoord in combinatie met de salt string
md5("ditIsEenSaltString"+wachtwoord);

Stel dat "ditIsEenSaltString" gewoon in de html van een pagina voorkomt, immers javascript is gewoon zichtbaar in de html source. Iedereen kan dan zien dat de hash gesalt is. Maar helpt die kennis eigenlijk bij het decoderen van de hash? (op welke manier dan ook?)
Zou je in dit geval beter wel of niet de hash kunnen salten?

[CodeCaster]

Ja, want als de salt bekend is kunnen ze alsnog bruteforcen om het oorspronkelijke wachtwoord te achterhalen. Stel, je wachtwoord is 'a' en de salt die je erachter plakt is 'salt', dan is de hash daarvan f4ffb581db4c299561399fc62138537e.

Als je nu gaat bruteforcen met a-zzzzzzzzzz en je plakt achter iedere gok de salt die bekend is, dan is het hele nut van die salt weg.

[ Voor 3% gewijzigd door CodeCaster op 06-01-2009 14:33 ]

[Voutloos]

CodeCaster schreef op dinsdag 06 januari 2009 @ 14:32:
dan is het hele nut van die salt weg.

Onwaar, want je zorgt er in ieder geval voor dat standaard/eerder opgebouwde rainbow tabel niet bruikbaar is.

[Arcane Apex]

Voutloos schreef op dinsdag 06 januari 2009 @ 14:38:
[...]
Onwaar, want je zorgt er in ieder geval voor dat standaard/eerder opgebouwde rainbow tabel niet bruikbaar is.

Dus het maakt in ieder geval het gebruik van rainbowtables moeilijker zoniet onmogelijk wanneer de saltstring extreem lang is?

[ Voor 8% gewijzigd door Arcane Apex op 06-01-2009 14:41 ]

[Voutloos]

Ja, je zorgt er dan in ieder geval voor dat een standaard/eerder opgebouwde rainbow tabel niet bruikbaar is.

Tevens heeft je salt ook nog nut in de zin dat het password equivalent (de hash ) voor eenzelfde wachtwoord niet hetzelfde is als bij andere projecten. Maar over hashen en salts is (oa) op GoT echt al heel veel geschreven. Vuistregel: Hashes gebruiken in security context == significante salt gebruiken.

[ Voor 59% gewijzigd door Voutloos op 06-01-2009 14:46 ]

[mithras]

Je moet bedenken hoe het werkt:

Server genereert salt
Server -> html code -> client
Client binnen html code de salt met ingevoerd password tot hash vormen
Client -> hash -> server.

Het punt hiermee is dat het password normaal gesproken onderweg niet versleuteld wordt verstuurd. En daarmee is het dus onveilig. Met deze methode moet je beide keren de data afluisteren, alvorens je met rainbow tabellen wat terug kan krijgen.
Het heeft daarom wel degelijk zin om een hash die je clientside maakt te salten.

[ Voor 16% gewijzigd door mithras op 06-01-2009 14:46 ]

[Arcane Apex]

Voutloos schreef op dinsdag 06 januari 2009 @ 14:42:
Ja, je zorgt er dan in ieder geval voor dat een standaard/eerder opgebouwde rainbow tabel niet bruikbaar is.

Dat is dan in ieder geval 1 klein voordeel. Maar omdat het niet helpt tegen brute force attacks vraag ik mij nu af hoe je bij client-side hashes de salt string dus onbekend kunt houden. Immers Javascript is gewoon te zien in de html source.

[Arcane Apex]

mithras schreef op dinsdag 06 januari 2009 @ 14:45:
Je moet bedenken hoe het werkt:

Server genereert salt
Server -> html code -> client
Client binnen html code de salt met ingevoerd password tot hash vormen
Client -> hash -> server.

Het punt hiermee is dat het password normaal gesproken onderweg niet versleuteld wordt verstuurd. En daarmee is het dus onveilig.

Maar het wachtwoord wordt toch aan de clientside gehashed alvorens naar de server verstuurd te worden? Dan is het wachtwoord onderweg toch alleen te zien als hash?

Edit:

mithras schreef op dinsdag 06 januari 2009 @ 14:45:
Het heeft daarom wel degelijk zin om een hash die je clientside maakt te salten.

Aha ok.

[ Voor 28% gewijzigd door Arcane Apex op 06-01-2009 14:51 ]

[mithras]

Arcane Apex schreef op dinsdag 06 januari 2009 @ 14:48:
[...]


Maar het wachtwoord wordt toch aan de clientside gehashed alvorens naar de server verstuurd te worden? Dan is het wachtwoord onderweg toch alleen te zien als hash?

Ja, dat klopt. Maar stel je twee casussen voor. Een waarbij je wel de salt gebruikt, een waarbij je niet de salt gebruikt.

Degene waarbij je niet de salt gebruikt, stuurt dus een hash van (bijvoorbeeld) md5(password) terug naar de server. Mocht iemand je sniffen en dit opvangen, is met een Rainbow table eenvoudig je password terug te halen.

Wanneer je wel een password gebruikt, stuur je md5( salt + md5(password) ) terug. Je kan met de Rainbow table vervolgens de tekenreeks salt+md5(password) terughalen. Maar wat ooit je password is geweest, dat is toch weer lastig terug te halen. Dat komt omdat je niet weet wat de salt is. Die moet je van tevoren ook afvangen wil je het password kunnen kraken. Dat gebeurt zeer zelden, dus daarmee is deze methode veiliger dan wanneer je geen salt gebruikt.

[gertvdijk]

mithras schreef op dinsdag 06 januari 2009 @ 14:52:
Wanneer je wel een passwordsalt gebruikt, stuur je md5( salt + md5(password) ) terug. Je kan met de Rainbow table vervolgens de tekenreeks salt+md5(password) terughalen. Maar wat ooit je password is geweest, dat is toch weer lastig terug te halen. Dat komt omdat je niet weet wat de salt is.

Een sniffer weet wel wat de salt is, want die moet plain-text over het web zijn gegaan naar de browser alvorens je md5( salt + md5(password) ) kan doen...

begintmeta schreef op dinsdag 06 januari 2009 @ 15:00:
En wat let je om de server random salts te laten uitgeven?

Dat doet niks af aan het bekend zijn van de salt ten tijde van het gesniffte inlogproces.

[ Voor 23% gewijzigd door gertvdijk op 06-01-2009 15:01 ]

[begintmeta]

En wat let je om de server per transactie unieke salts te laten uitgeven? Rainbowtables worden dan al helemaal een stuk minder zinvol...
De salt zal hoe dan ook publiekelijk bekend zijn, als je het veiliger wilt zou je asymmetrische encryptie er overheen kunnen leggen.

[ Voor 76% gewijzigd door begintmeta op 06-01-2009 15:02 ]

[CyBeR]

Salts moeten ook random zijn, en worden opgeslagen in plaintext naast het gehashte wachtwoord. Het dient er meer toe om rainbowtables bijzonder veel groter te moeten laten zijn en om twee dezelfde wachtwoorden anders te laten hashen (mits random salt) dan om je wachtwoord uber-onkraakbaar te maken.

Op het moment dat de salt niet bekend is kun je het wachtwoord niet verifieren want je kunt de hash dan niet goed berekenen.

[ Voor 17% gewijzigd door CyBeR op 06-01-2009 15:03 ]

[begintmeta]

Inderdaad CyBeR, dat bedoel ik, rainbowtables worden dan vrijwel zinloos.

gertvdijk schreef op dinsdag 06 januari 2009 @ 14:59:
...
Dat doet niks af aan het bekend zijn van de salt ten tijde van het gesniffte inlogproces.

Dat schreef ik ook niet (tenminste, ik zag later pas dat mijn post duidelijker zou zijn als ik mijn post even zou editen), maar het maakt rainbowtables aanzienlijk minder zinvol, anders zou het maken van een table+salt nog aantrekkelijk kunnen zijn, zeker voor toepassingen met veel gebruikers.

asymmetrische encryptie eroverheen Arcane Apex?

[ Voor 94% gewijzigd door begintmeta op 06-01-2009 15:11 ]

[gertvdijk]

CyBeR schreef op dinsdag 06 januari 2009 @ 15:02:
Salts moeten ook random zijn, en worden opgeslagen in plaintext naast het gehashte wachtwoord. Het dient er meer toe om rainbowtables bijzonder veel groter te moeten laten zijn en om twee dezelfde wachtwoorden anders te laten hashen (mits random salt) dan om je wachtwoord uber-onkraakbaar te maken.

Op het moment dat de salt niet bekend is kun je het wachtwoord niet verifieren want je kunt de hash dan niet goed berekenen.

We praten hier over twee verschillende casussen.

• Sniffen
• Het in handen krijgen van de database met wachtwoorden

Je moet je dus goed realiseren dat je met hashes het sniffen niet tegenhoudt en i.m.o. moet je je database op minstens ook op andere manieren beveiligen dan met hashes (goede code, geen SQL injections etc).

[ Voor 13% gewijzigd door gertvdijk op 06-01-2009 15:13 ]

[.oisyn]

Hier zijn al genoeg woorden aan verspild. Lees [alg] Wachtwoorden opslaan in plain-text eens door

[CyBeR]

gertvdijk schreef op dinsdag 06 januari 2009 @ 15:11:
[...]

We praten hier over twee verschillende casussen.

• Sniffen
• Het in handen krijgen van de database met wachtwoorden

Sniffen en een hashed wachtwoordendb in handen krijgen zijn bij (al dan niet salted) hashed wachtwoorden fundamenteel precies hetzelfde. Daarom is simpelweg (salted) hashes van wachtwoorden over het netwerk sturen net zo nuttig als plaintext wachtwoorden over het netwerk sturen. Het enige wat salts in dat geval toe zouden voegen is dat je, als je om een salted hash van een plaintext bekend wachtwoord vraagt, de hash value niet simpelweg kunt replayen. Maar daar ben je eigenlijk al met een challenge-response-systeem bezig.

[ Voor 32% gewijzigd door CyBeR op 06-01-2009 15:15 ]

[gertvdijk]

CyBeR schreef op dinsdag 06 januari 2009 @ 15:13:
Sniffen en een hashed wachtwoordendb in handen krijgen zijn bij (al dan niet salted) hashed wachtwoorden fundamenteel precies hetzelfde.

Nee, want bij sniffen is de salt bekend bij de attacker en bij een database kaping hoort dat absoluut niet het geval te zijn.

CyBeR schreef op dinsdag 06 januari 2009 @ 15:13:
Maar daar ben je eigenlijk al met een challenge-response-systeem bezig.

Daar heb ik een tijdje geleden ook eens over nagedacht, maar toen besloot ik dat een SSL certificaat van 45 euro voor drie jaar betere kosten/baten met zich meebracht. (alhoewel die helaas valt binnen de gekraakte categorie, maar dan praten we al over phishing en/of DNS hacks voordat dat misbruikt kan worden.)

Begrijp me overigens niet verkeerd. Ik moedig net als de rest het gebruik van hashes aan, maar je moet er gewoon niet mee verwachten dat het dan opeens heel veilig is en je moet daarom dan ook zeker andere veiligheidsmaatregelen niet ermee uit het oog verliezen!

[ Voor 59% gewijzigd door gertvdijk op 06-01-2009 16:06 ]

[Patriot]

CyBeR schreef op dinsdag 06 januari 2009 @ 15:13:
[...]


Sniffen en een hashed wachtwoordendb in handen krijgen zijn bij (al dan niet salted) hashed wachtwoorden fundamenteel precies hetzelfde. Daarom is simpelweg (salted) hashes van wachtwoorden over het netwerk sturen net zo nuttig als plaintext wachtwoorden over het netwerk sturen.

Wat bedoel je daar mee? Dat een wachtwoord hashed over het netwerk sturen niet veiliger is dan het wachtwoord plaintext over het netwerk sturen?

Het enige wat salts in dat geval toe zouden voegen is dat je, als je om een salted hash van een plaintext bekend wachtwoord vraagt, de hash value niet simpelweg kunt replayen.

Dat is toch sowieso het idee van salts? Voor zover ik weet maakt het ook niet uit dat de sniffer ook de salt doorkrijgt. Het wordt daardoor niet tot nauwelijks makkelijker om een string te vinden met een gelijke hash, als je de salt dan ook steeds anders maakt dan heb je helemaal niets aan de uiteindelijk verkregen gegevens..

[CyBeR]

Patriot schreef op woensdag 07 januari 2009 @ 11:33:
[...]

Wat bedoel je daar mee? Dat een wachtwoord hashed over het netwerk sturen niet veiliger is dan het wachtwoord plaintext over het netwerk sturen?

Pur sang, nauwelijks. Voorbeeld:

code:

gebruiker:
USER: blah
PASS: s3kr3t
OK

sniffer:
USER: blah
PASS: s3kr3t
OK

Vrij simpel te sniffen, attacker neemt 't gewoon letterlijk over.

Hashed:

code:

gebruiker:
USER: blah
PASS: 13cbb4d2c15e6a84f1cded5dc02ec09f
OK

sniffer:
USER: blah
PASS: 13cbb4d2c15e6a84f1cded5dc02ec09f
OK

Hee, da's precies hetzelfde idee. De haxx0rer weet dan weliswaar niet precies wat het wachtwoord is, maar hij heeft iets dat net zo goed is: de hash. Zo replayable als de pest. Dit wordt opgelost door challenge-authentication schemes waarbij de gehashte waarde aangepast wordt volgens een bepaalde, afgesproken, manier.

Dat is toch sowieso het idee van salts? Voor zover ik weet maakt het ook niet uit dat de sniffer ook de salt doorkrijgt. Het wordt daardoor niet tot nauwelijks makkelijker om een string te vinden met een gelijke hash, als je de salt dan ook steeds anders maakt dan heb je helemaal niets aan de uiteindelijk verkregen gegevens..

Correct. Echter heb ik salted hashes nog nooit op die manier gebruikt zien worden maar alleen in de achterkant. UNIX systemen gebruiken ze namelijk heel vaak.

gertvdijk schreef op dinsdag 06 januari 2009 @ 15:15:
[...]

Nee, want bij sniffen is de salt bekend bij de attacker en bij een database kaping hoort dat absoluut niet het geval te zijn.

Nee hoor, kijk maar eens hoe een tegenwoordig vrij standaard unix password (of om precies te zijn, shadow) database entryeruit ziet:

code:

root:$1$rTVAtzfL$cWAAi41pJkNwGm)7G9.oO0:13138:0:99999:7:::

Ontleed:
$1$ - dit is een MD5 hash
$rTVAtzfL$ - Salt
$rest - de hash zelf

[Voutloos]

Korte versie: de aanvaller heeft in beide gevallen het password equivalent, en die term liet ik al vallen...

[gertvdijk]

CyBeR schreef op woensdag 07 januari 2009 @ 11:55:
Nee hoor, kijk maar eens hoe een tegenwoordig vrij standaard unix password (of om precies te zijn, shadow) database entryeruit ziet:

code:

root:$1$rTVAtzfL$cWAAi41pJkNwGm)7G9.oO0:13138:0:99999:7:::

Ontleed:
$1$ - dit is een MD5 hash
$rTVAtzfL$ - Salt
$rest - de hash zelf

Ja duh, maar dat niet je MySQL/PostgreSQL/whatever database waar ook je websitegebruikers in staan.
Ik bedoelde, dat wanneer iemand toegang krijgt tot je database op wat voor manier dan ook (SQL injection bijv), dan heeft ie de salt nog niet waarmee de wachtwoorden zijn gehasht. Je moet dan ook je salt in je code zetten buiten de webroot, net als de rest van je includes. Als je dan een redelijk lange salt gebruikt voegt dit (momenteel nog) wel degelijk wat toe aan de beveiliging.

[ Voor 7% gewijzigd door gertvdijk op 07-01-2009 13:03 ]

[CyBeR]

gertvdijk schreef op woensdag 07 januari 2009 @ 13:00:
[...]

Ja duh, maar dat niet je MySQL/PostgreSQL/whatever database waar ook je websitegebruikers in staan.
Ik bedoelde, dat wanneer iemand toegang krijgt tot je database op wat voor manier dan ook (SQL injection bijv), dan heeft ie de salt nog niet waarmee de wachtwoorden zijn gehasht. Je moet dan ook je salt in je code zetten buiten de webroot, net als de rest van je includes. Als je dan een redelijk lange salt gebruikt voegt dit (momenteel nog) wel degelijk wat toe aan de beveiliging.

Je salt moet per wachtwoord anders zijn. Dat is het hele punt van salts. Punt is vooral namelijk dit:

marco@phoebe:~$ echo "hoi" | md5sum
766f1a227562764b8de355e0651eb116 -
marco@phoebe:~$ echo "hoi" | md5sum
766f1a227562764b8de355e0651eb116 -
marco@phoebe:~$

Terwijl met salts:
marco@phoebe:~$ mkpasswd -H md5
Password: (voer 'hoi' in)
$1$WozV6n4d$PLaDaeqjqjyhXkUtNtoVs1
marco@phoebe:~$ mkpasswd -H md5
Password: (voer 'hoi' in)
$1$NOOpesPm$FA.YGBtrwLs4.7kUVCi7U.

Simpelweg een salted hash met steeds dezelfde salt opslaan doet niet zo heel veel voor je security en het idee van 'hetzelfde wachtwoord, andere hash' is ook pleite.

[ Voor 29% gewijzigd door CyBeR op 07-01-2009 13:10 ]

[Cartman!]

Probleem met een salt per user is alleen dat de server eerst de username moet weten voordat je de salt kunt meesturen, hoe wil je dat dan praktisch oplossen?

Ik heb zelf een implementatie gemaakt met een vaste salt en een random token:
pass = hash(token+(hash(salt+ww))

en serverside die ik hash(token+db_waarde), in de database staat het wachtwoord dus als gehasht met salt. Zo ikrijg je een wachtwoord die maar 1 keer geldig is. Password hoeft nooit plaintext over de lijn.

[CyBeR]

Cartman! schreef op woensdag 07 januari 2009 @ 13:11:
Probleem met een salt per user is alleen dat de server eerst de username moet weten voordat je de salt kunt meesturen, hoe wil je dat dan praktisch oplossen?

Door alvast salts niet te gebruiken als vervanging voor een fatsoenlijk challenge-response-systeem Salts zijn alleen bedoeld voor de twee doelen die al eerder genoemd zijn aangaande meervoudig voorkomende wachtwoorden en rainbow tables. Het probleem wat jullie op proberen te lossen is al opgelost en heet Challenge-Response. Bijvoorbeeld, Wikipedia: CRAM-MD5.

[.oisyn]

CyBeR schreef op woensdag 07 januari 2009 @ 11:55:
Correct. Echter heb ik salted hashes nog nooit op die manier gebruikt zien worden maar alleen in de achterkant. UNIX systemen gebruiken ze namelijk heel vaak.

Ah, je hebt nog nooit ingelogd hier op GoT? Apart...

gertvdijk schreef op woensdag 07 januari 2009 @ 13:00:
[...]

Ja duh, maar dat niet je MySQL/PostgreSQL/whatever database waar ook je websitegebruikers in staan.
Ik bedoelde, dat wanneer iemand toegang krijgt tot je database op wat voor manier dan ook (SQL injection bijv), dan heeft ie de salt nog niet waarmee de wachtwoorden zijn gehasht. Je moet dan ook je salt in je code zetten buiten de webroot, net als de rest van je includes. Als je dan een redelijk lange salt gebruikt voegt dit (momenteel nog) wel degelijk wat toe aan de beveiliging.

Dat is security by obscurity. Een MD5 bruteforcen kost vrij veel processortijd, zeker als je wachtwoorden voldoende sterk zijn (lang, veel verschillende tekens, geen woorden), dus in dat opzicht is het niet zo heel erg als de salt bekend is, zolang hij voor iedere user maar verschillend is (zodat multi-user attacks niet meer mogelijk zijn).

[gertvdijk]

.oisyn schreef op woensdag 07 januari 2009 @ 13:26:
zolang hij voor iedere user maar verschillend is (zodat multi-user attacks niet meer mogelijk zijn).

Ik bedoelde het ook anders. Mijn post was wat te kort door de bocht. Wat ik wél bedoelde maar niet had geschreven was dat ik een geheime project-wide-salt gebruik en die aan de username plak wat dan de salt wordt voor de md5 hash. Dus zoiets: md5( project-wide-salt + username-of-ander-unieke-waarde + md5(password) ). Zo heb je geen trucendoos nodig om de user bekend te krijgen en heb je voor iedere user een andere salt (en is ie niet te raden).

[.oisyn]

De focus van mijn post lag op het al dan niet bekend moeten zijn van de salt, niet over het al dan niet uniek zijn van de salt

[gertvdijk]

Mijn posts zijn ook niet altijd even helder misschien, maar dit mag je toch echt uitleggen.

.oisyn schreef op woensdag 07 januari 2009 @ 13:47:
De focus van mijn post lag op het niet bekend moeten zijn van de salt, niet over het al dan niet uniek zijn van de salt

.oisyn schreef op woensdag 07 januari 2009 @ 13:26:
dus in dat opzicht is het niet zo heel erg als de salt bekend is, zolang hij voor iedere user maar verschillend is (zodat multi-user attacks niet meer mogelijk zijn).

[Cartman!]

user 1 heeft als salt: foo
user 2 heeft als salt: bar

bedoelt ie zodat je niet kunt bruteforcen incl. de salt die toch bij iedereen hetzelfde is.

Graag wil ik wel nog weten hoe je het voor elkaar krijgt om een unieke salt bij elke user te gebruiken op een pagina met username en password. Want de salt weet je toch pas als bekend is op de server welke user er inlogt?

[.oisyn]

gertvdijk schreef op woensdag 07 januari 2009 @ 13:56:
Mijn posts zijn ook niet altijd even helder misschien, maar dit mag je toch echt uitleggen.

[...]


[...]

Als ik het heb over de focus van mijn post moet je natuurlijk niet selectief gaan quoten , namelijk precies dat deel waar dan juist niet de focus op lag. Mijn punt was dat het dus niet zo heel erg is als de salt bekend is, en ook de salt is de achterhalen op het moment dat de hacker in staat is een account te creëren. Als je je gebruikers wilt beschermen doe je dat imho niet door de salt goed te verstoppen - dat is een schijnveiligheid.

[gertvdijk]

Cartman! schreef op woensdag 07 januari 2009 @ 13:59:
user 1 heeft als salt: foo
user 2 heeft als salt: bar

bedoelt ie zodat je niet kunt bruteforcen incl. de salt die toch bij iedereen hetzelfde is.

Graag wil ik wel nog weten hoe je het voor elkaar krijgt om een unieke salt bij elke user te gebruiken op een pagina met username en password. Want de salt weet je toch pas als bekend is op de server welke user er inlogt?

Er is natuurlijk een verschil of je wil voorkomen dat je gesniffte hashes kraakbaar zijn of de tabel met alle opgeslagen hashes. Dat eerste los je alleen op met challenge-response of SSL als ik me niet vergis.
Daarnaast is een mogelijkheid om elke user een aparte salt te geven door user-unique-property + project-wide-salt als salt te gebruiken. Een losse lijst, zoals jij voorstelt lijkt me lastig in de praktijk als je het buiten de database moet houden.

.oisyn schreef op woensdag 07 januari 2009 @ 14:25:
Als ik het heb over de focus van mijn post moet je natuurlijk niet selectief gaan quoten ,

Los ervan waar je focus lag, je sprak jezelf nogal tegen.

.oisyn schreef op woensdag 07 januari 2009 @ 14:25:
Mijn punt was dat het dus niet zo heel erg is als de salt bekend is, en ook de salt is de achterhalen op het moment dat de hacker in staat is een account te creëren. Als je je gebruikers wilt beschermen doe je dat imho niet door de salt goed te verstoppen - dat is een schijnveiligheid.

Ach het ligt eraan wat je veilig noemt. Het is in elk geval veiliger met een relatief simpel mechanisme. Tuurlijk kan je beter met SSL e.d. aan de slag, maar mijn vrees is altijd dat je juist door dat soort toepassingen andere veiligheidsmaatregelen laat versloffen of je je veilig waant terwijl dit niet hoeft te zijn en je daarom beter breed kan denken en meerdere schakels kan opzetten.

[ Voor 35% gewijzigd door gertvdijk op 07-01-2009 15:07 ]

[Voutloos]

Dat laatste hoeft dus niet, want dat is enkel obscurity...

[.oisyn]

gertvdijk schreef op woensdag 07 januari 2009 @ 15:01:
Los ervan waar je focus lag, je sprak jezelf nogal tegen.

Ik heb mijn posts nog eens doorgelezen en ik zie nergens dat ik mezelf tegenspreek. Wellicht dat je bepaalde aannames maakt bij de interpretatie van mijn posts?

.edit: Ah, ik zie denk ik al waar de schoen wringt:

.oisyn schreef op woensdag 07 januari 2009 @ 13:47:
De focus van mijn post lag op het niet bekend moeten zijn van de salt, niet over het al dan niet uniek zijn van de salt

Als ik dit zeg dan zeg ik niet dat ik vind dat de salt niet bekend mag zijn. Ik neem "het niet bekend moeten zijn van de salt" (jouw stelling) als onderwerp, en daar ligt de focus van mijn post op (maw, dat is waar ik op reageerde, en waar ik dus tegen in ging). Ik zal er wel "al dan niet" van maken voor de duidelijkheid.

[ Voor 61% gewijzigd door .oisyn op 07-01-2009 15:18 ]

[Patriot]

gertvdijk schreef op woensdag 07 januari 2009 @ 15:01:
[...]

Er is natuurlijk een verschil of je wil voorkomen dat je gesniffte hashes kraakbaar zijn of de tabel met alle opgeslagen hashes. Dat eerste los je alleen op met challenge-response of SSL als ik me niet vergis.
Daarnaast is een mogelijkheid om elke user een aparte salt te geven door user-unique-property + project-wide-salt als salt te gebruiken. Een losse lijst, zoals jij voorstelt lijkt me lastig in de praktijk als je het buiten de database moet houden.

Waar hij op doelde was het vooraf bij de client hashen. Dat kan niet met een user-unique-property omdat de user nog niet bekend is op dat moment. Overigens geeft een unieke salt per gebruiker geen extra beveiliging, alleen maar onnodige complexiteit (relatief complex t.o.v. een globale salt).

Een challenge response systeem is iets wat ik zou gebruiken om bij de client reeds te hashen (extreem makkelijk in elkaar te zetten) zodat een sniffer het wachtwoord in ieder geval niet plaintext op te sniffen is. Vervolgens nog een goede globale salt voor de database en je bent klaar.

Dan heb je volgens mij je doel bereikt: In de POST-request van de client is het wachtwoord alleen nog hashed terug te vinden en in de database staan geen wachtwoorden waar je met rainbowtables snel wat mee gaat kunnen.

[begintmeta]

Patriot schreef op donderdag 08 januari 2009 @ 23:35:
.... Overigens geeft een unieke salt per gebruiker geen extra beveiliging, alleen maar onnodige complexiteit (relatief complex t.o.v. een globale salt).
...

Afhankelijk van het aantal gebruikers kan het best interessant zijn unieke salts te maken, rainbowtables opbouwen wordt dan toch minder interessant.

[.oisyn]

Patriot schreef op donderdag 08 januari 2009 @ 23:35:
Overigens geeft een unieke salt per gebruiker geen extra beveiliging, alleen maar onnodige complexiteit (relatief complex t.o.v. een globale salt).

Weldegelijk. Stel je database ligt bloot en je hebt 100.000 gebruikers in je database. Het vinden van een collision met 1 van de hashes gaat dan 100.000 keer zo snel als wanneer je voor iedere gebruiker unieke salts gebruikt. En idd, zoals begintmeta al opmerkt wordt het maken van een specifieke rainbowtable voor die database dan een stuk interessanter omdat je daarmee in een keer 100.000 users tegelijk kunt aanvallen.

[begintmeta]

.oisyn schreef op vrijdag 09 januari 2009 @ 00:36:
.... En idd, zoals begintmeta al opmerkt wordt het maken van een specifieke rainbowtable voor die database dan een stuk interessanter omdat je daarmee in een keer 100.000 users tegelijk kunt aanvallen.

Vooral ook als je een sterke groei in aantal gebruikers verwacht wordt zoiets aantrekkelijk.

[Verwijderd]

gertvdijk schreef op woensdag 07 januari 2009 @ 15:01:
Een losse lijst, zoals jij voorstelt lijkt me lastig in de praktijk als je het buiten de database moet houden.

Je hebt altijd de mogelijkheid om dit in een aparte database weg te schrijven. Mocht er ergens een SQL injection mogelijk zijn dan komt deze altijd op de content database uit (waar je bv nieuws, userprofiles, etc). De security (userid+pwd+etc) database is alleen te benaderen vanaf een gesloten systeem (bv als aparte classe, waar een een bezoeker alleen bij kan komen via de loginprocedure).

Ik heb voor mijn eigen framework op het moment 2 "directe" users in gebruik, en indirect een berg meer ivm 3rd party software (minimaal 1 user/db per pakket).

Registratie vanaf mijn eigen framework en via een cronjob laat ik de users + rechten synchroniseren naar de pakketen (nee geen LDAP, ga ik verder niet op in atm). Login gaat via een SSO methode en ook gebruik ik bij de synchronisatie weer een aparte hash/salt tabel, om te zorgen dat bij een lekke 3rd party app de gelekte database (sql injection) niet kan leiden tot het kapen van rechten voor andere apps.

[Voutloos]

Pfff... anders doe je voor dat beetje security by obscurity er nog een extra schepje complexiteit bovenop. Je bent het nu enkel voor jezelf lastiger aan het maken hoor.

[Patriot]

.oisyn schreef op vrijdag 09 januari 2009 @ 00:36:
[...]

Weldegelijk. Stel je database ligt bloot en je hebt 100.000 gebruikers in je database. Het vinden van een collision met 1 van de hashes gaat dan 100.000 keer zo snel als wanneer je voor iedere gebruiker unieke salts gebruikt. En idd, zoals begintmeta al opmerkt wordt het maken van een specifieke rainbowtable voor die database dan een stuk interessanter omdat je daarmee in een keer 100.000 users tegelijk kunt aanvallen.

Hmm, dat is wel waar inderdaad. Maar uiteindelijk is dat ook weer een kwestie van bereidheid om moeite/resources in iets te willen steken. Ook met unieke salts kunnen er collisions gevonden worden.

[Cartman!]

.oisyn, kun je me dan nog uitleggen hoe je in een webomgeving in 1 pagina dit voor elkaar wil krijgen? De server weet immers nog niet welke salt hij moet gebruiken als de gebruiker de login pagina opvraagt.

[begintmeta]

Patriot schreef op vrijdag 09 januari 2009 @ 09:36:
[...]


Hmm, dat is wel waar inderdaad. Maar uiteindelijk is dat ook weer een kwestie van bereidheid om moeite/resources in iets te willen steken. Ook met unieke salts kunnen er collisions gevonden worden.

Je kunt altijd collisions vinden, wat dat betreft kun je gewoon plaintext wachtwoorden gebruiken, daarbij is de collision wel al met het blote oog duidelijk, maar het is zoals je schrijft altijd een kwestie van er moeite in willen steken..

[.oisyn]

Cartman! schreef op vrijdag 09 januari 2009 @ 09:43:
.oisyn, kun je me dan nog uitleggen hoe je in een webomgeving in 1 pagina dit voor elkaar wil krijgen? De server weet immers nog niet welke salt hij moet gebruiken als de gebruiker de login pagina opvraagt.

Simpel, gewoon salt baseren op de username. Zoals ik eerder al zei, het gaat er bij een salt om dat ie per user uniek is, niet dat hij niet bekend is.

Maar challange-response system zijn ook slechts nuttig voor de login pagina. Zodra je een nieuw account aan wilt maken of je wachtwoord wilt aanpassen dan moet er hoe dan ook informatie het web over die een eavesdropper kan gebruiken om met dat account in te loggen. Of dat nou 'password' of md5('kees' + 'password' + lange_vaste_tekenreeks) is. Beter gebruik je dus gewoon SSL, of een andere vorm van public key encryption waarmee de client het wachtwoord versleutelt met de publieke sleutel van de server.

[gertvdijk]

.oisyn schreef op vrijdag 09 januari 2009 @ 12:23:
Simpel, gewoon salt baseren op de username. Zoals ik eerder al zei, het gaat er bij een salt om dat ie per user uniek is, niet dat hij niet bekend is.

Tuurlijk wel (want je kan bruteforcen met de bekende salt). Maar ik denk dat je bedoelt dat je het niet voor elkaar gaat kunnen krijgen om dat met een onbekende salt te gaan doen, omdat immers de client en server die moeten afspreken en dit dus per definitie te sniffen is.

.oisyn schreef op vrijdag 09 januari 2009 @ 12:23:
Beter gebruik je dus gewoon SSL, of een andere vorm van public key encryption waarmee de client het wachtwoord versleutelt met de publieke sleutel van de server.

Inderdaad.
Toch hoop ik nog eens dat er asymmetrische encryptiemogelijkheden komen in browsers/javascript (denk aan GnuPG, waarbij ook met private/public keys wordt gewerkt). Dat kan dan een mooie tussenvorm zijn van SSL en simpel hashen, naast de challange-response mogelijkheden.

[.oisyn]

gertvdijk schreef op vrijdag 09 januari 2009 @ 12:44:
[...]

Tuurlijk wel (want je kan bruteforcen met de bekende salt).

Die discussie hebben we al gevoerd en het heeft niet echt zin om dat nog een keer te doen.

[begintmeta]

gertvdijk schreef op vrijdag 09 januari 2009 @ 12:44:
...
Inderdaad.
Toch hoop ik nog eens dat er asymmetrische encryptiemogelijkheden komen in browsers...

De meeste browsers hebben die toch al (wel in combinatie met symmetrische encryptie)?

[Cartman!]

.oisyn schreef op vrijdag 09 januari 2009 @ 12:23:
[...]
Simpel, gewoon salt baseren op de username. Zoals ik eerder al zei, het gaat er bij een salt om dat ie per user uniek is, niet dat hij niet bekend is.

Ja, precies maar ik bedoelde meer een 'externe' salt dus maar nevermind. Overigens lijkt me dat salt = username problemen kan opleveren als iemand van nickname wil wijzigen, dan moet ie direct opnieuw zn wachtwoord invoeren om weer te voldoen aan die eis maar nu dwaal ik een beetje af

[gertvdijk]

begintmeta schreef op vrijdag 09 januari 2009 @ 13:03:
De meeste browsers hebben die toch al (wel in combinatie met symmetrische encryptie)?

Oh, dat is nieuw voor mij dan. Kan je een voorbeeld geven? Symmetrisch is wel overkill voor alleen de user credentials.

Cartman! schreef op vrijdag 09 januari 2009 @ 13:24:
Ja, precies maar ik bedoelde meer een 'externe' salt dus maar nevermind. Overigens lijkt me dat salt = username problemen kan opleveren als iemand van nickname wil wijzigen, dan moet ie direct opnieuw zn wachtwoord invoeren om weer te voldoen aan die eis maar nu dwaal ik een beetje af

Nja, als je van nickname wil wijzigen lijkt het me niet raar om ook even je wachtwoord ter bevestiging te moeten geven. Moet hier op T.net ook bij elke andere wijziging die je doet aan je 'profiel'. Je checkt dan met de huidige nick of de hash klopt en als dat zo is maak je een nieuwe op basis van de nieuwe nick.

[ Voor 5% gewijzigd door gertvdijk op 09-01-2009 13:34 ]

[begintmeta]

gertvdijk schreef op vrijdag 09 januari 2009 @ 13:33:
[...]

Oh, dat is nieuw voor mij dan. Kan je een voorbeeld geven? Symmetrisch is wel overkill voor alleen de user credentials.
...

https(?)

[gertvdijk]

begintmeta schreef op vrijdag 09 januari 2009 @ 13:37:
https(?)

Ja duh. Dat noem ik al een paar keer.

Maar ik bedoel dus een tussenvorm van SSL en simpel hashen. Dus gewoon even een wachtwoordje goed versleuteld over de lijn sturen met de eenvoud van hashing. Dus i.p.v.

JavaScript:

md5(wachtwoord+salt)

wordt het

JavaScript:

gpg(wachtwoord,publicKey)

en eenmalig genereer je even een public/private key pair. Dan is het ook gewoon veilig en heb je geen rompslomp van SSL (apart IP, slomer, kost geld, etc).
Dit is dan toepasbaar op alle gegevens die je wil beschermen en dus in die zin breder inzetbaar dan challenge-response.

Er zijn wel soortgelijke initiatieven zie ik, maar niet toepasbaar in IE. (Goh, waarom verrast me dit niet)
SSL zal altijd een beter alternatief blijven, omdat je dit lastiger brak kan implementeren, je niet iets over het hoofd kan zien en ook het 'vertrouwen' in SSL zit ingebakken (hoewel dat dus nu voor een deel gekraakt is). Daarnaast is het nogal UNIX-achtig om iets als GPG als iets heel vanzelfsprekends te zien en zoiets dat niet is voor Windows omgevingen.

[ Voor 44% gewijzigd door gertvdijk op 09-01-2009 14:17 ]

[begintmeta]

gertvdijk schreef op vrijdag 09 januari 2009 @ 13:42:
[...]

Ja duh. Dat noem ik al een paar keer. Maar ik bedoel dus een tussenvorm van SSL en simpel hashen. Dus gewoon even een wachtwoordje goed versleuteld over de lijn sturen met de eenvoud van hashing. Dus i.p.v. md5(wachtwoord+salt) wordt het gpg(wachtwoord,public-key) en eenmalig genereer je even een public/private key pair. Dan is het ook gewoon veilig en heb je geen rompslomp van SSL (apart IP, slomer, kost geld, etc)

Ik dacht ook al...

Gewoon een Elgamal(bijvoorbeeld)-versleutelingssysteem erin.

[Cartman!]

Ik zou toch eerder kiezen voor een hash ipv. encryptie dan. Als iemand controle krijgt over je server kan ie anders alsnog de echte wachtwoorden gaan loggen.

[gertvdijk]

Cartman! schreef op vrijdag 09 januari 2009 @ 14:02:
Ik zou toch eerder kiezen voor een hash ipv. encryptie dan. Als iemand controle krijgt over je server kan ie anders alsnog de echte wachtwoorden gaan loggen.

Dan doe je hashing + asymmetrische encryptie.

begintmeta schreef op vrijdag 09 januari 2009 @ 13:58:
Gewoon een Elgamal(bijvoorbeeld)-versleutelingssysteem erin.

Die kwam ik ook tegen, maar dat vereist nog best wel wat kennis om dat te implementeren, terwijl dat dus helemaal niet zo hoeft te zijn. PHP ondersteunt GnuPG gewoon en als browsers dat ook in Javascript zouden doen zijn we van alle gezeik af.

[ Voor 43% gewijzigd door gertvdijk op 09-01-2009 14:25 ]

[Patriot]

gertvdijk schreef op vrijdag 09 januari 2009 @ 12:44:
[...]

Tuurlijk wel (want je kan bruteforcen met de bekende salt).

Natuurlijk niet! Een hash is altijd te bruteforcen. Het gaat erom dat je wil voorkomen dat ze met behulp van rainbow tables al je wachtwoorden kunnen achterhalen op het moment dat ze je gebruikerstabel in handen krijgen.

[.oisyn]

Cartman! schreef op vrijdag 09 januari 2009 @ 13:24:
[...]

Ja, precies maar ik bedoelde meer een 'externe' salt dus maar nevermind.

Bedoel je daarmee een alleen voor de server bekende salt of een salt die gebruikt wordt voor challange-response? Want dat laatste kan natuurlijk nog steeds.

[ Voor 3% gewijzigd door .oisyn op 09-01-2009 15:02 ]

[begintmeta]

gertvdijk schreef op vrijdag 09 januari 2009 @ 14:22:
[...]

Dan doe je hashing + asymmetrische encryptie.

[...]

Die kwam ik ook tegen, maar dat vereist nog best wel wat kennis om dat te implementeren, terwijl dat dus helemaal niet zo hoeft te zijn. PHP ondersteunt GnuPG gewoon en als browsers dat ook in Javascript zouden doen zijn we van alle gezeik af.

Een deel van ssl is natuurlijk ook asymmetrische encryptie/key exchange, dat zou je best kunnen gebruiken zonder https te gaan gebruiken.

[Cartman!]

.oisyn schreef op vrijdag 09 januari 2009 @ 15:02:
[...]

Bedoel je daarmee een alleen voor de server bekende salt of een salt die gebruikt wordt voor challange-response? Want dat laatste kan natuurlijk nog steeds.

challenge-response ja, maar in een webomgeving werkt het niet prettig om eerst je username op te geven en daarna je password (zoals bij unix zegmaar). Dus zit je toch vast aan de username als 'dynamische' salt. Dat de client weet dat de username de salt is maakt niet uit zoals je al eerder zei.