Wat heeft coderen voor nut?

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Pagina: 1 2 volgende »

Han php

Han php

23/08/2012 21:22:45
Quote Anchor link
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.
Gewijzigd op 23/08/2012 21:23:27 door Han php
 
PHP hulp

PHP hulp

14/11/2024 03:13:03
 
John Berg

John Berg

23/08/2012 21:32:01
Quote Anchor link
Ik gebruik heel vaak hetzelfde wachtwoord. Ik zou het toch niet fijn vinden als een webmaster mijn plain wachtwoord met email adres kon zien en daarmee op twitter, facebook tweakers e.d. kon inloggen.

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

Han php

23/08/2012 21:34:39
Quote Anchor link
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.
 
John Berg

John Berg

23/08/2012 21:39:59
Quote Anchor link
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.
 
Bart V B

Bart V B

23/08/2012 21:44:42
Quote Anchor link
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.
 
Obelix Idefix

Obelix Idefix

23/08/2012 21:57:20
Quote Anchor link
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 :(
 
Lex van der poel

lex van der poel

23/08/2012 22:40:01
Quote Anchor link
Ik vind dat als je bij een forum of dergelijke geregistreerd staat dat je er dan wel zeker van wilt zijn dat je gegevens veilig zijn en dat er ook geen een database bouwer jouw wachtwoord kan zien... Dus daarom is het voor privacy redenen ook van belang.
 

23/08/2012 22:57:20
Quote Anchor link
Je bent er nooit zeker van dat een beheerder je paswoord niet kan zien, ook al slaat hij ze gecodeerd op. Uiteindelijk verstuur jij je paswoord ongecodeerd op en wordt het pas verwerkt met bijvoorbeeld md5 op de server. Dat hele traject is je paswoord dus zichtbaar te maken.

Wat dat betreft is er maar een ding goed en dat is met https werken.
 
Write Down

Write Down

23/08/2012 23:35:47
Quote Anchor link
Voor mij is toch het belangrijkste: hackers. Een beheerder, die kan als hij echt wil toch altijd een methode vinden om je wachtwoord te ontfutselen. Jammer als dat gebeurd, maar dat weet je op voorhand. Als je dat niet wil, registreer je je beter nergens.

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

Tim van Norde

24/08/2012 00:19:46
Quote Anchor link
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.
 
Write Down

Write Down

24/08/2012 00:44:25
Quote Anchor link
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 :-)
 
Eddy E

Eddy E

24/08/2012 09:36:37
Quote Anchor link
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.
 
Ger van Steenderen
Tutorial mod

Ger van Steenderen

24/08/2012 12:34:06
Quote Anchor link
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
 
Donny Wie weet

Donny Wie weet

24/08/2012 12:48:58
Quote Anchor link
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?
Gewijzigd op 24/08/2012 12:49:32 door Donny Wie weet
 
Ger van Steenderen
Tutorial mod

Ger van Steenderen

24/08/2012 13:00:25
Quote Anchor link
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
Gewijzigd op 24/08/2012 13:01:19 door Ger van Steenderen
 
Eddy E

Eddy E

24/08/2012 13:39:15
Quote Anchor link
A.... inc/connect.php

Zodra hij bij de (FTP)-bestanden kan, kan hij toch alles vinden. Of het nou in htdocs\ staat of ervoor.
 
Ger van Steenderen
Tutorial mod

Ger van Steenderen

25/08/2012 09:38:21
Quote Anchor link
Dus jij legt gewoon de sleutel van je huis onder de bloempot naast de voordeur want die inbreker komt toch wel binnen?
 
Eddy E

Eddy E

25/08/2012 10:00:56
Quote Anchor link
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.
 
John Berg

John Berg

25/08/2012 10:11:25
Quote Anchor link
@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.
 
Eddy E

Eddy E

25/08/2012 10:16:53
Quote Anchor link
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?
 
John Berg

John Berg

25/08/2012 10:23:51
Quote Anchor link
@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"
 

Pagina: 1 2 volgende »



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.