webForumDet fria alternativet

Lagra känslig data

Datasäkerhet

9 svar · 644 visningar · startad av JAreMANNEN

Medlem sedan aug. 20002 272 inlägg
Frågan#1

Hej!

Har funderat lite på hur företag lagrar känslig information som används utav deras webplatser.
Om t.ex CDON har en kunddatabas med 450.000 poster som innehåller adressuppgifter, personnummer, kreditkortsuppgifter m.m.
I detta exemplet tycker man att kreditkortsnumret borde vara extra farligt att lagra "öppet" i en databas på en webserver.
Hur gör dom egentligen?
Är informationen krypterad?

Nu gör kanske inte just CDON just såhär men hur fungerar detta generellt? Vilka säkerhetskrav ska uppfyllas etc.?
Behöver man tillstånd från bank för att lagra t.ex kreditkortsinformation?

Anledningen till att jag frågar är att jag i framtiden kanske kommer att ställas mot just detta med förvaring av känsliga uppgifter.

Tack på förhand.

Medlem sedan feb. 200112 078 inlägg
#2

All data som kan ses som 'känslig' bör och brukar väl krypteras i databaser, ja.

Jag tror inte man behöver tillstånd från bankinstanser för att lagra kreditkortsnummer, nej. Det avtalet bör ligga mellan kunden och leverantören (t.ex. Dig och CDON).

Medlem sedan dec. 19995 874 inlägg
#3

Några tips.

Om du skall hasha lösenord är det bra om du saltar lite också eftersom det då blir otroligt mycket svårare att genomföra en dictionary attack mot det. Salt kan exempelvis vara dels användarnamnet/kundnummret plus ett annat salt som du har valt. Detta gör att två personer med samma lösenord inte får samma hash.
Kreditkortsinformation ser jag oftast ingen mening med att spara, och skall du absolut spara för exempelvis kunna spåra tillbaka vilket kort kunden angav föreslår jag att du bara tar med 12 av 16 siffror.
Personuppgifter kan du kryptera symmetriskt exempelvis genom DES3. Sedan kan för ännu mer ökad säkerhet skapa ett hashvärde på viktiga fält som du sedan kan kontrollera. Då ser du om någon har försökt ändra datan i databasen eftersom den lagrade hashen och testhashen kommer att skilja sig åt.

Medlem sedan aug. 20002 272 inlägg
#4

Okej, tack för tipsen!
När det kommer till krypteringen utav data, ska man köpa någon certifierad komponent för det ändamålet?
Måste väl vara en tvåvägskryptering (kryptering/dekryptering)!?
För man vill ju inte använda någon gratisvariant som finns på nätet direkt, känns inte speciellt säkert.
Eller finns det inbyggt nåt vettigt i de olika DBMS?

Medlem sedan dec. 19995 874 inlägg
#5

Nu vet jag inte i vilken miljö du utvecklar. Men i exempelvis .net-ramverket finns inbyggt stöd för både SHA och DES3.
Angående att du behöver dekryptera din kryptering så kan jag säga att det alltid går om det är krypterat. Däremot så finns det något som heter hashvärde. Exempel på funktioner är md5 och sha. Ett hashvärde är helt unik men blir samma varje gång du skickar in ett likadant värde. Det kan exempelvis vara bra att hasha lösenordet men att kryptera kortnummret. Du kommer aldrig att behöva få fram lösenordet igen och det är därför hash är så bra. Hash har även den egenskapen att den alltid har lika många antal tecken oavsett om du skickar in en sträng på 1 tecken eller en sträng på 10 000 tecken. En kryptering däremot växer på. Så ju längre klastrextssträng du har desto längre kryptosträng får du.

Medlem sedan aug. 20002 272 inlägg
#6

Brimba skrev:

Nu vet jag inte i vilken miljö du utvecklar. Men i exempelvis .net-ramverket finns inbyggt stöd för både SHA och DES3.
Angående att du behöver dekryptera din kryptering så kan jag säga att det alltid går om det är krypterat. Däremot så finns det något som heter hashvärde. Exempel på funktioner är md5 och sha. Ett hashvärde är helt unik men blir samma varje gång du skickar in ett likadant värde. Det kan exempelvis vara bra att hasha lösenordet men att kryptera kortnummret. Du kommer aldrig att behöva få fram lösenordet igen och det är därför hash är så bra. Hash har även den egenskapen att den alltid har lika många antal tecken oavsett om du skickar in en sträng på 1 tecken eller en sträng på 10 000 tecken. En kryptering däremot växer på. Så ju längre klastrextssträng du har desto längre kryptosträng får du.

Det där med MD5 och hash har jag använt och vet hur det fungerar. Just nu sitter jag med ASP och utvecklar men du gav mig just ytterligare en anledning till att gå över till .NET :)

Men jag funderar lite över det här med kryptering...

Ponera att jag laddar ner en gratis krypteringskomponent från en sida. Använder den och krypterar kortnumrena när dom lagras i databasen.
Efter en tid så gör någon intrång i min serverburk och plockar över all data från min databas. Kan den personen mha SAMMA komponent som jag krypterat datat med, dekryptera och få ut korrekt data?
Självklart beror det på HUR komponenten i sig är uppbyggd, men detta scenariot vore ju ingen höjdare!

Medlem sedan feb. 200112 078 inlägg
#7

Därför använder man envägskryptering (hashning?) , då man nästan aldrig behöver eller bör återskapa lösenord.

Medlem sedan dec. 19995 874 inlägg
#8

Normalt när man krypterar använder mig sig av en nyckel. Den nyckeln skall endast du känna till. Om däremot personen som fick tag på hela din databas även fick tag på nyckeln så kan han med lätthet dekryptera informationen. Det är därför det är viktigt att förvara nyckeln säkert, samt att göra en säker nyckel. Beroende på krypteringsmetod så ser nycklarna olika ut.
Men några detaljer som kan vara bra att tänka på när du skapar nyckel.

- Ju längre nyckel och meddelande som skall krytperas desto längre tid tar krypteringen.
- Längre nyckel är ett bättre skydd. Ponera exempelvis att din nyckel är "test" och någon utför en brute force mot din nyckel så går det ganska fort att komma fram till ordet "test". Om du däremot har över 7 tecken så börjar det genast att ta lite tid att genomföra en brute force. Sedan för varje tecken extra så blir det svårare och svårare. (tar alltså längre tid)
- Nyckeln skall inte vara ett ord eftersom den då blir en enkel måltavala för dictionary attacks. Använd gärna udda tecken å,ä,ö,¤,!,) osv.
- Du kan gärna använda olika nycklar för olika fält om du har möjlighet till det.
- Det är ju dessutom fullt möjligt - eftersom det är användardata - att en del av nyckeln utgör en annan del av användaren. Exempelvis kundnummer. Då blir det extra svårt att få fram nyckeln eftersom det är olika nycklar för varje användare. (post i databasen).

Men som jag skrev tidigare. Känner man till nyckelns uppbyggnad eller dess innehåll och har datan är det enkelt att dekryptera.

Medlem sedan aug. 20002 272 inlägg
#9

Kanon!
Tack för hjälpen och tipsen grabbar!
Nu har jag lite "kött på benen" om det skulle bli aktuellt :)

Medlem sedan mars 20032 667 inlägg
#10

Glöm nu inte skydda information på väg till och från databasen. :)

255 ms totalt · 4 externa anrop · v20260731065814-full.a51de22e
122 ms — deklarationer (db)
0 ms — hämta statistik (cache)
130 ms — hämta tråd, inlägg och bilagor (db)
121 ms — ändringar (db)