Hur sparar man krypterat till en AccessDB eller MSSQL DB.
Att kryptera t.ex. ett lösenord som sparas i en databas, hur är säkerheten med en sådan lösning.

Säkerheten beror helt på vilken typ av kryptering du använder dig av.
Men det är alltid säkrare att ha lösenordet krypterat i någon form än icke krypterat.

Du kan tex använda dig av MD5CryptoServiceProvider klassen för att kryptera ditt lösenord.

/Fredrik N

Ett synnerligen enkelt men inte helt dumt sätt är att använda HASHCODE.
Det är en envägsvariant för att kryptera. Det ska egentligen användas för att indexera värden men funkar ganska bra eftersom du inte kan krytera dem baklänges.

Vad gör är att du tar HASH-värdet från lösenordssträngen. Koden är ett tal och det talet sparar du i databsen. När någon sedan ska logga in tar du åter HASH-värdet och jämför med det i databasen.

<code>
'Vid inloggning
ValidateLogin(txtPass.text.GetHashCode())
</code>

Annars kan du titta närmre på Namespacet Cryptography i hjälpen.

//Mikael.NET

Jag håller med om vad Mikael skriver om att lagra lösenord icke-reversibelt genom en hash.

Men ibland vill man kunna få tillbaka lösenord eller annan krypterad text. Jag skulle rekommendera användande av Win32 API CryptProtectData och CryptUnprotectData för detta. Fördelen med dessa är att de krypterar baserat på den unika SID som en användare har i Windows, den behövs alltså inte lagras någon krypteringsnyckel på disk som någon annan kan komma åt.

För att köra dessa API i .NET måste man använda DllImport, VB.NET ett exempel finns på http://atomic.quilogy.com/downloads/DataProtector.vb.txt och C# på http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/SecNetHT08.asp.

Hoppas detta hjälper!

/Mattias

Bara en fråga ang crypto32.dll
Den metod du Mattias pratar om använder den SID man är som unik identifierare. Detta går ju bra så länge du kör i ett lokalt nätverk. Men när du kör via Webben kommer det ju alltid vara samma SID. Hur är säkerheten då?

//Johan N

Hej. Jag skulle inte använda GetHashCode() då denna kan variera beroende på Framework version, det är inte säkert du får ut samma retultat då. Sedan ger inte alltid GetHashCode() någon unik identifierare, felera exempel där man överlagrat den så har de returnerat en stängs längd som resultat.

"The behavior of GetHashCode is dependent on its implementation, which might change from one version of the common language runtime to another. A reason why this might happen is to improve the performance of GetHashCode. If you require the behavior of GetHashCode be constant, override the runtime implementation of GetHashCode with an implementation of your own that you know will never change."

Det är därför bäst att använda MD5 eller SHA1 som båda är Hash algoritmer.

PS. Hashning är inte kryptering ;-) Ds.

//Johan N

Förstår inte riktigt frågan, men jag ska försöka svara iaf.

Den SID som används vid krypteringen är SID för aktuell process. Så om en användare kör en webbapp så är det ju fortfarande webbappens användare som kör. Exakt vad som händer vid impersonation vet jag faktiskt inte, eftersom jag normalt inte jobbar med ASP.NET...

I webbfallet så är det ju webbservern den applikation som ska kryptera/avkryptera så om man i detta fall lagrar i databas så kan enbart den användare/maskin som har skrivit in det krypterade lösenordet läsa upp det, vilket är praktiskt om man delar databas med andra applikation och det finns risk för att lösenordet kan läsas av andra.

Fast i fallet ovan tycker jag nog att en säkrare lösning skulle vara att lagra en hash, som nämnts tidigare, eftersom ingen (inkl admin på webbservern) kan komma åt lösenordet.

Det som jag använder CryptProtectData till i mina projekt är att lagra lösenord till andra system, t.ex. lösenord till ett affärssystem eller databas som man måste kommunicera med. Dessa system kan t.ex. köras på Solaris och man måste köra socket-kommunikation med dem.

Problemet man då ställs inför är att lagra ett lösenord på den maskin som ska anropa affärssystemet. Att bara lagra den direkt i registry eller fil känns inte så bra. En "riktig" kryptering med nyckel (a la RSA) kräver ju just en nyckel, och hur ska man då lagra den? Kanske kryptera den :-) Man kan ju inte ha ett smartkort som man stoppar i när man behöver eftersom B2B innebär automatisk integration, inte manuell.

Genom att lagra den krypterat med CryptProtectData så vet jag att den enda som kan komma åt informationen är den användare som har lagrat den. Visst, om burken hackas helt så kan informationen läsas men i så fall så kan man också läsa vilken annan information som helst.

Så om webbserven t.ex. behöver lösenord för kommunikation med databas, om man inte kan integrerad säkerhet, så tycker jag CryptProtectData är så gott som något...

Långt svar, men iaf ett försöt till motivering.

/Mattias

Hej.

Vad jag menade med SID:en var den att alla som surfar in på min applikation där jag inte använder Windows authentication får samma SID. ASP.Net användaren i detta fall. På så vis krypteras all data med just ASP.Net användaren och då blir den inte unik för varje web-applikations användare (då alla är ASP.Net användaren på servern.). Är du med? Har alla ASP.Net användare samma SID kod? (eller vad man nu kallar det?) I så fall skulle crypteringen ske med samma SID på alla servrar som använder ASP.Net och då skulle man ju troligen lätt kunna knäcka den krypterade datan om man kom åt den?

//Johan N

Vad tusan nu då! Jag svarade ju på detta igår och nu är det borta!

Orsaken är säkert att när man skriver på ett svar en längre tid så timar sessionen ut mot pellesoft. När man klickar skicka så ser allt ut att gå bra (förutom att du kommer till startsidan och inte tillbaka till forum) och det skrivna är borta om man inte backar i browsern direkt. Jag skriver ibland i notepad först just pga detta men denna gång gjorde jag inte det...

Ska skriva ett nytt svar när jag orkar, just nu känner jag mig inte inspirerad...

/Mattias

Hej.
Förstår dig.
Har råkat ut för samma sak flera ggr.


//johan N

Nu har jag samlat kraft igen... Men det blir inte lika långt som det var.

"The security identifier (SID) structure is a variable-length structure used to uniquely identify users or groups." Dvs varje användare i en workgroup eller domän har en SID som är helt unik, jmf GUID. Ett exempel på SID är: S-1-5-21-1220945662-854245398-1202660629-1009, detta är SID för mitt lokala ASPNET konto.

Varje maskin som kör ASP.NET har alltså ett ASPNET konto med en unik SID, så när krypteringen sker så är den unik för just den maskinen.

Angående unik information så vill du ju just att den ska krypteras centralt med central nyckel. Om jag vill kryptera info som bara jag vill läsa så skulle inte jag skicka den till en webbserver :-)

För att kolla just din SID (om man nu vill det) finns det kod på http://www.codeproject.com/useritems/GetUserSid.asp.

/Mattias

Hum det har du rätt i. Har inte använt lokala konton så mkt, särkilt inte SIDen.

Du hittar ingen site som har kod exempel på hur man får fram hela SDDL stängen?

//Johan N

Mattias du skrev: "så när krypteringen sker så är den unik för just den maskinen".

Om vi nu bestämmer oss för att köra en applikation i ett Web Farm så borde vi få problem här!?, om vi inte ändrar användaren som ska köra applikationen i IIS eller i web.config till en användare som finns i domänet. Alltså inte den lokala ASPNET användaren. För så länge vi kör med en lokal användare och krypterar med dennes SID som är unikt per användare och per maskin!?

/Fredrik N