Wachtwoorden op Tweakers.net

[Turdie]

Met de recente hacks van LinkedIn en anderen vroeg ik me af hoe het zit met de wachtwoorden hier op Tweakers.net. Is mijn wachtwoord hier voorzien van een salt in de database?

[Verwijderd]

plan: Analyse: zwakke wachtwoorden op Tweakers.net
plan: Development-round-up - iteratie #4

[ Voor 29% gewijzigd door Verwijderd op 09-06-2012 15:43 ]

[Turdie]

Verwijderd schreef op zaterdag 09 juni 2012 @ 15:42:
plan: Analyse: zwakke wachtwoorden op Tweakers.net
plan: Development-round-up - iteratie #4

Thnx, maar in deze artikelen lees ik niet terug of de wachtwoorden een salt hebben, of is salten alleen voor MD5?

[ Voor 3% gewijzigd door Turdie op 09-06-2012 16:01 ]

[Osiris]

shadowman12 schreef op zaterdag 09 juni 2012 @ 15:56:
[...]


Thnx, maar in deze artikelen lees ik niet terug of de wachtwoorden een salt hebben (…)

Dan moet je beter lezen? Ik had 't letterlijk binnen 10 seconden gevonden.

Of nou ja, lezen, op de linkjes in het artikel klikken en dán verder lezen…

[ Voor 11% gewijzigd door Osiris op 09-06-2012 16:02 ]

[Hooglander1]

In het artikel staat het inderdaad niet expliciet genoemd.

Wel in een reactie van ACM:

quote: http://tweakers.net/react...=Posting&ParentID=4937449

De md5-hashes zijn als onderdeel van deze upgrade direct niet meer als md5 in de database. Om nog wel te controleren of jouw wachtwoord overeen kwam met wat er ooit als md5 stond, hebben we het nu het equivalent van zoiets in de code: $hashInDb == nieuweHash(md5($wachtwoord) . $salt)

Dus er wordt wel degelijk een salt gebruikt

[Osiris]

Hooglander1 schreef op zaterdag 09 juni 2012 @ 16:07:
In het artikel staat het inderdaad niet expliciet genoemd.

Wel in een reactie van ACM:


[...]

Dus er wordt wel degelijk een salt gebruikt

En in het wikipedia-artikel over PBKDF2, zoals ook in het 2e linkje van de 1e reply hierboven gelinkt staat, wordt ook duidelijk uitgelegt over 't hoe en wat ervan.

[ACM]

shadowman12 schreef op zaterdag 09 juni 2012 @ 15:42:
Is mijn wachtwoord hier voorzien van een salt in de database?

Twee zelfs. En bovendien een aanzienlijk zwaardere afgeleide key dan domweg 1 md5 of sha1-iteratie. Momenteel is dit bijvoorbeeld mijn wachtwoord en metadata, uiteraard staan er in de database niet zoveel a's in:

code:

{"meta":
  {"method":"pbkdf2",
    "hash":"sha512",
    "iterations":10000,
    "resultlength":64,
    "salt":"c1aaaaaaaaaaaaaaa1zZNw==",
    "systemsaltid":1,
    "lastchange":1234567890},
 "result":"pYmaaa45maaaSobaaacauaaaXxmaaadkzaaa68EaaaLkwaaall7aaaViWaaaZmXaaa+qMaaa87QaaaNU0aaaaQ=="
}

We slaan de wachtwoorden sinds bovenstaande aankondiging dus als json op om ze ook later eenvoudig via een ander algoritme met varierende metadata op te kunnen slaan. Het is bijvoorbeeld ook mogelijk in onze code om algoritmes te nesten. Dat hebben we toen direct met alle oude wachtwoorden gedaan: het md5-algoritme genest in bovenstaande pbkdf2. Dus daarmee is dan uiteindelijk het opgeslagen wachtwoord vrijwel net zo lastig terug te leiden tot het origineel, maar hoefden we niemand te dwingen zijn wachtwoord te wijzigen.

Ons standaardalgoritme is nu dus PBKDF2 met de sha512-hash en dat met 10.000 iteraties over het 64-byte resultaat (je kan ook 10 of juist 100 bytes uit PBKDF2 krijgen, maar mij leek 1 volledig 512-bit "block" genoeg). En per wachtwoord is er een willekeurig salt (uit /dev/urandom afgeleid) met voldoende adresruimte om een heel lage kans op dubbelen te krijgen.
Mochten we op een gegeven moment besluiten dat sha512 niet goed genoeg meer is of dat die 10.000 of die 64 bytes niet genoeg meer zijn, dan kunnen we triviaal de boel aanpassen en wordt het bij je eerstvolgende login (dan weten we tenslotte even je plain-tekst wachtwoord) opnieuw versleuteld opgeslagen.

Kortom, we gaan er van uit dat het nieuwe algoritme sowieso nog wel even mee gaat kunnen en daarnaast hebben we het voor onszelf heel eenvoudig gemaakt om het aan te scherpen of door een compleet ander algoritme te vervangen.

[BtM909]

ACM schreef op zondag 10 juni 2012 @ 11:05:

JSON:

{"meta":
  {"method":"pbkdf2",
    "hash":"sha512",
    "iterations":10000,
    "resultlength":64,
    "salt":"c1aaaaaaaaaaaaaaa1zZNw==",
    "systemsaltid":1,
    "lastchange":1234567890},
 "result":"pYmaaa45maaaSobaaacauaaaXxmaaadkzaaa68EaaaLkwaaall7aaaViWaaaZmXaaa+qMaaa87QaaaNU0aaaaQ=="
}

We slaan de wachtwoorden sinds bovenstaande aankondiging dus als json op om ze ook later eenvoudig via een ander algoritme met varierende metadata op te kunnen slaan.

Is het een DB ding geweest om t in 1 veld op te slaan als JSON (bijv. omdat 't performance issues teweeg brengt om de db uit te breiden)?

Overigens heb ik het nu ook zo, maar dan in "genormaliseerd" (dus in kolommen ).

[Orion84]

Ik kan het mis hebben, maar normalisatie is toch vooral interessant als je daadwerkelijk wat met de verschillende onderdelen van zo'n samengesteld attribuut zou willen doen (indexeren, sorteren, selecteren, joinen)? Het lijkt me niet dat je dat (vaak*) gaat doen op de componenten van zo'n password attribuut, dus biedt normalisatie weinig voordelen, maar wel het nadeel dat je minder flexibel bent in de opslagmethode van je wachtwoord.

*hoogstens eens in de zoveel tijd een selectie op een bepaald algoritme omdat je dat algoritme wilt uitfaseren en dus operatie moet uitvoeren op elk record waar dat algoritme gebruikt is.

[elevator]

10.000 iteraties? Dus we kunnen nu een DoS aanval doen dmv foutief met passwords in te loggen?

[BtM909]

Orion84 schreef op dinsdag 12 juni 2012 @ 16:16:
Ik kan het mis hebben, maar normalisatie is toch vooral interessant als je daadwerkelijk wat met de verschillende onderdelen van zo'n samengesteld attribuut zou willen doen (indexeren, sorteren, selecteren, joinen)? Het lijkt me niet dat je dat (vaak*) gaat doen op de componenten van zo'n password attribuut, dus biedt normalisatie weinig voordelen, maar wel het nadeel dat je minder flexibel bent in de opslagmethode van je wachtwoord.

Mijn vraag was (omdat er wel meer is genormaliseerd) waarom er specifiek voor JSON was gekozen. Het zou kunnen omdat het extenden van de tabel(len) nou eenmaal veel impact heeft of dat dit JSON object nu ook andere voordelen heeft

*hoogstens eens in de zoveel tijd een selectie op een bepaald algoritme omdat je dat algoritme wilt uitfaseren en dus operatie moet uitvoeren op elk record waar dat algoritme gebruikt is.

idd

Alleen zie ik niet in wat we nog meer zouden willen gaan toevoegen, tenzij we volledig op een andere manier van authenticatie stappen (want in de basis blijft het ongeacht de implementatie) dezelfde manier van hashing.

Aan de andere kant, PHP heeft native JSON support en andere omgevingen hebben dat ook, waardoor het niet per se trager is

---

elevator schreef op dinsdag 12 juni 2012 @ 16:20:
10.000 iteraties? Dus we kunnen nu een DoS aanval doen dmv foutief met passwords in te loggen?

Nee, het wachtwoord wordt 10.000 keer gehasht voordat het resultaat wordt opgeslagen).

staat dus los van hoevaak je eventueel zou kunnen authenticeren bij het inlogsysteem

[ Voor 12% gewijzigd door BtM909 op 13-06-2012 11:28 ]

[Kees]

BtM909 schreef op woensdag 13 juni 2012 @ 11:27:
[...]

Nee, het wachtwoord wordt 10.000 keer gehasht voordat het resultaat wordt opgeslagen).

staat dus los van hoevaak je eventueel zou kunnen authenticeren bij het inlogsysteem

Om het te vergelijken moet je dus ook 10.000 keer hashen, dus ja, ele heeft wel een punt (als er geen limiet aan inlogpogingen zou zitten).

[Osiris]

Kees schreef op woensdag 13 juni 2012 @ 11:48:
[...]

Om het te vergelijken moet je dus ook 10.000 keer hashen, dus ja, ele heeft wel een punt (als er geen limiet aan inlogpogingen zou zitten).

't Is natuurlijk de vraag hoeveel resources één zo'n login-poging vreet t.o.v. overige common gebruikte DDoS-doelwitten. Ik ga er vanuit dat een DoS niet mogelijk is en dat mislukte inlogpogingen gekoppeld worden aan IP en niet aan het account waarop gepoogd wordt in te loggen.

[ACM]

BtM909 schreef op dinsdag 12 juni 2012 @ 16:02:
Is het een DB ding geweest om t in 1 veld op te slaan als JSON (bijv. omdat 't performance issues teweeg brengt om de db uit te breiden)?

We hebben in principe een pluggable methode en nesting van methodes mogelijk. Dus we zouden deze hele pbkdf2 weer kunnen nesten in een pbkdf3 en dan moeten we uiteraard van beide de metadata nog weten om weer dat deel van de routine te kunnen creeren.
Verder is de metatadata per methode verschillend (onze 'deprecatedMd5' heeft bijv geen aanvullende metadata), waardoor het vrij lastig is e.e.a. te normaliseren naar een database. Dan zou je het hooguit nog in een documentdatabase kunnen proberen op te slaan, maar dat is nogal onhandig in combinatie met de rest van de opslag

En inderdaad, we doen niet zoveel met die losse metadata om er echt op te willen querien. Die enkele keer dat we willen weten wie nog steeds niet opnieuw ingelogd heeft sinds we het nieuwe systeem hebben opgezet, kunnen we daar vast ook wel een andere manier voor verzinnen

[ACM]

Osiris schreef op woensdag 13 juni 2012 @ 13:02:
't Is natuurlijk de vraag hoeveel resources één zo'n login-poging vreet t.o.v. overige common gebruikte DDoS-doelwitten. Ik ga er vanuit dat een DoS niet mogelijk is en dat mislukte inlogpogingen gekoppeld worden aan IP en niet aan het account waarop gepoogd wordt in te loggen.

't Is heel moeilijk om gebruiksvriendelijk tegen dat soort DoS-aanvallen te beschermen.

Koppelen aan ip beschermt je niet tegen een DDoS en is irritant voor mensen op scholen en andere grote organisaties waarbij alle bezoeken via een ip komen. Koppelen aan accounts betekent dat het mogelijk wordt om iemand uit zijn account buiten te sluiten door maar continu fout in te loggen op dat account.

Maar als je onze servers wilt overbelasten is er inderdaad vast wel een eenvoudigere methode voor te vinden dan foute inlogpogingen te forceren

[elevator]

Osiris schreef op woensdag 13 juni 2012 @ 13:02:
't Is natuurlijk de vraag hoeveel resources één zo'n login-poging vreet t.o.v. overige common gebruikte DDoS-doelwitten. Ik ga er vanuit dat een DoS niet mogelijk is en dat mislukte inlogpogingen gekoppeld worden aan IP en niet aan het account waarop gepoogd wordt in te loggen.

Ik ben er geen expert in, maar het idee achter de toegenomen complexiteit van password hashing is ook grotendeels gebaseerd op het feit dat het "bruteforcen" te moeilijk wordt / te lang duurt.

Met andere woorden, 1 password validatie stap moet behoorlijk CPU intensief zijn om effectief te zijn. Verder was het natuurlijk niet helemaal serieus omdat er inderdaad vermoedelijk interessantere targets kunnen zijn (maar die zijn wel weer makkelijker te beschermen denk ik)