Hackarna hackade: Databasen för ökänt forum säljs till högstbjudande

Jorå så att 😅

Hur kan ett forum som inriktar sig på att dela med sig av hackade databaser inte själva använda sig av krypterad databas?

Vad är det som är så omöjligt, svårt eller vad det kan vara, med att kryptera data innan det skickas in i en databas? Eller är det för att krypteringsnycklarna ligger på samma ställe som databasen själv vilket egentligen gör det rätt meningslöst med krypterad databas till att börja med?

Någon inbiten Databasadministratör får gärna upplysa mig!

Mvh,
WKL.

Även om databasen är krypterad så behöver applikationer och frontend all info i klartext automatiskt

Går ganska snabbt att dumpa data även om den är ’krypterad’

Nu har jag inte fått lära mig (de)kryptering av databaser, men så här tänker jag:

1) Du har krypterad databas som anropas via REST API. Krypterad data skickas.

2) På frontendsidan har du dekrypteringsnycklar och genom att du vet vad du gjorde för REST API-anrop så kanske du även har särskilda dekrypteringsnycklar för olika delar av databasen, eller liknande.

3) Om du då har åtkomst till dekrypteringsnycklar så behöver du bara komma in på databasen vilket lär vara enkelt då inloggningsuppgifter till databasen troligen finns på samma ställe som dekrypteringsnycklarna på frontendsidan.

Tänker jag rätt?

Mvh,
WKL.

Det beror på

Oftast är det snarare:
1. Krypterad data i databas
2. Krypteras upp i backend/databas
3. Klartext data skickas runt i frontend/browser

Men man kan kryptera data igen med session token för användaren. Det du är ute efter låter som något likt ’oläslig data för obehöriga’. I de flesta applikationer är dock all data behörig läsning för backendkoden, väldigt sällan information går krypterad hela vägen till klienten ens

Annars måste du ställa ut permanenta nycklar (identiteter) eller på något sätt göra en handskakning varje inloggning och kryptera om informationen med denna sessionsnyckel i backend

Det går såklart, men oftast är det inte gjort så för det blir bökigt

Det du pratar om kräver annars att nycklarna är fasta och gäller hela vägen in i databasen, så alla enheter du kan logga in från ska på något sätt få tag i samma nyckel… det går, men är lite bökigt att få till

Har du nycklarna tillgängliga i frontend tar du automatiskt bort syftet med dessa. Se frontend som något du helt saknar kontroll över. Vill du skydda din data från att bli sniffad från utsidan så har du HTTPS vilket räcker för det mesta.

Bara för något är krypterat betyder det inte att det är säkert/skyddat. Security by obscurity är inte något positivt

Att sätta upp en ordentlig miljö för hantering av krypterad data är inte enkelt och det finns många fallgropar som helt plötsligt gör det meningslöst. En lösning är att ha dina nycklar sparade på en annan fysisk server - fast samtidigt måste hämta in dessa för att kunna läsa din data. Får någon access till din backend-server så kan se säkert klura ut hur de ska hämta även dessa nycklar.
* Nu är jag ingen arkitekt/specialist inom detta. Jag är bara en systemutvecklare som pillat lite med allt möjligt.

Ja, just det. Om vi tänker så här då:

1) Krypterad data i databas på en server skickas efter korrekt fortfarande giltig lagrad API-nyckel från endast REST API.

2) Data dekrypteras i REST API som i sin tur ligger på en annan server och den skickar "läsbar text" via HTTPS till endast en specifik IP-adress i samband med fortfarande korrekt giltig API-nyckel.

3) "Läsbar text" visas i frontend som anropat REST API efter inloggning och med tillfällig fortfarande giltig API-nyckel.

Om databasen hackas så har vi ändå dekrypteringen på en annan server? Och hackas REST API-servern så har vi ändå databasservern kvar? Sedan har vi den svagaste länken inom IT: människorna bakom skärmarna/servrarna!

Mvh,
WKL.

Detta är det primära. Du vill sprida ut dig, tänk backup-lösning på lagringen hemma. Brinner ditt hus ner så har du inte nån nytta av din backup om den var placerad i samma hus.

Din databas bör vara på en egen server. Din applikation på en annan. Din databas bör sedan använda whitelist för vem som får anropa denne. Då kan du inte anropa servern från din egna burk bara för du har anslutningsuppgifterna (t.ex. vid röjd webbserver)

Du har följande applikationer;

• Databas med krypterat innehåll

• API som har krypteringsnycklar (antingen direkt i API:et eller hämtas från extern tjänst)

• Klient

1) Din klient anropar ditt API med tillhörande autentiseringsmetod.
2) API:et hämtar data från DB.
3) API:et använder sina krypteringsnycklar för att avkryptera det data som hämtats från DB.
4) API:et svarar klienten med avkrypterad data.

Att anslutningen sker över HTTPS får anses som en självklarhet idag

Vill du vara ”helt” säker så kan du göra så bara klienterna kan läsa sin egen data, då blir servern lättare också för den ser bara blobbar

Har du data som många behöver läsa får du dina största problem. Men du kan kryptera samma data med många nycklar, en för varje som behöver tillgång (aes key wrapping)

Men det blir ganska bökigt ganska snabbt om man inte tänker igenom helheten innan man börjar. Exakt vem ska kunna komma åt exakt vad. Ofta kan man till exempel dela upp krypteringsnycklar och funktionalitet på olika servrar och apier. Eller gå så långt som HSM eller andra säkra chip som smarta kort eller yubikey