Belegger.nl dwingt nieuwe wachtwoorden af na databasehack

Belegger.nl heeft zijn ruim 200.000 gebruikers verplicht een nieuw wachtwoord laten instellen onder het mom van onderhoud aan de database. In werkelijkheid bleek de website vatbaar voor sql-injectie waardoor de database toegankelijk was.

Tweaker Squ1zZy tipte Tweakers.net dat hij in staat is gebleken via sql-injectie toegang te krijgen tot de database van Belegger.nl. Hierdoor had hij de beschikking over de inlognamen en wachtwoorden van meer dan 200.000 geregistreerde gebruikers. Ook admingegevens van de website waren toegankelijk.

Nadat hij uitgever Sanoma hiervan op de hoogte had gebracht, heeft hij contact gehad met de ict-manager. Hoewel er naar aanleiding van dat contact al enkele technische aanpassingen aan de site zijn gedaan en geregistreerde gebruikers een nieuw wachtwoord hebben moeten instellen, constateerde Squ1zZy dat de database nog steeds toegankelijk was.

Een zegsman van Sanoma bevestigt tegenover Tweakers.net dat niet alle ontdekte kwetsbaarheden direct zijn gedicht. "We hebben contact gehad met Squ1zZy en naar aanleiding daarvan vorige week al enkele verbeteringen doorgevoerd. Ook hebben we meteen een extra audit laten doen. Een deel van de zaken die hieruit naar voren zijn gekomen zijn eerder al gedicht; het laatste staartje is maandag opgelost."

Volgens de tweaker had hij toegang tot diverse databases op de server van Belegger.nl, waarbij in diverse tabellen gebruikersgegevens stonden opgeslagen. In totaal zag Squ1zZy 201.953 accounts, waarbij van een groot deel het wachtwoord in plain text was opgeslagen. "In een andere tabel werd wel gebruikgemaakt van md5-hashing, maar die vorm van beveiliging is tegenwoordig eigenlijk al niet meer afdoende", aldus Squ1zZy tegenover Tweakers.net.

Volgens Squ1zZy maken meer sites van Sanoma gebruik van het vatbare component, al zouden de Nu.nl-sites hier dan weer geen gebruik van maken. Sanoma benadrukt dat er al geruime tijd aan een nieuwe website voor Belegger.nl wordt gewerkt die voor 1 oktober het daglicht moet zien. De resultaten van de audit zullen ook bij die nieuwe site worden gecontroleerd. De nieuwe site krijgt tevens een nieuw inlogsysteem dat standaard beschikt over versleutelde wachtwoorden. Bij de huidige database wordt dit nu alsnog gedaan.

Reacties (66)

[Squ1zZy]

Op belegger.nl staat inmiddels het volgende:

Op tweakers.net is vandaag een bericht verschenen over de veiligheid van onze database. Op 28 juli werden wij gewezen op een lek in het systeem. Wij hebben direct alle mogelijke middelen ingezet om dit lek te dichten. Op 29 juli hebben we al onze geregistreerde gebruikers een e-mail verstuurd dat we hadden besloten alle wachtwoorden te resetten.

Het bewuste lek is gedicht en Belegger.nl is bezig met het ontwikkelen van een nieuwe site. Wij betreuren de gang van zaken.

http://www.belegger.nl/ni...ctie_op_bericht_over_hack

De 29e zijn gebruikers geforceerd om hun wachtwoord te wijzigen, maar het was op de 30e nog steeds mogelijk om een SQL injection uit te voeren. Dus zelfs na het wijzigen van het wachtwoord is het niet zeker dat er iemand je wachtwoord heeft.

Ook is het mogelijk je wachtwoord aan te passen in het wachtwoord die je al had. Je werd dus niet geforceerd om een ander wachtwoord te gebruiken.

Ook was het mogelijk om een post van iemand anders aan te passen door je eigen post aan te passen en simpelweg in de URL de post ID te wijzigen. Zo kon je posts van andere aanpassen.

Ook was het mogelijk om met een ander gebruikersnaam een post te plaatsen. Met google chrome kon je je gebruikersnaam aanpassen voor je submit drukt. Zo werd er een post geplaats onder een ander gebruikersnaam.

[thof]

"Ook was het mogelijk om een post van iemand anders aan te passen door je eigen post aan te passen en simpelweg in de URL de post ID te wijzigen. Zo kon je posts van andere aanpassen.

Ook was het mogelijk om met een ander gebruikersnaam een post te plaatsen. Met google chrome kon je je gebruikersnaam aanpassen voor je submit drukt. Zo werd er een post geplaats onder een ander gebruikersnaam."

Dat lijkt me wel een erg grote fout, welke niet alleen met SQL-injectie te maken heeft. Volgens mij moet het hele authenticatie systeem maar eens goed na gelopen worden en hoop dat het dus beter zit in de vernieuwde website. Hoop dat ze dus niet twee maal dezelfde fout maken.

[GateKeaper]

Gaat lekker met al die lekken van tegenwoordig.

Al moet ik toegeven dat deze "bug" beter is aangepakt als dan vergelijkbare situaties in de vele andere nieuwsberichten. Zowel de "hacker" als belegger.nl hebben hier naar mijn inziens netjes gehandeld.

Het verplicht laten vernieuwen van wachtwoorden is natuurlijk dempen nadat het kalf verdronken is, maar aan de andere kant moeten we maar weer blij zijn dat ze er eerlijk voor uitkomen, en de gebruikers verzoeken wachtwoorden te wijzigen.

Ze hadden het ook stil kunnen houden zoals vele andere sites (zouden) doen.

*edit.. @ hieronder, beter als, beter dan.. Je begreep me toch?

[Reactie gewijzigd door GateKeaper op 23 juli 2024 05:18]

[Zoefff]

Met alle respect vind ik dit een behoorlijk halfbakken aanpak, al is het natuurlijk beter dan compleet verzwijgen van het probleem.

Ten eerste maken ze zich er nogal makkelijk vanaf door te melden dat:

Vanwege preventief onderhoud aan Belegger.nl, hebben we besloten om uw wachtwoord te resetten.

Je liegt keihard en zonder te blinken naar je meest trouwe gebruikers, namelijk zij die een account hebben aangemaakt. Als je faalt, ga dan ook met de billen bloot en laat merken dat je de problemen adequaat hebt opgelost in plaats van er over te liegen. Gebruikers komen toch wel met het nieuws in aanraking, en krijgen op deze manier een nog negatiever beeld over de website.

Ten tweede waren een groot deel van de wachtwoorden plaintext opgeslagen. Dat betekent dat gebruikers niet alleen op belegger.nl hun wachtwoord moeten veranderen, maar dat ditzelfde wachtwoord hoogstwaarschijnlijk op andere websites of emailaccounts aangepast moet gaan worden.

Door de hoofd-in-het-zand mentaliteit van belegger.nl worden gebruikers er niet op geattendeerd dat hun wachtwoord niet veilig meer is. Als je de fout maakt om wachtwoorden überhaupt in plaintext op te slaan, neem dan ook de verantwoordelijkheid op het moment dat dit mis gaat.

Hopenlijk wordt er veel ruchtbaarheid aan deze hack gegeven, want ik vind het een behoorlijk smerige en slordige manier van omgaan met vertrouwelijke gegevens

Update:
De "passreset" pagina die (nieuw?) in het leven is geroepen functioneert trouwens ook op een merkwaardige manier? Op http://www.belegger.nl/service.php?page=passreset kan ik een gebruikersnaam en nieuw wachtwoord opgeven. M.a.w., ik kan voor willekeurige gebruikers een nieuw wachtwoord aanvragen. De gebruiker ontvangt dan een mailtje met link om te bevestigen. Bij het klikken op de link (en hoeveel gebruikers zullen zich niet bedenken dat ze dat mailtje niet zelf hebben aangevraagd?) wordt het wachtwoord gewijzigd in het door mij ingevulde wachtwoord.

Oftewel, de aanvaller verzint een wachtwoord wat het slachtoffer alleen nog maar hoeft te bevestigen. Lekker stom.

[Reactie gewijzigd door Zoefff op 23 juli 2024 05:18]

[Gwaihir]

Voor zover bekend zijn deze wachtwoorden niet daadwerkelijk op straat komen te liggen. Waarschijnlijk heeft slechts die ene hacker er enkele daadwerkelijk gezien en is hij te goeder trouw. Met deze actie zijn ze schade dus voor, kortom: preventief onderhoud.

Ik vind het dus geen keihard liegen. Halfbakken, dat wel. Je geeft terecht aan dat de gebruiker hetzelfde wachtwoord ook elders zou moeten wijzigen. En voor de zekerheid zou hij ook z'n recente transacties toch even moeten nalopen.

[Zoefff]

Daar ben ik het absoluut niet mee eens. Dat er toevallig een goedwillend persoon contact opneemt geeft geen enkele indicatie van de hoeveelheid personen die hier al misbruik van hebben gemaakt. Het is leuk om er van uit te gaan dat dit niet is gebeurd, maar als je jezelf serieus neemt ga je uit van het worst case scenario, en geef je hiervan duidelijke feedback naar je gebruikers.

Als je zelf een webserver hebt draaien zou je voor de gein eens moeten kijken hoeveel requests je in de logs langs ziet komen met standaard SQL exploits. Zeker met een high-profile site als belegger.nl, met in de maand juni 410.000 unieke bezoekers (bron STIR) en bovendien waardevolle informatie zoals een schaduwportefeuille, kan je er niet van uit gaan dat dit soort zaken niet of automatisch of met de hand geprobeerd zijn door meerdere mensen.

Wie zijn billen brandt, moet op de blaren zitten. En dat is geen probleem, iedereen maakt fouten. Maar geef het wel netjes toe, en win het vertrouwen van je gebruikers (terug)

[Dreamvoid]

En voor de zekerheid zou hij ook z'n recente transacties toch even moeten nalopen.

Je kan op belegger.nl geen transacties doen, het is geen bank, het is een site met beleggersinfo en forums.

[Sfynx]

Update:
De "passreset" pagina die (nieuw?) in het leven is geroepen functioneert trouwens ook op een merkwaardige manier? Op http://www.belegger.nl/service.php?page=passreset kan ik een gebruikersnaam en nieuw wachtwoord opgeven. M.a.w., ik kan voor willekeurige gebruikers een nieuw wachtwoord aanvragen. De gebruiker ontvangt dan een mailtje met link om te bevestigen. Bij het klikken op de link (en hoeveel gebruikers zullen zich niet bedenken dat ze dat mailtje niet zelf hebben aangevraagd?) wordt het wachtwoord gewijzigd in het door mij ingevulde wachtwoord.

Oftewel, de aanvaller verzint een wachtwoord wat het slachtoffer alleen nog maar hoeft te bevestigen. Lekker stom.

Dat is wel heel erg slordig... wat is het nu voor moeite om gewoon een nieuw onvoorspelbaar password op te sturen na het klikken op die link?

[.oisyn]

maar aan de andere kant moeten we maar weer blij zijn dat ze er eerlijk voor uitkomen

Niet bepaald:

Belegger.nl heeft zijn ruim 200.000 gebruikers verplicht een nieuw wachtwoorden laten instellen onder het mom van onderhoud aan de database

Daarnaast, gebruikers verplicht hun wachtwoord laten wijzigen vereist ingrijpen door de gebruiker. Ik kan me voorstellen dat niet iedereen dagelijks die site of z'n mail checkt, maar in tussentijd kan wel iedereen gebruik maken van de inloggegevens. Beter reset je alle wachtwoorden. Maar het lijkt me sowieso netjes dat je even meldt dat de gegevens potentieel op straat lagen, ipv het gewoon maar even af te doen als databaseonderhoud.

[Reactie gewijzigd door .oisyn op 23 juli 2024 05:18]

[GateKeaper]

Begrijp ik, maar hoeveel berichten zijn er inmiddels wel niet geweest van sites die gehacked waren, waarbij de beheerders beloven de problemen op te lossen, maar waar eigenlijk gewoon niks gebeurd.

Hoe zit dit eigenlijk? Worden dit soort situaties (nog) niet afgevangen door onze "wet bescherming persoonsgegevens" ? Zo nee, dan wordt dat toch echt eens een keer tijd!

Er is ook en bouwbesluit voor het bouwen van gebouwen, laat er ook een bouwbesluit komen voor het ontwikkelen van webapplicaties. Twee potentiele regels zijn al; beveiliging tegen sql injectie en gehashed opslaan van wachtwoorden.

[mddd]

Ik denk niet dat het zin heeft om dergelijke regels op te stellen. Er zijn immers talloze wegen waarlangs het mis kan gaan. De regels zullen altijd achterlopen op de mogelijke aanvallen.

Iemand die gegevens beheert, hoort die behoorlijk te beschermen. Zoveel is duidelijk en dat is ook al wettelijk zo. Je hebt geen detail-regeltjes nodig om dat te regelen.

[GateKeaper]

In de bouw kan ook veel meer mis gaan dan wat wordt afgedekt. Toch helpt het om er regels voor in de wet te hebben staan.

Al is het alleen maar omdat de opdrachtgever geen budget vrij maakt voor bepaalde zaken. Dan zou de ontwikkelaar kunnen zeggen: "Beste man, volgens de wet bent u verplicht dit systeem te integreren. Ons advies is dus....."

Het behoorlijk beschermen gaat momenteel nogal eens fout. Dit soort zaken laten afdekken / controleren door een onafhankelijke instantie lijkt mij dus een verstandige zaak.

Een taak voor iets als de Opta voor de telecom doet. Een toezichthouder op bedrijfskritische websites (overheden, banken, beleggers, verzekeringen, grote commerciele bedrijven)

[mddd]

Ik ben het met je eens dat het goed is om bepaalde regels te hebben. Maar het geldt natuurlijk altijd dat een ontwikkelaar zou moeten zeggen "dit is niet veilig, dus we doen het niet op deze manier". Ik zie niet zo goed hoe je dat oplost door dergelijke regels.

Als een ontwikkelaar blijkbaar zonder regels wél bereid is om onveilige oplossingen te realiseren, en met regels dit niet meer doet, dan ligt daar het probleem. Niet in het ontbreken van de regels want de ontwikkelaar weet dan dus prima wat hij doet.

[GateKeaper]

Het is vaak genoeg niet de ontwikkelaar die bereid is om, maar de opdrachtgever die bereid is om, omdat hij er geen budget voor over heeft.

Door de opdrachtgever dan te confronteren met de wet, kan je hem vaak alsnog net over die streep krijgen om nog wat extra centen in de bak te gooien.

[Reactie gewijzigd door GateKeaper op 23 juli 2024 05:18]

[Sundog]

Een taak voor iets als de Opta voor de telecom doet. Een toezichthouder op bedrijfskritische websites (overheden, banken, beleggers, verzekeringen, grote commerciele bedrijven)

Ik neem aan dat je eigenlijk wat anders bedoeld, want het uitgangspunt van toezicht zou de bescherming van persoonsgegevens moeten zijn, niet of een website kritiek is voor de bedrijfsvoering.

Die toezichthouder bestaat al, want dat is eigenlijk het CBP (College Bescherming Persoonsgegevens). Alleen zal het CBP vooral reageren op klachten, tips of naar aanleiding van media verhalen. Het is ondoenlijk om alle websites en databases te gaan controleren, los van de vraag of dat überhaupt wenselijk is....

[Mathijs]

Enkel hashen is niet voldoende, er is nog wat zout nodig.

[Travelan]

Ik denk dat het eigenlijk wel meevalt met die 'lekken van tegenwoordig'. Het is denk ik meer het klimaat waar we nu in zitten, waarbij jan en alleman een site heeft en geen kaas heeft gegeten van security. Daarnaast is het natuurlijk op het moment erg 'hot' om sites te gaan kraken.

Ik vind het wel erg knullig voor zo'n groot mediabedrijf om dit soort fouten te permitteren. Het houdt mij in elk geval wakker om dit te voorkomen.

[O88088]

Kijk zo kan het ook, je hoeft niet meteen alles te publiceren.

[Squ1zZy]

1 van mijn punten om dit in het nieuws te plaatsen was dat ik verbaasd ben over het feit dat er vandaag de dag nog steeds SQL injections mogelijk zijn en waarbij wachtwoord un-encrypted in de database worden opgeslagen. Ik hoop ook dat er beheerders zijn die hun eigen site testen op deze vulnerability.

[O88088]

Je hebt in ieder geval niet zomaar alle gegevens op pastebin gezet, al een stuk beter dan die Anonymous zooi!

[Exorcist]

Met name de amateursites zijn slecht beveiligd tegen SQL injecties. Daarnaast, inderdaad, plain-text wachtwoorden in de database en je kunt je lol op. Van grotere sites zoals deze is het helemaal uit den boze.

Maar goed, hoe meer aandacht er aan besteed wordt, hoe groter de kans dat bij de beheerders () van grotere sites een lichtje aangaat om hun eigen beveiliging 's aan de kaak te stellen.

[Henrikop]

Je site vatbaar laten voor SQL Injection is gewoon prutswerk. En er is niet netjes mee omgegaan. Ik weet of de SQL Injection al mogelijk is vanaf de publieke pagina's, ik weet wel dat er crawlers zijn die testen op dit soort open deuren, de kans dat iemand de database dus wel heeft lijkt mij dus wel aanwezig. Aangezien half nederland hetzelfde wachtwoord gebruikt voor meerdere diensten vind ik dit behoorlijk slordig.

En wachtwoorden in plain text is gewoon een doodzonde, geen uitzonderingen.

Waar ik ook een hekel heb is aan sites die je wachtwoorden mailen. Dit betekent dat ze of wachtwoorden niet versleutelen of dat je wachtwoorden twee kanten op versleuteld zijn en daar is ook geen goede reden voor. Daarbij, als het in e-mail te lezen valt, zal het ook voor de medewerkers van het bedrijf te achterhalen zijn. Wachtwoorden zouden maar bij een persoon bekend mogen zijn, namelijk de gebruiker (wederom: geen uitzonderingen).

[Squ1zZy]

Dat is ook precies mijn reden waarom ik het slecht vind dat ze niet eerlijk hebben aangegeven dat gebruikersnamen en wachtwoorden waren bloodgesteld. Van de 200.000+ accounts die ik heb gevonden zijn de meeste met een gmail of hotmail account aangemeld. Je weet dus al waar je moet inloggen en met welke username. Via de mail zou je dan achter kunnen komen waar ze nog meer actief zijn.

Of het wachtwoord wijzigen op deze diensten en het wachtwoord laten emailen.

Gevaarlijkste is nog dat je niet door hebt dat er iemand in je mail zit omdat er met hetzelfde wachtwoord wordt aangelogged. Gebruikers worden pas op achterdochtig wanneer je hun wachtwoord zou wijzigen bijvoorbeeld en dat ze niet meer kunnen inloggen. PayPal is ook een goed voorbeeld.

Het stopt dus niet op de site van belegger.nl!

[-ETz-candyman]

Kan iemand mij uitleggen waarom md5-hashing dan niet meer voldoende zou zijn?
Beetje creatief met salts en het is toch direct een hele pak veiliger dan plain bewaren.

[mddd]

Inderdaad, met salt is het veel beter maar een md5 is tegenwoordig zó snel te berekenen dat het in het algemeen niet meer als een veilig algorithme word gezien. Met een brute force attack is het te snel te achterhalen.

[borft]

nog sterker, dat kan helemaal niet. Je kunt collisions vinden met rainbow tables, maar als er een salt gebruikt wordt, dan heb je daar niets aan.

[mddd]

Door een educated guess te doen met betrekking tot het salt en het wachtwoord, kun je alsnog héél veel mogelijkheden uitproberen en mogelijk dus tóch de wachtwoorden identificeren. Een salt maakt dit proces veel moeilijker, maar niet onmogelijk omdat md5 zo makkelijk is om te berekenen. Daarom gebruiken we tegenwoordig juist expres langzame algorithmes om hashes te berekenen.

[Foxpat]

Net als de vele beschikbare rainbowtables waardoor de meeste wachtwoorden binnen een paar seconden te kraken zijn.

[Wim-Bart]

md5 kan je gewoon met regenboogtabellen terugrekenen naar een aantal mogelijkheden, bij md5 kun je geen salt opgeven, althans niet in php. MD5 in php. Overigens kan dat bij SHA1 ook niet SHA1 in php.

Er zijn wel truukjes om dat te doen zoals zelf een salt concatenaten, maar netjes is het niet. Beter is het om crypt te gebruiken, daar kan je een salt opgeven.

[mddd]

Wel of geen ondersteuning voor een hash is een implementatie-detail. Een hash die je via crypt() maakt is precies even veilig als een hash die je maakt door zelf een salt en een string aan elkaar te plakken en dan te hashen.

[Reactie gewijzigd door mddd op 23 juli 2024 05:18]

[Just smile]

Best netjes dat de lek direct is doorgegeven aan Sanoma en dat deze niet direct publiekelijk is gemaakt. Ik ben benieuwd of deze tweaker zelf mee gaat werken aan de nieuwe website van bijvoorbeeld Belegger.nl.

Toch had dit helemaal niet mogen gebeuren, maar zo blijkt maar weer eens dat genoeg 'grotere' websites de makers daarvan er geen kaas van hebben gegeten.

Ik vind het van den zotte dat een website die bankgerelateerde gegevens van consumenten opslaat, geen verdomd goed systeem en beveiliging heeft.

Er moet duidelijk een internet wet komen dat dit soort 'fouten' als strafbaar worden bestempeld.

[mddd]

Er moet duidelijk een internet wet komen dat dit soort 'fouten' als strafbaar worden bestempeld.

Volgens mij zijn er voldoende kapstokken om in te grijpen als zoiets gebeurt. Als er door de site aantoonbaar slecht is gehandeld (niet in overeenkomst met gangbare eisen van veiligheid) dan is dat verwijtbaar.

Om hier nu weer een nieuwe regel voor te maken lijkt me dan ook niet zo nodig. En wat zou daar dan in moeten staan? Ga je precies beschrijven wat de eisen zijn qua techniek? Dat is niet slim want regelgeving loopt altijd achter. Of ga je aangeven voor welk soort sites er een strengere beveiliging nodig is? Dat wordt ook al heel snel subjectief.

Het is duidelijk dat dit ongewenst is, maar je kunt bij een dergelijke situatie als buitenstaander niet zomaar zeggen of het het gevolg is van slecht beleid, of van een ongelukkige misser in een systeem dat voor de rest degelijk in elkaar zit.

Dat gezegd hebbend, in dit specifieke geval: plain text is sowieso niet goed natuurlijk. Maar dan nog, ik denk dat je dat soort zaken niet in regelgeving moet willen beschrijven. Je zou in dit geval wel kunnen zeggen dat met de huidige kennis het duidelijk is dat plain text achterhaald is, en dus dat het beleid niet goed was.

edit:
Typo verbeterd en iets verduidelijkt.

[Reactie gewijzigd door mddd op 23 juli 2024 05:18]

[Dreamvoid]

Belegger.nl is geen bank, het is een soort Tweakers.net voor beleggers.

[Iblies]

Ben benieuwd hoe het met sites als Binck en Alex is. Daar is niet alleen echt geld te vinden, je zou er koersen mee kunnen manipuleren en zelf flink winst kunnen maken op kleine aandelen.

@Squ1zZy
Het is al eerder gebeurd, en de beveiliging zou beter moeten zijn;
Webwereld. Of het daadwerkelijk zo is weet je niet.

[Reactie gewijzigd door Iblies op 23 juli 2024 05:18]

[Squ1zZy]

Deze websites bepalen de koers niet
Het is een schakel tussen de koers en de belegger. De koers manipuleren en winst maken zoals jij aangeef is niet mogelijk

[Stoney3K]

Deze websites bepalen de koers niet
Het is een schakel tussen de koers en de belegger. De koers manipuleren en winst maken zoals jij aangeef is niet mogelijk

Je kan wel de database zo verbouwen dat de koersen niet meer kloppen, en daardoor het koopgedrag van beleggers beïnvloeden. Als je het laat lijken alsof een aandeel enorm keldert, gaat iedereen het massaal kopen (ook al is de werkelijke koers hoger) en gaat die koers ineens als een pijl de lucht in. Vervolgens gewoon de hele handel verkopen, en het verschil tussen jouw 'nep-koers' en de werkelijke koers mooi in je eigen zak laten verdwijnen.

[Squ1zZy]

Stoney3K: Daar zit wel wat in, maar de grote beleggers gebruiken niet deze site om de koers in de gaten te houden. Wel een goed punt opzich

Iblies en mddd: Daar had ik zelf nog niet aan gedacht +1

[mddd]

Koop- en verkoopopdrachten hebben wel degelijk invloed op de koers. Er is dus zeker wel kans op misbruik. Al helemaal als je afgeleide producten in ogenschouw neemt, waarmee je kunt speculeren op een stijging of daling. Stel dat je een groot aantal accounts zou kunnen overnemen, dan zou je al deze accounts een bescheiden aantal aandelen kunnen laten kopen, en daarmee in totaal een grote koersschommeling kunnen veroorzaken. En dan zelf cashen met je opties.

[gtissink]

Een hack is voor een belegginsinstituut altijd een blamage, maar
wel goede actie om iedereen te dwingen nieuwe passworden nemen.

De communicatie ...tja...wat moet ik daar op zeggen.... zeer creatief

[Anoniem: 340068]

Een hack is voor een belegginsinstituut altijd een blamage, maar
wel goede actie om iedereen te dwingen nieuwe passworden nemen.

De communicatie ...tja...wat moet ik daar op zeggen.... zeer creatief

hoope wel dat alle accounts wel disabled zijn.. anders kan iedereen die de password weet er nog in

[Sfynx]

Hoe komt het toch dat simpele SQL injecties met plain text wachtwoorden anno 2011 nog steeds mogelijk zijn? Vast weer een kwestie van de webbouwer inschakelen die de goedkoopste offerte weet te leveren

[jip_86]

Een legacy systeem lijkt me. ALs je maar voort en voort bouwt op je site van jaren terug dan kan dit zo gebeuren. Op een gegeven moment zal dit wel een keer meegenomen worden, dit zie je al aan het feit dat op de ene plek wel gehast werd en op de andere niet.

[Anoniem: 126717]

en geregistreerde gebruikers een nieuw wachtwoord hebben moeten instellen

Iets zegt me dat de gebruikers geen waarschuwing hebben gekregen dat het wellicht verstandig is om op andere sites waar die login/ww combinatie gebruikt worden ook te wijzigen?

[Squ1zZy]

Ik was ook verbaasd toen ik de melding kreeg om mijn wachtwoord aan te passen vanwege onderhoud. Check de post van Zoefff hierboven. Hij heeft een goed punt dat ze beter hadden kunnen aangeven wat er werkelijk aan de hand was. Ik ben het ook helemaal met Zoefff eens.