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.
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.
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.
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


A is toch in bijvoorbeeld een map include/settings/connect.php
B is dat het op een andere site staat?

Nee niet op een andere site maar in andere map dan waar de website in staat.
Bv
A C:\websites\donny.com\htdocs\include\settings
B C:\websites\donny.com\config

Alleen PHP kan in de map config
A.... inc/connect.php

Zodra hij bij de (FTP)-bestanden kan, kan hij toch alles vinden. Of het nou in htdocs\ staat of ervoor.
Dus jij legt gewoon de sleutel van je huis onder de bloempot naast de voordeur want die inbreker komt toch wel binnen?
Nee, net een ander plekje ;). Maar 't idee wel.
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.
@eddy: Je moet de ftp natuurlijk wel jailen tot de user, en root geen ftp access geven. Daarnaast heb ik bij mij de ftp verbonden aan ip adressen, ftp gaat alleen maar vanaf een vooraf toegestane locatie.
Om maar eens 2 dingen te noemen van de waslijst van beveiligingen die we hier hanteren.
O, nou zo goed ben ik dan niet beveiligd.
Daarbij ben ik de enige gebruiker van de FTP.... hoe kan iemand via internet achter mijn gebruikersnaam (en wachtwoord) komen?
@Eddy: nu snap ik het even niet meer. Eerst zeg je dat iemand via de FTP kan binnen komen, en nu weer niet.

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"

Reageren