Tijden veranderen
System-wide key
Code (php)
1
2
3
2
3
<?php
$hash = pbkdf2($system_wide_key . $salt . $password);
?>
$hash = pbkdf2($system_wide_key . $salt . $password);
?>
De system-wide key mag, anders dan de salts en de hashes, natuurlijk nooit in de database worden opgeslagen. Maar waar zal ik deze key dan opslaan? Wat kunnen jullie me aanbevelen?
Maar dat kost weer geld. Buiten de webroot kost niets extra.
Het punt is dat ik eigenlijk een derde niveau nodig heb. Buiten de root zijn namelijk gebruikersnaam en wachtwoord van de database opgeslagen, dus de system-wide key sla ik dan liever niet op hetzelfde niveau op. Niet dat de key dan nutteloos is, verre van, maar het kan nog veiliger, zoals Dos aangeeft, door de sleutel elders weg te parkeren.
Dus op een andere CDN oid.
Gewijzigd op 30/11/2014 22:04:08 door Bart V B
Verder gaat het ook om het principe natuurlijk. Je hebt namelijk:
1. Salt en wachtwoordhash in de database.
2. Databasegebruikersnaam en databasewachtwoord buiten de root.
3. System-wide key.
De system-wide key kan dus beter niet worden opgeslagen in (1) de database of (2) de configuratie buiten de root.
Ik snap wat je bedoelt te zeggen, maar is het echt noodzakelijk. Dat is wat ik me afvraag. Op het moment dat iemand je database leegtrekt, dan zijn de wachtwoorden via de hashes beschermd. Als iemand je server kraakt en dus overal bij kan, dan is in principe niks meer veilig. Als een hacker die expertise heeft, dan zal hij ook de expertise hebben om te kunnen zien waar die system-wide key vandaan komt ... en ... hij zal die key dan ook kunnen downloaden. Hij heeft immers toegang tot jouw server. De vraag is dus of dit niet een vorm van schijnveiligheid is.
Als iemand de database leegtrket, zou je dat kunnen zien alsof je ergens een raampje hebt open laten staan. Als iemand echter je voordeur forceert, dan vrees ik dat je platgezegd de l@l bent. Dan kun je de system-wide key wel ergens in een kluisje hebben gestopt, het probleem is echter dat de sleutel van die kluis zich ook ergens in huis bevindt.
Precies, daarom moet die sleutel dus niet in huis bewaard worden.
Sla je sleutel op buiten de root, dan is dat niet zozeer schijnveiligheid, maar is de toegevoegde waarde inderdaad veel beperkter. Je hebt dan meer een soort noodrem: je kunt bij wijze van spreken even // voor de define('SYSTEM_WIDE_KEY', '...') zetten en de heleboel gaat vanzelf op slot. Dat kan bijvoorbeeld nuttig zijn als je eerst wilt onderzoeken wat er loos is.
Bart noemde een toepassing die ik niet voor ogen had maar die ook nuttig kan zijn: het intrekken van een externe licentiesleutel heeft een vergelijkbaar effect.
Wat me wel interresant lijkt om te weten hoe je dat stukje externe code het beste zou kunnen mengen in je code.
Want dat lijkt me niet makkelijk.
Ik zou me kunnen voorstellen dat je daar een externe database voor in zet.
Dan zou je de sleutels op kunnen slaan per user/licentie of wat dan ook.
Daar zou je ook extern nog een beveiliging in kunnen brengen met meer dan 3 pogingen mislukt, de boel daar op slot te zetten.
Het is maar even een hersenspinsel.
Maar wat ik bedoel is dat je de sleutel (zijnde de key zelf óf de code om de key op te halen) altijd binnenshuis moet opslaan, anders kun je zelf ook de kluis niet meer openen ;)
Je hebt in feite 2 "secties" op server-niveau. Je hebt een publiek gedeelte (document root / web root) waarvan een bezoeker rechtstreeks bestanden kan aanroepen, en je hebt een niveau hoger ... een privé gedeelte waar een bezoeker niet bij kan.
Zorg ervoor dat al je code buiten de web root staat, ofwel in het privé gedeelte. Dus ook je system-wide key.
Als iemand via sql injectie databasegegevens steelt, dan heeft hij de system-wide key niet. Goedzo!
Echter, als iemand in staat is om binnen te dringen in het privé gedeelte, dan maakt het niet meer uit of jij die system-wide key op de server of ergens extern hebt opgeslagen. Namelijk:
Om een site te laten werken, moet de system-wide key beschikbaar zijn in het privé gedeelte. Ergens in de code staat dus óf de key zelf, óf een script dat de system-wide key ophaalt. Een hacker kan dat stukje code uitvoeren, en heeft vervolgens alsnog de key te pakken. Dus wat is dan nog de meerwaarde? Het enige wat je feitelijk doet is de key "verstoppen".
Oké, als je helderziend bent, dan zou het meerwaarde kunnen hebben. Dan kun je 5 minuten voordat de hacker jouw server binnendringt alle keys op de externe server deactiveren, maar ja ... ik ben niet helderziend helaas.
Wat ik hiermee wil zeggen is dat je dus eigenlijk maar 1 optie hebt, en dat is alles buiten de web root opslaan. Je kunt wel alles extern opslaan op een andere server, maar volgens mij heeft dat geen meerwaarde om hack-pogingen tegen te gaan. Wel heeft het als negatief effect dat de website trager wordt en dat op het moment dat de externe database eruit ligt, de complete website plat gaat.
>> Echter, als iemand in staat is om binnen te dringen in het privé gedeelte, dan maakt het niet meer uit of jij die system-wide key op de server of ergens extern hebt opgeslagen.
Je gaat er dan van uit dat webserver en databaseserver op dezelfde VPS-server draaien, maar dát is niet per se het geval. En ook niet heel verstandig, juist om de redenen die je zelf noemt. De aanname dat een gecompromitteerde webserver of FTP-server meteen de databaseserver raakt (en vice versa), gaat daarom lang niet altijd op.
Je kunt webservers (meervoud) en een cluster met databaseservers (meervoud) hebben; die delen dan een netwerk, maar meer ook niet. De idee om daaraan een extra laag toe te voegen voor die sleutel in hardware, op een extra server óf in een extra database is dus niet onlogisch.
Je kunt het enigszins met andere vormen van encryptie vergelijken. Dat kan peer-to-peer met twee partijen die elkaar vertrouwen. Maar het kan ook via een trusted third partij: een derde die door beide partijen wordt vertrouwd. Het enige verschil is dat je asymmetrische encryptie gebruikt, zonder decryptie.
Hehe, daar twijfelde ik niet aan, maar het was even om mijn verhaal duidelijk te maken.
Ik snap wel wat je bedoelt, maar omdat de servers onderling met elkaar kunnen praten vraag ik me af of je op deze manier extra veiligheid inbouwt.
Even ervan uitgaande dat iemand op je webserver inbreekt, dan staat ergens op die server een stukje code om de system-wide key op te halen. Weliswaar staat de key zelf er dan misschien niet op, maar wel de code om 'm op te halen. Dus mijn vraag is wat je daar dan mee opschiet, hooguit dat je het de hacker wat lastiger maakt omdat die nu moet zoeken naar een stukje code in plaats van een key.
Ik heb het topic geopend omdat ik me afvroeg hoe je het nog veiliger kunt maken: zelfs niet eens op dezelfde webserver opslaan.
In mijn eerste opzet staat de sleutel gewoon bij de databaseconfiguratie, zoals databasewachtwoord, maar dáár wil ik de sleutel liever weg hebben.
