Als je het zou coderen moet je toch ergens op je server een sleutel parkeren. En als hackers toch al op je server zitten, hoeven ze alleen maar te zoeken naar de sleutel. Met andere woorden: Je bereikt er vrij weinig mee.
Je zou eventueel Zend SafeGuard of IonCube kunnen gebruiken om je scripts te encrypten. Maar je wilt je configuratie toch altijd aanpasbaar houden.
Beste advies is wel om het configuratiebestand buiten de webroot te zetten. Mocht PHP op je server ooit opeens door merkwaardige omstandigheden overlijden, waarbij jan-en-alleman de broncode zien, dan ligt je configuratie-file in ieder geval NIET op straat.
En bovendien:
mysqli_query()!!
Het wordt hoog tijd om je functies te upgraden naar mysqli of PDO.
Blijkbaar draai je nog niet eens PHP 7!
En verder zie ik ook een grote SQL-injection in je query!!!
Om de data weer te tonen, moet je de boel weer ontsleutelen.
Indexen, foreign keys e.d kan je beter niet versleutelen, daar je dan niet meer kan zoeken.
Een encryptie sleutel kan je bijvoorbeeld aanmaken met een Stored Function :
De reden waarom ik dit wil is omdat er ook andere gasten in de webruimte toelating gaan krijgen, en ik op die manier bepaalde scripts waar ik jarenlang aan gewerkt heb wil beschermen, zodat ze er niet mee gaan lopen.
Daaropaansluitend: kan ik bovenstaande code in een externe pagina plaatsen, om dan op de originele website dmv een include de database toch nog te laten werken? Bijvoorbeeld dit?
Die include gaat natuurlijk niet werken. Via de webserver zal www.website.com/databasegegevens.php een lege pagina geven als output. Daarnaast zijn include() en require() vooral bedoeld voor lokale bestanden.
Die obfuscator doet niet echt veel spannends. Met een simpel script maakt het de variabelen en functies korter. Menig getalenteerd PHP-er kan nog zo nog terug zien wat een script doet. Als je het wilt encoden (obfuscaten is wat anders) dan moet je echt kijken naar producten zoals Zend Guard of IonCube. Het zijn wel betaalde producten, maar je code is met geen mogelijkheid terug te halen. Wel moet de webserver waarop het uitgevoerd wordt dit ondersteunen, maar die extenties zijn zo geïnstalleerd.
Als je andere gasten (ik neem aan medewerkers) toe wilt laten in je webomgeving, dan raad ik je aan om een testdatabase voor hun klaar te hebben staan en een testomgeving. Bij voorkeur een database met geanonimiseerde gegevens, en laat ze uiteraard ook een NDA tekenen als je sterk wilt staan. Met obfuscaten voorkom je echt niks.
Zorg ook voor de juiste rechten op de server, zodat mensen die geen developer zijn niet zomaar bij de scripts kunnen komen. Met een goede werkomgeving zou encoden van scripts niet eens meer nodig zijn.
Waarom zou je databasegevenens willen encrypten of obfuscaten (wat al helemaal niks uithaalt)? Je maakt het voor jezelf dan heel moeilijk om even je credentials aan te passen als het dringend nodig is. En ook developers maak je het lastig als ze even van database moeten wisselen.
Zorg liever dat je goede rechten hebt, en dat anderen niet bij je productieomgeving kunnen, plus dat ze een NDA tekenen waarin ze dus getekend hebben voor geheimhoudingsplicht.
Dat is zo een beetje de werkwijze bij elk bedrijf.
Fijn dat er nog andere mogelijkheden zijn, maar die wil ik niet toepassen. De vraag is niet waarom ik iets zou willen, maar eerder of iets mogelijk is, en hoe?
Ik vertrouw die gasten nu eenmaal niet, vandaar deze vragen. Maak je om mij maar geen zorgen ;-)
Misschien moet je even duidelijk zeggen wie je met gasten bedoelt?
Die hebben toch niks te maken met je code te maken? Zet een wachtwoord op je computer, en het is klaar! Desnoods bitlocker of veracrypt op je PC om je schijf te beveiligen.