Zeker, dat klopt.
Een stuk snellere, en eigenlijk ook betrouwbaardere, actie is dan ook gewoon de tweede methode die ik noemde in mijn reactie aan Civilian: dump de database, encrypt de dump, drop de database (of sloop de tabellen (drop/delete/truncate)) -> geef decryptie sleutel voor de dump zodat de database weer in ere hersteld kan worden.
Volledige cyclus is dan, indien betaald is voor decryptie:
dump, encrypt, drop -> decrypt, restore.
Maar in het geval van de meeste van die standaard scripts is het vaak helaas wel mogelijk om het gewoon on the fly te doen in de database zelf als er wat limitaties aanwezig zijn (zoals correct dumpen...). Zeker als je bijvoorbeeld te maken hebt met troep als WooCommerce; die propt sowieso al zo gigantisch veel data op de meest belachelijke plekken in enorme getalen; in principe maakt de encryptie dan vaak geen verschil voor de toegestane velden.
Maar je hebt gelijk, het is zeker niet altijd even makkelijk om het in de database zelf te doen. (Al heeft dat dan weer weinig te maken met de server configuratie in de zin hoe Civilian het bedoelt)
Ook kan het voor de hacker interessant zijn, mits een dump maken niet goed lukt, om slechts enkele cruciale delen van de database te encrypten in de database zelf; zoals besteldata van klanten als we het over webshops hebben, de complete inventory, et cetera. Dat zijn vaak behoorlijk grote velden, en zeker gebruikersgegevens zijn vaak al geschikt om encrypted data in op te slaan... Maar wel cruciale gegevens voor de beheerder. Dat dan niet de gehele database encrypt kan worden zal de hacker een worst zijn zolang de beheerder alsnog sterk geneigd zal zijn om te betalen om zijn meest cruciale database gegevens terug boven water te krijgen.
Het risico wat er echter aan vast zit met de dump methode is dat de dump, na encryptie, niet te herstellen valt; bijvoorbeeld doordat er een time-out was tijdens het dumpen ervan (al is dat ook weer om te omzeilen, het staat en valt met de hoeveelheid tijd die de hacker heeft; en hoe groot de database is. (na dump)) waardoor de dump nooit afgemaakt is. Dit is natuurlijk weer af te vangen door op foutmeldingen te controleren en het gebruik van methodes als bigdump, maar het wordt wel steeds complexer...
Niet dat de methode van on the fly in de database zelf zonder risico is natuurlijk, dat is nagenoeg waarschijnlijk een nog groter risico.
Anyway, de pest is dat er grof geld te verdienen valt, dus als ze extra kunnen vangen als ze ook databases "betrouwbaar" kunnen encrypten op zo'n manier: dan doen ze het. (Er zijn ook al gevallen bekend waarop het gebeurt is op de omschreven manier (
dump, encrypt, drop)).
Of dat niet kunnen herstellen een crimineel zal boeien is nog maar de vraag natuurlijk, al is het vaak wel zo dat deze criminelen euhh... "Betrouwbaar" zijn.

Ik zou ze bijna ethisch noemen.

Dat wil zeggen dat ze namelijk wél in 9 van de 10 gevallen na betaling ook inderdaad netjes de sleuteltjes overhandigen... In dat geval moet het natuurlijk wel zo zijn dat de integriteit van de bestanden, én de database, niet geschaad wordt...
Maar eerlijk is eerlijk, het is makkelijker om de dump te encrypten en de database vervolgens te droppen (of alle tabellen erin) dan om de database te encrypten *in de database zelf*. Helemaal mee eens.
Voor zover ik kan zien is dat in de gevallen waar databases encrypted zijn ook de gebruikte methode, en logisch ook: simpeler, doeltreffender en algeheel eigenlijk ook gewoon "veiliger".
Het scheelt een vermogen aan coding werk en compatibiliteit controles door het op deze manier te doen, en is in principe universeel inzetbaar op zo'n beetje elke database lay-out... Door de dump te encrypten zit je niet meer aan de limitaties van SQL zelf vast, maar is het gewoon "yet another file".
M'n complexere uitleg over wat *zou kunnen* (in de database zelf encrypten) was ook meer een voorbeeld van op welke manier dat kan, dan dat dit ook daadwerkelijk toegepast wordt.

"In the field" zal je veel vaker zien dat er een encrypted dump is en je originele database gewoon gedropped is, dan dat je een database in je SQL server vindt die geheel encrypt is binnen de database zelf.
M'n punt was enkel dat het prima mogelijk is, en dat dit niet staat of valt bij een "goede server configuratie". Beide manieren die ik heb omschreven zijn mogelijk (dus zowel de lekker simpele manier alsmede de zeer complexe manier), zelfs op goed ingestelde/geconfigureerde servers!, zolang de gebruiker maar ALL privileges nog heeft ingesteld op de gebruiker... En helaas is dat bij het overgrote merendeel van die websites het geval, waardoor beide beschreven methodes inzetbaar zijn: ongeacht een prima server configuratie! (Die doet immers prima wat ie moet doen...)
Het ligt uiteindelijk aan de hacker hoeveel geld ie er aan denkt te kunnen verdienen; en dus hoeveel tijd hij er in wilt steken.
[Reactie gewijzigd door WhatsappHack op 11 november 2015 06:16]