Door
Ozzie PHP
op 14-10-2014 01:08
gewijzigd op 14-10-2014 01:08
5.124 views
Maandag geha-c-ktdag!
Ik kreeg vandaag een mailtje van m'n hostingprovider met de mededeling dat een van m'n e-mailadressen behoort tot de 1,3 miljoen .nl e-mailadressen die in handen zijn gevallen van hackers.
Mijn hostingprovider vermeldt in de mail dat hun server niet gehackt is, maar dat het een wereldwijde hack betreft op 100.000'en websites. Er wordt geadviseerd om onmiddelijk je wachtwoord te veranderen.
Wat ik dus vreemd vind, is dat je je wachtwoord moet wijzigen. Dit houdt dus in dat mijn wachtwoord mogelijkerwijs gehackt is. Dan vraag ik me af hoe dat kan. De enige plek waar dat wachtwoord is opgeslagen, is toch op de server van mijn hostingprovider? En dan neem ik ook nog aan dat het versleuteld is opgeslagen. Mijn hostingprovider zegt dat hun servers niet gehackt zijn. Hoe zouden die hackers dan aan mijn wachtwoord moeten zijn gekomen? Een man-in-the-middle attack lijkt me dan de enige optie, maar ik ga er vanuit dat mijn gebruikersnaam en wachtwoord over een versleutelde verbinding worden verstuurd. Ik snap dus niet hoe dat zou kunnen. Iemand die hier meer over kan zeggen?
Haha ik ben niet terug, daarvoor heb ik helaas te weinig tijd :-) Maar misschien dat ik af en toe weer eens wat plaats.
Met mij gaat alles prima hoor. Hier ook nog alles op rolletjes?
Ik bedoelde een hash van het wachtwoord. En uiteraard moet er geen mogelijkheid zijn tot sql injectie e.d.
Hash is zo'n breed begrip. je hebt [php]md5[/php], [php]sha1[/php] en noem maar op. (zelf gebruik ik [php]bcrypt[/php]. lees hier waarom).
Belangrijk is dat het het complete plaatje beveiligd is
Ik bedoel alles. Van server beveiliging tot database beveiliging. Tot netwerk beveiliging. (ligt eraan of je eigen servers host etc maar goed je snapt me wel)
En zo zijn er nog een aantal, en dan hebben we het nog niet over spamming enzo.
Veel methodes gebruik je ook in combinatie met elkaar of voer je ze achteréénvolgens uit. Wat ik alleen probeer te zeggen is dat je met alleen SQL injection beveiliging + hashen van wachtwoorden er niet bent ;-)
Welke ik pas geleden ook tegen kwam was een var_dump van een Zend_Db object waar dus netjes de db connectie gegevens in stonden. Dus teveel debug informatie geven (sowieso de vraag waarom je dat live toont maar goed) is ook niet echt een goed plan ;-)
>> Welke ik pas geleden ook tegen kwam was een var_dump van een Zend_Db object waar dus netjes de db connectie gegevens in stonden.
En dat stond live? Aiii... da's niet handig.
>> Maar misschien dat ik af en toe weer eens wat plaats.
Wat ik zelf heel handig zou vinden, maar waar ik nog niet zo heel veel van weet, is een security topic waar al die zaken die jij hiernboven noemt aan bod komen. Gewoon in het kort "wat is het gevaar", "hoe werkt het (ongeveer)" en "hoe los je het op". Dus als je niet weet wat je moet plaatsen, zou dit wel een heel mooi topic zijn :)
Wat ik zelf heel handig zou vinden, maar waar ik nog niet zo heel veel van weet, is een security topic waar al die zaken die jij hierboven noemt aan bod komen. Gewoon in het kort "wat is het gevaar", "hoe werkt het (ongeveer)" en "hoe los je het op". Dus als je niet weet wat je moet plaatsen, zou dit wel een heel mooi topic zijn :)
Thanks Ward. Die had je al eens gegeven ;) Maar het lijkt me mooi als hier op phphulp zelf zo'n topic komt. En die ook ingaat op serverbeveiliging. Lijkt me erg nuttig.
Het probleem is dat het onderwerp zo groot is dat je voor elke methode wel een heel topic kan beginnen. Ik zou zeggen pak een aantal termen uit de sheet van Ward; google ze en leer.
En al doende leert men. Dus install thuis eens een servertje maak een kleine applicatie met login + bestandsbeheer o.i.d en ga eens lekker dingen slopen :-)
In het voorbeeldje wat ik je gaf... er is toch geen hacker die B4S_ijZ3lD0orn$123! kan raden?
Dat is een aanname.
Ozzie PHP op 14/10/2014 02:14:53
Dus als je zo'n soort wachtwoord gebruikt op een betrouwbare site,
Zelfs digid is lek.
Ozzie PHP op 14/10/2014 02:14:53
(even ervan uitgaande dat alles met een beveiligde verbinding gebeurt)?
Heartbleed & Poodle bekend bij jou?
Er word tijdens het programmeren van een script altijd geopperd, dat je de beveiliging gelijk moet mee nemen in het proces en niet achteraf.
Hierin word altijd aangegeven, vertrouw nooit, maar dan ook nooit, de gebruiker op je website, je weet immers niet wat ze uitspoken.
Als je dit gaat vergelijken met een hacker, dan is het aannemelijk dat ze een wachtwoord B4S_ijZ3lD0orn$123! niet raden.
Maar als een hacker, toegang weet te krijgen tot de database en alle persoonlijke informatie in handen weet te krijgen, dan is dit denk ik ook waardevol.
Laten we het volgende eens aannemen tot aan 14 oktober:
- Alle servers & geplaatste gehoste websites waren up-to-date op deze datum
- Alle websites waren voorzien van een SSL certificaat (vandaag nog steeds ;-) in aansluiting op je andere topic)
Wie zegt dat er dan nog steeds geen gevaar is voor bijvoorbeeld:
- Poodle ( aangekondigd in september 2014, maar laten we eens aannemen dat de beheerder op vakantie was voor 4 weken )
- Drupal bugs die nog niet ontdekt zijn.
Een gebruiker is niet te vertrouwen, een beheerder ook niet, je kunt jezelf niet eens vertrouwen, aangezien je zelf ook niet alles weet.
Aannames zijn gevaarlijk om te doen, net zoals dat een server beheerder kan zeggen, we zijn niet gehackt... Diginotar heeft ook wel eens wat verzwegen destijds...en die zijn nu........juist... failliet.
Tuurlijk moet je uitkijken met aannames... maar jullie gaan uit van bugs die nog niet bekend zijn. Dan wordt het lastig om je daartegen te wapenen. Wat is de conclusie van het verhaal? Dat je een nooit 100% veilige website kan opleveren? Want daar komt het dan wel op neer.
En dat heeft ook zo zijn zwakheden. Zo heeft bcrypt weinig geheugen nodig, waardoor het relatief snel te brute-forcen als je FPGA's gebruikt. Een betere keuze zou in dat opzicht scrypt zijn, maar dat zit nog niet standaard in PHP, voor zover ik weet.
In de praktijk zegt dat getheoretiseer echter niet zoveel, omdat het vaak al veel eerder strandt op aannames en op onwetendheid, onwil, onvermogen en onkunde. De een weet niet wat SSL is en de ander wil er geen paar tientjes aan besteden, maar het eindeffect van die onwetendheid of onwil is per saldo hetzelfde: geen goede beveiliging.
