De PHPhulp kroeg
Wat heeft coderen voor nut?
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.
Gewijzigd op 23/08/2012 21:23:27 door Han php
En nee, ik ga niet overal een ander wachtwoord gebruiken, ik zit op zoveel plekken, dat wordt ondoenlijk. Alleen voor financiele zaken gebruik ik andere wachtwoorden.
Enne, veiligheid begint ermee dat de database niet te benaderen c.q. te hacken is.
Gewijzigd op 23/08/2012 21:33:48 door John Berg
Han php op 23/08/2012 21:34:39:
Okee dat is een punt, vooral bij bankieren op internet bijvoorbeeld dat pincodes enzo zichtbaar zijn, maar je weet eigenlijk nooit wat er achter de schermen gebeurt op een server. Ookal is een goede webmaster iemand die geheimen kan bewaren.
Wat ik wel eens doe als ik het niet vertrouw is op de link voor wachtwoord vergeten klikken. Dan krijg ik een wachtwoord gemaild, als dat het originele wachtwoord is, dan is het helemaal fout.
Quote:
maar je weet eigenlijk nooit wat er achter de schermen gebeurt op een server
Laat ik eerst een offtopic voorbeeld geven voor de beeldvorming. :)
Je kunt de sleutel op de deur laten zitten dan is het heel makkelijk om binnen te komen. Andere optie is om je auto door de deur te rijden. Geeft het zelfde effect.
Hoewel je het eerste niet logisch vind, en het laatste ook nou niet echt handig..
Als een webmaster/developer de server onder zijn arm meeneemt dan zijn die gegevens ook niet veilig..
Een wachtwoord is niet meer of minder dan een obstakel om er (redelijk) zeker van te zijn dat er een juiste match is om bepaalde dingen te zien/doen.
Beveiliging is meer dan alleen dat ene wachtwoord. Zoals John al aangeeft begint het bij de server. Als je op webmaster/developer niveau bekijkt, dan moet het zo zijn dat alles gecontroleerd moet worden. Daar bedoel ik mee dat dingen afgedwongen moeten worden die jij alleen wenst wat er gebeurd.
John Berg op 23/08/2012 21:39:59:
Wat ik wel eens doe als ik het niet vertrouw is op de link voor wachtwoord vergeten klikken. Dan krijg ik een wachtwoord gemaild, als dat het originele wachtwoord is, dan is het helemaal fout.
Heb dat ervaren bij postfilter. Hen daarop aangesproken, dat dat onveilig is/lijkt.
Zij beweren dat ze de wachtwoorden wel degelijk beveiligd opslaan, maar dat ze het ook kunnen decoderen...
Heb mijn twijfels. Uitschrijven betekent echter (weer) bergen ongewenste reclame/telefoontjes. Kiezen tussen twee kwaden :(
Wat dat betreft is er maar een ding goed en dat is met https werken.
Mijn adres vind ik minder erg dan mijn username/password combo. Uiteindelijk is een adres voor een hacker weinig waard. Hij moet net zijn geld verdienen op het net, niet in real life.
Tim van Norde op 24/08/2012 00:19:46:
Je kunt je gegevens (adres, telefoon nummer, etc.) ook versleutelen door middel van een key. Zo hebben hackers niks aan de gegevens in de database zonder jouw encryptie-sleutel.
Je bedoelt als webmaster dan? Want als 'gewone' gebruiker kan je hier niet voor kiezen eh :-)
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.
John Berg op 23/08/2012 21:32:01:
Enne, veiligheid begint ermee dat de database niet te benaderen c.q. te hacken is.
Helemaal mee eens.
Enne, als je daar alle moeite (zoveel dat de JOZO door zijn zoutvoorraad heen is) voor gedaan hebt, en een hacker is zo getalenteerd dat ie toch toegang heeft, dan is het stomste wat je kunt doen een adres coderen met dezelfde sleutel die je op andere kolommen ook gebruikt.
Poll:
Waar staan je inloggegevens voor de database
A. ergens binnen de webroot
B. ergens buiten de webroot
PS
John, ik ben zo vrij geweest jouw opmerking te benadrukken.
Gewijzigd op 24/08/2012 12:36:39 door Ger van Steenderen
Ger van Steenderen op 24/08/2012 12:34:06:
Waar staan je inloggegevens voor de database
A. ergens binnen de webroot
B. ergens buiten de webroot
Waar staan je inloggegevens voor de database
A. ergens binnen de webroot
B. ergens buiten de webroot
A is toch in bijvoorbeeld een map include/settings/connect.php
B is dat het op een andere site staat?
Gewijzigd op 24/08/2012 12:49:32 door Donny Wie weet
Bv
A C:\websites\donny.com\htdocs\include\settings
B C:\websites\donny.com\config
Alleen PHP kan in de map config
Gewijzigd op 24/08/2012 13:01:19 door Ger van Steenderen
Zodra hij bij de (FTP)-bestanden kan, kan hij toch alles vinden. Of het nou in htdocs\ staat of ervoor.
Als hij binnen komt (op de FTP), dan maakt het toch niet uit of hij in de public-bestanden staat of in de private-bestanden. Hij kan dan overal komen.
Kijk, config.php kan je wel benaderen, maar er niets uit halen.
En nee, ik sla de wachtwoorden niet eerst op in een variabele voordat ik ze 2 regels later eenmalig gebruik.
Om maar eens 2 dingen te noemen van de waslijst van beveiligingen die we hier hanteren.
Daarbij ben ik de enige gebruiker van de FTP.... hoe kan iemand via internet achter mijn gebruikersnaam (en wachtwoord) komen?
Gebruikersnaam en wachtwoord zijn wel te achterhalen via een virus, brute force, xss en noem maar op.
Het hele idee moet nu net zijn dat als iemand je gebruikersnaam en wachtwoord achterhaald, en ook nog FTP toegang tot de server krijgt, hij nog steeds niet bij de user en password van de database mag kunnen komen. Dus als de FTP gejailed is, en de file ligt buiten de root van de gehackte gebruiker is het nog steeds "veilig"