kort guide om lösenord hantering

Permalänk
Medlem

kort guide om lösenord hantering

Hej
Jag har egentligen ingen utbildning i programmering eller datasäkerhet men jag är väldigt intresserad. Om det står något du tycker är helt fel eller kan förbättra så skriv det gärna här både för andra och min egen skull.

Jag tänkte skriva hur jag på ett säkert sätt skulle "hasha"(måste finnas ett bättre ord...) ett lösenord. Jag har sätt många skräckexempel där folk spara lösenord i klar text eller använder enbart md5 så därför tänkte jag att någon kanske får ut något av denna "guide"

Först och främst använd aldrig md5 då den är väldigt snabb vilket resulterar i att någon som försöker brute-force:a kan de testa fler kombinationer snabbare. md5 är också svag för en så kallad collision attack vilket betyder att man hittar flera kombinationer som ger samma hash.

Några mycket säkrare hash-algoritmer är sha256, whirlpool eller sha512 jag rekommenderar whirlpool. Alla har sina för och nackdelar så jag kommer inte gå djupare i varför då det inte är vad guiden är tänkt att handla om.

Nästa steg är att skydda sig mot så kallade rainbow tables det gör man genom att salta lösenordet innan man kör det genom en hash algoritm. Att salta betyder att man lägger till en massa tecken i lösenordet. Saltet bör vara unikt för varje lösenord och ska vara random. För att göra saltet bör man inte använda en prng som rand i php eller random i c#. Istället ska man använda en csprng som RNGCryptoServiceProvider i c#. Saltet bör vara minst lika långt som hashen.

Saltade strängen kan man sedan spara ihop med hasen i databasen. Det finns ingen ide att försöka gömma den någonstans efter som att om någon får tag på hasen så kan han ändå få tag på saltet också eftersom båda skickas och måste sparas i databasen samtidigt. Att hårdkoda saltet funkar inte heller då varje lösenord måste ha ett unikt salt så det aldrig kan finnas flera hash i databasen som är samma även om användarna använder likadant lösenord.

Näst sista steget är att skydda sig mot brute-force attacker det kan man göra genom att köra hasen flera gånger och på så sätt måste även den som försöker brute-forc:a köra algoritmen flera för varje kombination vilket givetvis tar längre tid som användarna behöver för att byta lösenord vid en eventuell attack.

Sista steget är mycket enkelt men också viktigt. Tillåt INTE användarna har för enkelt lösenord. Minst 7 bokstäver och med minst en siffra/tecken

Kan lägga upp lite exempelkod om någon är intresserad.

EDIT: ändrade till minst 7 bokstäver och med minst en siffra/tecken

Permalänk
Inaktiv

Hash-algoritmer såsom SHA eller Whirlpool används ofta som checksums för att jämföra om två filer är samma (tex. en du laddat ner på nätet) och är därför väldigt (relativt) snabba.

Istället borde man använda tex. bcrypt som speciellt är framtagen för att kryptera lösenord.

Denna länk har mycket nyttig info:
http://stackoverflow.com/questions/1561174/sha512-vs-blowfish...

Permalänk
Medlem

Minst 5 tecken är för kort för ett lösenord, det blir bara ca 1 miljard möjliga lösenord om du skiljer på stora och små bokstäver samt kräver siffror och tecken.

Egentligen gillar jag inte när det krävs specialtecken och liknande i lösenord heller, är mitt lösenord knypplandegrisarienlada är det mer än tillräckligt säkert trots att jag bara använd a-z. Väldigt mycket säkrare än S!D3k till exempel. Dock inser jag svårigheten att förklara det för användaren så vill man göra det lätt för sig så.
(Räknar man med ett ordföråd på 1000 ord blir det ungefär lika svårt som ett 8 teckens lösenord (1000^5 är ungefär samma som 78^8)

Det kan även vara en idé och behandla stora och små tecken som samma. Man sänker visserligen kraven rejält (vid 8 tecken blir lösenordet 35 gånger enklare), men med tanke på att folk har problem med CapsLock så kan man spara in en del support. Om man inte har något sätt att varna likt vid windows-inloggning, i annat fall borde även datorovana användare klara sig. (har haft support på folk som envist hävdat dom angivit rätt lösen trots att det dom angivit varit omvänt mot vad det egentligen varit, dvs tydligt visat på att dom missat caps)

Permalänk
Medlem
Skrivet av vb:

Minst 5 tecken är för kort för ett lösenord, det blir bara ca 1 miljard möjliga lösenord om du skiljer på stora och små bokstäver samt kräver siffror och tecken.

Egentligen gillar jag inte när det krävs specialtecken och liknande i lösenord heller, är mitt lösenord knypplandegrisarienlada är det mer än tillräckligt säkert trots att jag bara använd a-z. Väldigt mycket säkrare än S!D3k till exempel. Dock inser jag svårigheten att förklara det för användaren så vill man göra det lätt för sig så.
(Räknar man med ett ordföråd på 1000 ord blir det ungefär lika svårt som ett 8 teckens lösenord (1000^5 är ungefär samma som 78^8)

Skulle aldrig kunna tänka mig att använda lösenord på bara 5 tecken heller men mindre datorvana användare som inte använder lösenordet ofta så kan det bli svårt och komma ihåg och i rent säkerhets syfte tycker jag i alla fall att 5 tecken i huvudet är säkrare än 8 som är nedskrivna på diverse ställen.

Men gränsen kanske borde sättas runt 6-7 tecken...

Permalänk
Medlem

Jag tycker nog att det är bättre att ha ett säkert lösenord nedskrivet än att ha ett för lätt lösenord förutsatt att det är nedskrivet utanför datorn.

På tal om lösenordslängd, har du sett xkcdn om ämnet? http://xkcd.com/936/

Permalänk
Medlem

Till mitt senaste projekt använder jag mig av sha1. Jag tar sha1(lösen+sha1(salt)) där saltet är 1KB random från /dev/random.
PHP kommer få ett lösenordsgenereringssystem som bygger på bcrypt och saltning i 5.5 (tror jag det var).

Permalänk
Medlem
Skrivet av vb:

Jag tycker nog att det är bättre att ha ett säkert lösenord nedskrivet än att ha ett för lätt lösenord förutsatt att det är nedskrivet utanför datorn.

På tal om lösenordslängd, har du sett xkcdn om ämnet? http://xkcd.com/936/

Problemet med exemplet i länken är att de inte tänker på dictionary attacks.

Permalänk
Medlem
Skrivet av hampee94:

Problemet med exemplet i länken är att de inte tänker på dictionary attacks.

Jodå, han har räknat med ett ordförråd på ca 2000 ord. 2000 * 2000 * 2000 * 2000 är ungefär lika mycket som 2^44.

Permalänk
Medlem
Skrivet av hampee94:

Problemet med exemplet i länken är att de inte tänker på dictionary attacks.

Både ja och nej, men mest nej.

En dictionary-attack är en helt annan sorts angrepp som inte har någonting alls att göra med hashar; man gör attacken utifrån, ord för ord ur en ordlista. Ett ord som 'alpacka' går lätt att slå upp i en ordbok (svensk), vilket gör det till ett lättknäckt lösenord. Kombinerar man flera ord ur samma ordlista är attacken helt plötsligt mycket svårare; 'gnisslandetandkrämsalpacka' är inget ord som förekommer i ordlistor (i alla fall inte i de jag känner till) men det är lustigt och lätt att minnas.

En attackerare vet inte om du har 'kh25"%muffin' eller 'lulligöronmärktplåtsax' som lösenord. Förmodligen testar han med de vanligaste orden i en ordlista på säg 170000 ord. Skulle han vilja testa alla kombinationer av tre ord ur ordlistan har han 4913000000000000 olika kombinationer, och till den mängden räknas inte alla kombinationer av två ord (han vill antagligen testa 'våffelyoghurt' också om han ändå ska gå på plåtsaxen).

edit: 170,000 ord är en jävla massa ord, men tydligen finns det "typ" så många i svenska språket.

Visa signatur

Kom-pa-TI-bilitet

Permalänk
Medlem
Skrivet av hampee94:

Skulle aldrig kunna tänka mig att använda lösenord på bara 5 tecken heller men mindre datorvana användare som inte använder lösenordet ofta så kan det bli svårt och komma ihåg och i rent säkerhets syfte tycker jag i alla fall att 5 tecken i huvudet är säkrare än 8 som är nedskrivna på diverse ställen.

Men gränsen kanske borde sättas runt 6-7 tecken...

För att lättare komma ihåg lösenordet måste de associeras med något (nej, inte namnet på hunden eller barnen) eller bygga på något system. Att ha lösenordet nedskrivet är en bra idé i vissa fall medan en katastrof i andra. Hemma på skrivbordet kollar kanske inte så många men på jobbet är det värre.

Permalänk
Medlem
Skrivet av iXam:

Till mitt senaste projekt använder jag mig av sha1. Jag tar sha1(lösen+sha1(salt)) där saltet är 1KB random från /dev/random.
PHP kommer få ett lösenordsgenereringssystem som bygger på bcrypt och saltning i 5.5 (tror jag det var).

Skulle nog ändå inte rekommendera sha1. Har för mig att det är ungefär lika snabbt som md5.

Förövrigt så duger knappast fem tecken, (gjorde lite test själv med genererade md5-strängar och olika program, kom fram till att min gamla Athlon 6400+ kan bruteforca igenom alla sex tecken långa strings med stora och små tecken, siffror och tecken på nån timme. Med modernare CPU, användning av GPU och/eller med fler maskiner går det betydligt snabbare) och därför skulle jag rekommendera minst 8, samt uppmaning om att inte använda ord.

EDIT: I övrigt rätt bra guide dock!

Skickades från m.sweclockers.com

Permalänk
Medlem
Skrivet av Snacker:

Skulle nog ändå inte rekommendera sha1. Har för mig att det är ungefär lika snabbt som md5.

Typ. Men det är tillräckligt "ok" för tillfället. Jag kommer dock att göra om det ev Q1 2013 och då kommer det förmodligen göras enligt "best practise" då och förmodligen är 5.5 släppt (https://gist.github.com/3707231).

Permalänk

Som tidigare nämnts är väl Bcrypt att rekommendera. Finns ett smidigt library till PHP som ni kan hitta här:
http://www.openwall.com/phpass/

Kort exempel:

// Load Password Hash & Create Instance require 'PasswordHash.php'; $hasher = new PasswordHash(8, false); // Hash Password $hash = $hasher->HashPassword($password); // Check Password $check = $hasher->CheckPassword($password, $hash);

Visa signatur
Permalänk
Medlem

Tillför inget i diskussionen här, men du är medveten om att det finns en ny avdelning för just guider här på forumet va?
http://www.sweclockers.com/forum/140-guider/