[alg]challenge/response: password wijzigen

[wizzkizz]

Op dit moment heb ik een challenge/response systeem voor wat betreft het inloggen op een webapplicatie. Het werkt al een tijdje als een trein.
Nu ben ik de mogelijkheid aan het maken om wachtwoorden te wijzigen en zit ik met een probleem waarvoor ik nog geen oplossing heb kunnen vinden, ondanks de faq en een hele hoop topics door te lezen:

Hoe krijg ik het nieuwe wachtwoord op een dusdanige manier bij de server dat 1) het in geval van onderschepping niet te herleiden is tot het ingevoerde wachtwoord of een hash daarvan en 2) ik wel de hash in de db kan opslaan.

Als je het combineert met een random string (die evenwel op de server wel bekend is en tijdelijk in de db opgeslagen wordt) en daarna hasht, kun je de hash van het oorspronkelijke wachtwoord toch niet meer achterhalen? Of toch wel?

[MBV]

Waarom pak je niet het algoritme van een van de geaccepteerde algoritmen? Je zou bijv. PGP of SSH kunnen strippen voor jouw benodigdheden. Hoe die precies werken moet ik even in die stapel boeken graven, maar dat is idd globaal wat jij beschrijft

[Vaan Banaan]

Je verbinding zal je dan om te beginnen versleuteld willen hebben. Daarvoor zul je een https verbinding moeten opzetten. Maar dan heb je een certificaat nodig en dat kost wel het een en ander. Je kan met openssl een self signed certificate maken, maar dan moeten gebruikers dat wel willen accepteren als ze op je site komen.
Dan om het wachtwoord te wijzigen: Gebruik altijd de hash (met salt) van het wachtwoord om in je DB op te slaan. Dat is atijd one-way, dus niet meer te herleiden.
De bekendste hash algoritmen zijn: crypt, blowfish, md5 en sha. De laatste is het veiligst.
Het is niet belangrijk dat je het wachtwoord niet kan herleiden, als het wachtwoord wordt ingetypt, wordt in de db gekeken naar de salt, en daar met het wachtwoord de hash weer van berekend. Is dat dezelfde, als in de hash in de db, dan is het wachtwoord juist.

[wizzkizz]

Vaan_Banaan schreef op dinsdag 03 januari 2006 @ 15:48:
Dan om het wachtwoord te wijzigen: Gebruik altijd de hash (met salt) van het wachtwoord om in je DB op te slaan. Dat is atijd one-way, dus niet meer te herleiden.
De bekendste hash algoritmen zijn: crypt, blowfish, md5 en sha. De laatste is het veiligst.
Het is niet belangrijk dat je het wachtwoord niet kan herleiden, als het wachtwoord wordt ingetypt, wordt in de db gekeken naar de salt, en daar met het wachtwoord de hash weer van berekend. Is dat dezelfde, als in de hash in de db, dan is het wachtwoord juist.

de inlogprocedure werkt al wel, maar ik zoek alleen nog een manier om een soort challenge/response te kunnen gebruiken bij het wijzigen van het wachtwoord.

mijn vraag rees met name na het lezen van dit in de faq:

Bij password veranderen kun je wel combinatiehashes trekken op basis van vorige password waardoor er geen lekbare data over de lijn gaat.

p.s. ik gebruik sha256 als hashing-algoritme

[ Voor 26% gewijzigd door wizzkizz op 03-01-2006 16:18 ]

[Hydra]

wizzkizz schreef op dinsdag 03 januari 2006 @ 15:56:
de inlogprocedure werkt al wel, maar ik zoek alleen nog een manier om een soort challenge/response te kunnen gebruiken bij het wijzigen van het wachtwoord.

Zoals al gezegd is, je zult toch het nieuwe password over de lijn moeten sturen. Makkelijkste oplossing lijkt me HTTPS te gebruiken.

[bigbeng]

Volgens mij wordt hiermee bedoeld dat de client naar de server een hash stuurt waarmee hij zegt, vanaf nu is deze hash icm mijn oude hash mn "identificatiehash".

Je zorgt er dan voor dat de server een nieuwe identificatiehash kan berekenen zonder dat die ooit over de lijn is gegaan.

[Soultaker]

Je hoeft geen beveiligde verbinding te hebben. Je kunt coderen met het oude wachtwoord als sleutel. Neem bijvoorbeeld een simpele XOR-encryptie waarbij je de hashcode van het oude wachtwoord gebruikt als sleutel. De server kan die sleutel ook berekenen en zo het nieuwe wachtwoord achterhalen, terwijl de gegevens die op het netwerk voorbijkomen betekenisloos zijn voor iemand die het nieuwe wachtwoorden niet kent.

(Je hebt dan wel een beperking op de lengte het wachtwoord, maar dat is altijd zo.)

[ Voor 21% gewijzigd door Soultaker op 03-01-2006 16:45 ]

[wizzkizz]

ok, zoals het er nu naar uit ziet is xor betrekkelijk veilig en ook niet al te moeilijk om te implementeren.
Ga ik dat eens verder onderzoeken.
tnx voor de antwoorden so far.

[JHS]

Aanverwante vraag: Hoe krijg je dan het allereerste password bij de gebruiker .

[Soultaker]

Die zou je kunnen e-mailen (al is dat niet per se veiliger). Sowieso is challenge/response-authenticatie, net als het schema wat ik voorstelde, maar een beperkte oplossing, want het is wel vatbaar voor een man-in-the-middle attack. Je voorkomt er alleen maar mee dat je wachtwoorden plaintext over het netwerk verstuurd worden, maar de verbinding zelf beveilig je er niet mee. Daar heb je echt iets als SSL (HTTPS) voor nodig.

[ Voor 10% gewijzigd door Soultaker op 03-01-2006 17:56 ]

[wizzkizz]

JHS schreef op dinsdag 03 januari 2006 @ 17:19:
Aanverwante vraag: Hoe krijg je dan het allereerste password bij de gebruiker .

In eerste instantie gaat dat per post, samen met het contract enzo.

Soultaker schreef op dinsdag 03 januari 2006 @ 17:55:
Die zou je kunnen e-mailen (al is dat niet per se veiliger). Sowieso is challenge/response-authenticatie, net als het schema wat ik voorstelde, maar een beperkte oplossing, want het is wel vatbaar voor een man-in-the-middle attack. Je voorkomt er alleen maar mee dat je wachtwoorden plaintext over het netwerk verstuurd worden, maar de verbinding zelf beveilig je er niet mee. Daar heb je echt iets als SSL (HTTPS) voor nodig.

Daar heb je idd gelijk in. Maar het is een stuk veiliger dan gewoon plain verzenden. Er komt ook wel een mogelijkheid om er middels https mee te connecten, maar dat is er nu nog niet en voor de case dat gebruikers daarna toch een onbeveiligde verbinding gebruiken, vond ik het een goede aanvulling.

[josvane]

Ik weet het een oud topic!!!

Maar voor mijn systeem heb ik het zelfde probleem. Als ik XOR test in PHP werkt het perfect. Alleen is dat wel serverside. Het betekent dus dat mijn wachtwoord niet gehashed naar de server gaat.

Nu had ik gedacht om dus client side een hash te maken met javascript en dan als sleutel het oude wachtwoord. Maar de xor functie in javascript lijkt alleen maar met getallen te kunnen werken.

Heeft iemand een idee hoe ik javascript wel de text kan laten hashen, zodat php dit weer ongedaan kan maken.

[MBV]

Tja ehm, dan zet je de string toch om in een getal of serie getallen

[Onbekend]

XOR werkt met alles, alleen je moet het wel binair benaderen. Als je een letter gaat XOR-en dan kan het zijn dat je een onleesbaar karakter krijgt, maar door dit opnieuw te XOR-en heb je de oorspronkelijke letter terug.


Volgens mij kan je een hash niet (altijd) weer omvormen naar de oorspronkelijke tekenreeks. Waarschijnlijk doel je op encryptie. Kijk voor informatie eens op Wikipedia: Asymmetrische cryptografie en op Wikipedia: Pretty Good Privacy.

[H!GHGuY]

Euhr, is hier dan niemand die denkt aan diffie hellman?

Gebruik diffie hellman om een key te genereren op beide zijden en gebruik die dan als key voor een symmetrisch encryptie algoritme. Dit is ook de basis van SSL en andere technieken... Eigenlijk is gewoon HTTPS gebruiken al voldoende.