Hashade lösenord vs ohashade

Skillnaden ur säkerhetssynpunkt, är att om någon lyckas komma över de hashade lösenorden, måste han fortfarande gissa dem. Den lösenordssträng som han matar in vid en inloggning, förutsätts ju vara ohashad, och ska hashas för att jämföras med det hashade lösenordet som finns lagrat på servern. Hade däremot alla lösenord lagrats i klartext på servern, då hade inträngaren omedelbart fått tillgång till alla lösenord i klartext. Den skillnaden är ofta rätt väsentlig.

Re: Hashade lösenord vs ohashade

echoSwe skrev:

Men å andra sidan så kan man väl hasha slumpmässiga 8-9 teckenslösenord och sedan försöka med dem?

Det är därför man använder sig av ett salt. Mer läsning.

Allt beror på hur man ser det.

Man får tänka på att det finns ett OÄNDLIGT antal textsträngar som producerar en exakt likadan hash. :)

Tack för svaren. :)

desdecado skrev:

Allt beror på hur man ser det.

Man får tänka på att det finns ett OÄNDLIGT antal textsträngar som producerar en exakt likadan hash. :)

Fast det är ju inte så lätt att hitta dessa strängar.

Flyttas från ASP.NET

UlfT skrev:

desdecado skrev:

Allt beror på hur man ser det.

Man får tänka på att det finns ett OÄNDLIGT antal textsträngar som producerar en exakt likadan hash. :)

Fast det är ju inte så lätt att hitta dessa strängar.

Sant. Mig veterligen har man inte ännu hittat 2 strängar som ger samma hash, ändå så finns det oändligt många. =)

Sedan så kan man kontra påståenden som att exempelvis "detta password har 50miljarder möjliga kombinationer och tar 1år att lista ut". Man ska då tänka på att det är exakt LIKA STOR CHANS att man får rätt lösenord på FÖRSTA försöket som att få det på SISTA försöket. :)

desdecado skrev:

Sedan så kan man kontra påståenden som att exempelvis "detta password har 50miljarder möjliga kombinationer och tar 1år att lista ut". Man ska då tänka på att det är exakt LIKA STOR CHANS att man får rätt lösenord på FÖRSTA försöket som att få det på SISTA försöket. :)

Låt oss säga så här, om det tar ett år att testa igenom alla tänkbara kombinationer, då borde det ta i genomsnitt ett halvår att knäcka ett lösenord. Ibland går det fort. Ibland måste man verkligen testa igenom de flesta kombinationerna.

Nja...jag kan nog inte riktigt hålla med alla föregående talare här :)
Så...

Mig veterligen har man inte ännu hittat 2 strängar som ger samma hash

Om man tänker på hur en hash är uppbyggd så finns det självklart inte oändliga antal kombinationer. Gällande just lösenord som är såpass korta så är sannolikheten väldigt väldigt liten att hashen skulle bli samma. MEN - ju större strängen är (eller hela dokumentet som vid digitala signaturer av dokument tex) så ökar chansen hela tiden.
Alltså - man har hittat massor.

Låt oss säga så här, om det tar ett år att testa igenom alla tänkbara kombinationer, då borde det ta i genomsnitt ett halvår att knäcka ett lösenord

Bara för att lösenord är hashat så innebär det inte att det tar lång tid att knäcka.
En bra "Brute Force" crackar ett 5-siffrigt lösenord på några minuter, 6-siffrigt på några timmar osv.
En bra Dictionary-lookup (finns idag hash-dictionarys innehållande upp till 15 tecken långa hashar) plockar fram det på några milli-sekunder (ja nästan iaf! :)...

Så för att återgå till grundfrågan: "är det någon skillnad ur säkerhetssynpunkt på hashade och "vanliga" lösenord?"
Det beror självklart på.

Oftast är det säkrare med hashade lösenord - men att använda hashning är ingen säkerhet i sig. Det måste göras med förståelse och på rätt sätt. Mina tips är:

1. Krydda alla lösenord med en användarspecifik nyckel
2. Krydda vidare med en system specifik nyckel som ej sparas i webb-mappen
3. Använd SHA512 som hash-algoritm
4. Följ SD3 - Secure By Design, Secure på Deployment och Secure by Default
5. Använd HTTPS

Nästa fråga blir då - vad händer om någon gör en automatiserad inloggnings attack mot dina login-sidor? Då spelar det ingen roll alls hur lösenorden är sparade i databasen - de kommer ju som tidigare nämnt ändå alltid in i klartext...Så beroende på hur känslig din data är:
6. Använd CAPTCHA för att verifiera "riktiga" användare.

Finns det risk för att någon sniffar trafiken mellan server och db?
7. Skicka ej med lösenord i databas-frågor

Osv osv...det finns ingen guide-bok för att bygga säkra applikationer eller sidor...men med kunskap kommer man långt! :)

Kan rekommendera lite läsning på:
http://www.swesecure.com

Där kan ni läsa om både SD3, Hashning, Brute Force, Kryptering, säkerhet, hacking osv!

Har man väl kommit över HASHen så går det ALLTID att knäcka bara frågan om tid:

http://sarcaprj.wayreth.eu.org/

fredrik skrev:

Låt oss säga så här, om det tar ett år att testa igenom alla tänkbara kombinationer, då borde det ta i genomsnitt ett halvår att knäcka ett lösenord

Bara för att lösenord är hashat så innebär det inte att det tar lång tid att knäcka.
En bra "Brute Force" crackar ett 5-siffrigt lösenord på några minuter, 6-siffrigt på några timmar osv.
En bra Dictionary-lookup (finns idag hash-dictionarys innehållande upp till 15 tecken långa hashar) plockar fram det på några milli-sekunder (ja nästan iaf! :)...

Nu brukar man ju vanligtvis välja längre lösenord än 5-6 tecken. Dessutom ska man inte välja lösenord som förekommer i ordlistor. Tiden det tar att brute force-knäcka ett lösenord, växer exponentiellt med lösenordets längd. Därför kan det mycket väl handla om månader och år för ett typiskt lösenord som en säkerhetsmedveten person väljer, även om ett sex tecken långt ord knäcks på några timmar.