Tänkte kryptera nåt sånt här:
<code>
Dim encoding As New UTF8Encoding
Dim hashBytes As Byte() = encoding.GetBytes(nonCryptString & salt)

Dim sha1 As New SHA1CryptoServiceProvider
Dim cryptString = sha1.ComputeHash(hashBytes)
</code>
Där salt är en slumpad sträng på 5-10 bokstäver.

Detta borde väl vara en hyfsat säker one-way kryptering?

Om man ska hasha en sträng, vilket är egentligen säkrast, SHA1 eller MD5? Är det någon skillnad?

Hej,

För det första är inte Hash kryptering, blir lätt att man blandarihop dessa algoritmer. Det MD5 och SHA1 är helt enkelt vanliga hashalgoritmer som inte går att köra reverse på.

Skillnaden mellan SHA1 och MD5 i sin helhet är inte såp stor, det är typ två olika algoritmer. Jag anser nog att ingen är dirket bättre en den andra. Dock använder MD5 en 128-bit digiset och SHA1 en 160-bit digiset. Jag brukar vanligtvis använda SHA1 har för mig den är lite nyare. Men egentligen spelar det ingen större roll vilken du använder.

Vad är det du skall skapa? ett signerat medelande? Eller bara en salt för som du vill använda när du hashar ett lösenord?

Mvh Johan

Ok, då är jag med. Då kör jag med SHA1.

Skapar ett hashat lösenord. Saltet skickas in i funktionen, det finns sen tidigare.

ok :-)

Ibland kan folk använda salt som extra krydda fast det egentligen inte behövs. Det är viktigt att veta varför du sparar ner lösen med en hash. Särskilt då en hash inte kan reversas. Bara bruteforce kan knäcka det hela. En annan viktig bit när man använder salt är ju vad det är för slags salt man använder och hur man sparar ner den. Om du vill får du gärna förklara lite mera så kan jag ev se om din lösning är ok. ? Jag är oxå nyfiken på hur du skapar din salt, du sa att du slumpar fram den?

Mvh Johan

Jag ville inte ha "öppna" lösenord i databasen så jag började kolla runt lite efter artiklar. Som du säger, man behöver inte salta men det ger en extra säkerhet. I det här fallet kanske jag inte behöver det men eftersom jag bygger moduler så kommer jag kanske använda funktionen till annat som kräver lite mer säkerhet.
Vad man då skulle använda som salt var ju lite olika. T.ex. användarens namn, strängvariabel i en config fil, strängvariabel i en databastabell för inställning, osv.
En artikel jag fastnade för var http://www.ddj.com/documents/s=9024/ddj0402j/0402j.htm?temp=OwJGtx1knC.
Saltet skapas i en funktion
<code>
Public Shared Function CreateSalt(ByVal size As Integer) As String
Dim rng As RNGCryptoServiceProvider = New RNGCryptoServiceProvider
Dim buff As Byte() = New Byte(size) {}
rng.GetBytes(buff)
Return Convert.ToBase64String(buff)
End Function
</code>
och det blir då olika för varje användare. Saltet lagras i databasen tillsammans med användaren. Nu blir ju det "öppet" istället för lösenordet, men men.

När jag skapar en ny användare kör jag CreateSalt och sedan hashfunktionen på lösenordet med det skapade saltet och så lagrar jag användaren i databasen.

Om det är en bra lösning vet jag inte så jag tar gärna emot tips och andra lösningar. Men jag tyckte att artikeln var bra.

Hej, kunde inte läsa artikeln. Måste registrera mig.

Men sättet du tar fram Salt är av bästa sort. Det är en mycket säker Randomhanterare. Många använder vanliga Random vilket inte alls är direkt bra då den är förutsägbar. Går inte in i mer detalj varför. Kanske stod i den artiklen du läste?

Hur var det du sparade din salt? hängde inte riktigt med. la du den ihop med lösen? Många skriver hanteringar på detta sätt.

Skapa hash av lösen och salt. Lägg salt i slutat av Lösen.

HASHSALT

sedan plockar de ut SALT och kollar om HASH == Hash(lösen+sort)
Jag själv föredrar en egen kolumn där jag lägger min salt i Base64 sträng och en för hashat lösen (där jag använde rsalten i min hashning.) gör denna Hash av lösen till en Base64 sträng oich sparar ner.

Sedan vid verifiering plockar jag Lösen ur DB och min salt kör en hash på inputLösen från användare tillsammans med min Salt och Jämför dessa.
Detta kändes bättre på något sätt. Fördelen är att jag kan välja vilken Hash algoritm jag vill ha. I fallet ovan så skulle strängen bli olika lång berorende på hash algoritm. Och på så vis måste rutinen för att plocka ut SALTdaten bli mer komplex.

Mvh Johan

Jag lagrar saltet i användartabellen.
När jag skapar användaren så gör jag följande:
1. salt skapas med ovanstående randomfunktion
2. jag hashar lösen+salt
3. jag lagrar det hashade lösen+salt i en binary kolumn i användartabellen
4. jag lagrar saltet i en nchar kolumn (kanske ska välja nåt annat)

När jag loggar in:
1. Skapar en ny UserClass med hjälp av användarnamn/email
2. Om en användare med angivet användarnamn/email finns ->
3. Eftersom användaren fanns har jag nu användarens salt i min UserClass. Jag hashar angivet lösen+usersalt
4. Jag jämför det hashade lösen+salt från databasen med det hashade testlösen+usersalt som jag precis hashat.
5. Om det är lika så är det en korrekt inloggning.

Låter som min rutin, Rätt vanlig, går nog inte göra på ett enklare sätt :-)
Dock är det ju olika hur man vill spara datan. Jag skulle nog valt nvarchar på både Lösen och din salt kolumn. Och där använda Base64. Men det är nog mer en smaksak. Tror det är vanligast att göra så. En annan anledning att jag valde detta sätt är för att mina membership klasser är transparanta så jag kan välja annan datakälla utan problem. Lättare att hanskas med strängar som hanteras på samma sätt då.

Mvh Johan

Saltet är Base64, det ser du i randomfunktionen ovan.

Ett problem jag har dock är själva jämförelsen när jag ska logga in.

cryptPassword är en Byte()
user.password är en Byte()
Om jag gör cryptPassword.Equals(user.password) så får jag false.
Men om jag skriver ut varje byte i båda för kontroll så är de exakt lika.
Något tips på hur man ska jämföra två Byte()?

Det är oxå ett skäl till varför jag gör det till en Base64 sträng..

Jag plockar min Salt gör om Base64 till Bytes.
Jag tar mitt lösen (det jag får in som en sträng) gör om den till bytes,
tar dessa bytes + salt bytes hashar kör en Base64 sträng på denna bytesdata och jämför om den är samma som den Base64 som mitt lösen i DB är.

Alltså:

1... Tar emot Lösen som sträng från ex ex TextBox.
2... Gör om detta lösen till en Byte data.
3... Hämtar Salt + Lösen från DB baserat på Användarnamn som jag oxå har som paramter.
3... Gör om min Salt (som är en Base64 i Dbn) till Bytes.
4... Tar mitt inputlösen som nu är byte data, hashar det med den Byte salt jag hämtat.
5... Gör mitt nya hashade lösen till en Base64 kollar om den är samma som mitt Base64 lösen jag plockade från Dbn:

typ:
if(dbPassword.Equal(inputHashedPassword)

Mvh Johan

Ok, men om jag gör om mitt hashade lösen+salt byte() från databasen till Base64 och mitt nyhashade loginlösen+usersalt till Base64 så är jag på samma ställe som du?

Ja det tror jag. Låter så i alla fall.

Mvh Johan

Yes, jämförelsen funka galant när jag gjorde om båda Byte() till Base64String.

Då kan jag sätta en bock i protokollet och gå vidare till nästa modul.

Tack för hjälpen.

vad är skillnaden mellan SHA1 och SHA512 då?

btw, intressant läsning.

cya,
/PatrikB

Det är oxå Digit bits.

Mvh Johan

Gällande denna diskussion och om hashade lösenord med salt kommer följande fundering:

Vad är det egentligen "saltet" skyddar oss mot här? Jo, varken är det ju mot Brute/Dict-attacker utan snarare mot "onda" databasadministratörer, webbhotellspersonal eller attackerare som fått tag på tabellen med lösenord. Problemet som jag ser det om man nu skapar sin lösenordshash med ett bara ett salt/användare är att en obehörig enkelt kan utföra exempelvis dict-attacker (och möjligen till viss del Brutes) mot lösenorden då saltet är synligt.

Istället skulle jag föredra en lösning där man förutom ett salt/användare även använder sig av ett "system"-salt, vilket då bidrar till dels unika hashlösenord/användare samt skydd mot "återskapning" av lösenordshashat om någon kommer åt databasen.

SHA1 består förresten av 160 bitar och SHA512 av 512.

Fredrik,

På vilket sätt anser du att Salten är synlig? I databasen om man lägger det i ett eget fält?
Om du tar ett systemunikt värde som en extra salt lägger du ju bara en extra krydda på som du dessutom kan komma åt om du redan kan komma åt databasens innehåll. För då har du troligen så god access att du kan få fram systemets värde.

"Vad är det egentligen "saltet" skyddar oss mot här? Jo, varken är det ju mot Brute/Dict-attacker utan snarare mot "onda" databasadministratörer,"

Nja. inte direkt. Där har du en aning fel med en liten smula sanning.
Om du exempelvis inte saltar ett lösen kan en hashning av två olika ord ge exakt samma resultat och på så vis underlätta en Brute då du helt plötsligt kan ha två helt olika tecken för ett lösenord.

I teorin. (Obs! exemplet är inte relevant.)
A med MD5 kanske blir A34ldjd3
ÖB med MD5 kan också bli A34ldjd3. Det betyder att Brute attack enklare kan fungera då du kan komma in med A samt ÖB även om A skulle vart det rätta lösenorder.
En administratör kan inte få fram A genom A34ldjd3 och inte heller ÖB utan att göra en Brute attack. Då du inte kan köra reverse på Hash. Så det spelar ingen roll om Saltet skulle vara synligt.

Salten skyddar dig alltså genom att göra varje lösen unikt. Om Nisse har lösen A och Olle samma kommer inte den elaka administratören se samma Hasresultat för Nisse och Olle på så vis skyddar du även här de två användarna från att visa den elaka administratören eller hackern vilka som angett samma lösen.

Admin konto kan ha Ader45 och 30 andra användare kanske oxå har Ader45, kan man då logga in med en av dessa 30 vet hackern eller den elaka administratören även ett lösen som fungerar för Admin.
Med salt skulle Admin och de andra 30 få unika resultat och på så vis skydda en sådan avläsning.
Men Observera! Du måste göra Brute mot de Hashvärden du kan se för att få fram ett lösen.
Varken systemunikt värde samt slumpad Salt ger dig ett bra skydd, det som ger dig ett verkligt bra skydd är att använda kluriga lösen med andra tecken än A-Z och 0-9. Dessa lösen knackar du bara under någon enstakad minut eller to m sekunder.

Mvh Johan

"På vilket sätt anser du att Salten är synlig? "
Saltet är ju synligt då det ligger i "klartext" (base64) i databasen.

Visst kan det vara så att attackeraren även har tillgång till systemsaltet, men lite av grejen är att denne inte VET att ett systemsalt har använts. En kolumn i tabellen däremot är ganska enkel att lista ut (särkskilt om den är namngiven typ "userHashSalt"). Det kan tom vara så att ytterligare en variabel ska användas som salt (längden på användarnamn eller annat "hemligt").

"En administratör kan inte få fram A genom A34ldjd3 och inte heller ÖB utan att göra en Brute attack."
Nej, men just en Brute (möjligen en en dict.attack) är det den metod som kan återskapa värdet.

"...kan en hashning av två olika ord ge exakt samma resultat ..."
MD5 kan förvisso generera samma hash flera gånger, men det gäller bara då längden > 16....och även då är chansen otroligt minimal. Läste nånstans:
"In fact, if you started a brute force search now for two strings of similar length that hash to same value, you are not likely to find them until sometime after the Sun runs out of fuel."

Jaja, vet inte hur mycket sanning det ligger i det...men ja, en viss liten chans är det kanske. :)

Ja, att salt alltid ska användas vid hashning är ju helt klart. Alltså att se till så att varje användare får ett unikt hash (även då skyddar vi oss mot den onde administratören), det är ju ett steg. Nästa steg som jag jag ville poängtera är att ytterligare salt ytterligare minimerar chansen för att en utomstående ska återskapa hashen då de har saltet. Med extra salt som inte är "synlig" skulle det antagligen kräva flera års datorkraft för att hitta rätt kombination. Med bara ett salt som dessutom är synligt går det avsevärt mycket fortare.

Håller med dig fullt om att "kluriga" lösenord är att rekommendera för ökat skydd.

mvh Fredrik

Fredrik.

Du vet väl att öppen kod är säkrare än låst kod ;-) där i ser du hur du får tag i system salten, Och om du har låst kod kan du via IL readers eller Dissassebly apps ändå återskapa hur du gör så skyddet varar inte länge. Även extra krydda ökar tiden att logga in. Vad händer när du behöver bygga om hårdvaran då sysemunika IDs oftast härstammar från något identifierbart vid en installation? Då kommer inte ett enda lösenord att fungera.

Jo en sak till, om man är elak admin så spelar ju lösen ingen roll om han/hon vill sabba något. Bara för personen att börja pula med datan i databasen rakt av.

Mvh Johan

Jo, det är klart, riktigt skyddad blir man väl aldrig...IL-läsare och dyligt finns ju klart, vilket som sagt skulle avslöja hash-förfarandet...

...håller med om att ett dolt systemlösenord kan medföra vissa problem med förstås...

Slutsatsen är väl att man får hoppas att man slipper "onda" db-admins! :)

Antar sen att det ligger i utvecklarens händer att välja sitt förfarande, själv väljer jag systemhash i kombination med användare-hash, det försvårar i alla fall lite för den som är ute efter lösenord :)

Intressant diskussion i alla fall!