Hann inte läsa igenom alla inlägg men glöm inte session fixation attack om inte det är nämnt..

Tänk så här då.. Om jag gör ett script som skickar in alla möjliga användarnamn och de mest vanliga lösenorden. Dvs. jag försöker inte logga in med samma användarnamn hela tiden. Då har jag 5 försök per användarnamn och timma. Har man i stället en 5 sek. delay vid varje felaktigt försök så blir det mycket svårare, eller?

// Mats

Jo, visst tar det längre tid, i praktiken finns det risk för att dom legitima användarna tycker det är drygt att vänta bara för att dom skriv in fel lösenord en gång, dagen samhälle är mkt stressat :-)

Man kan ju fördröja på olika sätt, men om man använder vanliga sleep-delayer på en webserver förblir anslutningen/processen öppen på servern, så ifall dom matar på med många användare samtidigt från olika datorer blir det lättare att utföra en denial of service attack om man har en sådan typ av delay.

Det kanske är bättre att lägga till en begränsning för antalet felaktiga inloggningar per IP-nr, då kan "hackarna" bara ha 5 försök/IP-nr, oavsett vilket användarnamn dom försökte med. Sen kan man ha en whitelist för dom IP-nr som ska ha lösare restriktioner.

Ja det låter som en bra approach. Men allvarligt.. hur många skriver fel lösen? Oftast vet man ju sina lösenord (eller är det bara jag som har koll på mina?) :)

Jag personligen skriver fel rätt ofta, pga jag har olika lösenord och en del av dom är krångliga.
Ju enklare lösenord ju mindre risk att man skriver fel ;)

Har suttit och läst igenom denna trevliga tråd nu och tänkte bidra med något som jag har funderat på att testa.

Problemet är som tidigare nämnt att saltet som man använder sparas någonstans, så kommer någon åt det så är det kört i vilket fall som helst, trots tex SHA1.

Jag vill lägga saltet i minnet på webbbservern och enbart läsa det därifrån.
Vid en omstart eller liknande måste alltså saltet anges av en person, vilket kan göras via tex lämpligt gränssnitt (mobil, webbsida etc... och då med SSL företrädesvis). Saltet skrives i en fil varpå servern/applikationen startas om. Vid start av applikation läses saltet in i minnet och filen raderas.

Någon som testat detta innan jag testar...?

/Mani

Salt är i första hand till för att motverka rainbow-table attacker och för att motverka att två användare med samma lösenord får samma hash. även om hackaren vet saltet så skyddar det mkt bra ändå, sedan bör varje användare ha sin egen salt.

Det man kan göra är att lägga till en statiskt salt utanpå användarens salt, denna statiska salt lagras enbart i RAM (som du syftar på), jag kollade lite detta förut (i Apache) men jag hittade inget bra sätt att läsa in det statiska saltet till RAM så att alla sessioner kommer åt det på ett enkelt sätt. Jag kom på nu att det kanske funkar att sätta det som en ENV variabel, rapportera om du hittar något bra sätt.

Jag kör det mesta i Windows, så jag tänkte där använda en applikationsvariabel för ändamålet. Tanken är precis som du säger att ha ett personligt salt för varje medlem också.

/Mani