geha-c-ktdag
Pagina: « vorige 1 2 3 volgende »
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?
Quote:
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 md5, sha1 en noem maar op. (zelf gebruik ik bcrypt. lees hier waarom).
Quote:
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)
Zomaar een lijstje:
- Bruteforce
- Man in the middle attacks (**hint: WiFI Pineapple**)
- SQL injections
- Cross Site Scripting,
- Exploits
- DDos
- Session / cookie hijacking
- Remote File inclusion / Path Traversal
- X-Forwarded-For spoofing
- xPath injection
- Stack buffer overflows / Heap overflows
- Arp Poisoning
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 ;-)
Niels
Gewijzigd op 29/10/2014 21:59:40 door Niels K
>> Hier ook nog alles op rolletjes?
Ja, volgens mij wel, haha...
>> 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 :)
Laterzzz
Ozzie PHP op 29/10/2014 22:22:56:
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 :)
PHP Security Cheat Sheet
Gewijzigd op 29/10/2014 22:29:38 door Ward van der Put
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 :-)
Gewijzigd op 29/10/2014 22:36:59 door Niels K
Ozzie PHP op 14/10/2014 02:14:53:
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.
Voorbeeld: Drupal melding van 29 oktober
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.
Niels Kieviet op 29/10/2014 21:54:53:
zelf gebruik ik bcrypt
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.
Ozzie PHP op 30/10/2014 12:24:13:
Dat je een nooit 100% veilige website kan opleveren? Want daar komt het dan wel op neer.
Ja, in theorie wel, want dit geldt voor elk technisch project, van auto's en vliegtuigen tot webapplicaties. Als je daar bang voor bent, moet je zakken voor je rijbewijs, vliegangst ontwikkelen en vooral altijd thuis blijven ... en aldaar vervolgens slachtoffer worden van verstikking, verdrinking, brandwonden, het inslikken van giftige producten of een valpartij.
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.
"Mijn hostingprovider zegt dat hun servers niet gehackt zijn. "
>> je kunt jouw klanten/websitegebruikers dus nooit een 100% veilige site beloven.
Enough said ;-)
Maar je verbindt nu 2 verschillende dingen aan elkaar ;-)
De hostingprovider geeft aan dat hun servers NIET gehackt zijn. Dus de vraag is hoe de hackers dan je wachtwoord kunnen weten. Ja, het zou kunnen dat je hetzelfde wachtwoord bij een andere site gebruikt die niet goed beveiligd is. Dat zou de enige mogelijkheid zijn lijkt me.
Is iets onoplosbaar, dan is het geen probleem meer, maar een voldongen feit waarin je moet berusten.
Het verschil zien is de kunst.
God, grant me the serenity to accept the things I cannot change,
The courage to change the things I can,
And the wisdom to know the difference.
Klopt. Wat je hoogstens kan beloven, is dat je eventuele (potentiële) zwakke plekken zo snel als mogelijk probeert te verhelpen. Maar let op dat het dan gaat om een inspanningsverplichting en niet om een resultaatverplichting, want dan kun je alsnog gigantisch de sjaak zijn. ;-)
Quote:
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.
Sure, een 100% veilige encryptie bestaat ook gewoon niet. Je moet het een aanvaller alleen zo lastig mogelijk maken.
Zelf ben ik niet zo'n fan van scrypt. Lees onderstaande linkjes maar eens waarom:
- http://blog.ircmaxell.com/2014/03/why-i-dont-recommend-scrypt.html
- http://security.stackexchange.com/questions/26245/is-bcrypt-better-than-scrypt
- http://security.stackexchange.com/questions/4781/do-any-security-experts-recommend-bcrypt-for-password-storage
Voor een hele mooie uitleg plus samenvatting: http://security.stackexchange.com/questions/211/how-to-securely-hash-passwords
Niels
Gewijzigd op 31/10/2014 20:19:56 door Niels K
Dat is op zich duidelijk. Maar wanneer doe je het als programmeur goed? Dus stel we gebruiken bcrypt, maar we staan toe dat hackers oneindig mogen proberen dan lijkt het me niet handig, maar als je bijv. zorgt dat ze maar max. 5 keer kunnen proberen dan zit je wel redelijk safe toch?
Gewijzigd op 01/11/2014 00:19:34 door Ozzie PHP
De conclusie van je eerste link is dat scrypt met zwakke settings ongeveer even sterk is als bcrypt. Het laat zich raden wat er gebeurt als je wél de juiste instellingen gebruikt. ;-)
De algehele teneur van de berichten is dat men scrypt liever niet gebruikt omdat het pas een paar jaar oud is en dus niet zoveel is getest als bcrypt. Echter, als je naar de algoritmiek gaat kijken, wint scrypt met twee vingers in zijn neus. Bovendien zijn de artikelen (op de eerste na) alweer een paar jaar oud en dus geschreven toen scrypt nog erg nieuw was. Inmiddels heeft men scrypt alweer een paar jaar kunnen testen en ik kan me eigenlijk niet herinneren de afgelopen tijd security advisories te hebben gelezen die het gebruik van scrypt afraden.
Het voordeel van bcrypt (zijn 'ouderdom') is meteen ook het nadeel. bcrypt is alweer zo'n 15 jaar oud en dus ingehaald door de technologie. Zoals ik al zei in een eerdere post, is bcrypt slecht bestand tegen een brute force van een heleboel parallelle FPGA's. Verder is bcrypt gebaseerd op blowfish, een algoritme dat ook een aantal zwakke plekken heeft en daardoor niet eens meer wordt gebruikt door degene die het heeft bedacht. Als ik naar scrypt kijk, krijg ik de indruk dat dat een stuk toekomstvaster is.
Pagina: « vorige 1 2 3 volgende »