Du ska logga in och etablera en symmetrisk sessionsnyckel.
Attackeraren känner till autentiseringsalgoritmen.
Attackeraren har ordbok och topplista på lösenord.
Attackeraren kan avlyssna all klient/server-trafik tills du har din symmetriska nyckel.
Attackeraren kan avbryta, ändra och förfalska klient/server-trafik.
Det finns ingen betrodd tredje part.
Du vill ha något säkrare än SSH och snabbare än ren Diffie-Hellman.
Du vill ha zero-knowledge password proof, dvs du visar aldrig lösenordet utan bevisar bara att du har lösenordet.
Du vill inte att en SQL injection ska ge attackeraren en vanlig lösenordshash (MD/SHA) att knäcka. Inte ens en statiskt saltad hash duger för dig.
Du vill använda ett enkelt lösenord.
Du vill ha ...
http://en.wikipedia.org/wiki/Secure_Remote_Password_protocol
Version 6, hårdgranskat, från Stanford. Så coolt att jag baxnar.
Prenumerera på:
Kommentarer till inlägget (Atom)
5 kommentarer:
Verifikatorvärdet som sparas "serverside" i SRP är i princip en saltad hash, så det där med skydd mot databasdumpar kan du stryka...
Hej Olle!
Det är klart att verifikatorn ihop med saltet och användarnamet ska räcka för att autentisera användaren så om det är det du menar med "i princip" så håller jag med.
Men ska man jämföra med lösenordshashar så är det ju för det första en lösenordshash som skickas till servern, inte ett lösenord. För det andra så är det individuellt salt per lösenord vilket inte alltid är sant för vanliga lösenordshashar. För det tredje så får man närmast jämföra det med multipel hashning eftersom en brute force-attack måste utföra hela kedjan för att få fram lösenordet.
Ja, det är det jag menar, alltså stämmer inte påståendet "Du vill inte att en SQL injection ska ge attackeraren en lösenordshash att knäcka".
Vad gäller work factor för SRP-beräkningen är den högre än många andra lösenordsverifikationssystem, men dock konstant. bcrypt medger en bakåtkompatibel konfigurerbar ökning av work factor vilket är en av dess fördelar. Future-proofing!
OK, jag köper en ändring till "vanlig lösenordshash (MD/SHA)". Har uppdaterat.
Future proofing är intressant. Diskuterade multipel hashning med lite folk. Typ SHA256 x 100. Sen kan man bara hasha vidare i takt med att prestanda/utrymme hos attackerare kräver det. Utan att behöva be om lösenordet.
Antalet hashningar skulle kunna bero av lösenordet vilket närmar sig security by obscurity men vore ett intressant skydd mot brute force. Eller vad tror du?
Det börjar likna PBKDF2, banne mig...
Variabelt antal rundor sänker bara säkerheten (vid en attack känner ju angriparen kandidat-lösenordet), bättre att sätta en och samma höga ribba för alla.
MÅSTE man uppfinna något själv så låter ju ett par tusen rundor SHA inte så illa, som du sa kan man ju faktiskt utöka antalet rundor vid behov.
Skicka en kommentar