Hoofdcategorieën
Device Settings

[RSS] [quick] Index » Nieuws » Pro » Development » PHP-update 5.3.7 bevat beveiligingsgat

PHP-update 5.3.7 bevat beveiligingsgat

Door Dimitri Reijerman, dinsdag 23 augustus 2011 12:30, views: 17.459

De PHP-ontwikkelaars hebben een waarschuwing uitgegeven waarin dringend wordt aangeraden om de laatste update met versienummer 5.3.7 niet te installeren of te gebruiken. De update zou een ernstige fout bevatten in de crypt()-functie.

Met de crypt()-functie van de scripttaal kan een string versleuteld worden en van een hash worden voorzien. Echter als in PHP-versie 5.3.7 de crypt()-functie wordt aangeroepen met het MD5-algoritme en enkele salt-karakters, dan geeft de functie alleen de salt-karakters terug in plaats van de gewenste hash. Het probleem zou niet optreden als crypt() wordt aangeroepen met het DES- of Blowfish-algoritme, zo meldt de bugreport.

Door de fout in de versleutelingsfunctie wordt door de PHP-ontwikkelaars sterk afgeraden om de update te installeren. Een nieuwe update met versienummer 5.3.8 zou op korte termijn, mogelijk binnen enkele dagen, beschikbaar moeten komen om het probleem met de crypt()-functie te verhelpen. De bug is echter al afgelopen vrijdag verholpen.

Omdat PHP op een groot aantal websites wordt gebruikt, zijn bugs in de scripttaal potentieel gevaarlijk. Om deze gaten te dichten brengen de ontwikkelaars met regelmaat updates uit.

Volgende 13:17 Fanatec introduceert modulaire ClubSport-stuurbasis
Vorige 12:24 Sony verandert Home in social games-platform
Advertentie

Lees meer over

Gerelateerde content

Gerelateerde jobs

Reacties

Flat modeFlat mode Sorteer aflopendSorteer aflopend Moderatie FAQModfaq
Niveaufilter: -1 Ongewenst: 82 reacties zichtbaar820 Off-topic / Irrelevant: 82 reacties zichtbaar82+1 On-topic: 64 reacties zichtbaar64+2 Informatief: 7 reacties zichtbaar7+3 Spotlight: 0 reacties zichtbaar0
«  1  2  »

Door Xesxen, dinsdag 23 augustus 2011 12:33

Score: 0
Laat ik net mijn server hebben geinstalleerd. Eens kijken welke versie ik draai, want ik gebruik dit toch wel vaak.

EDIT: Gelukkig zit er in de debian distro een oudere versie van PHP. (5.2.6)

[Reactie gewijzigd door Xesxen op dinsdag 23 augustus 2011 12:34]

Door Kamiquasi, dinsdag 23 augustus 2011 12:59

Score: 1
Gelukkig zit er in de debian distro een oudere versie van PHP. (5.2.6)
Zo gelukkig is dat nou ook weer niet - de nieuwere versies dichten ook een halve berg beveiligings problemen.

Op zich niets mis met 5.3.7 tenzij je de MD5 functie gebruikt, je salt toevallig in het verkeerde PHP keelgat schiet, en je geen sanity check doet op het resultaat.

Door Myrdhin, dinsdag 23 augustus 2011 13:08

Score: 1
Gelukkig doet Debian aan backporting van bug fixes.. Dus ondanks dat je een oudere versie draait worden de bugs vaak gebackport zodat je toch veilig bent.

Door daft_dutch, dinsdag 23 augustus 2011 13:08

Score: 1
Zo gelukkig is dat nou ook weer niet - de nieuwere versies dichten ook een halve berg beveiligings problemen.
Sorry??? Debian heeft naar mijn weten een zeer actief veiligheidsteam dat actief gaten in de software dicht met patches op de versie de Debian levert.
Dit gebeurt voor alle packages in de Debian repository. Dus ook bijvoorbeeld phpmyadmin. Waardoor Debian IMHO Veel veiliger is dan bijvoorbeeld Redhat omdat die een zeer kleine repocitory heeft. Waardoor mensen geforceerd worden zelf software te installeren waar ze zelf de veiligheid van moeten garanderen! Ik noem naar een site ontwikkeltraject waar een phpmyadmin in zit. en dat na veel testen in productie wordt gezet met een phpmyadmin waar worms graag gebruik van maken. (iets was onmogelijk is met de 12 jaar ongewijzigde Debian methodiek)

edit: bij mijn servertje thuis is de phpmyadmin alleen van af de localhost geschikbaar. omdat ik toch via ssh inlog kan ik net zo goed een poortje forwarden.

[Reactie gewijzigd door daft_dutch op dinsdag 23 augustus 2011 13:15]

Door arjankoole, dinsdag 23 augustus 2011 13:14

Score: 1
Zo gelukkig is dat nou ook weer niet - de nieuwere versies dichten ook een halve berg beveiligings problemen.
Misschien ben je niet goed bekend met hoe distributies werken, dus wellicht goed om het even uit te leggen.

Een distributie bepaald op een bepaald moment welke versie ze gebruiken binnen een bepaalde release, voor die versie van debian is dat dus 5.2.6. Als er vervolgens binnen PHP bugs/security issues opduiken die relevant zijn voor de versie die Debian voert binnen een release, dan zal het Debian team de patches voor die problemen ook implementeren op hun versie, en een update verstrekken. Daarom is het op distributies (maakt niet uit of je nou aanhanger bent van debian, redhat of andere smaken) altijd van best groot belang dat je de updates controlleert. Ze bevatten namelijk doorgaans security fixes. (en zo niet, staat dat aangegeven, en kun je dus wat conservatiever zijn qua instalatie)

Door demonite, dinsdag 23 augustus 2011 14:03

Score: 1
Begrijp ik dat nou goed dat je bij debian dus een versie 5.2.6 + x-aantal patches krijgt ipv een officiele versie met een release nummer? Dat kan toch niet waar zijn? Hoe weet het debian team nou dat een patch voor een probleem in PHP dat in 5.3.4 gefixed is ook werkt met 5.2.6 ?

Door gertvdijk, dinsdag 23 augustus 2011 15:13

Score: 2
Begrijp ik dat nou goed dat je bij debian dus een versie 5.2.6 + x-aantal patches krijgt ipv een officiele versie met een release nummer? Dat kan toch niet waar zijn? Hoe weet het debian team nou dat een patch voor een probleem in PHP dat in 5.3.4 gefixed is ook werkt met 5.2.6 ?
Backporten heet dat. Security fixes worden vaak 'upstream' al vaak in oudere branches (5.2.x) aangeboden, maar soms moet je als distro nou eenmaal zelf wel eens wat backporten als het zo ernstig is.
En soms is een fix niet 1-op-1 over te nemen door het verschil in code. Dan wordt er vaak wel hulp geboden door de upstream ontwikkelaars of zijn er ook andere distro's met hetzelfde probleem waardoor er gewoon kan worden 'afgekeken'.

Daarnaast worden security fixes onder te tafel al gemaakt alvorens de details worden onthuld. (CVE details zie je vaak pas als er al een fix voor is.)

Door daft_dutch, dinsdag 23 augustus 2011 17:08

Score: 1
Om een voorbeeld te noemen.
Debian stable zit sinds vorige week op iceweasel (lees firefox) versie 3.5.16-9 En een paar bugs die deze security update veroorzaakte zijn gevonden zijn Firefox Versie 3.6.20
Ik pak een Windows VM met firefox 3.6 update naar laatste versie: You’re now running Firefox 3.6.20
Debian Top product!!

[Reactie gewijzigd door daft_dutch op dinsdag 23 augustus 2011 20:01]

Door hostname, dinsdag 23 augustus 2011 13:01

Score: 1
EDIT: Gelukkig zit er in de debian distro een oudere versie van PHP. (5.2.6)
Dan draai je een oude Debian, in de huidige stable (Squeeze) zit 5.3.3.

Door deadinspace, dinsdag 23 augustus 2011 17:09

Score: 1
Dan draai je een oude Debian, in de huidige stable (Squeeze) zit 5.3.3.
Inderdaad, en dat is geen handige keuze als je net geinstalleerd hebt. De security support voor Debian 5.0 (Lenny) loopt in april 2012 af, en als er dan een veiligheidslek wordt ontdekt in de PHP die in Lenny zit krijg je daar geen updates voor.

Dus mijn advies aan Xesxen: upgrade naar 6.0, of installeer die server nog een keer maar dan met 6.0 ;)

Door demilord, dinsdag 23 augustus 2011 18:41

Score: 1
[...]

Inderdaad, en dat is geen handige keuze als je net geinstalleerd hebt. De security support voor Debian 5.0 (Lenny) loopt in april 2012 af, en als er dan een veiligheidslek wordt ontdekt in de PHP die in Lenny zit krijg je daar geen updates voor.

Dus mijn advies aan Xesxen: upgrade naar 6.0, of installeer die server nog een keer maar dan met 6.0 ;)
1 voordeel is dat je de hardste bugs in 6.0 eruit kan laten slopen, dus een beetje kan laten rijpen voor je gaat updaten naar 6.0

Door deadinspace, dinsdag 23 augustus 2011 18:52

Score: 1
1 voordeel is dat je de hardste bugs in 6.0 eruit kan laten slopen, dus een beetje kan laten rijpen voor je gaat updaten naar 6.0
Maar Debian 6.0 is al meer dan een half jaar geleden gereleased, dus eventuele kinderziektes zijn er wel uit, en de resterende security support op 5.0 is korter dan een half jaar.

Dat maakt 5.0 in mijn ogen een slechte keuze voor een nieuwe server, en ook voor bestaande servers moet je onderhand toch eens nagedacht hebben over upgraden.

[Reactie gewijzigd door deadinspace op dinsdag 23 augustus 2011 19:28]

Door thegve, woensdag 24 augustus 2011 00:01

Score: 1
Los van wat deadinspace zegt.
Debian ondersteund altijd 3 versies, oldstable, stable, en testing(soort acceptatie versie).
Deze laatste word uiteraard niet voor productie aangeraden, maar draait al wel op desktops en op ontwikkelservers en dergelijke en word al actief getest door de, in het geval van Debian immense, community.
Als Debian een nieuwe 'stable' lanceert zijn deze doorgaans dan ook echt 'stable'.

Door deadinspace, woensdag 24 augustus 2011 14:22

Score: 0
Debian ondersteund altijd 3 versies, oldstable, stable, en testing(soort acceptatie versie).
Je vergeet unstable (welke weer testgebied voor testing is) ;)

Bovendien wordt oldstable slechts één jaar ondersteund (dat wil zeggen, tot één jaar nadat er een nieuwe stable release is uitgekomen).

Door Sh1fty, dinsdag 23 augustus 2011 12:33

Score: 1
5.x.7 versies zijn vervloekt bij PHP?

Bij gerelateerde content staat een soortgelijk nieuwbericht over versie 5.2.7 :+

Door Zarc.oh, dinsdag 23 augustus 2011 13:01

Score: 0
Voor anderen is de 7 dan weer een lucky number ;)

Door clanerz, dinsdag 23 augustus 2011 12:34

Score: 1
Ik kreeg het al benauwd toen ik het artikel las en had zoiets van dat word dus downtime...

Maar gelukkig staat deze update er nog niet op

Door thomasvk, dinsdag 23 augustus 2011 12:34

Score: 1
Dan vraag ik me toch af of ze bij het PHP-team geen regressietests of unit tests hebben. Zeker bij dit soort functies, die toch redelijk "belangrijk" zijn (dat wil zeggen, dat het vrij ernstig is als er een fout in voorkomt) wil je voorkomen dat er per ongeluk een fout in slipt. Als je gewoon een test suite hebt met unit tests voor alle functies (of alleen de belangrijkste functies) en die draait voor het maken van een release, dan komt zo'n situatie nooit voor.

Door BRAINLESS01, dinsdag 23 augustus 2011 12:42

Score: 1
Er zijn wel geautomatiseerde tests en als je ze uitvoert falen ze. Probleem is dat ze niet gebruikt zijn :P

Door Blue-eagle, dinsdag 23 augustus 2011 13:06

Score: 1
En dat is gewoon nalatig. Als je op zoveel miljoenen servers draait kan je geen updates uitbrengen zonder er 100% zeker van te zijn dat alles klopt. Het stond vroeger al zo bekend als een pruts taaltje. Dit soort nieuws doet ze geen eer aan.

Door Jaccoh, dinsdag 23 augustus 2011 14:55

Score: 0
offtopic:
Die onzin heb ik overigens nog nooit gehoord :). Maar nalatig is het zeker wel als het waar is dat de tests er zijn maar niet uitgevoerd.

Door YopY, dinsdag 23 augustus 2011 13:42

Score: 1
Als ze niet gebruikt worden zit er een zwakke schakel in het releaseproces - dwz dat mensen het (blijkbaar) handmatig moeten doen. Releases moet je via de CI server doen.

...als je die hebt natuurlijk.

Door hostname, dinsdag 23 augustus 2011 13:03

Score: 1
Ze hebben wel een vrij goede en complete testsuite, maar deze geeft gemiddeld zo'n 200 fouten. Dat maakt zo'n testsuite meteen vrij nutteloos aangezien je het dan niet door hebt als er een extra test faalt.

Er wordt nu wel geroepen dat het handig is om die testsuite te fixen, maar dat vergt uiteraard tijd en het lijkt erop dat de PHP developers die tijd liever aan iets anders besteden.

[Reactie gewijzigd door hostname op dinsdag 23 augustus 2011 14:50]

Door intel_478, dinsdag 23 augustus 2011 13:10

Score: 0
Dit is nou een van de redenen dat ik bepaald geen fan ben van php. Die mentaliteit wat testen betreft is niet aan mij besteed.

Door RubenBentein, dinsdag 23 augustus 2011 17:18

Score: 1
Het kan ook zijn dat ze dit scenario gewoon vergeten testen zijn in hun testcase... Het is ook niet dat de hele functie niet meer werkt. Enkel wanneer er gecrypt wordt met MD5 en een eigen salt.
Om hierdoor direct te gaan zeggen dat PHP een mentaliteit heeft van niks te testen is wat grof. Alsof elke developer hier nog nooit een incomplete test heeft geschreven...

Door Antipater, dinsdag 23 augustus 2011 21:05

Score: 1
Alleen in dit geval was er wel degelijk een unittest voor die faalde. De bug was ook nog eens geintroduceerd door met werkende code te rommelen.

Dat je zomaar code released waar het halve internet op draait, wetende dat er allerlei unittests falen, je niet de moeite neemt ze te bekijken en in security code gaat zitten harken...Ik zou dit niet als best practice willen omschrijven.

Door daft_dutch, dinsdag 23 augustus 2011 21:09

Score: 1
Ik ben een grote fan van PHP. De documentatie is uitstekend, functionaliteit,simpliciteit dito
En over testen 200 fouten zijn bekende risico's dus altijd beter dan onbekende risico's.

Mijn automatische test facilitator is geschreven in PHP en de taal bij uitstek voor dit doel. Het zorgt er voor dat we automatisch na een voltooide build automatisch de boel installeren/configureren (snapshot) test omgeving opzetten. (snapshot) en testen. Of de applicatie server nu Windows,Linux of AIX is en de database nu lokaal/remote oracle of MSSQL is. En of de boel nu ESX,VMworkstation of echt is. (snapshot faalt wel eens)
Elke blocking installatie/configuratie bug is een major feature request voor de php code.
En je met php in no time die feature er in kan hacken.

Voor deze toepassing zijn Leesbaarheid,flexibiliteit/aanpasbaarheid heel belangrijk. performance NULL en veiligheid vergelijkbaar met 0

Maar als 24/7 stabiliteit, top performance en data integriteit (zonder dat geen veiligheid) de eisen van jou software zijn. Is PHP niet de software die je zoekt. Dat is nog altijd c en/of c++

[Reactie gewijzigd door daft_dutch op dinsdag 23 augustus 2011 21:10]

Door Niemand_Anders, dinsdag 23 augustus 2011 13:11

Score: 1
Dus dan haal je de testen welke foutmeldingen geven UIT de suite zodat je WEL weet wanneer een correcte test fout gaat. En dan kun je ook rustig een voor een de 200 testen welke fout meldingen geven repareren.

Een test suite welke standaard foutmeldingen geeft is volledig nutteloos. Test dan gewoon niet. Is half goed doen is vele malen erger dan iets niet doen!

Door YopY, dinsdag 23 augustus 2011 13:42

Score: 0
Hoe kunnen ze tijd aan iets anders besteden als hun software gewoon stuk is? :/ wat een baggermentaliteit.

Door Sfynx, dinsdag 23 augustus 2011 18:27

Score: 0
Er wordt nu wel geroepen dat het handig is om die testsuite te fixen, maar dat vergt uiteraard tijd en het lijkt erop dat de PHP developers die tijd liever aan iets anders besteden.
Waarvoor hebben ze die testsuite dan eigenlijk gemaakt? :')

Door daft_dutch, dinsdag 23 augustus 2011 13:18

Score: 0
Dan vraag ik me toch af of ze bij het PHP-team geen regressietests of unit tests hebben. Zeker bij dit soort functies, die toch redelijk "belangrijk" zijn (dat wil zeggen, dat het vrij ernstig is als er een fout in voorkomt) wil je voorkomen dat er per ongeluk een fout in slipt. Als je gewoon een test suite hebt met unit tests voor alle functies (of alleen de belangrijkste functies) en die draait voor het maken van een release, dan komt zo'n situatie nooit voor.
Als jij een keer php Zelf gecompileerd had wist je het antwoord. Er zijn iets van veertien duizend of zo

Door martin149, dinsdag 23 augustus 2011 12:34

Score: 1
Hoe zou dit eigenlijk gevaarlijk kunnen zijn, zo werkt toch gewoon een functie niet, maar zijn er geen grote problemen. Je kunt op deze manier toch niks hacken. (of heb ik het fout?)

EDIT: Mijn host draait gelukkig nog 5.2.17

[Reactie gewijzigd door martin149 op dinsdag 23 augustus 2011 12:37]

Door Xesxen, dinsdag 23 augustus 2011 12:37

Score: 1
Als je gebruikt maakt van hashing om bijv. in te loggen, is dat niet zo handig als de gebruikers niet kunnen inloggen. Ik gebruik de hashing om samen met twee string, username en het password een hash te maken, welke ik daarna valideer met wat in de database staat. Als alles niet meer klopt...

Door Jegorex, dinsdag 23 augustus 2011 12:38

Score: 1
Als je nu een account aanmaakt dan zal het wachtwoord in de database alleen de salt zijn.
Vervolgens kun je met elk willekeurig wachtwoord inloggen.

Door MSalters, dinsdag 23 augustus 2011 13:29

Score: 1
En, om het erger te maken, als je vervolgens naar 5.3.8 upgrade, dan kan niemand meer inloggen met z'n oude passwoord. De 5.3.8 hash zal namelijk vrijwel nooit (<0.000001%) gelijk zijn aan de 5.3.7 hash. Dus je kunt de T.net nieuwsberichten van volgende week voorspellen: een aantal sites zullen een PW reset aankondigen.

Door BRAINLESS01, dinsdag 23 augustus 2011 13:38

Score: 1
Alleen voor nieuwe gebruikers, voor oude gebruikers staat de oude hash nog in de database natuurlijk.

Door cyberstalker, dinsdag 23 augustus 2011 13:50

Score: 1
Niet per se. Bestaande gebruikers zullen nu niet meer kunnen inloggen. Een groot deel van deze gebruikers zal vervolgens een nieuw wachtwoord aanvragen.

Dit nieuwe wachtwoord zal vervolgens onjuist worden opgeslagen maar mensen zullen kunnen inloggen. Wanneer de bug dan vervolgens gefixed wordt kunnen mensen weer niet inloggen tot ze wederom een nieuw wachtwoord aanvragen.

Door poepkop, dinsdag 23 augustus 2011 20:34

Score: 1
Nou volg ik je niet meer, want een 5.3.6 hash zal hetzelfde zijn als een 5.3.8 hash, het is toch gewoon md5?
Overigens, is md5 niet al achterhaald en kan je niet beter sha gebruiken? Of heeft dit ook invloed op sha?

Door Gamebuster, woensdag 24 augustus 2011 08:11

Score: 0
Md5 en sha1 verschillen niet schokkend veel. bcrypt is goed voor login hashes

Door kaneter, dinsdag 23 augustus 2011 12:41

Score: 1
Als crypt() alleen de salt teruggeeft, betekent dit dus in feite dat je op een standaard inlogsysteem dat gebruik maakt van deze functie met elk willekeurig wachtwoord kunt inloggen. Dit geldt natuurlijk niet voor gebruikersaccounts die zijn aangemaakt vóór deze PHP-update.

Edit: spuit11

[Reactie gewijzigd door kaneter op dinsdag 23 augustus 2011 12:43]

Door i-chat, dinsdag 23 augustus 2011 13:16

Score: 1
klopt - die gebruikers kunnen gewoon helemaal NIET inloggen...

Door Cheatah, dinsdag 23 augustus 2011 13:30

Score: 1
Die gaan dus wellicht een nieuw wachtwoord instellen dat wél werkt, maar vervolgens werkt élk ander wachtwoord óók.

Door ChaoZero, dinsdag 23 augustus 2011 12:41

Score: 0
Nee je hebt het goed.
Anderzijds (wanneer je even probeert, en kijkt of bij veranderende invoer dezelfde salts terugkomen!) geeft het wel een klein stukje van de beveiliging bloot.

Stel bijvoorbeeld dat ieder wachtwoord 'ge-salt' wordt met $password_ditiszout, dan zou ik john the ripper instrueren achter iedere try "_ditiszout" te plakken. Scheelt natuurlijk een boel tijd om te bruteforcen maar een sterk wachtwoord blijft een sterk wachtwoord!

Door Tomdevries, dinsdag 23 augustus 2011 12:44

Score: 1
In geval van authenticatie zal je huidige systeem inderdaad falen. Echter, wanneer je met deze bug een nieuwe account registreer wordt je wachtwoord gehashed opgeslagen als de plain salt.

Wanneer bij het inloggen dezelfde crypt wordt gebruikt, die immers altijd dezelfde hash (de salt in dit geval) teruggeeft, is het dus mogelijk om met wat voor wachtwoord dan ook in te loggen.

[Reactie gewijzigd door Tomdevries op dinsdag 23 augustus 2011 12:45]

Door Gertjan, dinsdag 23 augustus 2011 13:05

Score: 1
EDIT: Mijn host draait gelukkig nog 5.2.17
"gelukkig"? Zie de releasenotes van PHP 5.3.7:

All PHP users should note that the PHP 5.2 series is NOT supported anymore. All users are strongly encouraged to upgrade to PHP 5.3.7.

PHP 5.3.0 is meer dan twee jaar geleden uitgekomen. Als ik jou was zou ik op zoek naar een host met een beter upgrade-beleid. Nu nog op de 5.2-tak zitten is onverantwoord, zeker gezien het feit dat een upgrade-procedure meestal wel enige tijd met zich meeneemt. Tenzij je host natuurlijk besluit om 's nachts 'eventjes te upgraden'. In dat geval zou ik zeker op zoek gaan naar iets anders ...

Door arjankoole, dinsdag 23 augustus 2011 15:37

Score: 1
All PHP users should note that the PHP 5.2 series is NOT supported anymore. All users are strongly encouraged to upgrade to PHP 5.3.7.
Dat PHP 'm niet meer officieel support, betekend niet dat de distro's dat ook niet meer doen. Zeker in HA / Enterprise omgevingen geld: als het niet stuk is, ga 't dan niet repareren.

De meeste distro's (lees: de goeie) voeren namelijk gewoon de security fixes door met backports. Qua security ga je er niet op achteruit, alleen qua feature set. Maar als je HA / Enterprise wil, wil je automatisch al geen bleeding edge.

Door Precision, dinsdag 23 augustus 2011 18:01

Score: 1
[...]als het niet stuk is, ga 't dan niet repareren.[...]
Maar wanneer is iets stuk? Als blijkt dat iets niet meer veilig is dan is het stuk maar komt 't pas boven water als iemand iets probeert die hij niet mag.

Door mocean, dinsdag 23 augustus 2011 12:35

Score: 1
Je zou toch zeggen, dat zo'n fout bij een unit-test wel gelijk naar boven zou komen! Ongelooflijk dat zo'n fout helemaal doorkomt tot de stable release.

Ben wel benieuwd hoe lang deze bug al in de code zit van 5.3.7, kan iemand dat makkelijk zien uit mbv source control?

Door koku82, dinsdag 23 augustus 2011 14:16

Score: 1
Volgens mij faalde de betreffende Unit Test ook, dat is het vreemde eraan. Dit staat er namelijk in het bug report:
Confirming, some very recent update broke it - right now unit tests fail on SVN. I
wonder if nobody run it before release?
Waarschijnlijk gewoon niet opgevallen dus. Wellicht omdat er standaard een hoop tests falen/skippen, waardoor het niet duidelijk is?

Door Phoib, dinsdag 23 augustus 2011 12:38

Score: 1
Gevalletje "oeps, verkeerde variabele teruggeven" :P

Nu is dit hier niet zo'n ramp als 5.2.7, md5 is al onveilig, en de salt voegt weinig tot niks toe.

Door Booster, dinsdag 23 augustus 2011 13:11

Score: 1
Uh, die salt zorgt anders wel voor een flinke extra drempel voor het bruteforce kraken van wachtwoorden met meer dan 7-8 karakters. Dat is tegenwoordig een cruciale toevoeging.

Door Phoib, dinsdag 23 augustus 2011 13:20

Score: 1
Enige keer dat een salt nuttig is is als je de hash in handen krijgt, en in de meeste gevallen heb je dan ook wel de salt erbij (SQL injectie).

Aangezien je de salt en het eindresultaat hebt, moet je alleen nog weten hoe de salt gebruikt wordt. Als je een custom site hebt kan je je eigen methode verzinnen, maar als je een forum gebruikt is de implementatie van de salt bekend.

Nu is het nog een kwestie van rainbowtables hashen met de salt en vergelijken. Die salts zijn meestal een paar karakters, dus md5 kan er in een keer, snel, doorheen.

Natuurlijk, het duurt langer om die gehashte rainbowtable te maken en te vergelijken, maar veiliger dan een gewoon gehasht password? Nee. Er blijft dezelfde kans op collisie, en je blijft in dezelfde orde van grote van oplossingen die je door moet lopen om te bruteforcen.

md5 met salt is niet substantieel veiliger dan md5 zonder salt.

Door hostname, dinsdag 23 augustus 2011 13:21

Score: 1
Maar als je nu per gebruiker een andere salt maakt dan moet er per gebruiker een nieuwe rainbowtable aangelegd worden, wat de tijd die benodigt is om de hash te kraken enorm vergroot.

Door Phoib, dinsdag 23 augustus 2011 15:08

Score: 1
Niet erg veel groter, md5 is, zoals ACM al zegt, erg snel uit te rekenen, zeker als de salt minder dan 32 characters heeft, want dan kan md5 er in een keer doorheen.

Het zal zeker langer duren, maar niet substantieel langer. Het duurt niet opeens 10.000 keer zo lang, en het risico voor collisions blijft hetzelfde.

md5 is niet veilig meer, en een salt voegt daar weinig aan toe.

Door Booster, dinsdag 23 augustus 2011 13:40

Score: 1
Ik denk dat je een gedeelte van de werking van salt mist :)
http://en.wikipedia.org/wiki/Salt_%28cryptography%29

Uiteraard moet je nogsteeds ook wachtwoorden laten maken van een bepaalde sterkte voor het nut gaat hebben, maar die restricties zijn niet erg bijzonder.

Door ACM, dinsdag 23 augustus 2011 14:08

Score: 1
Puur md5 is domweg zo snel te berekenen dat een salt het weinig minder interessant maakt om te brute forcen. Uiteraard moet je dan elk account los brute forcen, maar dan nog is het prima mogelijk als je bedenkt dat met de huidige generatie GPU's (mijn Radeon 6950 iig) je al makkelijk 1-2 miljard md5-hashes per seconde kunt uitproberen.

Door Phoib, dinsdag 23 augustus 2011 15:12

Score: 1
Ik denk dat je een gedeelte van de werking van salt mist :)
http://en.wikipedia.org/wiki/Salt_%28cryptography%29

Uiteraard moet je nogsteeds ook wachtwoorden laten maken van een bepaalde sterkte voor het nut gaat hebben, maar die restricties zijn niet erg bijzonder.
De sterkte van het wachtwoord wordt minder relevant als de hashmethode zelf onveilig blijkt. MD5 is niet veilig meer, er bestaan efficiente methodes om vanuit een hash een oplossing te achterhalen.

Zie ook http://www.win.tue.nl/hashclash/ HashClash voor de veiligheid van MD5.

Door deadinspace, dinsdag 23 augustus 2011 17:53

Score: 2
De sterkte van het wachtwoord wordt minder relevant als de hashmethode zelf onveilig blijkt.
Dat klopt.
MD5 is niet veilig meer, er bestaan efficiente methodes om vanuit een hash een oplossing te achterhalen.
En dat klopt niet helemaal.

Er bestaan nog geen bijzonder efficiente methoden om vanuit een hash een oplossing te genereren (een zogenaamde preimage attack). De efficientste preimage attack tegen MD5 heeft een complexiteit van 2123 (zie hier), wat significant hoger is dan de entropie van vrijwel alle wachtwoorden. Dat betekent dat brute force (al dan niet met een dictionary) nog steeds efficienter is.

Wel zijn er efficiente collision attacks gevonden (dat is waar jouw HashClash link over gaat), maar die genereren alleen twee inputs die naar dezelfde waarde hashen, en zijn dus nutteloos als je naar een specifieke hash toe moet werken. Het is met dergelijke collisions absoluut mogelijk om narigheid uit te halen (zie de Certificate aanval), maar op wachtwoordhashes heeft het geen invloed.

Begrijp me niet verkeerd; er zijn hele significante problemen met MD5, en die zullen alleen maar erger worden. Ik juich het gebruik van betere hashes (met name SHA-512) van harte toe, maar MD5 voor wachtwoordhashing is niet zo lek als jij doet voorkomen. En dat betekent dus dat een veiligheidsprobleem in PHP's MD5 implementatie relevant is.

Door thomasvk, woensdag 24 augustus 2011 00:41

Score: 1
Als je vanuit een hash een oplossing kunt achterhalen, dan heb je zo'n beetje het beste compressie algorithme ter wereld bedacht. DVDtje overzetten? Gewoon hash kopiëren en later weer even omzetten naar data.

Er zijn collisions gevonden (dwz. verschillende payloads die dezelfde hash dragen), en er zijn verschillende exploits gevonden. Zo kun je een standaard payload hebben, met arbitraire extra data, die altijd dezelfde hash vormen. Daarmee kun je bepaalde executables manipuleren en daar bijvoorbeeld virussen in verstoppen, zonder dat programma's die hashes checken (zoals package managers op Linux) het door hebben (hoewel diezelfde package managers nu allemaal betere hashes, zoals SHA1, gebruiken).

Voor wachtwoorden is MD5 nog lang niet 'heel slecht', zeker omdat je hashes gewoon niet om kunt draaien. Door collisions is het wel wat gevaarlijker. En omdat je een MD5 sneller kunt berekenen dan bijv. een SHA1 hash, is MD5 ook zwakker (ivm brute force attacks, etc).

Door deadinspace, woensdag 24 augustus 2011 14:24

Score: 0
Als je vanuit een hash een oplossing kunt achterhalen, dan heb je zo'n beetje het beste compressie algorithme ter wereld bedacht. DVDtje overzetten? Gewoon hash kopiëren en later weer even omzetten naar data.
Nee hoor. Dat je een oplossing voor een hash kunt vinden wil niet zeggen dat dat ook de originele input is. Het kan een heel andere input zijn dit simpelweg tot dezelfde hash leidt.

Vergeet niet, er zijn oneindig veel inputs die tot eenzelfde hash leiden ;)

Door deadinspace, dinsdag 23 augustus 2011 17:32

Score: 2
Enige keer dat een salt nuttig is is als je de hash in handen krijgt, en in de meeste gevallen heb je dan ook wel de salt erbij
Natuurlijk heb je de salt er bij, die is onderdeel van de hash!
En natuurlijk heeft een salt alleen zin tegen het offline kraken van hashes, dat is waar salts voor bedoeld zijn.
Aangezien je de salt en het eindresultaat hebt, moet je alleen nog weten hoe de salt gebruikt wordt.
Het is gewoon gestandaardiseerd hoe een salt toegepast wordt, daar is niks geheims aan. Een salt voegt geen extra geheimzinnigheid toe. Een salt dient puur om rainbow tables nutteloos te maken.
Nu is het nog een kwestie van rainbowtables hashen met de salt en vergelijken.
Nee, dat heeft geen enkele zin. Elke hash heeft zijn eigen salt, dus je kunt geen rainbow tables maken voor een bepaalde salt. Het enige dat je kunt doen is rainbow tables maken voor alle salts, maar daarmee worden de rainbow tables onmogelijk groot. En nogmaals, dat (en niet meer) is precies het nut van een salt.

Bij MD5 is een salt van 8 6-bit tekens gebruikelijk, dat betekent dat de rainbow tables 248 = 281.474.976.710.656 maal zo groot moeten zijn. Dat is onhaalbaar, en dus heeft precomputation geen zin meer.
en je blijft in dezelfde orde van grote van oplossingen die je door moet lopen om te bruteforcen.
Ja, maar nogmaals: dat is niet waar een salt voor dient. Een salt is om precomputation (rainbow tables) onaantrekkelijk te maken waardoor een aanvaller moet bruteforcen ipv een rainbow table lookup te doen.
md5 met salt is niet substantieel veiliger dan md5 zonder salt.
Wel dus. Voor een redelijk specifieke aanval weliswaar (precomputed dictionary attacks aka rainbow tables), maar dat is een vrij relevante aanval als het op wachtwoordhashes aankomt.

[Reactie gewijzigd door deadinspace op dinsdag 23 augustus 2011 17:36]

Door deadinspace, dinsdag 23 augustus 2011 17:20

Score: 1
Nu is dit hier niet zo'n ramp als 5.2.7
Eh, niet zo'n ramp? De manier waarop de crypt() functie in 5.3.7 faalt zou ervoor kunnen zorgen (een en ander hangt van details af) dat aangemaakte gebruikers op een site met elk willekeurig wachtwoord kunnen inloggen.
md5 is al onveilig
Er zijn problemen met MD5, maar die zijn (nog) niet relevant voor het gebruik van MD5 als wachtwoordhash. Het is verstandig om naar andere hashing algoritmes te migreren, maar dat betekent niet dat MD5 per definitie onveilig is.

Overigens is MD5 nog altijd ordegroottes beter dan DES als wachtwoordhash.
en de salt voegt weinig tot niks toe.
Niks is minder waar. Bij een standaard salt-grootte (8 tekens) wordt een rainbow table voor een dictionary attack een factor 248 = 281.474.976.710.656 groter, wat een dergelijke aanval onpraktisch maakt.

[Reactie gewijzigd door deadinspace op dinsdag 23 augustus 2011 17:55]

Door Earry, dinsdag 23 augustus 2011 12:41

Score: 2
PHP 5.3.8 staat al online. Verander de download URL maar eens. Hij is alleen nog niet officieel gereleased dmv nieuwsbericht op de site.

Door WhiteDog, dinsdag 23 augustus 2011 12:42

Score: 1
Denk dat het allemaal nog wel meevalt. Veel servers zitten nog gewoon op 5.2.x en zelfs al ben je over naar 5.3.x dan ja je ook niet snel een productiemachine upgraden naar de allerlaatste versie zonder goeie reden.

Bovendien moet je ook nog is een bepaalde functie op een bepaalde manier gaan gebruiken. De waarschuwing is er vooral omdat je met deze bug je achterliggende database gaat vervuilen met verkeerde data en/of je ineens fouten krijgt bij verificatie van strings. Je kan hier ook niet meteen een workaround voor verzinnen zonder je code en database aan te passen.

Door hostname, dinsdag 23 augustus 2011 13:06

Score: 1
Ik denk dat 6 securityfixes opzich wel een goede reden zijn om je productieserver te updaten naar de nieuwste versie.

Verder is het een kwalijke zaak dat veel servers nog op 5.2.x draaien, support daarvoor is al meer dan een jaar geleden gestopt en het moet voor developers inmiddels wel mogelijk gaan worden om de nieuwe features uit 5.3 te gebruiken. Het is jammer dat door dit soort fouten het upgraden van PHP niet zo heel vanzelfsprekend is als het zou moeten zijn en er vaak (terecht) extra voorzichtig wordt gedaan om te voorkomen dat er iets stuk gaat.

Door deadinspace, dinsdag 23 augustus 2011 17:24

Score: 1
Verder is het een kwalijke zaak dat veel servers nog op 5.2.x draaien, support daarvoor is al meer dan een jaar geleden gestopt
Dat hangt maar net van je platform af. Er zijn namelijk vendors die nog wel degelijk security support leveren op PHP 5.2.x.

Zo bevat Debian 5.0 (Lenny, oldstable) PHP 5.2.6 en levert daar ook nog gewoon security support op tot april 2012. De PHP in Lenny heeft dan ook al 13 updates ondergaan.
«  1  2  »

Op dit item kan niet meer gereageerd worden.

Volgende 13:17 Fanatec introduceert modulaire ClubSport-stuurbasis
Vorige 12:24 Sony verandert Home in social games-platform
VNU Media logo Hosted by True

© 1998 - 2012 Tweakers.net B.V. - Alle rechten voorbehouden - Contact - Jouw privacy - Algemene Voorwaarden

Uitgever van:

Website van het jaar 2011