Door
Han php
op 23-08-2012 21:22
gewijzigd op 23-08-2012 21:23
5.703 views
Hallo wat heeft het voor nut om opgeslagen wachtwoorden te coderen als je ze in de database zet? Ja... Ik weet wel dat het dan heel moeilijk is (onmogelijk als je het goed doet) voor hackers/crackers om de wachtwoorden ooit te ontcijferen.
Het is de webmaster z'n taak om de gegevens van de bezoeker goed te beschermen.
Maar als er emailadresssen, namen, huis adressen etc. in de database staan wordt dat evengoed meegenomen als de gecodeerde wachtwoorden en dan zijn er toch nog gegevens uitgelekt, ookal zijn de wachtwoorden niet te achterhalen.
De hacker kan dan misschien niet inloggen op een account van een gebruiker, maar alles wat er op het account te zien is, staat ook in de database. Ik bedoel niet echt dat het zinloos is om wachtwoorden te coderen, maar als je het zo bekijkt...
Of zit ik nu helemaal fout?
En verder kun je eigenlijk niet de andere gegevens coderen (email, adressen etc.) omdat de gebruiker die anders steeds zou moeten invullen, net als z'n wachtwoord.
Als iemand op de FTP kan binnenkomen maakt het niet meer uit waar je wachtwoorden staan. Dan kunnen ze toch overal komen. Hoe iemand op de FTP binnenkomt... geen idee. Ja, wachtwoord/gebruikersnaam brute-forcen oid.
Als je FTP-toegang hebt, open je gewoon config.php (of connect.php etc), ongeacht waar die ook staat. Jij spreekt over het bereik van een gebruiker (ftp-user).... die gaat toch gewoon over alle bestanden? Of heb jij een website-user-ftp? Ik heb maar 1 ftp-user: en die kan overal bij. Die gebruik ik alleen om bestanden te uploaden/downloaden.
Voor de database heb ik wel 2 users: 1 met alle rechten, 1 (en die is voor php) met beperkte rechten (geen tabellen wijzigen/verwijderen/toevoegen).
Ja, dat je ftp-users beperkt in hun mappen, is dat mogelijk. Maar jij hebt dus een extra user aangemaakt die niet in de map /config kan komen? Dat is handig.
Maar om daar te komen (bij het invoeren van je configuratie-instellingen), moet je toch in /config kunnen komen. Gebruik je dan een andere user.
En waarom zal die user (met root-toegang) niet gehackt worden en die andere wel?
Kijk, als je andere personen toegang geeft tot de FTP van je site (iets wat ik doe voor 1 persoon), dan kan die alleen maar in haar eigen map/domein komen.
We werken nooit als users die alle rechten hebben. Users worden 'gevangen' gehouden in hun deel, eventueel met wat links erin om andere (afgeschermde) delen erbij te zetten.
Het configuratie bestand kan alleen maar gelezen worden door de webserver user (daarmee kun je niet inloggen) en root.
Root heeft alleen ssh/sftp (en geen onveilige ftp) toegang vanaf het IP adres van de zaak. Om root toegang te krijgen zul je:
- in moeten breken op de zaak, dat is beveiligd met een alarm
- het password van een PC moeten hebben (is eenvoudig te kraken, maar het alarm loeit en het beveiligingsbedrijf is onderweg)
- het root password van de webserver moeten hebben (als dat dat niet vooraf hebt bemachtigd ben je verloren)
Een root user is degene die de server beheert, of het nu een FTP of database server is, deze wordt aangemaakt tijdens de installatie van de server. Deze wordt trouwens door mij ook nooit maar dan ook nooit root admin of administrator genoemd.
Om even bij FTP te blijven, als je weet hoe het FTP protocol werkt, kan je vanuit waar dan ook ter wereld proberen verbinding te maken met jouw FTP server. En dat gebeurd ook, ga maar eens in de logs kijken.
Als je nu de server goed configureerd hebt (IP blocking etc.) wordt dat uiteindelijk een stuk minder, maar het houdt nooit op.
@Ger: Tegenwoordig draaien we zelfs geen FTP server meer, juist vanwege een aantal beveiligingsproblemen. We gebruiken tegenwoordig uitsluitend SSH als SFTP. Versleuteld, sneller en naar onze indruk ook stabieler als FTP.
En m.b.t. ip blocking, we blokkeren alles en zetten alleen IP's die we willen toestaan open. Voordat we openVZ gebruikten zetten we de firewall ook nog wel eens open op het MAC adress, zodat je van je eigen laptop b.v. in de trein kon werken. Dat gaat met openVZ niet meer. Had ook als nadeel dat als de laptop gestolen werd, er een (tijdelijk) lek was.
En uiteindelijk wil je die gegevens alsnog ongecrypt weergeven. Waarom vraag je ze anders?
Kijk, een emailadres crypten kan ik me iets bij voorstellen, maar een telefoonnummer.... waarom heb je hem, als je hem voor de bezoekers niet toont?
Toon je ze wel: dan decrypt je ze en hoeft een hacker je database niet in om die gegevens te pakken.
Informatie dat wordt opgeslagen door webshops misschien ;) Die wil je niet laten zien aan iedereen. (Creditcard info?)
[quote="Eddy Erkelens op 24/08/2012 09:36:37"]
En uiteindelijk wil je die gegevens alsnog ongecrypt weergeven. Waarom vraag je ze anders?
Kijk, een emailadres crypten kan ik me iets bij voorstellen, maar een telefoonnummer.... waarom heb je hem, als je hem voor de bezoekers niet toont?
Toon je ze wel: dan decrypt je ze en hoeft een hacker je database niet in om die gegevens te pakken.
Informatie dat wordt opgeslagen door webshops misschien ;) Die wil je niet laten zien aan iedereen. (Creditcard info?)
[/quote]
Het punt van Eddy is dat je sommige dingen niet hoeft te encrypten, omdat het simpelweg geen nut heeft. Stel je schrijft/gebruikt een encryptie algoritme voor het versleutelen van een adres. Eveneens kan je dus de originele waarde bekomen door decryptie. Dan is de vraag, wat is het nut... Ook al kan je bijvoorbeeld alleen als admin dit adres zien. Als de hacker in je database geraakt, is het wellicht een koud kunstje om zichzelf admin rechten te verlenen. Dus met andere woorden, het encrypten van sommige data is onnodige overhead.
Banken zijn zo slim geweest om pinautomaten weg te zetten ipv contant geld op te laten nemen, en toch is er iemand op het ludieke idee gekomen om met een bulldozer (over brute force gesproken) die pinautomaat uit de muur te trekken en daarnaast ook nog eens even alle banden van de politieauto's van het dichtstbijzijnde politiebureau lek te steken (waar gebeurd).
Met andere woorden, perfecte beveiliging bestaat niet.
Maar wat ik niet begrijp is dat de nadruk zoveel op de codering van gegevens in de database ligt. Dat is de binnenkant, je moet eerst de buitenkant beveiligen, en daarna de binnenkant.
