[Javascript / ...] Beveiligd wachtwoorden versturen, veilig?

[Rekcor]

Onlangs meen ik een manier bedacht te hebben om wachtwoorden van een website beveiligd te versturen zonder een https-verbinding. Wachtwoorden in een normaal webformulier worden namelijk 'gewoon' als tekst over lijn gestuurd, en kunnen dus onderschept worden (zo heb ik mij laten vertellen).

code:

1)
     client   |    server (bijv PHP/MySql)                                
              |
wachtwoord ---|---> match met wachtwoord

Mijn eerste idee was om het wachtwoord te versleutelen met bijv. MD5 (zie http://pajhome.org.uk/crypt/md5/ voor Javascript).

code:

2)
                         client   |    server                                 
                                  |
wachtwoord --> wachtwoord  md5 ---|---> match met wachtwoord md5 in database

Dit levert nog geen hogere beveiliging op: de kwaadwillende kan immers gewoon het versleutelde wachtwoord gebruiken ipv het origineel. Maar wat als we aan het originele wachtwoord een timestamp toevoegen? Bijv. het aantal minuten van het huidige uur.

Dan krijgen we:

code:

 3)
                                   client   |    server                                
                                            |                                   
wachtwoord --> wachtwoord+timestamp  md5 ---|---> match met wachtwoord+timestamp md5 in database

De timestamp kan natuurlijk geraden worden door de kwaadwillende, maar de 'gehashde' combinatie van wachtwoord+timestamp niet/nauwelijks. Aangezien het niet waarschijnlijk is dat een verzoek aan de server meer dan 1 seconden nodig heeft, is de kans klein dat de timestamp van de client en de server niet matchen (moeten beide systeemtijden natuurlijk wel gelijk lopen, maar dit is te calibreren met bijv. ajax)

Mijn vraag: is dit wiel al ettelijke malen uitgevonden? En: lijkt jullie dit een redelijk waterdicht systeem?

[Alex)]

Dit wordt heel vaak gebruikt ja, wat je doet (met die timestamp) heet een salt.

[OruBLMsFrl]

Waterdicht? Als je de systeemklokken gelijk moet laten lopen, dan heb je soms al een onoverkomelijk probleem lijkt me, simpelweg omdat de gebruiker geen rechten heeft om de klok aan te passen. Zelfs normale gebruikers hebben dat recht op een windows 2000/xp machine al niet, laat staan guest accounts. Kan zijn dat jouw Ajax engine dan een relatieve tijd opslaat, maar dan nog is het niet waterdicht. Over telefoonlijnen of satellietverbindingen zullen we het maar helemaal niet hebben, daar krijg je soms al een ping tijd van een seconde. Bovendien, als de server, ofwel de client even een seconde aan een ander programma of netwerkprobleem kwijt is, dan gaat de authenticatie al mis. Met minuten zou ik het nog overwegen, maar secondes? Lijkt me vrij sterk dat iemand een reply attack binnen een minuut uitvoert... maar goed, met SSL bescherm je natuurlijk ook de privacy van de gebruiker, uitgaande van een volledig beveiligde verbinding.

[ Voor 23% gewijzigd door OruBLMsFrl op 18-03-2007 22:27 . Reden: nog wat hooi op de wagen ]

[Rekcor]

Alex) schreef op zondag 18 maart 2007 @ 22:21:
Dit wordt heel vaak gebruikt ja, wat je doet (met die timestamp) heet een salt.

Dacht ik al. Toch ga ik met (een beetje) trots gevoel naar bed, dat ik zelf ook op dat idee gekomen ben

[Rekcor]

Bas van der Doorn schreef op zondag 18 maart 2007 @ 22:25:
Waterdicht? Als je de systeemklokken gelijk moet laten lopen, dan heb je soms al een onoverkomelijk probleem lijkt me, simpelweg omdat de gebruiker geen rechten heeft om de klok aan te passen. Zelfs normale gebruikers hebben dat recht op een windows 2000/xp machine al niet, laat staan guest accounts. Kan zijn dat jouw Ajax engine dan een relatieve tijd opslaat, maar dan nog is het niet waterdicht. Als de server, ofwel de client even een seconde aan een ander programma of netwerkprobleem kwijt is, dan gaat de authenticatie al mis. Met minuten zou ik het nog overwegen, maar secondes?

Je kunt toch ajax de server-tijd op laten halen en die vervolgens verdisconteren in de te versturen timestamp? Natuurlijk kan het een keer misgaan, maar dan kun je het verzoek nog een keer versturen (als je het met ajax zou doen) of de gebruiker nogmaals om zijn ww vragen...

[orf]

In de JavaScript source zie je wat er gebeurt en kun je dat dus ook simpelweg nadoen. Een timestamp is gemakkelijk herkenbaar.

[Borizz]

De tijd hoef je niet perse met ajax te synchroniseren, dit is onnodig moeilijk doen lijkt mij. Je kan de tijd gewoon door php in je javascript outputten, zodat de client weet hoe laat het op de server is. Van daaruit zou je verder kunnen tellen.

Het is overigens ook mogelijk om in php een willekeurige salt te laten generen en deze in de gebruikersessie opslaan. Deze salt kan je timestamp dan vervangen.

[JHS]

Overigens wordt er voor een salt vaak niet een timestamp gebruikt, maar een random string die van de server komt en in de ommegaande request gebruikt moet worden .

[OruBLMsFrl]

Rekcor schreef op zondag 18 maart 2007 @ 22:27:
[...]
Je kunt toch ajax de server-tijd op laten halen en die vervolgens verdisconteren in de te versturen timestamp? Natuurlijk kan het een keer misgaan, maar dan kun je het verzoek nog een keer versturen (als je het met ajax zou doen) of de gebruiker nogmaals om zijn ww vragen...

Als je met willekeurige internetverbindingen rekening moet houden red je het naar mijn ervaring niet binnen een seconde, tijdsynchronisatie in het algemeen. Maar goed, ook al ziet iemand dat je tijden gebruikt, dan nog moet je het wachtwoord kennen wat ook gehashed wordt om een aanval te lanceren. Dus wat dat betreft is salten altijd een stuk beter dan puur.

[OruBLMsFrl]

JHS schreef op zondag 18 maart 2007 @ 22:28:
Overigens wordt er voor een salt vaak niet een timestamp gebruikt, maar een random string die van de server komt en in de ommegaande request gebruikt moet worden .

Op zich een aardig idee, maar als iemand zijn sessie veel te lang open laat staan en maar door blijft klikken in die applicatie, dan zul je dus toch nog makkelijk op de sessie kunnen inbreken als je in het midden zit. Met die timestamps is het veel lastiger, omdat je dan geen toegangshash hebt die binnen een sessie eeuwig geldig blijft.

[crisp]

JHS schreef op zondag 18 maart 2007 @ 22:28:
Overigens wordt er voor een salt vaak niet een timestamp gebruikt, maar een random string die van de server komt en in de ommegaande request gebruikt moet worden .

Inderdaad; wij gebruiken eenmalige tokens als salt bij het 'versleuteld inloggen' hier op Tnet

Dus het antwoord op 'is dit wiel al uitgevonden' is ja, en op 'is het veilig' wederom ja

[ Voor 11% gewijzigd door crisp op 18-03-2007 22:33 ]

[Bergen]

De aanmelding op MSN Messenger werkt ook ongeveer zo. De MSN-server stuurt een MD5-hash naar de client, die versleutelt het wachtwoord mbv die hash en stuurt het resultaat terug naar de server.

[OruBLMsFrl]

crisp schreef op zondag 18 maart 2007 @ 22:32:
[...]
Inderdaad; wij gebruiken eenmalige tokens als salt bij het 'versleuteld inloggen' hier op Tnet

Dus het antwoord op 'is dit wiel al uitgevonden' is ja, en op 'is het veilig' wederom ja

Met eenmalige tokens werkt het prima natuurlijk, maar daarmee krijg je wel een aardige serverbelasting als je vaak opnieuw in gaat loggen zoals de TS aangeeft. Maar goed, met een onbeveiligde verbinding kun je als je de boel kunt sniffen toch wel op de openstaande sessie inbreken of berichten injecteren, dus wat dat betreft ben je naar mijn idee altijd wel de pineut als je de boel echt wil beveiligen

[ Voor 3% gewijzigd door OruBLMsFrl op 18-03-2007 22:38 ]

[Borizz]

Bas van der Doorn schreef op zondag 18 maart 2007 @ 22:32:
[...]

Op zich een aardig idee, maar als iemand zijn sessie veel te lang open laat staan en maar door blijft klikken in die applicatie, dan zul je dus toch nog makkelijk op de sessie kunnen inbreken als je in het midden zit. Met die timestamps is het veel lastiger, omdat je dan geen toegangshash hebt die binnen een sessie eeuwig geldig blijft.

Dat zou je dus af kunnen vangen door elke x minuten de salt te refreshen (zou wel via ajax kunnen). Als je de salt op tijd baseert ben je afhankelijk van de klok op de client machine (ook al synchroniseer je de tijd).

[CyBeR]

Net nog een tikje beter is het wachtwoord md5'en, pre- of suffixen met een salt, en het geheel met md5 naar de server sturen. Die haalt dan z'n wachtwoord uit de db, plakt de salt er voor of achter en md5't het geheel. Komt dat overeen -> mooi, anders pech. Op die manier hoef je het wachtwoord niet plaintext op te slaan. (Klein detail, maar wel belangrijk imo).

[OruBLMsFrl]

Borizz schreef op zondag 18 maart 2007 @ 22:38:
[...]

Dat zou je dus af kunnen vangen door elke x minuten de salt te refreshen (zou wel via ajax kunnen). Als je de salt op tijd baseert ben je afhankelijk van de klok op de client machine (ook al synchroniseer je de tijd).

Lijkt mij een prima oplossing, eens per minuut of halve minuut de salt refreshen met die goede tijdsynchronisatie. Blijft natuurlijk het probleem dat iemand die alles kan sniffen ook meteen alle informatie heeft om de sessie te kapen, iets dat alleen SSL echt kan voorkomen. En als je echt iedere halve minuut opnieuw moet inloggen heeft het waarschijnlijk nog een lagere overhead ook

[CyBeR]

Over het algemeen log je een keer in en hoeft je wachtwoord niet bij elke request over de lijn. Die salt kun je dus beter eenmalig genereren, meesturen met de request voor de login page, en daarna nooit meer gebruiken.

[Verwijderd]

Nog niemand die de afkorting CHAP heeft laten vallen ?

http://en.wikipedia.org/w...e_authentication_protocol

Deze techniek word vaak gebruikt voor autorisatie systemen.

[crisp]

Waarom zou het genereren van eenmalige tokens een aanslag op je serverbelasting zijn? Bij elke pageview die je hier op GoT of op de frontpage doet worden toch ook al meerdere queries uitgevoerd...

[CyBeR]

Probleem met CHAP is dus weer dat je wachtwoorden plaintext op moet slaan.

[Verwijderd]

CyBeR schreef op zondag 18 maart 2007 @ 22:47:
Probleem met CHAP is dus weer dat je wachtwoorden plaintext op moet slaan.

Tuurlijk niet, wachtwoorden sla je als hash op in de database en dit maakt helemaal niets uit voor CHAP.

[CyBeR]

Verwijderd schreef op zondag 18 maart 2007 @ 22:49:
[...]

Tuurlijk niet, wachtwoorden sla je als hash op in de database en dit maakt helemaal niets uit voor CHAP.

Kuch.

2.2. Disadvantages

CHAP requires that the secret be available in plaintext form.
Irreversably encrypted password databases commonly available cannot
be used.

http://tools.ietf.org/html/rfc1994

[OruBLMsFrl]

Gewoon salten zoals CyBeR aangeeft, dan zit alles goed. Het enige probleem is, dat als iemand bij het aanmaken van het wachtwoord wordt gesniffed een aanvaller natuurlijk gewoon als die gebruiker kan inloggen met behulp van het algoritme dat hij ook kan zien op de client. Dus eigenlijk zou je om het geheel waterdicht te krijgen eenmalig een SSL verbinding moeten gebruiken om je wachtwoord door te sturen naar de server.

[Verwijderd]

CyBeR schreef op zondag 18 maart 2007 @ 22:50:
[...]
Kuch.
[...]
http://tools.ietf.org/html/rfc1994

Grappig, ik zal het eens doorlezen maar ik zou niet weten waarom het niet werkt. gebruik dit systeem al jaren Ik zal me dan ongetwijfeld niet geheel aan de CHAP specs houden.

[edit]
Ik doe dit.

1. Stuur een challenge naar de client (random sha1 hash)

2. Client maakt een hash van het wachtwoord + de challenge code res = sha1(challenge+sha1(password));

3. Wis netjes het pain text wachtwoord

4. Stuur alles terug naar de server

5. De server doet het zelfde sha1(challenge + 'hash uit database') == res

Zoiets in het kort.

[ Voor 35% gewijzigd door Verwijderd op 18-03-2007 22:57 ]

[CyBeR]

Bas van der Doorn schreef op zondag 18 maart 2007 @ 22:51:
Gewoon salten zoals CyBeR aangeeft, dan zit alles goed. Het enige probleem is, dat als iemand bij het aanmaken van het wachtwoord wordt gesniffed een aanvaller natuurlijk gewoon als die gebruiker kan inloggen met behulp van het algoritme dat hij ook kan zien op de client. Dus eigenlijk zou je om het geheel waterdicht te krijgen eenmalig een SSL verbinding moeten gebruiken om je wachtwoord door te sturen naar de server.

Dat probleem is idd zonder compleet beveiligde verbinding niet echt te voorkomen denk ik. Je moet op een gegeven moment toch echt minimaal de md5 hash naar de server sturen.

[sjhgvr]

Ik heb t ooit eens zo gemaakt: (hoewel misschien wat overkill, maargoed)

DB:
User, Password (salted hash), Salt

Client: Hallo server, mag ik de inlog pagina?
Server: Genereerd "RANDOM" en serveert de inlog pagina (met "RANDOM").
Client: Na t verlaten van t username veld, word de username (a la AJAX) naar de server gestuurd.
Server: Zoekt de bijbehorende salt op en stuurt deze terug. (Indien geen salt gevonden, ontvangen username hashen met een static salt (zodat iemand niet kan testen als een gebruikersnaam daadwerkelijk in gebruik is of niet.)
Client: Typt wachtwoord. Bij versturen zend: hash(RANDOM + getypt password + ontvangen salt)
Server: Vergelijk de ontvangen data met: hash(RANDOM + DB Password)

No Match? Access denied.
Match? Access granted.

[ Voor 72% gewijzigd door sjhgvr op 18-03-2007 23:01 . Reden: Whoops .. foutje (quote knop ipv edit) ]

[OruBLMsFrl]

CyBeR schreef op zondag 18 maart 2007 @ 22:54:
[...]
Dat probleem is idd zonder compleet beveiligde verbinding niet echt te voorkomen denk ik. Je moet op een gegeven moment toch echt minimaal de md5 hash naar de server sturen.

Als je bang bent omdat mensen de hele tijd meldingen krijgen dat je certficaat dat je zelf getekend hebt misschien niet geldig is kan het een uitkomst zijn dat ze zo'n melding alleen krijgen bij het aanmaken van een account, ipv bij iedere inlog natuurlijk Maar goed, ik heb laatst nog voor 2 websites een 3-jarig SSL certificaat afgesloten voor 116 euro inc btw met bedrijfsnaam erop. Als er niets op hoeft te staan kun je geloof ik al voor een tientje per jaar aan de bak

[Verwijderd]

Lol DaPi, zie mijn edit 1 post hoger bijna hetzelfde.

[OruBLMsFrl]

DaPi schreef op zondag 18 maart 2007 @ 22:56:
[...]
Client: Na t verlaten van t username veld, word de username (a la AJAX) naar de server gestuurd.
Server: Zoekt de bijbehorende salt op en stuurt deze terug.[...]

Niets ten nadele van deze methode, op zich kan extra salten nooit kwaad, maar als iemand bij de hash kan die naar de server verzonden wordt, dan heeft ie de RANDOM en ook deze gebruiker specifieke salt te pakken. En aangezien het wachtwoord per gebruiker verschilt heb je niet echt veel winst naar mijn idee, anders dan dat deze methode een aanvaller misschien in de war brengt omdat zijn standaard scriptje des doods niet meer werkt
Blijft altijd het punt dat als een aanvaller het verkeer bij het overzenden van het wachtwoord voor de eerste keer kan afluisteren, hij het wachtwoord altijd kan nabootsen. De server moet de account immers ook met datgene wat de client dan overzend in de toekomst kunnen authenticeren.

[ Voor 16% gewijzigd door OruBLMsFrl op 18-03-2007 23:05 ]

[sjhgvr]

Bas van der Doorn schreef op zondag 18 maart 2007 @ 23:02:
[...]

Niets ten nadele van deze methode, op zich kan extra salten nooit kwaad, maar als iemand bij de hash kan die naar de server verzonden wordt, dan heeft ie de RANDOM en ook deze gebruiker specifieke salt te pakken. En aangezien het wachtwoord per gebruiker verschilt heb je niet echt veel winst naar mijn idee, anders dan dat deze methode een aanvaller misschien in de war brengt omdat zijn standaard scriptje des doods niet meer werkt

De winst is dat als de DB gekraakt zou worden.. dat je dan meer moeite moet doen om t password te kraken. Non salted hashes kun je hedendaags niet echt veilig noemen >> Rainbow tables

[CyBeR]

Volgens mij is een rainbow table genereren van een md5 hash al bijna onmogelijk. Dan moet je dus 2^128 mogelijkheden genereren. Je kunt dan beter collisions gaan opzoeken en die kun je voor elke hash wel krijgen, salted of niet.

[Verwijderd]

Als je de salt code naar de client stuurt heeft dat eigenlijk al geen nut meer voor de veiligheid van je database. Dan kun je beter je wachtwoord encrypten ipv hashen en dan is CyBeR ook meteen gelukkig

[edit]
@CyBeR: Als je een collisions vind voor een hash uit de database kun je daar geen bal mee juist omdat deze ge'salt is. Pas als je de salt code uit de source kunt plukken schiet je wat op.

[ Voor 32% gewijzigd door Verwijderd op 18-03-2007 23:23 ]

[OruBLMsFrl]

DaPi schreef op zondag 18 maart 2007 @ 23:06:
[...]
De winst is dat als de DB gekraakt zou worden.. dat je dan meer moeite moet doen om t password te kraken. Non salted hashes kun je hedendaags niet echt veilig noemen >> Rainbow tables

Hmmm, dat bevalt me wel, binnenkort maar de boel aanpassen dan, want het kan nooit veilig genoeg (4096 bits RSA ftw ). Draai zelf trouwens ook hashed wachtwoorden over mijn SSL verbinding, zodat de server niets plaintext hoeft op te slaan. Wat een schok zal dat zijn als een aanvaller ooit die SSL verbinding kraakt en het wachtwoord nog niet heeft... laat staan met deze dubbele salt techniek
Trouwens, tegen rainbow tables hebben we toch SHA-1, of nog beter, SHA-2?

Voor mijn ubuntu 6.06 LTS machine heb ik het volgende gedaan:
php5-mhash installeren voor salts en dan: $sha256b=base64_encode(bin2hex(mhash(MHASH_SHA256,$phrase)));
Clients met jssha2 de passwords laten hashen gevolgd door een salting hash met behulp van een random code die de server meestuurt. Toch een stuk veiliger dan SHA-1 of MD5.

This thread is easy to find through google, so I translated and summarized the above thread in English, enjoy.
For my Ubuntu 6.06 LTS server I did the following to allow SHA-2 hashes:
install package php5-mhash (php4-mhash also exists if you use PHP4)
In PHP use $sha256b=base64_encode(bin2hex(mhash(MHASH_SHA256,$phrase))); to get SHA-256 hashes server side
Use jssha2 (http://anmar.eu.org/projects/jssha2/) to let the clients hash the password and then salt it with a server generated random number that it sends along with the login page. This is a lot safer than MD5 and SHA-1 for which faster and faster collision algorithms are becoming available. Always use an SSL connection when users register themselves and send the password or its SHA-2 hash to the server (don't forget to also use SSL when changing the password), otherwise an attacker can still compromise your security by sniffing it at that time even if you use salts, because the client side algorithm is very easy to obtain by any attacker and future authentication must rely on the data sent from the client to the server when creating or changing the password.
If you cannot use SSL do any of the following:

- accept that your authentication protection is not foolproof
- use encrypted VPN tunnels to the server for registration and password changes
- transmit the password hash offline
- transmit the password hash by encryped email
- transmit the password hash by any other secure method you deem appropriate

[ Voor 60% gewijzigd door OruBLMsFrl op 24-03-2007 16:43 . Reden: Kwam de thread tegen op google in de top 10 results ]