Onderzoekssite Telegraaf verstuurt wachtwoord in url

De website van het Bureau Consumenten Onderzoek, het onderzoekspanel van De Telegraaf, gaat onveilig om met de logingegevens van gebruikers. Wachtwoorden worden onversleuteld opgeslagen en worden meegestuurd in de url.

Tweakers.net-user Edwin, die niet met zijn achternaam op het internet wil, ontdekte de kwetsbaarheid in de website van het Bureau Consumenten Onderzoek. De wachtwoorden van gebruikers worden onversleuteld opgeslagen en worden bij bepaalde acties meegestuurd in de url. Zo bevat de authenticatielink van een gebruiker zijn onversleutelde wachtwoord. Ook bij sommige links in het gebruikerspaneel en bij het versturen van nieuwe onderzoeken wordt het wachtwoord meegestuurd.

Het is overigens onduidelijk waarom het wachtwoord in de mail wordt meegestuurd; ook als het wachtwoord wordt weggehaald, is het mogelijk om een account te activeren. De gebruiker wordt verder niet geauthenticeerd. Het is onduidelijk of dat voor alle enquêtes geldt. Voor het wijzigen van wachtwoorden of het inzien van gegevens is in ieder geval wel een wachtwoord vereist.

De ontdekker van de kwetsbaarheid lichtte het Bureau Consumenten Onderzoek al op 18 april in. Volgens Niels van Dijken van het Bureau Consumenten Onderzoek moet de kwetsbaarheid inmiddels zijn verholpen, maar het tegendeel is waar. Van Dijken kan niet aangeven waarom gekozen is voor deze onveilige manier van authenticeren: "We doen dit al een aantal jaar zo", zegt hij. Ook is onduidelijk waarom de wachtwoorden onversleuteld worden opgeslagen. Het is gebruikelijk om wachtwoorden te versleutelen voordat ze worden opgeslagen.

Reacties (87)

[Verwijderd]

We waren ons er niet van bewust dat de manier van aanschrijven van onze panelleden kwalijk zou kunnen zijn. We hebben ons de kritiek aangetrokken en maatregelen getroffen en bekijken nu of deze maatregelen voldoende zijn of dat er meer nodig is. Excuses aan iedereen die zich er aan heeft gestoord. Groeten. Martijn Brinkhoff, Research Manager Telegraaf Media Nederland/BCO.

[JaHe]

+1 voor het speciaal aanmaken van een profiel op deze website om te vermelden bij de tweakers dat dit probleem speelt en dat jullie er iets aan gaan doen.

-1 voor het feit dat dit eigenlijk al in testfase van het project getackled had moeten zijn door de software niet zomaar live te plaatsen.

Weet niet of jullie software aanbesteden of zelf ontwikkelen, denk dat het wel slim is om hier van te leren voor toekomstige IT projecten.
Het is niet dat wij er ons aan storen, dit is een testcase voor hoe je niet met wachtwoorden of privegegevens van gebruikers om moet gaan bij gebruik van IT.
Zoals menigeen hier al terecht heeft opgemerkt, kan het probleem eenvoudig op verschillende wijzen voorkomen worden.

[.oisyn]

We waren ons er niet van bewust dat de manier van aanschrijven van onze panelleden kwalijk zou kunnen zijn

En dat is nou precies de oorzaak van het geheel. Da's een beetje net zoiets als zeggen "we waren ons er niet van bewust dat we veilig om moesten springen met je persoonsgegevens" . Wat mij betreft mogen hier gewoon keiharde straffen voor uitgedeeld worden, zodat bedrijven zich leren te realiseren dat ze voorzichtig moeten zijn met dergelijke gegevens.

[Reactie gewijzigd door .oisyn op 23 juli 2024 03:00]

[DrFurioux]

Ik vind het dan wel weer goed dat jullie de kritiek opnemen en proberen er wat aan te doen.
Goed zo Televaag!

[Klovan]

Dit is niet de enige onderzoekssite die de wachtwoorden in een URL meestuurt. Het Media Appreciatie Panel van IntomartGFK doet dit ook. Zie screenshot.

[Alfredo]

Dommel (Belgische ISP) maakt zich hier ook schuldig aan. Als je je inlogt op het controlepaneel van je account, blijft je wachtwoord in de URL staan (&password=...). Uiteraard komt het dan ook ineens in de geschiedenis van je browser te staan. Ook als je vanuit de browser een pagina print, zie je het onderaan in de URL staan (zo kreeg ik het wachtwoord van een vriend in handen).
Kwalijke zaak, maar Dommel weigert dit pertinent aan te passen. Volgens hen is dit de "normale procedure". Het antwoord toen ik dit aanbracht: "Dit is de normale procedure. We gaan ervan uit dat de pc die u gebruikt strikt persoonlijk is en er dus geen risico bestaat op het lekken van deze wachtwoorden. De verbinding zelf is ook een SSL-beveiligde verbinding."

Ja lekker, SSL beveiliging maar dan wel het wachtwoord plain-text in de URL laten staan. Ben je vet mee. Misschien moet ik ook maar eens een nieuwstip insturen, blijkbaar reageren bedrijven dan wel adequaat.

[Reactie gewijzigd door Alfredo op 23 juli 2024 03:00]

[Clock]

De webshop TakeItNow (toch best een grote) doet dit ook. Heb het ze gemeld, maar ze vonden het niet nodig hier iets mee te doen.

[JaHe]

Als programmeur met ruim 15 jaar ervaring kan ik je zeggen dat er vele malen meer websites zijn met dergelijke flaws erin. Heb zelfs al websites gezien waarbij complete SQL commando's in javascript samengesteld worden en als te executen string verstuurd worden naar een server om vervolgens doodleuk klakkeloos geexecute te worden.

Of het een stagiar is, iemand zonder kennis van beveiliging van data, zonder kijk op het geheel plaatje, gebruik van slecht gecopy-paste voorbeelden weet je niet.
Het kan ook nog zomaar zo zijn dat dit gebeurd omdat IT projecten tegenwoordig niets meer mogen kosten, snel af worden geraffeld en zonder te testen live worden geplaatst.

Dit is aan de orde van de dag tegenwoordig waarin IT demands en tijdsdruk hoog zijn, dan worden dergelijke fouten snel gemaakt als er ook geen kwaliteitswaarborging is en alles klakkeloos omwille van sales en commercie snel af moet van de baas. Die baas intresseert het geen zak of het veilig is of niet, het enige wat hij ziet is omzet, waar het uiteindelijk in elk bedrijf om gaat.

[Dreamvoid]

Als het alleen om de commercie zou gaan, zou het bij de overheid allemaal perfect in orde moeten zijn - en we weten allemaal dat dat niet zo is. Commercieel of non-profit, er worden gewoon overal in IT projecten fouten gemaakt door het nemen van shortcuts - uit luiheid, onkunde en tijdsdruk.

[LooneyTunes]

Als het alleen om de commercie zou gaan, zou het bij de overheid allemaal perfect in orde moeten zijn - en we weten allemaal dat dat niet zo is.

Probleem is natuurlijk dat de overheid wél commerciële partijen inhuurt. En daa r gaat het mis

Commercieel of non-profit, er worden gewoon overal in IT projecten fouten gemaakt door het nemen van shortcuts - uit luiheid, onkunde en tijdsdruk.

Zelfs de dagelijkse praktijk.
't Heeft denk ik ook te maken met het betrokken zijn bij de zaak. Eigen personeel zal vaker nét dat stapje extra doen.

[Astronaut]

Nonzin dat dit specifiek een kosten-technische fout betrof, of dat een dergelijke fout veelal het gevolg is van kostenbesparing, met hoge demands, of met een hoge tijdsdruk. Het is pure onkunde.

Versleuteld met wachtwoorden omgaan is geen optie op de factuur, maar standaard. Vergelijk het met een auto: elk deur heeft standaard een slot. De koper interesseert het geen zak wat voor slot het is en of het wel een uniek slot is. Daar ga je vanuit. Idem dito met huizen; en zo kan ik nog wel een hoop slechte metaforen verzinnen .

Een SHA'tje erover heen plaatsen kost een halve euro en voorkomt dat je in het nieuws komt. Tel uit je winst!

[Reactie gewijzigd door Astronaut op 23 juli 2024 03:00]

[JaHe]

Beetje kromme vergelijking, dat het geen optie op de factuur is snap ik ook wel, zo staan er nog veel meer werkzaamheden die ik als programmeur moet uitvoeren niet op de factuur.

denk dat een betere vergelijking kan zijn :

Ik wil goude handgrepen op mijn auto, kost tijd en geld om die gouden handgrepen speciaal op jouw auto te maken. Zet daar iemand op deze plek neer die nog nooit wat met goud bewerking heeft gedaan, de monteur die hem moet bevestigen en in principe prima capabel is om de standaard handgrepen te bevestigen.

Dan heb je kans dat je troep krijgt, slechte afwerking of zullen de handgrepen wel blijven zitten wanneer je over een hobbelige weg rijd? Dit gebeurd, tenzij deze monteur eerst even een cursusje doet, hem iemand vertelt hoe hij dat moet doen (uit ervaring) of iemand voor aflevering van het eindresultaat nog even controleert of het allemaal wel goed bevestigd is. Daarbij komt dan ook nog dat alles binnen een dag gedaan moet worden aldus de baas anders gaat de koper naar een ander.

Anyway dit gebeurd dagelijks zo.

[Astronaut]

Ik gaf al toe dat mijn vergelijkingen krom waren. Ik begrijp jouw vergelijking, maar die is ook krom

En fin, ik neem aan dat beveiliging en encryptie in jaar 1 van de opleiding worden gegeven? Het is als een automonteur die weet hoe hij wielen erop moet schroeven, als een arts die pleisters kan plakken, als wiskundige die kan vermenigvuldigen, een schilder die kan afplakken, een tuinier die onkruid kan wieden, een tweaker die kan overklokken. Met andere woorden: keiharde basiskennis.

[hackerhater]

Helaas niet
Ik zit nu in 3e jaar (HBO) informatica en nu pas dingen over beveiliging en ook nog niet diep

[Verwijderd]

Sta er ook niet van te kijken. Dit soort missers komt regelmatig voor. Ook bij grote bedrijven die een goede reputatie hebben. Meeste hiervan blijft ongemerkt en komt nooit uit.
Maar dat tegenwoordig er flink verdiend wordt aan dit soort fouten door er misbruik van te maken door hackers bendes maakt de kans dat het toch uitkomt wel groter.
Security by design is het devies. Hopelijk dat de bouwer dit never nooit meer zal vergeten.

[siebrand]

TTG gebruikt het product Dub InterViewer van Nebu (http://www.nebu.com/dubinterviewer). Dat is de club die een betere oplossing moet verzinnen. TTG kan zelf weinig aan het product veranderen.

Overigens lijkt ook tweakers.net niet standaard aan te laten melden via https. Zo wordt dus ook een wachtwoord in platte tekst over het lijntje verstuurd. Daar is ook een boeiende boom over op te zetten.

[01001000]

Prachtig hoe vele security experts het hier hebben over veiligheid. Maar zonder de gegevens over wat er op de site is opgeslagen (persoons gegevens of alleen un/pw) of dat er wel of geen waarschuwing staat of de site secure is e.d. kan dit nog enigsinds ok zijn of ongeloofelijk fout (ontelbaar fora die zo werken). Gebruikers moeten alleen wel leren om niet maar 1 pw te hebben...

Als dit wel veilig moet zijn dan stap 1: https, 2. minimum security check (pwned is te kort), 3. niet unsecure mailen van un/pw combinatie, 4. hash pw storage (geen MD5) 5. IP coupling van timed sessies. 6. geen un/pw in URL 7. browser password store blokkeren etc etc
Geen van die stappen opzich is voldoende (alleen hash is nonsense), hoewel https al een lekkere zou zijn.

Overigens 18e gemaild en na 7 dagen klagen dat het niet is opgelost (fundamentele aanpassing security model) is niet reeel, ze hadden hooguit de site offline kunnen halen. En als dat voldoende reden is dan word het rustig op internet.

deze post word ook unsecure met un/pw over internet gestuurd overigens...tweakers maar offline halen?

[Moartn]

Slordige fout inderdaad, maar laten we niet te panisch doen: het wachtwoord staat ook zonder de URL al als plain text in de mail, en als ze straks het wachtwoord uit de URL halen, dan vult de gebruiker het wachtwoord zelf in op de website, en dat wordt vervolgens verstuurd via non-https POST. Da's maar marginaal veiliger natuurlijk.

[ajakkes]

Door het bezoeken van de URL die in de mail staat, staat het wachtwoord in de geschiedenis van de browser. Deze is door iedereen die toegang heeft tot de computer in te zien.
Als na bezoek van deze site een andere site wordt bezocht staat het wachtwoord misschien ook nog wel in de bezoekersgeschiedenis van de bezochte site: Referer page.

Een wachtwoord in een mail die alleen naar de gebruiker zelf gestuurd wordt is niet zo heel vervelend. Maar dat het wachtwoord regelmatig in de url voorkomt wil zeggen dat het wachtwoord ongecodeerd in de database is opgeslagen (Het wachtwoord zelf zou op later tijdstip niet te achterhalen moeten zijn).

Een non-https POST wachtwoord is alleen op het moment dat het verzonden wordt te achterhalen. Een wachtwoord plain-text in een database en/of in de browsergeschiedenis is heel lang beschikbaar voor hackers. Dit noem ik niet marginaal.

[Verwijderd]

Slordige fout inderdaad, maar laten we niet te panisch doen: het wachtwoord staat ook zonder de URL al als plain text in de mail, ...

Dát is ook al een reden om panisch te doen. Wachtwoorden onbeveiligd mailen is not done
.
Een gebruiker hoort die te onthouden, zelf op te schrijven en anders de optie 'wachtwoord vergeten' te gebruiken (die dan natuurlijk wel met een tijdelijk wachtwoord moet werken). Genoeg sites die op deze manier werken.

[SunnieNL]

Net zo fout idd.

Zou idd netter zijn als ze de inlogpagina in ieder geval secure maken (en alle andere pagina's met persoonlijke gegevens erin) na de aanpassing van de url en het ww daar uitgefilterd is.

[Icekiller2k6]

opmerking van dat het wachtwoord daarom ongecodeerd opgeslagen klopt trouwens niet..

zolang de code met een eigen algoritme/eigen salt encrypt is kun je hem nog altijd decrypten...

Ik ken best veel bedrijven die hun wachtwoord opslaan met hun eigen algoritme zodat ze makkelijk hun wachtwoorden terug kunnen halen..

meestal wordt dit dan wel op een "offline" pc gedaan waar enkel de decryptie key & programma op staat die dit kan.

Uiteraard voor online diensten ... waarbij je een "verander wachtwoord als je het vergeet" dit totaal niet nuttig is en gewoon met een api key ofzo kunt werken.

[Kwastie]

Een wachtwoord hoor je niet te encrypten, maar te hashen..

i.t.t. encrypten kun je een hash niet decrypten (de-hash(en)). Je zou wel een collision kunnen berekenen, maar je weet nooit zeker of dat het gelijk is aan originele wachtwoord. En als je er een salt aan toevoegt word de kans dat de collision gelijk is aan het originele wachtwoord heel klein.. (tenzij je natuurlijk de salt hebt)

[mobstaa]

hahahahaha hebben ze $_GET gebruikt ofzo? hahahaha:P dit vind ik wel heeeeeel amateuristisch ik vind dat je als je daar gaat werken toch wel een beetje van programmeren af moet weten.

[Netrunner]

Zo erg is het ook weer niet, ik kan opmaken uit de url dat het hier om een interview of enquete ging. De impact is wederom laag.

[SunnieNL]

Impact is niet laag:
1. Met die gegevens kan ik ook inloggen en persoonlijke gegevens in zien. De kans is groot dat naam/adres/tel.nr/email allemaal zijn ingevoerd.
2. Zoals aangegeven door Tom, gebruiken veel mensen dezelfde wachtwoorden bij meerdere sites.

[Verwijderd]

Als mensen hetzelfde wachtwoord gebruiken op verschillende websites, is dat niet de schuld van die websites.
Het is gewoonweg dom van die mensen (ik reken mezelf hier ook onder voor alle duidelijkheid). Men weet nooit hoe (en in dit geval dus óf) de wachtwoorden versleuteld worden.
Een website beheerder met slechte bedoelingen heeft dus heel wat informatie in handen om aan de slag te gaan op andere websites.

[.oisyn]

Als mensen hetzelfde wachtwoord gebruiken op verschillende websites, is dat niet de schuld van die websites.

Klopt, maar dat is de stelling ook niet. Als website moet je gewoon fatsoenlijk met dergelijke gegevens omgaan, en niet gewoon doen alsof het niet uitmaakt omdat mensen toch verschillende wachtwoorden zouden moeten gebruiken, ookal weet je dondersgoed dat dat gewoon niet gebeurt.

[GAIAjohan]

Tsja, maar tegenwoordig ben je lid op zoveel sites/netwerken etc dat allemaal evrschillende wachtwoorden niet vol te houden is.

[-Tom]

Tenzij mensen voor meerdere websites hetzelfde wachtwoord gebruiken. Dan kan de impact ineens een stuk minder klein blijken. Het mag dan wel niet slim zijn om dezelfde wachtwoorden gebruiken, maar genoeg mensen doen het nog steeds.

Slechte zaak..

[Verwijderd]

Kleine Update;

Het was maandag de 18e al doorgemaild.
Vrijdag kwam de eerste reactie terug.

[Singelaar]

Uh, heb je alleen hiervoor een nieuw profiel aangemaakt?

Mm je wil natuurlijk anoniem blijven

[Verwijderd]

Nee, ik kon m'n oude niet meer vinden.

[Verwijderd]

Nu weten we tegelijk je geboortejaar, Edwin. ;-)

On topic: ik heb in mijn mailbox nog een oude registratiemail gevonden van Tweakers.net uit 2004 waar exact hetzelfde werd gedaan: gebruikersnaam en paswoord onversleuteld in de URL!

URL zag er zo uit:
http://www.tweakers.net/m...ord=ONVERSLEUTELDPASWOORD

Hierbij werd het volgende gemeld: "dit is veilig zolang je je password meteen verandert"

P.S.: de URL werkt vandaag nog steeds

[Verwijderd]

Feestje bouwen dan... ;-)

On topic:
De gegevens in die mail daar ging het mij eigenlijk helemaal niet om.
Het gaat er mij juist om dat het wachtwoord leesbaar in de url's staat. (bijv. als je een enquête in wilt vullen)

Dat is in de geschiedenis en met auto aanvullen erg makkelijk te zien. Op een eigen pc hoeft dat geen probleem te zijn maar wel voor mensen op die veel op openbare pc's werken. (bibliotheek, school, ..)

Zeker gezien men vaak (hoe fout het ook is) hetzelfde wachtwoord gebruikt voor verschillende sites.

Naar mijn mening heeft een site een bepaalde zorgplicht over hoe ze met je gegevens omgaan. Dat lijkt hier goed fout te gaan.

[4Real]

Ik begrijp zijn opmerking niet echt over het nut van encryptie. Bij het opslaan van wachtwoorden is het toch zo simpel om een one-way-encryption uit te voeren, zodat deze op zo'n manier worden opgeslagen dat deze niet direct inzichtelijk zijn. Als databasebeheerder ga je daar toch ook om eisen zodat niet elke boer met toegang direct de wachtwoorden kan zien, dat is toch een stukje privacy wat je biedt?

Zoveel meer werk is het ook weer niet om te maken het enige wat nodig is is om de wachtwoorden door een bv: MD5 functie heen te halen en je bent klaar.

Maar daarbij zijn opmerking van 'dit doen wij al jaren zo' zal er bij de cultuur horen. Het moet daar eerst helemaal goed mis gaan voor dat ze het inzien.

[Kwastie]

One-way-encryption bestaat niet, je bedoelt zeker een hash.

MD5 zou ik niet meer gebruiken, deze hash is nogal achterhaalt en een collision is vrij makkelijk te berekenen, zelf zou ik voor SHA-256 + random salt gaan.

One-way-encryption is trouwens een oxymoron, een soort van paradox

[Reactie gewijzigd door Kwastie op 23 juli 2024 03:00]