en/decrypt database password
Lange tijd beetje gekeken maar niet veel gereageerd.
Maar had gisteren een idee en weet niet zeker of het acceptabel is om in een framework te gebruiken.
Mijn idee is om het database password ge-encrypt op te slaan in de database-config.php.
En in mijn database controller de ge-encrypte string te decrypten doormiddel van een crypt class.
Graag zou ik willen weten wat jullie hier van vinden.
M.V.G,
Wouter.
Het levert namelijk pas structureel iets op als de encryptie en decryptie strikt gescheiden zijn.
Ward van der Put op 08/11/2013 18:42:00:
Hoe ziet je serverconfiguratie eruit?
Het levert namelijk pas structureel iets op als de encryptie en decryptie strikt gescheiden zijn.
Het levert namelijk pas structureel iets op als de encryptie en decryptie strikt gescheiden zijn.
Hoe bedoel je dit precies ?
Mijn idee is om bijv het password van de db al geëncrypt in de database-config file te zetten.
En voordat mijn database class hem kan gebruiken dat hier een decrypt functie overheen gaat.
Misschien eventueel het password dat al geëncrypt is om hier een salt overheen te gooien dmv van een unieke sessie variable.
Hopelijk snap je wat ik bedoel.
gr,
Wouter.
Maar ik ben bezig met een systeem voor bij mij op het werk.
Ik wil dus maximaal beveiligen, gewoon omdat het misschien wel mogelijk is.
Plus als het wel kan dan vraag ik me af waarom niet, vind het fijn om te weten dat er veel moeite wordt gedaan om belangrijke gegevens extra te beveiligen ook al zou het over de top zijn.
Je wil je password encrypten en kunnen decrypten.
Als argument geef je aan dat het veiliger moet zijn.
Als je je password encrypt, dan is het voor de gewone sterveling inderdaad niet meer te lezen.
Maar als iets omkeerbaar is het voor de die hard hacker een kwestie van wat vingeroefening doen om tot een resultaat te komen.
Dan vraag ik me af loont dit wel de moeite om daar tijd in te steken.
Beter is om de query's dicht te timmeren.
Je database verbinding via een beveiligd lijntje te laten lopen. Daar heb je meer aan denk ik, dan iets doen wat schijnheiligheid heet.
Gewijzigd op 09/11/2013 20:23:27 door Bart V B
En de reden waarom ik me password wil encrypten en decrypten is niet voor een eventuele hacker,
Maar eerder voor de mensen bij ons op het werk. ( gezien het feit dat er niemand in de db verder mag komen zonder explicite toestemming. )
En of het loont om hier moeite in te steken ?
Waarom niet het weer een extra beveiliging die je aanmaakt toch voor het geval dat..
Ook als er een hacker zou zijn heb ik liever dat het wat extra tijd kost om in de db te komen zodat je in ieder geval nog de tijd hebt om te reageren.
Anders gezegd, of het nu mensen van je werk zijn of niet: don't give them the key! Zorg dat ze niet bij het database wachtwoord kunnen komen.
Gewijzigd op 09/11/2013 20:58:53 door Frank Nietbelangrijk
Ik snap dat ze de code niet mogen hebben en/of krijgen maar juist om die reden wil ik het encrypten.
En omdat het me gewoon net iets beter lijkt dan gewoon blank in config file zetten.
Schijnheiligheid moet natuurlijk schijnVeiligheid zijn. :)
Ik kan niet zo wennen aan die automatische aanvulling op mijn gsm.
Dus mijn excuses mocht ik je daarmee gekwetst hebben dat was zeer zeker niet de bedoeling.
Hoe bedoel je niet verder in de database komen? Als het te lezen is kan je via de cli er toch gewoon bij??
Of ik nou password1 moet tikken of iets van eHvwe&@qorimf8woo1439 het is effe wat meer tikwerk maar uiteindelijk ben je binnen. Dus dat gaat niet werken.
Zeker als men gewoon vrij op de server kan spelen.
Bart V B op 09/11/2013 21:06:38:
Hoe bedoel je niet verder in de database komen? Als het te lezen is kan je via de cli er toch gewoon bij??
Of ik nou password1 moet tikken of iets van eHvwe&@qorimf8woo1439 het is effe wat meer tikwerk maar uiteindelijk ben je binnen. Dus dat gaat niet werken.
Zeker als men gewoon vrij op de server kan spelen.
Of ik nou password1 moet tikken of iets van eHvwe&@qorimf8woo1439 het is effe wat meer tikwerk maar uiteindelijk ben je binnen. Dus dat gaat niet werken.
Zeker als men gewoon vrij op de server kan spelen.
Nee het hele punt van het wachtwoord encrypten is juist dat ze er niet bij kunnen, zelfs als ze het encrypted wachtwoord hebben.
Verder lijkt het mij nog steeds een beetje overdreven, ik neem aan dat je je collega's op je werk wel kunt vertrouwen? Maak je dagelijks backups van je database?
Het kan natuurlijk wel, is je eigen persoonlijke voorkeur
Bart V B op 09/11/2013 21:06:38:
Wouter,
Schijnheiligheid moet natuurlijk schijnVeiligheid zijn. :)
Ik kan niet zo wennen aan die automatische aanvulling op mijn gsm.
Dus mijn excuses mocht ik je daarmee gekwetst hebben dat was zeer zeker niet de bedoeling.
Hoe bedoel je niet verder in de database komen? Als het te lezen is kan je via de cli er toch gewoon bij??
Of ik nou password1 moet tikken of iets van eHvwe&@qorimf8woo1439 het is effe wat meer tikwerk maar uiteindelijk ben je binnen. Dus dat gaat niet werken.
Zeker als men gewoon vrij op de server kan spelen.
Schijnheiligheid moet natuurlijk schijnVeiligheid zijn. :)
Ik kan niet zo wennen aan die automatische aanvulling op mijn gsm.
Dus mijn excuses mocht ik je daarmee gekwetst hebben dat was zeer zeker niet de bedoeling.
Hoe bedoel je niet verder in de database komen? Als het te lezen is kan je via de cli er toch gewoon bij??
Of ik nou password1 moet tikken of iets van eHvwe&@qorimf8woo1439 het is effe wat meer tikwerk maar uiteindelijk ben je binnen. Dus dat gaat niet werken.
Zeker als men gewoon vrij op de server kan spelen.
@bart, Oke dan sorry dat ik verkeerd heb opgepakt.
Njah ik wil gewoon zeker weten voor zover ik het voor elkaar kan krijgen ( op een lokale bedrijf's server ) dat niemand het password kan lezen.
Misschien overbodig of het heeft geen nut.
maar bij ons op het werk wordt altijd gezegd alle kleine extra beetje helpen toch weer een beetje.
Maar dan weet ik voorlopig genoeg, ik ga eerst zelf wat proberen.
Misschien dat ik een opzet vind die wel werkt al is het maar een beetje.
Toevoeging op 09/11/2013 21:23:22:
NOLot - op 09/11/2013 21:12:21:
--> Nee het hele punt van het wachtwoord encrypten is juist dat ze er niet bij kunnen, zelfs als ze het encrypted wachtwoord hebben.
Verder lijkt het mij nog steeds een beetje overdreven, ik neem aan dat je je collega's op je werk wel kunt vertrouwen? Maak je dagelijks backups van je database?
Het kan natuurlijk wel, is je eigen persoonlijke voorkeur
Verder lijkt het mij nog steeds een beetje overdreven, ik neem aan dat je je collega's op je werk wel kunt vertrouwen? Maak je dagelijks backups van je database?
Het kan natuurlijk wel, is je eigen persoonlijke voorkeur
Daarom wil ik via een sessie variable het password encrypten ( dus met tijd of browser agent ) door een hash gooien.
Verder heeft niemand op het werk verstand van php maar er zijn er wel een paar die graag rondneuzen door alle bestanden heen.
Ik neem aan dat een willekeurige niet zomaar toegang heeft op de server zelf.
Want dan zou je dat eerst moeten dichten.
Ik weet natuurlijk niet hoe jullie structuur in elkaar zit maar misschien is het een idee om het te te scheiden over 2 servers?
Bijvoorbeeld een dev server en de uiteindelijke server waar niemand bij kan behalve degene die daar de rechten voor hebben?
Hier hebben ze al wel programma's op lopen maar weet niet zeker wat voor structuur dat ze hier hebben toegepast.
Ik weet dus ook niet of op die server de lokale webserver geïnstalleerd moet worden.
Maar als dat wel het geval is zal iedereen van het kantoor personeel bij die bestanden kunnen tenzij je deze inderdaad afschermt met rechten.
Toch bedankt voor de informatie @frank, @nolot en @bart.
Zal eens kijken wat ze op het werk willen doen met de opzet en kan daarna bekijken of encrypten en extra mogelijkheid zou zijn ( die wel op een zinvolle manier wordt toegepast. )
Om de simpele reden dat wanneer iemand toegang heeft tot jou database configuratie bestanden, het een kleine stap is om te kijken welke encryptie is gebruikt om zo jou encryptie op je wachtwoord te decrypten. Men zegt wel eens, security trough obscurity, maar zoals eerder al vermeld is dat schijnveiligheid.
Als je de database wil afschermen moet je het in andere hoeken zoeken. Wachtwoorden altijd hashen, belangrijke data encryptioneren en natuurlijk alles afvangen met een sterk certificaat. En dan niet een simpel SHA-1 gebruiken, kijk eens naar SHA-3, deze zou binnen niet al te lange tijd effectief te gebruiken moeten zijn. Voor encryptie zou ik eens kijken naar aes/rijndael en dan de 256 bits sleutels gebruiken. Wanneer je informatie veilig opgeslagen is, hoef je je minder zorgen te maken om collega`s die voor de grap iets in de database willen doen. Maar, zoals met alles geldt ook hier; je veiligheid is zo sterk als de zwakste schakel.
Wat je overigens ook moet voorkomen is dat straks niemand meer bij de data kan komen mocht jij onder een bus belanden. Als jij de enige persoon bent die de inns en outs weet van de complete IT veiligheid ben je eerder een risico dan een versterkende factor, immers, wie wil z`n complete hebben en houden nu in de handen hebben van 1 persoon? Zorg er dus voor dat alles veilig maar wel netjes en gedocumenteerd opgeslagen wordt!