Database gegevens op straat ?
Hopelijk staat dit onderwerp in de juiste rubriek, zo niet mijn excuus hiervoor.
Tegenwoordig hoor je steeds meer dat gegevens kunnen worden ontfutseld door criminelen. Daar geloof ik uiteraard sterk in. Hoe dit komt kan ik logisch verklaren : het antwoorden op ontvangen phisingmails kan dit veroorzaken, het gebruik van gemakkelijke paswoorden zoals bv "123456" enz.
Maar wat ik niet goed snap is dat criminelen een database kunnen kopiëren. Ik zou echt niet weten hoe je dat kan doen als je geen inlog - of ftp-gegevens hebt, mijn kennis hierin is trouwens ondermaats. Je hoort regelmatig dat duizenden persoonlijke gegevens op straat worden gegooid. De tabellen die ik toevoeg in een database zijn altijd versleuteld met een 128-bits versleutelcode. Het lijkt me sterk dat criminelen die erin slagen de database te kunnen hacken dat ze ook de inhoud kunnen lezen. Zie ik dit correct ?
Wat is jullie mening hierover ? Dank.
Gewijzigd op 20/01/2024 16:24:33 door Ronny Vangaster
Je kan gegevens uit een tabel extraheren en ze exporteren naar bv een csv-bestand. Maar als de tabel is versleuteld heb je daar weinig aan, daar word verder niks over verteld. Volgens mij komen de versleutelde gegevens dan ook niet op straat. Met een automatische dagelijkse back-up van de database en versleuteling van de tabellen kan er weinig worden gehackt volgens mij ...
Ronny Vangaster op 20/01/2024 16:22:14:
De tabellen die ik toevoeg in een database zijn altijd versleuteld met een 128-bits versleutelcode.
Waar sla je de sleutel op? Op dezelfde server? Of op een webserver die toegang heeft tot een databaseserver?
Ik vermoed dat er weinig of geen aandacht word besteed aan bv Wordpress-websites, eenmaal de site af is, is er verder weinig aandacht voor veiligheid en kan met sql-injectie gevoelige data worden geëxtraheerd uit een tabel, alhoewel dat er hier ook een plugin voor bestaat ....
Ronny Vangaster op 21/01/2024 11:48:21:
De coderingssleutel is nergens opgeslagen, die is "ingebakken" in de applicatie.
Hoe heb je de coderingssleutel dan "ingebakken" in de applicatie zonder de sleutel op te slaan in de applicatie?
Ik ga ervan uit, dat als je enkele duizenden Euro's betaald voor een ontwikkeltool, dat de ontwikkelaars van deze tool echt wel iets van encryptie af weten.
Gewijzigd op 23/01/2024 04:29:39 door Ronny Vangaster
Ronny Vangaster op 23/01/2024 04:04:49:
Ik ga ervan uit, dat als je enkele duizenden Euro's betaald voor een ontwikkeltool, dat de ontwikkelaars van deze tool echt wel iets van encryptie af weten.
hmmm.
Tik eens "datalek" in een zoektool en filter op Nieuws.
Daar staan namen als KLM en het Kadaster bij.
Die hebben waarschijnlijk wel meer dan een paar duizend euro betaald aan de ontwikkeling van hun databases.
Gewijzigd op 23/01/2024 11:23:43 door Ronny Vangaster
Dat eerste is makkelijk te controleren. Kijk in de database met bijv phpmyadmin.
Je weet hoe dat moet : https://www.phphulp.nl/profiel/ronny-vangaster/38154/
https://mariadb.com/kb/en/data-at-rest-encryption-overview/
https://severalnines.com/blog/exploring-different-ways-encrypt-your-mariadb-data/
https://www.cisco.com/web/about/security/intelligence/05_11_db-encryption.html
Gewijzigd op 23/01/2024 12:42:01 door Adoptive Solution
Dank je voor de nuttige links die je gaf. De bestanden zijn niet versleuteld, maar wel de tabellen.
https://www.postgresql.org/docs/current/encryption-options.html
Encryptie in de database zelf is niet echt veilig omdat SQL statements (met wachtwoorden..) gelogd worden wat dan ook weer een risico is. Autorisatie als accounts, rechten en RLS moet gewoon goed ingeregeld zijn, de gegevensdrager moet voorzien zijn van encryptie (bitlocker / LUKS / ..) en het transport moet versleuteld zijn.
Dat laatste is echt een achilleshiel, want wie doet dat? Wie heeft de verbinding met de applicatieserver en de database server beveiligd met TLS? En wie heeft de HTTP-verbinding tussen de proxy webserver en de applicatieservers beveiligd met TLS? Omwille van 'performance' wordt encryptie nogal eens achterwege gelaten, met een term als SSL Offloading.
Wat veel mensen zich ook niet realiseren, is de 'store now, decrypt later'-tactiek die ook toegepast wordt. Met dat in het achterhoofd wil je alleen nog TLS 1.3 gebruiken met de beste ciphers. En dan alleen wanneer het nodig is gegevens over een publiek netwerk verplaatsen.
Er zijn allerlei manieren om gegevens te versleutelen in een database, zoals bijvoorbeeld met searchable symmetric encryption. Maar wat je ook verzint, elke methode heeft voor- en nadelen. Postgres somt het aardig op: Encryptie in de database zelf is niet echt veilig omdat SQL statements (met wachtwoorden..) gelogd worden wat dan ook weer een risico is. Autorisatie als accounts, rechten en RLS moet gewoon goed ingeregeld zijn, de gegevensdrager moet voorzien zijn van encryptie (bitlocker / LUKS / ..) en het transport moet versleuteld zijn.
Dat laatste is echt een achilleshiel, want wie doet dat? Wie heeft de verbinding met de applicatieserver en de database server beveiligd met TLS? En wie heeft de HTTP-verbinding tussen de proxy webserver en de applicatieservers beveiligd met TLS? Omwille van 'performance' wordt encryptie nogal eens achterwege gelaten, met een term als SSL Offloading.
Wat veel mensen zich ook niet realiseren, is de 'store now, decrypt later'-tactiek die ook toegepast wordt. Met dat in het achterhoofd wil je alleen nog TLS 1.3 gebruiken met de beste ciphers. En dan alleen wanneer het nodig is gegevens over een publiek netwerk verplaatsen.
Mijn bedoeling is NIET om mensen te testen op hun kennis, maar wel om te kunnen vaststellen hoe veilig of onveilig versleuteling werkt.
https://www.weforum.org/agenda/2022/09/organizations-protect-quantum-computing-threat-cybersecurity/
Er zijn tools om computerprogramma's terug te vertalen naar leesbare code, bijvoorbeeld met een disassembler. Als iemand er werk van maakt kan diegene zien waar de sleutel vandaan komt en daarmee alle gegevens ontsleutelen. Voor als de quantumcomputer er nog niet is, want vanaf dan ligt zowat alles op straat. Voor meer info zie