[PHP/MySQL] beveiliging bij connectie

[Yo-han]

Mensen ik zit met een grote vraag, en ben er achter gekomen dat veel meer mensen die vraag hadden moeten stellen.
Het probleem is namelijk het volgende:

Ik ben een applicatie aan het ontwerpen voor een psychologe die online haar klanten wil behandelen. Nu draait een groot deel van de site op een en maa ssl verbinding en ook de connectie met de database gebeurt over de ssl verbinding. Nu zou je denken dat de connectie helemaal veilig is maar aangezien MySQL 4.0 nog niet helemaal ssl een ssh ondersteund zijn er dus nog aardig wat beveiligingslekken...

Zo kwam ik er achter dat het verzenden van het paswoord en de loginnaam helemaal goed gaat. Maar dat het teruggeven tragisch is... Met een sniffer kan iedereen volgens na wat lezen, een groot deel van de persoonlijke gegevens uitlezen. Er is zelfs een leuke verbinding te leggen.
Met dit gegeven op zak ben ik eens opzoek gegaan op het net samen met mijn grote vriend de sniffer en tot mijn grote verbazing kwam ik er achter dat ik niet de enige was met dit probleem.

Nu heb ik in de search, op google gezocht maar vond niet direct mooie oplossingen hiervoor. Mischien is er iemand op GOT die hier ervaring mee heeft of een goeie link weet waar meer info over dit probleem te vinden is...?

[Verwijderd]

ach got gebruikt het toch ook niet... dus ook mijn got password zou zo gesnift kunnen worden

offtopic:
wat is de site van die psychologe?? want had laatst iemand die ook psygoloog was en het zelfde wilde, ik wil ff weten of het de zelfde is

[Yo-han]

Verwijderd schreef op 21 May 2003 @ 18:58:
ach got gebruikt het toch ook niet... dus ook mijn got password zou zo gesnift kunnen worden

offtopic:
wat is de site van die psychologe?? want had laatst iemand die ook psygoloog was en het zelfde wilde, ik wil ff weten of het de zelfde is

Dat zeg ik niet, maar de inlognamen en paswoorden vliegen zonder speciale handelingen op de servers gewoon vrij rond tussen de mysql-server en de client... Kijk en das klote.
Mijn vraag is dus hoe anderen dit opgelost hebben.

offtopic:
Ik kan niet zomaar met prive gegevens van klanten gaan gooien, maar haar voornaam is Marijke

[HunterPro]

dayoman schreef op 21 May 2003 @ 19:02:
[...]


Dat zeg ik niet, maar de inlognamen en paswoorden vliegen zonder speciale handelingen op de servers gewoon vrij rond tussen de mysql-server en de client... Kijk en das klote.
Mijn vraag is dus hoe anderen dit opgelost hebben.

offtopic:
Ik kan niet zomaar met prive gegevens van klanten gaan gooien, maar haar voornaam is Marijke

euh, gewoon zorgen voor zo min mogelijk hops tussen je mySQL bak en je webserver? Zowiezo belangrijk als je flink wat hits hebt en alles uit mySQL put? Oftewel een vlan? Met een loadbalancer er voor? En een firewall?

ik zie het probleem niet?

[ Voor 6% gewijzigd door HunterPro op 21-05-2003 19:04 ]

[ArchRAIDen]

Probeer dit eens:
(ooit ook hier ergens vandaan geplukt)

(1) Server stuurt client random var, $rnd

(2) Client neemt MD5 hash van ingetyped password, $md5up = md5($userpass)

(3) Client string concat (1) met (2) en neemt daar md5 hash van, $net = md5($md5up.$rnd)

(4) Client stuurt server $net, niet in plaintext en ook geen replay attack mogelijk

(5) Server haalt echte gehashde wachtwoord uit database, $md5realpass. Wachtwoorden staan niet plaintext in de database dus.

(6) Server vergelijkt. $net == md5($md5realpass . $rnd). Als gelijk, login correct.


<meuk>

[ Voor 23% gewijzigd door ArchRAIDen op 21-05-2003 19:06 ]

[GarBaGe]

losse SSL-client gebruiken en vanaf MySQL lokaal naar de SSL-applicatie en die server verder afschermen...
MySQL + Apache + PHP op 1 machine, betekent dat je alleen poort 443 (SSL) open hoeft te hebben.
Op de machine zelf kan je gewoon niet ge-encrypt werken...

[Verwijderd]

quote: http://www.mysql.com/doc/en/General_security.html

Do not transmit plain (unencrypted) data over the Internet. These data are accessible to everyone who has the time and ability to intercept it and use it for their own purposes. Instead, use an encrypted protocol such as SSL or SSH. MySQL supports internal SSL connections as of Version 4.0.0. SSH port-forwarding can be used to create an encrypted (and compressed) tunnel for the communication.

In veel gevallen zal een verbinding tussen een MySQL server en client verlopen over een netwerk dat afgeschermd is van het Internet. Hoewel dat geen garantie is voor veiligheid van je data, zorgt dat in ieder geval wel dat niet iedereen op het Internet met een packet sniffer usernames en passwords kan sniffen.

[Verwijderd]

/me heeft anderhalf jaar geleden al zo'n site opgezet voor een klant

[bigtree]

Je kan ook compression inschakelen bij het connecten (PHP >= 4.3), dan gaat je data in ieder geval niet plain-text van client naar server en vice versa. Kijk eens naar de parameter client_flags van mysql_connect.

[Yo-han]

ArchRAIDen schreef op 21 May 2003 @ 19:05:
Probeer dit eens:
(ooit ook hier ergens vandaan geplukt)

(1) Server stuurt client random var, $rnd

(2) Client neemt MD5 hash van ingetyped password, $md5up = md5($userpass)

(3) Client string concat (1) met (2) en neemt daar md5 hash van, $net = md5($md5up.$rnd)

(4) Client stuurt server $net, niet in plaintext en ook geen replay attack mogelijk

(5) Server haalt echte gehashde wachtwoord uit database, $md5realpass. Wachtwoorden staan niet plaintext in de database dus.

(6) Server vergelijkt. $net == md5($md5realpass . $rnd). Als gelijk, login correct.


<meuk>

Is zeker een keer te proberen!

GarBaGe schreef op 21 mei 2003 @ 19:08:
losse SSL-client gebruiken en vanaf MySQL lokaal naar de SSL-applicatie en die server verder afschermen...
MySQL + Apache + PHP op 1 machine, betekent dat je alleen poort 443 (SSL) open hoeft te hebben.
Op de machine zelf kan je gewoon niet ge-encrypt werken...

Gebeurt nu al min of meer maar is niet de meest relaxte oplossing

Verwijderd schreef op 21 mei 2003 @ 19:13:
[...]

In veel gevallen zal een verbinding tussen een MySQL server en client verlopen over een netwerk dat afgeschermd is van het Internet. Hoewel dat geen garantie is voor veiligheid van je data, zorgt dat in ieder geval wel dat niet iedereen op het Internet met een packet sniffer usernames en passwords kan sniffen.

Eeeh, als je kan achterhalen waar de client zijn data wil halen moet het nog steeds mogelijk zijn. Mischien niet met sniffer maar dan op een andere mogelijkheid...

[Yo-han]

bigtree schreef op 21 May 2003 @ 19:27:
Je kan ook compression inschakelen bij het connecten (PHP >= 4.3), dan gaat je data in ieder geval niet plain-text van client naar server en vice versa. Kijk eens naar de parameter client_flags van mysql_connect.

Dit is volgens mij een zeer bruikbare oplossing als ik het even snel bekijk. Als je dit combineert met eerder genoemde opties...

[HunterPro]

dayoman schreef op 21 mei 2003 @ 19:28:
[...]

[...]


Eeeh, als je kan achterhalen waar de client zijn data wil halen moet het nog steeds mogelijk zijn. Mischien niet met sniffer maar dan op een andere mogelijkheid...

Ga je een bank-site draaien of zo Niks is beveiligd tegen physical attacks. Als de persoon die jij niet vertrouwt bij jouw servers kan, bijvoorbeeld in een colo, moet je maar een eigen colo afhuren of een kluis-rackkast kopen.

Ik denk dat je het gevoel van 'veiligheid' een beetje naar onredelijke grenzen trekt. Hoezo moeten er tussen de mySQL client en server (het lijkt me dat je een webapplicatie draait die met een HTTPS/HTML frontend werkt) een stuk extranet (internet dus) zitten? Lijkt me enigszins vaag als jij zo graag die verbinding tussen die 2 secure laat verlopen.
[edit]
De beste beveiliging is gewoon de UTP-plug er uit, en de deur op slot. Een forse waakhond wil ook nog wel helpen.

[ Voor 8% gewijzigd door HunterPro op 21-05-2003 20:11 ]

[Yo-han]

HunterPro schreef op 21 mei 2003 @ 20:11:
[...]


Ga je een bank-site draaien of zo Niks is beveiligd tegen physical attacks. Als de persoon die jij niet vertrouwt bij jouw servers kan, bijvoorbeeld in een colo, moet je maar een eigen colo afhuren of een kluis-rackkast kopen.

Ik denk dat je het gevoel van 'veiligheid' een beetje naar onredelijke grenzen trekt. Hoezo moeten er tussen de mySQL client en server (het lijkt me dat je een webapplicatie draait die met een HTTPS/HTML frontend werkt) een stuk extranet (internet dus) zitten? Lijkt me enigszins vaag als jij zo graag die verbinding tussen die 2 secure laat verlopen.
[edit]
De beste beveiliging is gewoon de UTP-plug er uit, en de deur op slot. Een forse waakhond wil ook nog wel helpen.

Overdreven??? Ik geloof dat jij niet begrijpt wat een psychologe doet...

Lijkt me niet erg tof dat al je psychische problemen of problemen die je met je baas hebt op straat liggen inclusief je telefoonnummer en mail adres...

[ripexx]

dayoman schreef op 21 mei 2003 @ 23:13:
[...]


Overdreven??? Ik geloof dat jij niet begrijpt wat een psychologe doet...

Lijkt me niet erg tof dat al je psychische problemen of problemen die je met je baas hebt op straat liggen inclusief je telefoonnummer en mail adres...

Je moet natuurlijk wel het kosten aspect in de gaten houden, als je db en webserver op dezelfde fysieke server staan of communiceren via een eigen dedicted netwerk, dan zal niemand de daar bij kunnen, behalve de admins daar. Verder zorg je dat je verbinding met de client via een ssl/https verbinding gaat zodat dat verkeer beveiligd is, meer garanties kun je niet geven. Het blijven keuzes, en die psychologe zal ook niet alle files in een kluis bewaren, maar alles gewoon in een afgesloten archief kast doen, die nog met een tandenstoker te open is. Gewoon een kwestie van afwegen.

[Verwijderd]

ripexx schreef op 21 mei 2003 @ 23:28:
[...]

Je moet natuurlijk wel het kosten aspect in de gaten houden, als je db en webserver op dezelfde fysieke server staan of communiceren via een eigen dedicted netwerk, dan zal niemand de daar bij kunnen, behalve de admins daar. Verder zorg je dat je verbinding met de client via een ssl/https verbinding gaat zodat dat verkeer beveiligd is, meer garanties kun je niet geven. Het blijven keuzes, en die psychologe zal ook niet alle files in een kluis bewaren, maar alles gewoon in een afgesloten archief kast doen, die nog met een tandenstoker te open is. Gewoon een kwestie van afwegen.

Voordat je een site gaat beveiligen, moet je je eerst het volgende afvragen:

"Wat heeft een hacker aan de informatie die hij/zij uit het beveiligde deel kan halen?"

Als je logisch nadenkt weet je dat een hacker het echt geen reet kan interesseren of er iemand zelfmoordneigingen heeft, overspannen is van zijn suffe baantje of wat voor problemen ook.

Kortom, is imo een SSL verbinding al eigenlijk wat overdreven. Zorg gewoon dat wachtwoorden niet zomaar gespoofed kunnen worden door ze te crypten met md5() of sha1()... Daarnaast zorg voor een beetje degelijk inlogsysteem en controleer de variabelen die door de gebruiker geëdit kunnen worden al dan niet met preg_match().

Geloof mij, dan zit je echt wel goed hoor! D'r is geen hacker die er zoveel moeite in zal steken om andermans probleempjes te kunnen lezen...