Beste keuze voor veilig inlogsysteem website

[SvMp]

Ik ben bezig met het bouwen van een veilig inlogsysteem. Ik sta nu voor een keuze: Salt per sessie toevoegen + publieke salt per user, of geen salt per sessie toevoegen + geheime salt per user.

Hoewel hier vele topics over zijn, en ook op Google veel is te vinden, zijn de meningen erg verdeeld. Ik zie zelf veel voordelen in een salt per sessie, maar dan is volgens mij de consequentie dat de user-salt publiekelijk bekend wordt. Soms lees je dat dit absoluut niet acceptabel is, sommige bronnen zeggen dat het niets uit maakt.

Wat ik nu heb gemaakt:
- Iedere user heeft een salt
- Deze salt wordt naar de cliënt gestuurd als een bepaalde user wil inloggen of een wachtwoord wil wijzigen
- Cliënt side worden wachtwoord en salt gecombineerd, SHA512 gecodeerd en meegestuurd met het login formulier. Uiteraard wordt het plain-text wachtwoord dat de user heeft ingevoerd niet mee gestuurd. Dit is doorgevoerd in alle dialoogvensters/pages waar een user een wachtwoord opgeeft (login, wachtwoord keuze bij registratie, wachtwoord keuze via gemailde wachtwoord-restore-link en wachtwoord wijzigen).
- Serverside is het momenteel heel simpel: Meegestuurd gecodeerde wachtwoord wordt vergeleken met wat er in de database staat.

Al een hele verbetering t.o.v. wat ik eerder had, namelijk formulieren die plain-text verstuurd werden en wachtwoord hashes obv. MD5 zonder salt.

Maar het kan beter. De huidige situatie is nog gevoelig voor man-in-the-middle attacks waarbij simpelweg het gecodeerde wachtwoord wordt gestolen en naar hartelust kan worden gebruikt om in te loggen.
Nog een nadeel aan de huidige situatie: User-salt is bekend omdat deze mee wordt gestuurd naar de cliënt.

Ik kan naar mijn idee twee kanten uit:

1. Per sessie een salt meesturen, die na elke loginpoging niet meer geldig is. Hierdoor wordt een hash die door sniffing is verkregen onbruikbaar.
Ik gebruik dan bijvoorbeeld SHA512(sessie_salt+SHA512(user_salt+user_pass)) als hash.
Sessie-salt wordt uiteraard naar de cliënt gestuurd evenals de user-salt. Die sessie-salt vervalt na elke login (succesvol en onsuccesvol).
Server-side wordt een hash op basis van SHA512(user_salt+user_pass) uit de database gehaald, vervolgens SHA512(sessie_salt+dbhash) en dat wordt vergeleken met de hash die vanuit de cliënt komt. Ongeacht de uitkomst van die vergelijking wordt de sessie_salt vernietigd en eventueel opnieuw random gegeneerd voor een volgende poging.

Voordeel: Een onderschepte hash is niet te gebruiken.
Nadeel: User salt openbaar

2. De salt per user geheim houden.
Nu stuur ik die mee.
Als ik die geheim hou, dan stuurt de client een hash op basis van SHA512(user_pass), eventueel met een vaste salt er bij om bestaande dictionaries onbruikbaar te maken.
Server-side wordt een hash op basis van SHA512(user_salt+SHA512(user_pass)) uit de database gehaald, vervolgens wordt de hash vanuit de cliënt verder gecodeerd met SHA512(user_salt+cliënt_hash) en vergeleken met de hash in de database.

Voordeel: User salt niet openbaar
Nadeel: Als de hash wordt onderschept kan hiermee ingelogd worden (wachtwoord is gelukkig wel onbekend).

Naar mijn idee is het niet mogelijk om keuze 1 en 2 zo te combineren dat de nadelen vervallen en alle voordelen gelden. Volgens mij is het onmogelijk om een user salt toe te passen in combinatie met een salt per sessie zonder die user salt mee te sturen naar de cliënt.

Maar misschien zie ik iets over het hoofd.
Wat is de beste keus?

Ik neig naar keuze 1. De kans dat de database in verkeerde handen valt is kleiner dan dat een meegestuurde hash wordt onderschept.

N.B. Deze vraag staat los van het gebruik van SSL. Uiteraard heb je met een beveiligde verbinding het probleem niet meer dat de hash onderschept kan worden, en kan is keuze 2 het meest aantrekkelijk.

[ACM]

SvMp schreef op donderdag 15 december 2011 @ 13:37:
N.B. Deze vraag staat los van het gebruik van SSL. Uiteraard heb je met een beveiligde verbinding het probleem niet meer dat de hash onderschept kan worden, en kan is keuze 2 het meest aantrekkelijk.

Deze vraag moet je juist niet los zien van SSL.

Door SSL toe te passen heb je al je stappen om "veiliger" inloggen te faciliteren niet meer nodig. Sowieso dwing je jezelf met deze code tot slechts 1 sha512-iteratie voor het wachtwoord, waardoor brute-force van een uitgelekte database relatief eenvoudig is. Bovendien is het wachtwoord helemaal niet nodig om te weten, want je kan gewoon alles bereiken met die sha512(user_pass). Dat een salt bekend zou zijn zou geen probleem mogen zijn, een salt voegt vooral meer entropy aan de opslag-keyspace toe het is normaliter niet bedoeld als onderdeel van een beveiligingsprocedure an sich.

Mijn advies zou zijn: gooi al deze trucage overboord. Gebruik SSL voor je communicatie met ingelogde gebruikers en sla je wachtwoord flink stevig gehashed op. Daar zijn meerdere methodes voor, o.a. diverse crypt-varianten, pbkdf2 en meer exotische algoritmes als bcrypt. Door de toepassing van SSL kan het verder geen kwaad dat dat wachtwoord 'plain text' wordt overgestuurd. Op die manier kan je veel zwaardere en later veranderende versleuteling van je wachtwoorden doorvoeren zonder tegen beperkingen van de client-side aan te lopen.

Door dat allemaal overboord te gooien maak je het jezelf makkelijker. Het enige wat je nog hoeft te doen is forceren dat men SSL ook gebruikt en niet via non-ssl gaat browsen. Door de sessie-cookie op secure te zetten en verder niet anders te communiceren of in html te verwerken zorg je er ook voor dat die alleen met SSL-requests wordt meegestuurd.

[_Erikje_]

Waarom het wiel opnieuw proberen uit te vinden door complexe SALT trucage toe te passen als er voor jouw platform vast wel een kant en klaar, goed doordacht systeem beschikbaar is.

Ssl + bcrypt lijkt mij een verstandige oplossing. Bcrypt is namelijk rete traag waardoor bruteforcen minder interessant wordt.

Misschien is blacklisten een optie om bruteforcen verder te voorkomen. Als het een intrapte systeem is kan je ook nog denken aan een tokensysteem.

[Jaaap]

Hmmm... veel SSL liefde hier.
Wees je wel bewust van de beperkingen van SSL en dan met name de "trust base", wie kun je vertrouwen?

[Keiichi]

Buiten de trust om levert SSL natuurlijk op dat je niet zomaar afgeluisterd word. (Wellicht nog wel een man-in-the-middle attack mogelijk als de trustbase niet in orde is)

[Jaaap]

Keiichi schreef op donderdag 15 december 2011 @ 23:08:
Buiten de trust om levert SSL natuurlijk op dat je niet zomaar afgeluisterd word. (Wellicht nog wel een man-in-the-middle attack mogelijk als de trustbase niet in orde is)

Ja dus dat je niet door "Joe Average" wordt afgeluisterd.
Als je niet wilt dat je door overheden enzo wordt afgeluisterd moet je naar een andere oplossing zoeken.

[pedorus]

Jaaap schreef op donderdag 15 december 2011 @ 23:06:
Hmmm... veel SSL liefde hier.
Wees je wel bewust van de beperkingen van SSL en dan met name de "trust base", wie kun je vertrouwen?

Tsja, hier valt niet tegen op te werken behalve door iets als convergence te gebruiken/aan te raden (hoewel ook dat niet helpt als je eigen servers gehackt worden). Je kunt bijvoorbeeld wel het wachtwoord versleutelen met javascript, maar dit helpt natuurlijk niet. Een attacker zal eenvoudigweg dit stukje javascript veranderen.. Kortom, javascript zorgt er alleen maar voor dat iets als noscript niet meer werkt en maakt de boel dus onveiliger

[ACM]

Jaaap schreef op donderdag 15 december 2011 @ 23:06:
Hmmm... veel SSL liefde hier.
Wees je wel bewust van de beperkingen van SSL en dan met name de "trust base", wie kun je vertrouwen?

Dat is natuurlijk waar, maar javascript kan je ook niet vertrouwen. Zolang er geen betrouwbaar (als in beveiligd en niet aanpasbaar) aangeleverde code is, heeft het weinig zin om er allerlei beveiligingsroutines in te schrijven. Als iemand je communicatie kan afluisteren, kan ie je javascript aanpassen. Zie bijvoorbeeld dit verhaal over cryptografie in javascript.

Bij SSL weet je in ieder geval dat je niet extern aangeleverde cryptografische code krijgt, maar die bij je browser werd geleverd.

Je hebt absoluut gelijk dat SSL ook beveiligingsproblemen kent (zoals o.a. met Diginotar werd aangetoond), maar er is vziw geen bruikbaar alternatief waarbij de beveiliging daadwerkelijk beter is. Daarvoor moet je op zijn minst op een betrouwbare en veilige wijze de ver- en ontsleutelingsroutines kunnen aanleveren en dat is iig met de huidige werking van javascript niet het geval.

[Zoijar]

Wikipedia: Challenge-response authentication

Jaaap schreef op donderdag 15 december 2011 @ 23:13:
Ja dus dat je niet door "Joe Average" wordt afgeluisterd.
Als je niet wilt dat je door overheden enzo wordt afgeluisterd moet je naar een andere oplossing zoeken.

Welke dan? Want de "problemen" met SSL zijn fundamenteel aan beveiliging: hoe weet ik zeker dat ik praat met degene waar ik denk dat ik mee praat? Op quantum-encryptie na, wat niet erg praktisch is nog, kan elke key exchange onderschept worden. De enige manier om dat te voorkomen is om een hogere autoriteit te gebruiken voor identificatie. Als je die niet kan vertrouwen breekt elke beveiliging.

[Voor 73% gewijzigd door Zoijar op 17-12-2011 12:58]

[SvMp]

ACM schreef op zaterdag 17 december 2011 @ 10:27:
Als iemand je communicatie kan afluisteren, kan ie je javascript aanpassen.

Dit bezwaar begrijp ik niet. Bedoel je dat iemand het Javascript zo kan aanpassen dat er stiekum ook een plain-text versie van de data wordt meegestuurd zodat de afluisteraar dat kan onderscheppen?

Javascripts aanpassen is wel een flink niveau hoger dan alleen afluisteren. Afluisteren is namelijk niet al te moeilijk, de juiste data manipuleren is een stuk lastiger. Dan moet je HTTP-requests gaan onderscheppen, en de gewijzigde javascripts teruggeven.

[pedorus]

Stap even af van HTTP, daar valt niet mee te beveiligen. Als je een HTTPS-request wil onderscheppen, dan heb je bijvoorbeeld een vervalst certificaat nodig, of toegang tot de originele certificaten. Iemand die dat kan, is prima in staat om gewijzigde javascripts terug te geven, dat is een stuk eenvoudiger. De kans is zeer groot dat het dan een gerichte aanval betreft, dus javascript gaat je echt niet meer helpen.

[Noork]

Bedoel je overigs niet een 'nonce' ipv salt?
Salt zie ik persoonlijk meer iets wat je aan een pw string toevoegt, voordat je een hash er van trekt. Nonce kun je meer zien als een soort one time password, wat samen met je echte pw ge-encrypt over de lijn wordt gestuurd. Zo'n nonce kun je b.v. een beperkte geldigheid geven (tijdens sessie voor 5 min o.i.d.) Dit voorkomt replay door man in the middle.

Ben het trouwens met de SSL boys in dit topic eens. Lijkt me een veel effectievere manier tegen man in the middle.
Zelf zou ik eerst eens op papier zetten waaraan je beveiliging moet voldoen. Stel gewoon een eisen, bepaal aan de hand daarvan de 'beste keuze'.

[TheNephilim]

Check dit: Wikipedia: PBKDF2

Interessante aanpak waarbij je meerdere keren hashed met salt. Behalve deze aanpak zou je de login kunnen doen met SSL en de rest van de website gewoon http. Helemaal veilig is SSL nooit, maar het voegt wel een extra laag toe.

Op een gegeven moment moet je ook afwegen of al die veiligheidslagen wel nodig zijn voor wat je aan het maken bent. Extra veiligheid betekend soms een slechtere gebruikerservaring. Bijv; mensen begrijpen dat hun bankgegevens gevoelig zijn en vinden het niet erg dat ze meerdere 'obstakels' moeten nemen om in te loggen. Iemand die gewoon in wil loggen op een forum waar hij/zij af en toe wat plaatst en leest heeft geen zin in TAN-codes en/of Random Readers.