Under dem veckor som gått så verkar det låta som att dem flesta i WN rekommenderar sha1+salt för inloggningssystem.
Vissa pratar om lite mer avancerade tillägg och kombinationer vilket jag inte greppar för att kunna bygga själv.
Det här är den nivå jag klarar av, räcker det eller är jag körd om jag använder den i mitt inloggningssystem?
http://www.phpit.net/article/handling-pass...rds-safely-php/

Jag pratade med folk utanför Sverige som inte verkar ha upplevt våra hackersstormar så dem tycker att md5 fortfarande är brukligt för inloggningar. Bland annat menade en snubbe att md5 är likvärdigt med sha1+salt ur ett visst perspektiv ja ni kan ju läsa själva hur han förklarade ni som kan kryptologi. Så åter till min huvudfråga räcker det med att jag implementerar sha1+salt?

Verkar okej när det gäller hantering av lösenord...

Tänk på följande saker
Lagra inte salt och lösenord tillsammans
Sätt minimum-längd på lösenorden, samt en siffra och ett specialtecken
Vid databaskoppling ska du använda PDO med prepared statements.

Och sist men inte minst...om din databas blir hackad.... tänk på att detta endast köper dig tid till att byta ut alla lösen.

Hur menar du då i den enkla guiden då sade dem att saltet kommer att sparas i databasen.
http://www.phpit.net/article/handling-pass...rds-safely-php/
Lösenorden måste ju sparas på samma databas så dem kommer ju att ligga på samma ställe. Vart sparar man annars saltet som ska implementeras på alla sha1 pölsade lösenord?

Många sparar det siom på bilden jag bifogat. Spara det absolut inte i samma table, och helst inte ens i samma databas.

ic då får jag försöka att koppla ihop 2 databaser för mina class filer isåfall. Kommer ta ett tag innan jag lyckas med det OOP är forfarande som grötkod i mina ögon :blink: tar mig evigheter att förstå och kunna modifiera småsaker som skulle gått på sekunder i procedural programming.

Gör så... bara du på något sätt kan separera lösen och salt. Lyckas man dumpa din databas och får tag i hash+salt så spelar saltet inte någon roll längre och man är tillbaka där man började... ett hashat lösenord.

Man kan då helt enkelt köra hashet mot rainbow tables...

Du kan även köra med multiple runs (tror det heter så)... det betyder att du loop-hashar ihop hash+salt, x antal gånger och sen sparar x precis som salt...separat.

Alltså... när ett lösenord ska sparas händer följande:

Du hashar lösenordet
Du skapar ett salt
Du slumpar fram ett tal
Du fogar ihop salt+hash till en hash om och om igen (så många gånger som talet du slumpade fram är)


EDIT*

På så sätt behöver en hackare lösenordet, saltet och x.

Liten sidofråga.

Jag har en tabell med MD5-hashade lösenord utan salt och vill lägga till salt till denna. Hur går man lämpligen tillväga? Ska man flagga upp det vid nästa användarinloggning, kolla att det är rätt lösenord och sedan lägga till salt och uppdatera hashen eller kan man göra det på annat vis?

Saltet kan du med gott samvete spara i samma tabell då det inte är hemligt, använd dock ett dynamiskt så inte samma salt används.
Om Brazzan har bra förklaring varför du ska spara det på annat ställe är jag väldigt nyfiken på det svaret :)

SHA1(lösenordet+salt)
lösenordet bör vara krav på längd, tecken osv och saltet dynamiskt. Sen får man kämpa om du ska knäcka alla lösenord.

Får du tag i varje salt för varje lösenord så försvinner ju lite syftet med saltet... även om det är dynamiskt. Du har ju då en sträng som du vet används i sammanfogningen.

Dock vet jag inte hur pass enkelt eller svårt det är när man har saltet... men varför chansa? Tar inte många minuter att fixa en separat lösning.

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.

Hellre göra för mycket än för lite är den filosofin jag försöker beskriva.

Edit*
En annan sak jag vill nämna också. Det är viktigt att man lyssnar på personer som SimonP och andra som verkar besitta en hel del kunskap inom området.. men samtidigt bör man inte förkasta andra förslag för att dem verkar onödiga enligt en själv. Det är viktigt att ta in alla synpunkter och basera ett beslut på den samlade kunskapen.

Man lever farligt om man inte lyssnar på andras synpunkter inom detta området. Samtidigt så är det otroligt bra att en sån här diskussion sker, både för mig och för andra. Jag är den första som erkänner om jag har fel, det kan ni lita på.

Har man många users kan det påverka serverprestandan.

-en extra query för varje inloggning
-en extra query för varje registrering
-en extra query för varje borttagning
-en extra tabell som tar plats i cacheminnet på sqlservern
-en extra tabell att ta backup på

Enda gången som en separat salt-tabell kan hjälpa till är väl vid databasdumpning via sql-injections?
Isåfall är det nog bättre att lägga tid på att skydda sig mot SQL-injections.

Om en hacker har rootat servern spelar det ingen roll om salten ligger i en separat tabell.

Visst går det att separera saltet, frågan är bara om det är värt det?

Det du säger är sant... och jag kan väl sträcka mig så långt att "min lösning" bara behövs i vissa situationer. Samt så är det sant som du säger att det kräver lite extra prestanda att ha en sån här lösning.

Om det är värt det eller ej är ju upp till var och en. Jag tycker det är roligt och informativt att diskuttera detta med bland annat dig :) .... Jag får bra och konkreta svar som får mig att tänka. Jag hoppas att jag har en liknande påverkan på andra. Det är aldrig fel att få sina kunskaper omskakade.

Dock vill jag också nämna att jag ogillar att bli anklagad för att vara okunnig och dum som denna tråden tyvärr resulterat i (skett utanför forumet).

Jag brukar bland annat använda mig av sha1(användarnamnet) som salt. Det saltet lagrar jag ingenstans eftersom inloggningsfunktionen vet att den ska salta med sha1-hashen av det angivna användarnamnet.

Det är också en bra lösning.

Japp, diskussion är bra.
Det här med IT-säkerhet och kryptering är dock inte så enkelt som många tror, jag har sysslat med det i snart 10 år och fortfarande kan jag lära mig nya grejor eller komma på saker som man kan göra bättre.

Exakt. Man får inte låsa sig till en "tro" om man kan säga så. Jag har inte utvecklat riktigt så länge som du, det är en av anledningarna till att jag hänger i dessa typer av trådar.. vill utveckla mig själv och kunskaperna... samt få sina ideer kritiserade och i slutändan gå här ifrån med en bättre syn på saker och ting.

Spelar ingen roll för mig vad som är akademiskt korrekt eller inte under motorhuven. Simpelt md5+salt eller sha1+salt skulle uppfylla mitt behov och är lagom för min ringa kompetens. Så länge som jag uppnår det här så är jag säker :)

Brazzan, visst är det bra att komma med nya idéer, men just säkerheten är livsfarlig att börja laborera med själv. Man kan som amatör tycka att man lägger till extra funktioner som förstärker säkerheten, men det är inte ovanligt att det får motsatt effekt.
Säkerhet som bygger på algoritmer är oerhört komplex och bör lämnas över till experter. Det bästa vi som programmerare och webbmasters kan göra är att följa deras riktlinjer.

Jag brukar se till att varje användare har ett login och ett användarnamn. Detta för att det ska bli svårt att brute-forca eller köra dictionary-attack på användare (man måste ju veta vem som har vilken login först) samt statiskt och dynamiskt salt.

Som statiskt salt brukar jag bara köra någon textsträng i PHP-sidan såsom "hej12[3]" och sen slänga in md5(dynamisktsalt.lösenord.statisktsalt) där det dynamiska saltet bara består av något fält som hör till användaren, typ id eller login. Det här är det bästa jag har lyckats komma på, så om någon har några invändingar eller tips så är det bara att skriva.

Salt är väll mest för att ingen ska få lösenordet i klartext ?

Om någon gör en brute-force så kommer det ju ändå inte spela någon roll om saltet
är 10000000 tecken eller inget alls. För när användaren loggar in så läggs ju
saltet på det vanliga lösenordet. Så varför skulle man behöva olika listor med ord?

Då är det väll bättre att bara skydda sig mot SQL-injections och spärra ett konto eller
en ip efter ett visst antal felaktiga inloggningar för att slippa brute-force?

Tvärtom. Lösenordshashen består ju av lösenord + salt. Ju mera salt, dessto längre tid tar det att göra en brute-force.

Edit: Eller det beror ju på hur man menar att denna brute-force går till. Om den sker via inloggningsformuläret på hemsidan så hjälper ju såklart inte saltet. Men om någon kommit över en databasdump eller liknande och alltså har tillgång till lösenordshashen, det är då man har nytta av saltet.

Jo, men ha då även i tanken att iaf inte md5 är en unik hash på något vis...

Te.x så kan P och pojke ha samma hash. (Bara ett exempel, vet inte om dem har det)

Det finns ingen i den akademiska världen som har lyckats hitta en given-hashkollision i MD5.
Sök på google ang. "preimage attack MD5".

Som jag skrivit förut, det är större chans att träffas av blixten än att hitta en given-hashkollision i MD5.

Denna phpsnutt använder jag, vilket är baserat på att det inmatade lösenordet använts för att skapa ett salt.

function chash($password, $salt) {
return sha1(crypt(md5(sha1($salt)), md5($salt))).sha1(md5($salt).sha1(sha1(md5($salt.s ha1(crypt($password, $salt).sha1(md5($password).$salt))))));
}

chash("mittpass", crypt(md5("mittpass"), sha1("mittpass")));

:o

Det där är inte bra, salt ska inte baseras på lösenordet.

Hur fort skulle ett dåligt lösenord (säg "volvo") hashat i SHA512 (utan salt) kunna hittas i en kollisionsattack med en "vanlig" persondator?

Det finns inga kollisionsattacker mot SHA512, däremot brute-force och rainbow-attacker, det skulle bara ta några sekunder att hitta "volvo". Med ett så kort lösenord spelar det ingen roll om man har salt heller.

Googlade runt lite, och läste om en kille som hade bruteforcat ett sha256 lösenord som var "test" alltså bara 4 tecken, det tog honom (med en modern persondator) 4 dagar. Säg att man tvingar lösenord att vara 8 tecken långa och har dom i sha512, kan man kanske sova lite lungt, iallfall om man byter lösenord varje vecka/månad?

Källa: http://khsw.blogspot.com/2005/01/sha256-br...d-revealer.html

Slutsats: Oavsett vilken krypteringsmetod du använder (inom rimliga ramar), plus salt - så överlever du dagens dekryperingsförsök.