Krypteringsmissar – när ditt skydd bara ser säkert ut

När kryptering används på fel sätt

Vi använder kryptering för att skydda känsliga data: lösenord, personnummer, betalningsinformation, tokens, och mycket mer. Tanken är att även om någon skulle komma åt vår databas, så ska informationen vara oläsbar utan rätt nycklar.

Problemet är bara att det ofta görs på fel sätt. Det kan handla om att data aldrig krypteras till att börja med. Eller att den krypteras med en gammal algoritm, en hårdkodad nyckel, eller utan någon riktig nyckelhantering alls. I vissa fall blandar utvecklare ihop vad som är transportskydd (till exempel TLS) med skydd av data i vila, och missar att det är två olika saker.

Ett exempel på hur det kan gå fel är från det uppmärksammade fallet med den finska psykoterapikliniken Vastaamo.

Ett konkret exempel: Vastaamo-läckan

När en angripare år 2020 tog sig in i Vastaamos system kunde han enkelt komma åt tusentals patientjournaler. Varför? Jo, informationen var lagrad i klartext, det vill säga helt okrypterad. Det fanns ingen säkerhetsmekanism som skyddade själva innehållet, trots att det rörde sig om känsliga psykoterapidata.

Angriparen krävde sedan både företaget och patienterna på pengar för att inte publicera informationen. Totalt drabbades över 30 000 personer, och konsekvenserna blev katastrofala: böter, förlorat förtroende, och till slut konkurs. Hade denna data varit ordentligt krypterad, med korrekt nyckelhantering, hade skadan kunnat begränsas drastiskt.

Hur allvarligt kan det bli?

Krypteringsfel är kanske inte lika dramatiska som ett dataintrång i sig, men de gör intrånget långt farligare. När känslig information lagras utan kryptering eller med svaga metoder, blir konsekvenserna direkta om någon får tag på den.

Ett läckt lösenordshash skyddat med bcrypt är ett problem. Ett lösenord lagrat i klartext är en katastrof. Och det gäller inte bara lösenord, det gäller alla typer av känsliga data.

Varför händer det här?

Det finns flera vanliga orsaker till kryptografiska fel. En är att utvecklare förlitar sig på att HTTPS (TLS) räcker och därför aldrig krypterar data i databasen. En annan är att man använder osäkra eller föråldrade algoritmer som MD5 eller SHA-1. De går att knäcka med moderna verktyg.

Ett annat vanligt problem är nyckelhanteringen. Nycklar som ligger i klartext i koden, checkas in i Git-repos eller delas i chattkanaler är inte säkra, de brukar ofta användas mot oss. Och utan tydlig ansvarsfördelning, loggning eller rotationsstrategier blir det omöjligt att veta om nycklar komprometterats.

Hur skyddar vi oss?

Här är några konkreta åtgärder för att undvika denna typ av sårbarhet:

1. Identifiera känsliga data

Börja med att kartlägga vilken typ av data som faktiskt är skyddsvärd, till exempel personuppgifter, autentiseringsuppgifter, betalinformation eller API-nycklar. Många system hanterar känslig information utan att det är tydligt dokumenterat eller förstått internt.

Genom att förstå var känsliga data finns och hur den rör sig i systemet kan man bättre avgöra var skydd behövs.

2. Använd moderna och beprövade algoritmer

Välj algoritmer som är etablerade och fortfarande betraktas som säkra, såsom AES-256 för symmetrisk kryptering eller RSA-2048 för asymmetrisk. Undvik att använda utdaterade algoritmer som MD5 eller SHA-1, även om de fortfarande finns tillgängliga i vissa bibliotek. Använd också kryptobibliotek som hanterar låg-nivådetaljer korrekt. Försök aldrig skriva ditt eget bibliotek för kryptologi.

3. Kryptera data i vila och under överföring

Kryptering bör inte bara tillämpas när data transporteras över nätverk (till exempel med HTTPS), utan också när den lagras i databaser, backupfiler eller loggar. Detta skyddar information även om en angripare får fysisk tillgång till lagringsmediet. Se till att krypteringen sker med starka nycklar och korrekt konfiguration. Kryptering utan nyckelhantering är inte mycket bättre än ingen kryptering alls.

4. Hantera nycklar korrekt

Kryptonycklar bör behandlas som minst lika känsliga som den data de skyddar. De ska aldrig ligga hårdkodade i källkod, lagras i versionshantering eller ligga öppet på servern. Använd i stället dedikerade nyckelhanterare som AWS KMS, HashiCorp Vault eller Azure Key Vault, där du också får loggning, åtkomstkontroll och nyckelrotation på köpet.

5. Verifiera och testa implementationer

Även om du använder rätt bibliotek och algoritmer, kan fel uppstå vid implementationen, till exempel genom att återanvända IV:er, använda ECB-läge eller glömma att verifiera signaturer. Använd säkerhetsverktyg som automatiskt kan analysera kodbasen efter vanliga kryptografiska misstag. Komplettera med manuell granskning och säkerhetstestning i CI/CD-processen för att upptäcka logiska brister.

6. Logga och bevaka krypteringsrelaterade händelser

Ha koll på hur nycklar används, när de ändras, och om datalagring sker okrypterat av misstag. En korrekt loggad händelsekedja gör det möjligt att snabbt agera vid incidenter, till exempel om en nyckel plötsligt används från okänd IP-adress. Övervakning hjälper inte bara att upptäcka angrepp utan också att efterleva krav i regelverk som GDPR och ISO 27001.

Sammanfattning

Kryptografiska fel uppstår ofta när vi antar att data redan är skyddad, eller när vi litar för mycket på teknik vi inte riktigt förstår. Ett felaktigt implementerat skydd är i praktiken inget skydd alls.

Lösningen är inte att göra allt själv, utan att använda välbeprövade bibliotek, moderna metoder och robust nyckelhantering. Det är bättre att ha en enkel men korrekt kryptering, än en avancerad men osäker lösning.

Tänk på att det inte räcker med att kryptera. Du måste kryptera rätt!

Vill du se hur det här fungerar i praktiken? Kolla in vår video här nedan där vi visar exakt hur kryptografiska fel fungerar och hur lätt det kan gå fel.

Är du osäker på hur din applikation hanterar känsliga data? Kontakta gärna vårt AppSec-team på appsec@decerno.se. Vi hjälper dig få koll på både krypton och riskerna.