Is het mogelijk dat het hele systeem dezelfde encryption key gebruikt?
Het gevaar is dan wel dat je systeem gehackt wordt en ze zo alles kunnen decrypten.

Anders is end-to-end encryption misschien een idee? Al weet ik niet of dat met meer dan 2 gebruikers kan.

Misschien heb je hier iets aan?

Weet niet of de Belgische wet toelaat dat je bankgegevens mag opslagen.

Citaat van Aaron

Het is een voorbeeld. Ik wil voornamelijk wachtwoorden van hun emailaccounts en webhosting opslaan op een veilige manier zodat mijn collega’s er ook aan kunnen.

Dat is mogelijk! Zal dit bekijken.Nog iemand met andere mogelijkheden? Wil ze graag vergelijken

Ik ga hier wel heel ver in, voor ieder gevoelig veldje in mijn database maak ik 2 unieke random keys aan die in ecnryptie wel worden erkend als IV (vaste karakter lengte) en Key (willekeurig). Deze set van 2 random keys worden per gebruiker en per gevoelig veldje dus opgeslagen op de webserver zelf. De geencrypteerde string gaat dan zo in de database op z'n juiste plaats. Stukken veiliger door per user gedefinieerde unieke keys te genereren tenzij uiteraard je FTP zou gehacked worden. Ikzelf gebruik hiernaast ook 1 master IV en key die worden gebruikt om ook FTP side bijvoorbeeld een bestaande geencrypteerde bankrekeningnr lijst set op te slaan om zo enkel vanuit de FTP heel snel te controlleren op een bestaande bankrekening. Master encrypteren gebeurt dan uiteraard wel volledig FTP based en heeft enkel zijn nut in snel bestaande geencrypteerde waarden terug te vinden zonder iedere gebruikers, gevoelig veldje te decrypten om te vergelijken.

Master encryptie gebruik ik dus enkel om data te kunnen vergelijken waar ik dat nodig acht en uiteraard bewaar ik niets van master encrypties in de database maar gewoon puur in de FTP als simpele geserialiseerde .txt bestandjes. Zo kunnen ze zeker je master keys niet achterhalen met database toegang, uiteraard wel met FTP toegang! De gebruiker's eigen IV en Key is dus het enige mogelijke dat hij zou kunnen ontcijferen tenzij je natuurlijk bij iedere bewerking de IV en Key opnieuw genereerd!

Bij encrypteren van gevoelige data die vergelijkbaar moet zijn dien ik dus wel dubbel te encrypteren 1x voor het gevoelige database veldje en 1x met mijn master key set om die gevoelige data snel en makkelijk te kunnen opslaan, bewerken en vergelijkingen volledig vanuit de FTP vergelijken kan zelf zonder te moeten decrypteren al zijn beiden paden hier gewoon mogelijk.

Master encryptie zie ik dus zelf als encrypteren en decrypteren met telkens dezelfde keys (Dus niet random, wat uiteraard vergelijkingen dan mogelijk maakt! En waarvan je encrypties dus best niet in je database belanden.)

PS: als het een wachtwoord betreft kan ik alleen maar encrypteren afraden en eerder opteren om het te hashen dat is namelijk van nature onomkeerbaar!

Misschien ben je hier wat mee alles hierboven beschreven in PHP code met voorbeelden in een 200 tal slordige lijntjes! Zie bijlage. Deze oplossing echter enkel geschikt voor de kleinere projecten, moet eigenlijk dringend werken aan een schaalbare oplossing en zeker de diepe dir trees vermeiden! Success! Hoor ook graag anderen hun ideeën omtrent dit onderwerp!

Neem eens een kijkje: https://github.com/illuminate/encryption

Package die gebruikt wordt door Laravel voor encryptie. aka, heel veel gebruikt

Hm, interessante materie, maar is dit niet een beetje "who watches the watchmen"?
In de zin van, als je dan toch full tinfoil hat conspiracy theory modus gaat, wanneer is het dan genoeg?

Het is goed om veiligheid in lagen te stoppen, maar om nu alles te encrypten, dit is wellicht misschien wat overkill? Dit belemmert je wellicht ook om van andere optimalisaties in een database gebruik te maken (zie ook hieronder) zoals voor zoekfunctionaliteit? Als je een of andere custom laag hiervoor hebt kun je waarschijnlijk niets direct vinden in deze brei.

Als je bang bent dat dingen uitleesbaar zijn via phpMyAdmin - bied dan simpelweg deze mogelijkheid niet? Maak rechtstreekse (of mogelijk nog beter? indirecte) databasetoegang alleen mogelijk via een beveiligde shell. En zet wellicht een aparte databaseserver op die verder losstaat van de applicatieserver. Je zou ook whitelists kunnen opstellen voor wie de database uberhaupt toegankelijk is; wat trouwens hopelijk toch wel gebeurt, neem aan dat er geen GRANTs uitgegeven worden aan 'god'@'%' of dat je alles ophangt aan je root user :p.

Misschien zou je ook naar "native support" voor encryptie kunnen kijken. Je zou best je eigen encryptielaag kunnen rollen, maar als dit niet je vakgebied is of je jezelf geen vis in het water voelt met deze materie zou ik out-of-the-box / standaard componenten gebruiken. En dat heeft misschien als bijkomend voordeel dat andere functionaliteit nog steeds beschikbaar is.