Beveiliging: laatste 3 wachtwoorden-check & encryptie

[Cloud]

coldasice schreef op dinsdag 02 augustus 2011 @ 09:02:
[...]


Dit artikel snijdt echt wel hout en natuurlijk zijn er dingen ter verbetering maar roepen dat je dit wel even de grond in boort slaat nergens op. Om het wat constructiever te laten klinken: Ik denk dat iedereen meer geinteresseerd is in je aanbevelingen en verbeteringen.

Om eerlijk te zijn ben ik daar ook wel benieuwd naar; want het artikel heeft toch echt wel een punt hoor.
@Voutloos: Wat is er dan zo grondig mis mee dat jij het artikel 'wel even de grond in boort'?

Sterker nog, ik raad al tijden mensen aan een dergelijk wachtwoord (meerdere common/uncommon woorden) te gebruiken als ze moeite hebben een veilige te bedenken.

[ Voor 12% gewijzigd door Cloud op 03-08-2011 11:57 ]

[EricBruggema]

http://php.net/manual/en/function.similar-text.php is een prachtige functie die waarschijnlijk het doel dient!

Verder zijn er nog genoeg ideeën om je wachtwoorden te controleren.

- Controleer van 0 t/m lengte of deze het zelfde zijn
- Maak een berekening op basis van letter/cijfers en check deze (oud en nieuw ww).

And so on... hoop dat je hier wat aan hebt!

[Cartman!]

Daar heb je dus niks aan want dan moet je dus eerst nog steeds de plaintext-versies van de vorige passwords hebben, daar gaat de hele discussie over

[MLM]

niet alles gelezen, maar:
bij het veranderen geef je oud + 2x nieuw op meestal. op dat moment kan je het oude password opslaan als plaintext (en de nieuwe gehasht natuurlijk), gezien het toch niet meer geldig is (immers, er is een nieuwe password). omdat je forceert dat het password niet gerelateerd of lijkt op de vorige (doel van het topic), kan aan een verzameling oude plaintext passwords niet de nieuwe gevonden worden, dus maakt het niet uit dat ze plaintext zijn maar nog steeds is het nuttig om je database niet weg te geven natuurlijk

[alwinuzz]

Suggereer je nu serieus om de oude wachtwoorden plain-text op te slaan? Niet doen!

MLM schreef op woensdag 03 augustus 2011 @ 21:47:
niet alles gelezen, maar: [...]

Lees de rest van het topic a.u.b...

Ik schrik echt van sommige suggesties hier.

[Fusioxan]

@EricBriggema,
Deze functie kwam ik laatst ook tegen, omdat ik met een soortgelijk probleem als de TS had. Cartman! reageert wel dat je nog steeds de plaintext nodig hebt, maar dan doe je toch gewoon wat djexplo zei?

djexplo schreef op maandag 01 augustus 2011 @ 10:59:
Een standaard wachtwoord formulier vraag altijd :
Bestaand Wachtwoord
Nieuw Wachtwoord
Herhaling Nieuw Wachtwoord

Of te wel als je dat gebruikt, heb je opdat moment een niet versleuteld versie van zijn oude wachtwoord.

Stappenplan:
1: User vult formulier in en klikt op submit
2: Script moet gaan werken. Hij gebruikt een hash om te kijken of het opgegeven wachtwoord hetzelfde is als het oude wachtwoord.
2a: TRUE-> similar_text gebruiken similar_text('oud', 'nieuw', minimale percentage) om te kijken of hij veel op het nieuwe wachtwoord lijkt (ja oké, unhashed... Maar je stuurt ze ook gewoon in plain naar de server om te hashen, dus waarom zou je het niet gebruiken voordat je het hasht?)
2aI TRUE -> bericht retourneren dat het nieuwe te veel op het oude wachtwoord lijkt
2aII FALSE -> oke, bericht kan gehasht en wel naar de database worden gestuurt
2b FALSE -> bericht retourneren dat het opgegeven oude wachtwoord niet het oude wachtwoord is.

Als jullie een klein momentje hebben, laat ik mijn paint-skillz even zijn werk doen.

Edit:

[ Voor 2% gewijzigd door Fusioxan op 03-08-2011 23:04 . Reden: paintskills ]

[DukeBox]

Even vanaf een hele andere kant bekeken, ik begrijp dat het om een bedrijfs applicatie gaat.
Nu ga ik er een beetje vanuit dat daar ook een MS AD is. Waarom authenticieer je de gebruiker daar niet tegen aan ? In AD kun je precies de password eisen instellen die jij wilt.

[Victor]

Een password hashing algoritme moet aan een aantal eigenschappen voldoen wil het veilig zijn:
- Het moet gebruik maken van een willekeurige salt om te voorkomen dat een methode met voorberekende hashes (zoals rainbow tables) effectief ingezet kan worden.
- Het moet een langzaam hashing algoritme gebruiken. Hierdoor valt het alleen toepassen van MD5 of SHA-1 al direct af. Deze algoritmen zijn zo snel dat het brute force genereren van alle mogelijke combinaties (salt of niet) met wat GPU-kracht zo gepiept is (we praten hier afhankelijk van de gebruikte tekenreeks over minutenwerk).

Nu kun je zelf allerlei slimme truken gaan verzinnen (die waarschijnlijk niet zo slim zijn als je zelf denkt), of je gebruikt het werk van mensen met echt verstand van zaken op dit vlak. Een oplossing die bovendien al door vele andere slimmeriken tegen het licht is gehouden en tot nu toe als veilig beschouwd wordt: bcrypt. Voor PHP is er het Portable PHP Password Hashing Framework dat deze hashing methode aanbiedt.

[Fusioxan]

Victor, een vraagje. Waarom zou je een wachtwoord wat niemand mag weten gaan encrypten? De bedoeling van hashen is (meen ik) het veranderen van een string zodat hij niet meer terug te draaien is.

[Victor]

Fusioxan schreef op donderdag 04 augustus 2011 @ 18:36:
Victor, een vraagje. Waarom zou je een wachtwoord wat niemand mag weten gaan encrypten? De bedoeling van hashen is (meen ik) het veranderen van een string zodat hij niet meer terug te draaien is.

Ik zou niet weten waarom je een password zou encrypten. Ik stel dan ook het gebruik van een hashing methode voor waarbij het oorspronkelijke password erg lastig is terug te halen.

[ZpAz]

Goed, ik vind dit altijd een stomme regel. Maar waarom niet gewoon een tabel met 'user_old_passwords' waarin je de UID, salt van dat wachtwoord en het wachtwoord zelf (gehashed) opslaat.

Dan gewoon met een for loopje samen met de invoer van de gebruiker loopen door de oude wachtwoorden. Levert de salt plus invoerwaarde hetzelfde resultaat op als een eerder wachtwoord? Dan dat melden.

Whoops, er moet nog een klinkt als check op, shoot me.

[ Voor 8% gewijzigd door ZpAz op 04-08-2011 19:20 ]

[Cartman!]

@Fusioxan: heel leuk want dan kun je vergelijken met het vorige password, en waar trek jij die 2 daarvoor ineens vandaan? Lees het topic helemaal svp.

@ZpAz: Het gaat er ook om of ze lijken op het vorige password, hoe wilde je dat gaan doen?

[ACM]

Victor schreef op woensdag 03 augustus 2011 @ 23:56:
Een password hashing algoritme moet aan een aantal eigenschappen voldoen wil het veilig zijn:

In principe is het niet verplicht dat het een hash is. Zolang je maar een indicatie hebt om mee na te gaan of de gebruiker inderdaad het wachtwoord kende. De vereisten aan die indicatie zijn uiteraard aanvullend dat het niet-triviaal moet zijn om een wachtwoord eruit terug te leiden, een van de eigenschappen van hashing-algoritmen.
Er zijn bijvoorbeeld ook methodes onder de noemer "zero-knowledge password proof" waarbij het wachtwoord uberhaupt nooit bij de serverzijde bekend wordt, enkel afgeleide bewijzen (evt deels aan de hand van een challenge-response). Het nadeel is dat ze over het algemeen een stuk werk aan de client-side verwachten, waarbij met name Javascript de beschikbare cryptografische rekenkracht nog vrij sterk beperkt.

Dus je mist eigenlijk nog een eis bij je wachtwoordopslag:
- Het moet zodanig opgeslagen worden, dat onomstotelijk is te bewijzen dat de gebruiker inderdaad het wachtwoord kende, zonder dat de daarvoor opgeslagen data omkeerbaar is naar het originele wachtwoord. Oftewel, dat enkel brute-forcen overblijft om het originele wachtwoord te achterhalen.

- Het moet gebruik maken van een willekeurige salt om te voorkomen dat een methode met voorberekende hashes (zoals rainbow tables) effectief ingezet kan worden.

Dat hangt helemaal van het gebruikte principe af. Maar je hebt gelijk dat als er gebruik van hashes of vergelijkbare eenmalige versleutelingen wordt gemaakt, dat het dan verstandig is de boel zodanig toe te passen dat brute-forcen (en voor-genereren voor rainbow tables) enkel op losse keys mogelijk is, niet op een hele reeks. Bij hashing wordt dat inderdaad opgelost met salts.

- Het moet een langzaam hashing algoritme gebruiken. Hierdoor valt het alleen toepassen van MD5 of SHA-1 al direct af. Deze algoritmen zijn zo snel dat het brute force genereren van alle mogelijke combinaties (salt of niet) met wat GPU-kracht zo gepiept is (we praten hier afhankelijk van de gebruikte tekenreeks over minutenwerk).

Eigenlijk is de eis hierbij iets anders Het gebruik van brute-forcing is door de eerste eis de enige manier om het origineel te achterhalen. Om te voorkomen dat ontdekte codes in reele tijd terug te halen zijn, moet het algoritme relatief rekenintensief zijn. En bij hashes - die bedoeld zijn om snel berekend te worden (ook de hele sha2-reeks) - betekent dat dat je bijvoorbeeld kan "key stretchen".

Nu kun je zelf allerlei slimme truken gaan verzinnen (die waarschijnlijk niet zo slim zijn als je zelf denkt), of je gebruikt het werk van mensen met echt verstand van zaken op dit vlak. Een oplossing die bovendien al door vele andere slimmeriken tegen het licht is gehouden en tot nu toe als veilig beschouwd wordt: bcrypt. Voor PHP is er het Portable PHP Password Hashing Framework dat deze hashing methode aanbiedt.

Naast bcrypt biedt PHP ook een sha256/sha512-based crypt aan die behoorlijk veilig is, deze herhaald de hash een paar duizend keer om zo te voorkomen dat je met eenmalige hashing zit.
Daarnaast is het door RSA ontwikkelde PBKDF2 nog inzetbaar, hoewel dat in theorie meer bedoeld is voor sleutels van willekeurige lengte (bijv een 2048-bits key genereren adhv een wachtwoord van willekeurige lengte).

Van andere methodes zoals Secure Remote Password kreeg ik het idee dat het in beginsel best goed werkt, maar als nadeel heeft dat in web-based omgevingen het staat of valt met de rekenkracht die Javascript je biedt en daardoor is in de huidige implementaties de communicatie zelf relatief licht versleuteld. Als je die communicatie dan onderschept of de validatie-sleutel uit de database vindt is het alsnog eenvoudiger om te brute forcen dan domweg een paar duizend iteraties sha256 of bcrypt.

[Hydra]

LuCarD schreef op maandag 01 augustus 2011 @ 11:09:
Je zou zoiets kunnen doen.

PHP:

$passes =  array('qwerty', 'qwerty1','1qwerty', 'mijnwachtwoord!1','mijnwachtwoord!2','mijnwachtwoord!3');
foreach ( $passes as $pass ) {
echo $pass . "> ". soundex($pass) . " > " . md5("zout".soundex($pass)) ."<br>";
}

De md5 versie van soundex opslaan en vergelijken.

Lekker veilig ook

[ReenL]

@Victor: Een salt hoeft niet "random" te zijn alleen uniek per wachtwoord.

Rainbow tables zijn niet van toepassing als je de wachtwoorden correct hashed, dat is op dit moment wachtwoord + seed & duizenden keren sha512. Het enige doel van de seed is de hashes van 1 brute force poging onbruikbaar te maken voor het tweede wachtwoord.

[ThaNOD]

De xkcd van vandaag is wel weer erg toepasselijk voor dit topic:

http://xkcd.com/936/