Brazzan hur mycket tar du i betalt för att pimpa upp ett färdigt md5 system skrivet i OOP och gör om till sha1+salt+(din-magic-touch)?
Det här tar aldeles för mycket tid från det jag egentligen vill koncentrera mig på <_<

Nej, det stämmer inte, saltet är i första hand till för att försvåra dictionary och stoppa rainbow attacker.
Det dynamiska saltet kan sparas i samma databas.

Ja, det räcker väldigt långt, se till att varje användare har en egen salt bara. Lägg gärna till en lösenordspolicy så att användarna inte kan välja för enkla lösenord.

Håller inte med. Man bör spara det separat. Det är lite som att ge bort en bit av kakan tycker jag... det ska dock nämnas att man måste veta hur man fogar ihop hash+salt, men varför chansa...

Det är ju inte jätte avancerat att separera och lagra saltet på annan plats... även om det kanske bara ger en liten förbättring ur ett säkerhetsperspektiv. Det tar inte så lång tid.

Men, alla gör vi olika :) Jag väljer att lägga 10min extra på att lagra det separat.

Brazzan: Verkar som du inte vet vad saltet har för syfte eftersom du tycker det ska lagras separat och syftet med saltet skulle försvinna när någon kommer över dessa.

.... Ett salt används för att utöka säkerheten på ett lagrat lösenord. Främst är det till för att stoppa attacker där man testar lösenordet mot en lista med kända lösenord... rainbow-tables.

Om man har slumpade salt för varje lösenord krävs det att man bygger upp nya listor för varje salt, vilket tar väldigt väldigt lång tid. Det är det som stoppar en en lista med kanske 10 000 lösenord att läcka ut i klartext... alltså, man måste bygga upp listor för varje användare och salt som finns, 10 000ggr.... vilket inte är realistiskt.

Men det kanske bara krävs att man knäcker ett lösenord, administratörens och på så sätt får tillgång till en adminpanel, webhotellet eller andra ställen där han har samma lösen.

Återigen.. varför chansa när det inte är så svårt att lägga det separat.

Håller med SimonP om att det är onödigt att spara saltet på annan plats, det är ju som sagt lösenordspolicyn som är avgörande!

Anledningen till att man inte ska göra det, förutom att det är onödigt, är för att det ger dålig struktur och bygger för mycket onödig komplexitet i applikationen.

Brazzan, egentligen räcker det väl med att ha en rätt simpel salt (tex användarens user-id) för att uppnå det du pratar om. Dvs att man måste generera nya rainbow-tables för varje user.

Det känns som att det är en rätt markant ökning i säkerhet som räcker för de flesta?

Själv har jag löst det genom att saltet är ett slumpmässigt antal bytes som läggs på och som inte behöver sparas separat. Antalet salt-bytes kan räknas fram "baklänges" vid verifieringen om lösenordet som ska testas bara är av rätt längd.

Vill inte posta min kod här men något liknande finns här (.NET).

Det beror på hur "galen" man är när det gäller säkerhet. Det är inte komplicerat att separera och det behöver inte bli dålig struktur.

Ja alltså för att få bort problemet med att en hackare testar alla lösenord mot r-tables löses ju med ett slumpat salt för varje användare.. oavsett hur okomplicerat saltet är.Men det jag menade var att det kanske bara behövs genereras en ny table för admin lösenordet och på så sätt lyckas ställa till saker och ting. Speciellt med tanke på folks förmåga att använda samma lösenord till flera saker.... Sen kanske man får se mail-adresser kopplade till användarnamn... då kan man ju exempelvis börja leta efter @microsoft.com, @apple.com osv osv och liksom sikta sig in på dem och bygga upp r-tables baserade på deras salt.


Att spara saltet tillsammans med lösenordet är som du säger en lösning som räcker långt, men jag förstår fortfarande inte varför man ens ska chansa när det inte är svårt att fixa en separat lösning. Det är det som jag blir lite irriterad över... även om det bara ger en 1% ökning av säkerhet, så är det ju positivt med tanke på att det tar 10min att separera saltet från lösenordet.

Angående lösenordspolicy så nämnde jag det tidigare också. Det blir ju mycket bättre om man lyckas införa en policy som sätter minimun kvar på lösenordet.

Ni får tycka jag är paranoid eller onödigt komplicerad... men jag väljer att göra vad jag kan för att minimera chansen.... vi lever ju i en tid där det finns ett ökande hot från personer vars syfte är att förstöra för andra, bara för att dem kan.