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.
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
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.
Misschien dan een tip dat alleen die mensen met verstand van zaken op de lokale server kunnen komen.
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?
Voor zover ik weet hebben we 1 bedrijf's server lopen.
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. )
Volgens mij haal je twee verschillende dingen door elkaar, enerzijds wil je de database dichttimmeren en anderzijds het pad er naartoe ook dichttimmeren; op zich geen slecht idee echter los je met je cryptografie niets op.
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!
