Hej!

Håller på att kämpa mig igenom exempel och få förståelse för lösenordssäkerhet.
Lyckats med att spara hashade lösenord och authentisera användare i webconfig och databas.

Har sökt en massa på nätet men tappat tråden. Sökningen gav dock vid handen (som jag uppfattade det) att det är möjligt att med både salt och hash få tillbaka lösenordet i klartext.
... När jag hittade det hade jag inte kommit så långt som till det jag klarat av att förstå nu, så jag slarvade ju förstås bort den länken, i tron att den skulle vara lätt att hitta igen.

Undrar om någon kan peka på en länk, ge exempelkod ed.

Gärna också + och - för att använda en sådan metod (om det nu går, dvs. att jag inte fått det om bakfoten).

/Ann

Hej,

Det är egentligen rätt enklet.

Salt är ju en krydda... man slänger på den för att ens hash skall bli olika trotts att man anger samma lösen.

A blir exempelvis alltid 34E (OBS! skoj kod... detta är inte rätt HASHdata för A)

Så om jag anger A och du anger A så får vi samma hash.

Nackdelen med detta är följande. Om någon får tag i min databas och alla värden, kan han/hon
lätt hitta användare som har samma lösenord och på så sätt lättare försöka komma fram till dessa.
Sedan kan det oxå vara så (i väldigt få fall) att två olika lösen kan ge samma hash...

Pseu...

KattMat = 3456
HundKiss = 3456

på så vis kan en bruteforce attack komma in trotts fel lösen för hashen är detsamma.
(Bruteforce är när man testar ett värde efter ett annat tills man nåt en träff. kan ta lång tid.)

Vad en salt nu kan göra är att se till så inga lösen blir samma hash.

Kattmat = 3456 + Salt = 98765
HundKiss = 3456 + Salt = 034392

Så ett bruteforce försök blir lite klurigare då du verkligen måste ha fram rätt kod.

För att detta skall fungera måste varje Salt för varje person vara unik.
Det finns lite varianter hur man skall lagra detta.

Somliga gör en salt på x antal tecken och lägger den efter det hadhade lösen och pga detta vet man att x antal tecken är ens salt restan lösenhashed som är saltad.

Ex på en sådan rutin.
Kolla lösen:

1... skickar in KattMat
2... Kör en Hash på denna får ex. 123456
3... Plockar lösen från databasen
4... Plockar ut min Salt som jag la sist på 256 tecken.
5... Tar min Hash som gjordes i punkt 2 och kör den med min Salt
6... Jag tar detta värde o kollar om det är samma som i dbn (OBS! removar salten från DBns lösen.

för att skapa lösen. Gör jag typ samma.

1... Tar emot KattMat
2... Kör en Hash
3... Skapar en Salt
4... Kör salt med Hash
5... Lägger Salt efter Hash
6... Sparar i databasen

En anna variant är att spara Salten i en kolumn och Hahasde lösen i en annan. (Så gör jag nu, såg att även ASP .net 2.0 kör på detta sätt med sina Membership saker.)

Liten kodsnutt jag skrev för ett bra tagsedan. gör säkerligen göra snyggare :-)

<code>
public static string ComputeHash(string plainText,string algorithm,byte[] saltBytes)
{
//Create one hashAlgoritm object
HashAlgorithm hashAlgorithm = HashAlgorithm.Create(algorithm);

//Get bytes from string
byte[] plainTextBytes = Encoding.ASCII.GetBytes(plainText);

//create the byte array with data to hash
byte[] bytesToCompute = new byte[plainTextBytes.Length + saltBytes.Length];

//fill the bytesToCompute with plaintext byte data
for(int i=0;i<plainTextBytes.Length;i++)
bytesToCompute[i] = plainTextBytes[i];

//fill the bytesToCompute with salt byte data
for (int i=0; i < saltBytes.Length; i++)
bytesToCompute[plainTextBytes.Length + i] = saltBytes[i];

//Cimpute hash.
byte[] hashBytes = hashAlgorithm.ComputeHash(bytesToCompute);

return(Convert.ToBase64String(hashBytes));
}
</code>

Vad jag gör är att jag skapar mitt lösen med en Salt.

Hoppas jag fick till en bra förklaring. sitter o halvsover här nu... Skall hoppa i natten...
en länk på ett annat ex har du här.

http://www.obviex.com/samples/hash.aspx

GOtt nytt!!!

Mvh Johan

Jo... Nackdel med Hash samt Hash med Salt är att du itne kan återskapa lösenordet om användaren glömt sitt... Men av säkerhetsskäl genererar jag alltid ett nytt och sätter en flagga i dbn att användaren måste byta lösen vid login.

Mvh Johan

Jo, Johan tack! Mina smilgropar fick en workout.

Men....
1. Läser inte C-kod så bra.
2. Kunde inte hitta var jag fick tillbaka lösen i klartext.


Alternativ mindre trevligt. Jag är en komplett idiot som tror att det ska vara möjligt?

Trodde att salt var krypteringsnyckeln på någe sätt.


En får leta vidare. Tar saker till mig pö om pö så detta blir antingen pö eller pö.

Men förklaringen till varför man använder salt kunde jag ta till mig, den var bra.

Gott slut och gott nytt på dig!

/Ann

********************************************
Edit: så ska man använd F5 mellan varven. Okej.
Får leta efter annan lösning att skicka iväg data som jag inte kan ändra.
Men för de ändamål där det är relevant så är det bra med inputen på flaggan att byta lösen, den idén har jag greppat.

Hej Ann.

En hash är en envägsfunktion, det går inte att återskapa ursprungsdata med en hash vilket är ett syfte med att använda den i lösenordssammanhang. Om din lösenordsdatabas kommer på villovägar står inte lösenorden i klartext och kan inte heller återskapas. Detta gör det svårare för en angripare att missbruka den stulna informationen (om vi antar att användare använder samma lösenord på flera ställen, vilket de gör :-)

En hash är därtill uppbyggd så att en liten ändring av ursprungsdata skall ge en stor förändring av det hashade värdet. Detta gör att om jag prövar mig fram, men inte hittar rätt skall jag inte med små ändringar av det lösenord jag provar kunna skapa den hash jag söker. Detta används även vid signering av dokument (public key-kryptering/signering).

Eftersom flera lösenord (motsvarande) kan ge samma hash används salt för att variera hashen. Detta gör att om du och jag väljer samma lösenord så kommer de i "krypterad" (läs hashad) form (och saltade) att vara olika och vi kan därför inte avgöra om de är samma eller ej.

Hoppas det rätar ut ett par frågetecken.

Alex

<b>på så vis kan en bruteforce attack komma in trotts fel lösen för hashen är detsamma.
(Bruteforce är när man testar ett värde efter ett annat tills man nåt en träff. kan ta lång tid.)

Vad en salt nu kan göra är att se till så inga lösen blir samma hash.

Kattmat = 3456 + Salt = 98765
HundKiss = 3456 + Salt = 034392

Så ett bruteforce försök blir lite klurigare då du verkligen måste ha fram rätt kod. </b>

Nja, salt förhindrar väl inte problemet med att två olika lösenord kan få samma hash? Däremot förhindrar det att man ser vilka lösenord som är samma som du skrev.

/Johan

"Nja, salt förhindrar väl inte problemet med att två olika lösenord kan få samma hash? "

Jo det är precis vad det även förhindrar.

Kanske inte förtydligade att Salten skall vara unik för varje lösen.

Mvh Johan

Ok, jag har säkert missat något viktigt i resonemanget med salt. Jag skriver ner hur jag har förstått det hela så kanske du kan peka på min miss :) (alltid kul att läsa sig hur saker går till...)

I det här fallet med lösenordsverifiering så sparar man något unikt för varje lösenord (kallat salt), som exempel XYZ. Denna salt läggs sedan till på slutet (till exempel) på lösenordet innan det hashas. Eftersom två olika lösenord (teoretiskt) kan få samma hash borde väl två saltade lösenord också kunna få det.

Eftersom
Hash("KattMat") == Hash("HundKiss")

skulle väl även
Hash("KattMatXYZ") == Hash("HundKissXYZ")

Nu är ju inte risken överdrivet stor med bra hash-funktioner...

Fast det kanske inte var alls detta du menade?

/Johan

Johan D,

Njao.... Den chansen du pratar om är jätteliten. Dock är chansen med två rena hash oxå ganska liten men den minimeras kraftigare om man har med en salt. Sedan så minskar risken för bruteforce om man bara får tag i lösen och inte dess salt.

I ditt exempel använder du samma salt i båda fallen, men man skall helst ha en unik salt/lösen.
Så XYZ kanske är för ena men andra har QWE som Salt och en tredje RTE etc...

Jag lägger alltid min Salt löst men använder den när jag skapar ett lösen eller ser om ett skrivet lösen är rätt.

1... Hämtar hashatlösen (där salten ingick i hashningen)
2...Plockar rentextlösen från textbox, kör hash på den med Salt som är unikt satt för användaren.
3... kör hash på rentext lösen och med salten, sedan ser jag om de är lika.

Även om du skulle få samma hashvänrde i databasen med Salten så har du en unik salt/lösen och på så vis kan du inte få ut samma svar... hum. hur skall jag förklara det bättre. testar så här.

Johan har KattMat + unik Salt (abc) = 123456
Mats har HundMat + unik Salt (cde) = 123456

om jag nu loggar in med Mats o skriver KattMat så blir inte dessa 123456 med Mats unika salt.
om jag loggar in med Johan o skriver HundMat med Johnas unika salt så blir inte svaret 123456.
Ex med salt.
KattMat + cde = 7890129
HunMat + abc = 2453643

Men om jag inte hade någon salt, så skulle Johan kunna komma in med både HundMat och KattMat för de gav samma hash. Är du med?

Ex utan salt.
Johan har KattMat = 123456
Mats har HundMat = 123456

Mvh Johan

Att salten skyddar mot attacker där angriparen har tillgång till databasen köper jag helt, det var inte det jag "protesterade" mot. Att det däremot skyddar mot att två olika ord kan få samma hash, vilket jag tolkade ditt svar som, är jag fortfarande skeptisk till.

Det borde vara ungefär lika stor sannolikhet att "RättLösen" har samma hash som "FelLösen" som att "RättLösenMedSalt" har samma som "FelLösenMedSammaSalt". Sannolikheten är så liten med en bra hash-funktion att den är försumbar i sammanhanget, men den borde vara lika stor i båda fallen...

/Johan

"Det borde vara ungefär lika stor sannolikhet att "RättLösen" har samma hash som "FelLösen" som att "RättLösenMedSalt" har samma som "FelLösenMedSammaSalt"."

Men det är just detta som inte går att återskapa. Det gör inget om rättlösemedsalt har smama resultat som fellösenmedsalt för du måste ha samma salt då. Och då Salt är unik / lösen blir inte fallet så.

Även om det i DB står 123456 på 100 st så kommer alla dessa 100 alltid ha en unik egen Salt vilket gör att du måste ha rätt salt och rätt lösen för att få fram 123456.

Det är algoritmen med salen i sig som ser till detta inte hur värdet ser ut på papper.

Mvh Johan

<b>"Det borde vara ungefär lika stor sannolikhet att "RättLösen" har samma hash som "FelLösen" som att "RättLösenMedSalt" har samma som "FelLösenMedSammaSalt"."

Men det är just detta som inte går att återskapa. Det gör inget om rättlösemedsalt har smama resultat som fellösenmedsalt för du måste ha samma salt då. Och då Salt är unik / lösen blir inte fallet så.</b>


Det måste väl "gå att återskapa"? Salt ju unik för användaren, inte för det av användaren inmatade lösenordet? Säg att olle ska logga in, han har lösenordet FulFisk och i exemplat med salt har han Peppar som salt.

Utan salt:
Hash("FulFisk") = 1234
Nu finns det en liten, liten risk att Hash("FinFågel") = 1234, om så är fallet kan olle logga in med lösenordet FulFisk OCH FinFågel.

Med salt:
Hash("FulFiskPeppar") = 3456
Nu finns det en liten risk (rimligtvis samma sannolikhet som i förra exemplet, eller den ökade på den hashade texten kanske minskar sannolikheten?) att Hash("FetKänguruPeppar") = 3456. Olle kan alltså logga in med både FulFisk och FetKänguru.

Alltså ingen skillnad med och utan salt för just detta problemet, eller? Salt löser ju annars som du skriver en del andra problem.

/Johan

Johan,

Även om LösenA + SaltA ger <b>samma</b> hash som LösenB + SaltB så betyder det inte att de båda lösenorden med de omvända saltvärdena, dvs LösenA + SaltB samt LösenB + SaltA ger samma hash - vare sig mot varandra eller mot de första paren Lösen + Salt.

Visst kan det alltid förekomma en minimal chans att du skulle få ut rätt svar ändå, men genom att lägga till ett salt så minska du den chansen väldigt mycket mer.

"Alltså ingen skillnad med och utan salt för just detta problemet, eller? Salt löser ju annars som du skriver en del andra problem. "

Precis som Andreas säger så finns ju chansen, men den är såååå extremt liten att man troligen inte ens kan säga hur liten den är... 1 på 200000000000000000000000000000000000 kanske? ;-)

Chansen är lite större utan salt, men ändå rätt liten. MS hade en säkerhetsbrist i deras hantering då de inte använde eller använder hash, tror det var i windows? har jag fel nu? någon som vet? Vet att *nix folk tjatade om hur kass det var att de uteslöt salt etc...

Mvh Johan

<b>Precis som Andreas säger så finns ju chansen, men den är såååå extremt liten att man troligen inte ens kan säga hur liten den är... 1 på 200000000000000000000000000000000000 kanske? ;-)</b>

Ja, det håller jag med om. Problemet är bara teoretiskt, i praktiken har det ingen betydelse...

<b>Chansen är lite större utan salt</b>

Det är just detta jag inte förstår. När en och samma person försöker logga in är det ju alltid samma salt som läggs till lösenordet innan det hashas. För att sannolikheten att 2 olika angivna lösenord (av samma person som försöker logga in) ska få samma hash ska minska vid användning av salt innebär det ju att enbart den ökade längden av den hashade strängen har betydelse då det alltid är samma salt som läggs till. OM det är så skulle man kunna åstadkomma samma säkerhetsförbättring genom att alltid lägga till en sträng som alltid är samma vid hashning av alla lösenord (dock är det ju betydligt sämre än salt i många andra fall), eller ännu bättre, lägga till salt + ytterliggare en sträng som alltid är samma för ALLA användare och ALLA lösenord.

Äh, jag kan inte förklara, det är jag medveten om. Så om ingen förstår vad jag menar nu så ger jag upp :) Detta är ju trotts allt inget stort problem.

/Johan

Johan D,

Problemet med hash är att resultatet ger olika längder, en lång sträng som hahsas kan få kortare hash sträng en om strängne var kort.

Så vad Sal minskar är.

chansen att se om folk har samma lösen.
chansen att köra bruteforce på hittade lösen (måste känna till salten oxå)
chansen att få hash med samma värde även om datan är olika.

Salt är som sagt en extra krydda, men en extra krydda har inte alltid gjort ny maträtt.
Dock lite variation...

Mvh Johan

Förutom att använda ett unikt salt / lösenord förespråkar jag även att ett system-salt ska användas. Den slutliga hashen består då alltså av:
"Systemsalt" + "Användarens lösenord" + "Unikt salt"

Om man ENBART kör med ett salt (unikt) så kan följande problem uppstå:
Då det unika saltet måste sparas i databasen tillsammans med det hashade lösenordet gör detta att om någon kommer över databasen kan de utföra en Brute Force då de redan har saltet.

Om man nu även använder ett system-salt som sparas helt separat ifrån databasen så minskas i alla fall chansen att även detta värde ska hittas och därmed användas i en BF.

Om du är intresserad av fler artiklar i ämnet så ta gärna en titt på:
http://www.swesecure.com där artiklar och kodexempel på både hash-funktioner och kryptering finns.

Ni pratar om att chansen för att få samma hashvärde (skapat av två olika lösenord) minskar när man lägger till salt. Det kan faktiskt vara fel. Om vi exempelvis tar MD5 som exempel så kommer den alltid att vara unikt konsistent upp till 16 tecken. Eftersom ni pratar om lösenord och de flesta användare inte har lösenord på längre än 16 tecken så kommer därmed hashen alltid att vara unik och risken för dubbletter i databasen är alltså lika med noll. Däremot överväger naturligtvis användandet av system- och användarsalt vida dess möjliga nackdelar. Jag ville bara säga att chansen för hashdubbletter inte minskar på grund av ett salt, däremot minskar betydelsen för den som kommer över det hashade värdet.

<b>Jag ville bara säga att chansen för hashdubbletter inte minskar på grund av ett salt</b>

Precis vad jag försökte säga, fast jag var nog inte så bra på att förklara... :)

/Johan

Patrik... o Johan

"Jag ville bara säga att chansen för hashdubbletter inte minskar på grund av ett salt "

Precis ingen som sagt, men en sådan dublett är helt oanvändbar och säger inte så mkt. Då man måste nyttja salten till det hela. Det är ju inte så att Katt och häst går att logga in med bara för att dessa två fick samma hash fast med olika salt. För Katt + salt != samma som häst + kattens salt.

System Salt kan man nyttja, ex Asp .net användarens unika SID. etc... fast man måste vara lite förisktig att binda sitt system för mkt med ett os gör oxå att man har en hård kopplad arkitektur mot systemet och det skall man ju undvika om det går.

"...vara unikt konsistent upp till 16 tecken. Eftersom ni pratar om lösenord och de flesta användare inte har lösenord på längre än 16 tecken så kommer därmed hashen alltid att vara unik..."

Menar du att MD5 alltids ger 16 tecken? nja... den kan ju ge 5 tecken trotts att man har 16 tecken som lösen. Eller var det kanske SHA1 som gjorde så... hum... nu blev jag osäker... Men i vilket fall spelar detta ingen roll.

Mvh Johan

<b>"Jag ville bara säga att chansen för hashdubbletter inte minskar på grund av ett salt "

Precis ingen som sagt</b>

Då är vi överens alltså, för det var det jag tolkat det du skrivet som och det jag har invändningar emot :)

<b>Det är ju inte så att Katt och häst går att logga in med bara för att dessa två fick samma hash fast med olika salt.</b>

Nej, men om Katt och häst får samma hash med samma salt (vilket borde ha lika stor sannolikhet, väldigt liten, men ändå) kan användaren som har Katt som lösenord även logga in med häst. Detta kommer inträffa inträffa för olika lösenord för olika användare (eftersom de har olika salt). Om det är som Patrik säger att MD5 är unikt upp till 16 tecken kommer det aldrig inträffa i praktiken dock...

/Johan

Johan D,

Jepp, det har ingen nekat heller, men chansen är ottroligt liten :) nästan omöjlig...
Man kan ju om man vill även köra DES eller kanske RSA om man är lite orolig, fast ibland är för
mkt säkerhet ochså en överdriven overhead. Då det inte alltid ger bättre skydd för det.

I .Net 2.0 kommer man ha olka varianter för lösenordshantering i Membership bitarna.
Du kan välja krypterat lösen, hahsat lösen, med eller utan salt etc...

Mvh Johan

Hej! Nej jag menar inte att längden på resultatet från MD5-funktionen varierar Den producerar alltid 32 (hex) tecken långa resultat. Den är alltså alltid konstant. Däremot är det så att MD5 jobbar med grupper. Varje "grupp" består av 128 bitar (16 tecken). Om vi matar in en sträng som är exempelvis 20 tecken så kommer den göra två grupper. Den första gruppen består av de 16 tecken vi har och den andra består också av 16 tecken, men där 12 är utfyllnadstecken. När längden blir längre än 16 tecken så kan MD5 algoritmen generera dubbletter, men om det man matar in är 16 tecken eller kortare så vet vi att utmatningen (16 tecken, eller 32 tecken (hex)) alltid är unikt.

Länk till RFCn för MD5: http://www.faqs.org/rfcs/rfc1321.html