Veilige manier om in te loggen...
Erwin H op 04/07/2012 08:50:45:
Een absoluut antwoord is in dit soort situaties vaak niet te geven. Al was het maar omdat veel zaken continu veranderen. Volgens mij zijn er echter twee punten van belang:
1) als je client side al het password hashed, moet je er rekening mee houden dat hash methode en eventuele salt ook al clientside beschikbaar moet zijn. Daarmee in javascript en dus ook leesbaar voor de aanvaller. Lijkt me dus nooit een volledig veilige methode
2) wat je ook doet client side, de echte authenticatie vindt plaats server side. Dus ofwel je moet het password zo hashen/encrypten/salten dat de uitkomst precies gelijk is aan de waarde in je database, ofwel je moet ervoor zorgen dat je wat je al gedaan hebt nog terug kunt draaien. Het eerste lijkt me niet wenselijk omdat je dan je hele beveiligingsmethode feitelijk prijs geeft, het tweede is in principe niet super veilig.
Wim E op 03/07/2012 20:34:34:
1. Kun je nu challenge/response samen met een salted wachtwoord in db combineren?
2. Is het dan slimmer om challenge/response te gebruiken + hashed password of kan er dan beter gebruik worden gemaakt van hashed+salt en stuur je het wachtwoord hashed over de lijn?
2. Is het dan slimmer om challenge/response te gebruiken + hashed password of kan er dan beter gebruik worden gemaakt van hashed+salt en stuur je het wachtwoord hashed over de lijn?
Een absoluut antwoord is in dit soort situaties vaak niet te geven. Al was het maar omdat veel zaken continu veranderen. Volgens mij zijn er echter twee punten van belang:
1) als je client side al het password hashed, moet je er rekening mee houden dat hash methode en eventuele salt ook al clientside beschikbaar moet zijn. Daarmee in javascript en dus ook leesbaar voor de aanvaller. Lijkt me dus nooit een volledig veilige methode
2) wat je ook doet client side, de echte authenticatie vindt plaats server side. Dus ofwel je moet het password zo hashen/encrypten/salten dat de uitkomst precies gelijk is aan de waarde in je database, ofwel je moet ervoor zorgen dat je wat je al gedaan hebt nog terug kunt draaien. Het eerste lijkt me niet wenselijk omdat je dan je hele beveiligingsmethode feitelijk prijs geeft, het tweede is in principe niet super veilig.
Bedankt voor je reactie:)
Er is tevens een topic gaande over beveiliging maar dat terzijde...
Naar mijn idee is dus de afweging waar je de nadruk op legt.
Client kant betekent:
Client[wachtwoord + challege] -> Server[response == [hash(wachtwoord)+challenge]
Voor server zou zijn:
Client[wachtwoord] -> Server[hash(wachtwoord+salt) == hashed(wachtwoord+salt)]
Mijn voorkeur zou hierin zijn:
Client[hash(wachtwoord)] -> Server[hash(hashed(wachtwoord)+salt) == hashed(wachtwoord+salt)]
Overigens lijkt mij de challenge/response toch de voorkeur te hebben.
Dit omdat het wachtwoord clientside / onderweg niet te herleiden is en indien ze in de database zitten, dat ze er toch al zijn, ongeacht het wachtwoord (wat niet plain text is opgeslagen). Daarbij geldt, als je in de DB zit, zou je in de code nog wel een extra waarde kunnen toevoegen aan de hash zelf. Dus bijv. altijd hash...en dan abc bijv aan toevoegen:) ook soort van salt(A)