Hackers kraken forum SETI@Netherlands

Het forum van de Nederlandse tak van het onderzoeksproject SETI is gekraakt. Een vermoedelijk Amerikaanse hacker maakte met sql-injectie onder meer wachtwoorden en e-mailadressen buit. Het lek is inmiddels gedicht.

De stichting SETI@Netherlands, dat het Amerikaanse onderzoeksproject SETI helpt met het ontdekken van buitenaards leven, laat weten dat de sql-hack woensdag op het vBulletin-forum plaatsvond. Hoewel het lek inmiddels is gedicht, stelt de organisatie dat bij de hack persoonlijke gegevens zijn buitgemaakt. Een van de gebruikers laat weten sinds donderdag spam te ontvangen, maar onduidelijk is of dit daadwerkelijk gerelateerd is aan de hack.

In een mail aan haar gebruikers adviseert de stichting gebruikers om hun wachtwoorden te wijzigen. Het is niet duidelijk hoeveel gebruikers het forum heeft. Andere delen van de website van de stichting zijn ongeschonden, omdat het forum losstaat van de rest van de site en zijn eigen naam- en wachtwoordsysteem heeft.

De hackaanval zou afkomstig zijn van de Stanford University, zo zou blijken uit de logs. SETI heeft de Amerikaanse universiteit benaderd om uit te zoeken welk ip-adres verantwoordelijk was voor de aanval. "Tijdens de aanval bleken er slechts weinig mensen aangelogd op het ip-adres. Dat zegt niet alles, maar wie weet levert dit nog resultaat op", laat het bestuur van de stichting weten.

IT-banen

Reacties (70)

Verwijderd 21 oktober 2011 14:19

Even een correctie op dit artikel van Yoeri Nijs:

De hack heeft niet plaatsgevonden op het vBulletin-forum, maar op de site van SETI@Netherlands: www.seti.nl.
Het forum van SETI@Netherlands, te weten http://forum.seti.nl, is verschoond gebleven van de inbraak.

De gemelde spam heeft zeer waarschijnlijk niets met de inbraak te maken, er zijn namelijk ook mensen die ca 4 dagen eerder al last hadden van genoemde spam.

De email met de melding over deze hack is verstuurd aan iedereen die zich ooit heeft aangemeld op de site. Het betreft ruim 5.700 email adressen.
Normaal versturen we alleen aan mensen die zich aangemeld hebben voor de nieuwsbrief, in dit geval is er besloten iedereen een email te sturen.

-------------------------------------------------------------
In tegenstelling tot wat in sommige reacties wordt gezegd, wordt SETI@Netherlands niet gerund door professionals, maar door een aantal vrijwilligers, die de site en het forum onderhouden in hun vrije tijd.

We hebben hier te maken met een historisch gegroeide situatie.
De club bestaat al meer dan 11 jaar. En 11 jaar geleden waren de eisen die aan opslag van wachtwoorden gesteld werden nog niet zo streng gedefinieerd.
Helaas is de oorspronkelijke opzet van die database in die 11 jaar nooit meer onderhanden genomen, wat wellicht wel had moeten gebeuren. Maar zoals gezegd, we zijn geen professioneel instituut, maar een club bestaande uit goedwillende, onbezoldigde, vrijwilligers.

[Reactie gewijzigd door Verwijderd op 25 juli 2024 20:32]

BasieP 21 oktober 2011 11:04

Nog steeds mensen/bedrijven die niet inzien dat het gebruik van 'standaad software' zoals vBulletin ook inhoud dat je kwetsbaarder bent voor dit soort aanvallen, en je dus altijd up2date moet blijven.

Ze dichten hun gaten echter wel wat sneller dan bepaalde nederlandse gemeenten

xxxneoxxx @BasieP • 21 oktober 2011 11:34

Veel bedrijven hebben meer dan alleen een ICT afdeling. Valt mij regelmatig op dat op tweakers veel mensen (scholieren?) rond lopen die helemaal geen feel hebben met het bedrijfsleven en geen realistische kijk op het bedrijfsleven hebben.

We zitten wereldwijd al jaren in een financiële crisis, waardoor grotere projecten e.d. uitgesteld worden, en overal bezuinigd wordt. Laat ICT nu net een mooie directe bezuiniging zijn binnen veel bedrijven.

Als je al je collega's wegbezuinigd ziet worden, dan is het up 2 date houden van webservertje X met alle recente patches niet je eerste prioriteit. Sterker nog, veel systeembeheerders kiezen er voor om niet continue alles te patchen, aangezien je dan niet aan je dagelijkse werkzaamheden toe komt. En een hoop software krijgt elke maand/2 maanden patches, wat regelmatig leidt tot downtime, da's ook niet echt wenselijk voor de meeste bedrijven.

Nu zeg ik niet dat het overal zo geregeld is, maar dat is WEL wat ik steeds vaker om mij heen zie in het bedrijfsleven. De praktijk zeg maar, i.t.t. wat veel mensen hier propageren, schoolbankjes theorie. Het is in de praktijk sowieso schijnbaar vrij lastig inzichtelijk te maken wat ICT nu daadwerkelijk oplevert/bespaart, maar besparen op ICT lukt de meeste managers toch snel genoeg. Zeker als het niet de core-business is bij een bedrijf.

Haribo112 21 oktober 2011 11:03

SQL injectie. kreun... Ik leer in klas 1 van het vwo al mysql_real_escape_string()... da's echt wel het basiscommando. Dat er serieus volwassen, professionele mensen zijn die dit nog vergeten bij het maken van een website is toch te bizar voor woorden.

YopY @Haribo112 • 21 oktober 2011 13:57

SQL injectie. kreun... Ik leer in klas 1 van het vwo al mysql_real_escape_string()... da's echt wel het basiscommando. Dat er serieus volwassen, professionele mensen zijn die dit nog vergeten bij het maken van een website is toch te bizar voor woorden.

Mwa, de software die ze gebruiken is vBulletin v. 3.8.4 (wordt lekker prominent onderaan de pagina geadverteerd - pro tip, haal alle versie-informatie van software die je draait weg uit je opmaak en foutmeldingspagina's), vBulletin is ondertussen al antieke software, en 3.8.4 is uit 2009, dwz antiek. Waarschijnlijk is de vB SQL library uit die tijd gewoon braq.

Ook de schuld van de eigenaren natuurlijk, dan moeten ze hun vB licenties maar vernieuwen en upgraden, of omschakelen naar andere software - vB 3.8.4 is namelijk lek.

Soggney @Haribo112 • 21 oktober 2011 11:07

Die professionelen hebben uw klas 1 niet gevolgd, en serieus niet alles staat op een mysql database.
Het is te bizar voor woorden dat je aanneemt dat alles wat je op school ziet ook live gedeployed wordt.

Dat SQL-injectie nog kan is jammer, maar helaas nog wel een feit. Maar het is niet atlijd te omzeilen met mysql_real_escape_string() .

Bauknecht @Soggney • 21 oktober 2011 12:18

Het enige wat ik te bizar voor woorden vind is dat er blijkbaar nog veel systemen zijn die hun queries zelf samenstellen ipv stored procedures of prepared statements te gebruiken.
Je datalaag is duidelijk gescheiden van de rest, én omdat code en data compleet gescheiden worden, moet je al een crack zijn om nog met injectie weg te geraken.

Edit op hieronder: een cast "vergeten"? Ik zou denken dat je omzettingen en escaping in je datalaag steekt, zodat je niet telkens opnieuw zelf aan die escaping moet denken. Dat is trouwens ook het meest logische: hoe er ge-escaped moet worden, moet je businesslogica niet weten, dat is de zorg van je datalaag die met je databank praat. En die moet systematisch, op een consequente en voldoende wijze, de nodige formattering en escaping doen van je input. En dat test je dan grondig door er alle mogelijke rommel tegenaan te gooien die je kan bedenken. En dan ben je goed bezig.
Als er dan een systematische flaw inzit, ok, dat kan gebeuren. Dan hoef je jezelf niets te verwijten, je hebt tenminste je best gedaan om het zo proper mogelijk op te lossen. En die flaw kan dan op één punt in je code opgelost worden en het spel is terug potdicht.

Maar programmeurs de grond instampen omdat ze 'soms vergeten te escapen': count me in. Dat zijn mensen die IMHO beter geen software schrijven omdat ze blijkbaar niet logisch kunnen nadenken en ontwerpen.

[Reactie gewijzigd door Bauknecht op 25 juli 2024 20:32]

Blaise @Bauknecht • 21 oktober 2011 15:23

Waarschijnlijk gebruikt VBulletin geen stored procedures of prepared statements vanwege compatibiliteit met platformen. PDO zit pas standaard in PHP sinds versie 5.1. En veel shared webhosting omgevingen zijn pas net over op PHP5, of draaien zelfs nu nog PHP4.

En ja, als je andere manieren gebruikt voor escaping, en/of dat steeds handmatig moet doen, dan kan er iets fout gaan.

Verwijderd @Blaise • 21 oktober 2011 15:45

Je kunt met een paar regexes zelf een 'prepared statement' en een PHP array met parameters (die je escaped) 'mergen', en dat richting je database sturen. Precies wat PDO doet als de db-server zelf geen prepared statements ondersteunt. Gegarandeerd net zo veilig als prepared statements, zolang je maar altijd je prepared-statement-queries via die functie naar 'echte' queries ombouwt, die de database snapt.

Er is dus geen enkele reden geen prepared statements te gebruiken als je PHP driver het niet ondersteunt.

$params = array('name' => $_POST['username']);
$db->execute("SELECT * FROM users WHERE username = :name", $params);
// wat er gebeurt: $query split je op pattern ":xyz", je pakt zo de value uit de $params, escaped die, concat hem in een nieuw op te bouwen $query, en voert hem uit de op DB

Tuurlijk haal je dit soort truuks alleen uit als je geen PDO hebt, maar dan zit je tenminste veilig. En niet klagen over string-manipulation performance, want de overhead is verwaarloosbaar klein.

[Reactie gewijzigd door Verwijderd op 25 juli 2024 20:32]

onox @Blaise • 21 oktober 2011 20:30

Mensen die nu nog PHP 4 gebruiken moeten, om in Steve Jobs termen te praten, worden vernietigd met een nucleaire bom

Mja, mensen blijven eigenwijs he, ze willen vaak niet luisteren en blijven lekker strings aan elkaar plakken

[Reactie gewijzigd door onox op 25 juli 2024 20:32]

Remcoder @Soggney • 21 oktober 2011 11:19

Elke breed gebruikte database library heeft tegenwoordig ondersteuning voor het escapen van queries.

Als je een library hebt die dat niet ondersteund kun je beter een andere zoeken.

J.J.J. Bokma @Remcoder • 21 oktober 2011 19:03

Een beetje library laat je werken met "bind parameters". Juist het hele escape feest (PHP) draagt bij aan SQL injecties.

Remcoder @Haribo112 • 21 oktober 2011 11:10

Nu een website op die manier lek laten is inderdaad not done. Maar je moet je even bedenken dat de meeste websites jaren geleden ontwikkeld zijn toen security nog niet zo'n grote issue was en dus minder beveiliging bevatten.

Tegenwoordig kan elke 10-jarige aan scripts komen om sites te hacken en worden er dus ook meer sites aangevallen die niet bijgewerkt zijn met nieuwe technieken om te beveiligen.

xoniq @Remcoder • 21 oktober 2011 14:27

Wat je nu aangeeft, dat is waarom een website onderhouden hoort te worden .. Een website hoort up-to-date te zijn wanneer jij niet gehacked wilt worden.

poepkop @xoniq • 21 oktober 2011 20:07

Makkelijker gezegd dan gedaan: Niet veel bedrijven durven hun klant een factuur te sturen voor een beveiligings-check, want dan geven ze de klanten het gevoel dat de site nooit goed gebouwd is.

The Zep Man

Privacy
Hackers

@Remcoder • 21 oktober 2011 13:48

Nu een website op die manier lek laten is inderdaad not done. Maar je moet je even bedenken dat de meeste websites jaren geleden ontwikkeld zijn toen security nog niet zo'n grote issue was en dus minder beveiliging bevatten.

Dit pleit niet de verantwoordelijke van de site vrij van het niet onderhouden. Als een site niet redelijk beveiligd is (het toestaan van SQL injecties valt hier niet onder), zou de verantwoordelijke net zo aangepakt moeten worden als de hacker. Immers: het is niet alleen de verantwoordelijkheid over de eigen data, maar ook die van anderen.

Voor de rest ben ik het met een aantal andere reacties eens: een strikte scheiding tussen programma- en datalaag geniet de voorkeur om de kans op dit soort simpele hacks drastisch te verminderen.

[Reactie gewijzigd door The Zep Man op 25 juli 2024 20:32]

Verwijderd @Remcoder • 21 oktober 2011 17:20

sql-injecties waren anders al breed bekend onder de mensen die kennis hebben jaren geleden.

Ik denk dat wat script kiddies wat tooltjes hebben gemaakt om alle websites faf te kunnen gaan.

Memori @Haribo112 • 21 oktober 2011 11:47

Je voert geen mysql_real_escape_string() uit op een integer. Doordat er wellicht meerdere programmeurs aan geknutseld hebben, kan het maar zo zijn dat er i.p.v. %d een '%s' is gebruikt in een sprintf() functie. Of gewoon vergeten de input te casten naar een integer. Het kunnen zoveel dingen zijn, en het overkomt iedereen wel eens. Je moet gewoon pech genoeg hebben als iemand dit ontdekt en er kwade bedoelingen mee heeft.

De programmeurs de grond in stampen doordat een sql-injectie mogelijk was, is best wel flauw.

J.J.J. Bokma @Memori • 21 oktober 2011 19:06

Niks flauw: dit zijn gewoon prutsers. Verder, je hoeft helemaal niet met escape string en ander gepruts aan de slag als je simpel weg gebonden parameters gebruikt.

Milt @Haribo112 • 21 oktober 2011 12:48

Het is zo basis dat je het eigenlijk niet meer moet gebruiken. Kijk eens naar prepared en/of parameterised SQL statements en parameter binding. Dan laat je de escaping geheel over aan de database layer (waar het eigenlijk ook hoort).

J.J.J. Bokma @Milt • 21 oktober 2011 19:09

Precies, amen. Het verbaast mij steeds weer dat in bijna elke discussie hier mensen met eigen broddelwerk en "mysql_real_escape_string" (en ander geleuter) aan komen zakken, terwijl het zo simpel is: parameter binding.

En altijd opletten als je dynamisch een deel van je query bouwt, want daar helpt niks tegen als je dat niet goed doet (b.v. tabel naam uit de URL plukken).

lauwie0 @Haribo112 • 21 oktober 2011 11:23

Je zou bijna denken dat ze dit express doen bij seti om de echte data over contact met ET te verhullen

J.J.J. Bokma @Haribo112 • 21 oktober 2011 19:01

Jammer, dan heb je het toch verkeerd geleerd. Beste is bind parameters (mysqli). Een groot deel van die SQL injectie ellende komt juist omdat mensen menen dat het soms wel en soms niet escaped moet worden.

Verwijderd @Haribo112 • 22 oktober 2011 17:56

De mysql_real_escape wordt door de toegepaste hack mooi omzeilt.

jeroen94704 21 oktober 2011 11:13

Zucht, en weer blijkt een website zijn wachtwoorden (blijkbaar) in plain text op te slaan. Het MD5 SQL commando is echt niet moeilijk hoor.

comecme @jeroen94704 • 21 oktober 2011 22:16

Dat verbaast mij eigenlijk ook het meest. In de mail die ik heb gekregen staat dat de hacker m'n userid en wachtwoord te pakken heeft gekregen. Dat lijkt dus te impliceren dat de wachtwoorden ongecodeerd waren opgeslagen.

En aangezien Seti nou niet echt een belangrijke site voor me is gebruik ik dezelfde userid/wachtwoord-combinatie inderdaad ook op veel andere sites. Wat een ellende om die allemaal af te lopen (voor zover ik uberhaubt weet op welke sites ik ze gebruik) om het wachtwoord te veranderen.

Verwijderd @comecme • 22 oktober 2011 03:11

nee, jouw wachtwoord kan gecodeerd opgeslagen staan. alleen elke keer dat je inlogt codeer je je wachtwoord. het zwakste punt is dan de codering niet meer maar de lengte van je wachtwoord. als jouw wachtwoord "krekel" is dan word dat misschien gestuurd als "ad206ca3bf01cbd813fdce3d67a7f1e3"(hex md5).
dit is niet meer terug te rekenen. maar ik kan wel van "a" tot "zzzzzzzzz" proberen tot ik met de zelfde codering op "ad206ca3bf01cbd813fdce3d67a7f1e3" uitkom. als ik dit bij alle mogelijkheden heb gedaan is het een kwestie van die md5 value terug zoeken en komt er "krekel" uit (en in sommige gevalled dubbele of nog meer mogelijkheden". zodra jouw wachtwoord 17 karakters bereikt heb ik theoretisch 256 wachtwoorden die de zelfde md5 codering heeft als die van jouw.
in een rainbow table is het heel snel terug te vinden wat jouw wachtwoord geweest was terwijl jouw wachtwoord wel gecodeerd was.

comecme @Verwijderd • 22 oktober 2011 11:21

Als de wachtwoorden als hash zijn opgeslagen is het dus niet waar wat er in het mailtje staat. Dan hebben ze m'n wachtwoord helemaal niet buitgemaakt. Hooguit kun je dan stellen dat ze mogelijk m'n wachtwoord hebben kunnen achterhalen.

Voor hetzelfde geld is het ze alleen om de emailadressen gegaan.

Verwijderd @comecme • 22 oktober 2011 13:21

dan hebben ze niet direct je wachtwoord buitgemaakt, maar dat wilt niet zeggen dat het verre van onmogelijk is om je wachtwoord te achterhalen. als je wachtwoord 16 karakters of korter is heb je ongeveer 1+1/2 (1 omdat je achtwoord er tussen staat en een halve kans omdat kortere wachtwoorden ook die hash kunnen geven) mogelijke wachtwoorden die overeen komen met jouw hash code.
daarnaast moet jij kunnen inloggen, dus die hash stond waarschijnlijk daar wel opgeslagen want je moet immers kunnen inloggen.
ga er niet van uit dat als het gecodeerd opgeslagen staat dat het veilig is. in tegendeel zelfs, als het md5 was is met een rainbow table je wachtwoord binnen een paar minuten te achterhalen, met brute force word het na 9 karakters alleen het tijds process langer om de zelfde hash te genereren.

dus, ja ze hebben *mogelijk* je wachtwoord, maar zit niet veel ruimte tussen dat er meerdere wachtwoorden mogelijk zijn om op de zelfde hash uit te komen.
naar mijn weten maakt de codering niet veel uit omdat de server een vaste waarde moet vasthouden om jouw wachtwoord te checken als je inlogt en coderingen (hash berekening eigenlijk) kun je altijd zelf genereren (net zo lang tot de zelfde uitkomst eruit komt van jouw hash)

[Reactie gewijzigd door Verwijderd op 25 juli 2024 20:32]

Verwijderd @Verwijderd • 24 oktober 2011 14:52

correctie****
ik las "Voor hetzelfde geld hebben ze alleen de emailadressen buitgemaakt" inplaats van "Voor hetzelfde geld is het ze alleen om de emailadressen gegaan."
mijn fout

CMG @jeroen94704 • 21 oktober 2011 11:25

MD5 is prima te reversen zoals tweakers.net zelf ook in een van de laatste .plan's heeft laten zien

Verwijderd @CMG • 21 oktober 2011 15:02

Juist MD5 is een berekening. enige wat je kan doen is een reverse lookup, maar dan moeten de uitkomsten wel al bekend zijn (denk aan een rainbow table). als het wachtwoord 17 karakters(bytes) zou zijn, zijn er (theoretisch)256 andere wachtwoorden met de zelfde md5, omdat je simpelweg niet meer dingen kan identificeren met minder.
dus heel beperkt reverse, terug rekenen gaat gewoon niet.
bruteforce zal voor een goed aantal md5's te doen zijn. maar dan moet het wachtwoord niet te lang zijn geweest.

[Reactie gewijzigd door Verwijderd op 25 juli 2024 20:32]

Shal-Ziar 21 oktober 2011 11:07

Ik ben eerlijk gezgegd vooral benieuwd naar de motivatie achter deze hack. Op de site staat wel is waar onderzoek, maar niet van het type waarmee bedrijven hun voordeel kunnen doen dus het lijkt me niet dat deze aanval verbonden is aan het bedrijfsleven.

De hacker verveelde zich waarschijnlijk.

Mr. Awesome @Shal-Ziar • 21 oktober 2011 11:14

Volgens de mail die ik kreeg van SETI@Netherlands hebben ze het IP van de hacker kunnen achterhalen en blijkt het van Stanford University af te komen. Misschien een onderlinge ruzie tussen Stanford en Berkeley?

CMG @Mr. Awesome • 21 oktober 2011 11:23

Nee, aan het uni netwerk hangen heel veel persoonlijke systemen die vaak slecht secured zijn. Deze gebruikers vormen dan ook een fijn doelwit aangezien ze beschikken over een snelle verbinding (tegenwoordig veel minder van belang dan vroeger, maar toch). Je ziet dan ook dat hackers deze ip range (vuln scans) of de gebruikers zelf (via social engineering) targeten. Ik acht de kans groter dat het gewoon om een compromised systeem gaat dat als laatste punt in een keten is gebruikt om op jacht te gaan.

Titusvh @Shal-Ziar • 23 oktober 2011 11:38

In de mail die ik als mede-slachtoffer kreeg stond dat mijn mailadres, username en password(!) zijn buitgemaakt.
Daar kan je leuke dingen mee doen!

Bierkameel 21 oktober 2011 11:02

Hoe moeten we ooit buitenaards leven vinden als we al niet eens fatsoenlijk een database kunnen beveiligen

xoniq @Bierkameel • 21 oktober 2011 14:25

Dat is dan ook de reden dat we buitenaards leven zoeken, in de hoop dat deze wezens slimmer zijn en wij dus dit soort dingen van hun kunnen leren

.

Maar zonder gekheid, ik vind het vrij schandalig dat er nog zoveel SQL-injectie voorkomt in de grote websites .. Wordt daar geen vernieuwingen of onderhoud gedaan?

Hoe moeilijk is het om bijvoorbeeld gebruiker invoer te escapen met bijvoorbeeld mysql_real_escape_string() e.d.

En dan noem ik nog maar het meest simpele voorbeeld ..

En voor echt numerieke waarden altijd (int) voor de waarde zetten wanneer dit een query in gaat.

[Reactie gewijzigd door xoniq op 25 juli 2024 20:32]

poepkop @xoniq • 21 oktober 2011 20:01

Enorm moeilijk. Genoeg sollicitanten gezien die nog nooit van de functie gehoord hebben, en dat soort lui hebben dan een HBO diploma op zak.

Maar je geeft nu een simpel voorbeeld, waar ik een voorstander van ben is om met verschillende SQL-users te werken: De meeste sites hoeft de SQL-user geen schrijfrechten te hebben (bij een Forum is dit anders), dus kan je net zo goed die schrijfrechten uitzetten.
En je kan natuurlijk ook functies schrijven die het 1) eenvoudiger maken om met je database te werken en 2) meteen de beveiliging voor hun kiezen nemen (Bauknecht legt het hieronder bijzonder goed uit).

Wat ik overigens ook ontzettend stom vind is dat bedrijven alles maar opslaan in die databases die online staan, puur uit gemak.

[Reactie gewijzigd door poepkop op 25 juli 2024 20:32]

onox @xoniq • 21 oktober 2011 20:22

Je kunt SQL-injectie voorkomen door queries te parameteriseren d.m.v. prepared statements. Dan geef je de parameters apart mee i.p.v. dat je string concatenation gaat toepassen.

Titusvh @xoniq • 23 oktober 2011 11:33

Ja en dan ook nog de wachtwoorden plaintext op te slaan. Want in de mail die ik van hen kreeg stond dat ook mijn wachtwoord is buitgemaakt.

Zowel de SQL-injectie als unencrypted opslaan van wachtwoorden anno 2011 is eigenlijk gewoon grove nalatigheid. (lees: aansprakelijheid)

Sneezzer @Bierkameel • 21 oktober 2011 11:11

/sarcasm
Ik ben blij dat de "hackers" nutteloze hacks doen op nutteloos spul...
/einde sarcasm

Ik hoop dat de epeen van de hackers nu eindelijk eens groot genoeg is en de wereld weer eens in het echt gaan bekijken ipv. de hele dag random sql injecties afvuren tot ze een hit hebben.

Fbian @Bierkameel • 22 oktober 2011 14:35

Mooi voorbeeld van een drogreden geef je.

NeFoRcE 21 oktober 2011 11:05

Jammer dat dit nog steeds de meest voorkomende veiligheidslek is. Je zou toch verwachten dat bedrijven hun zaakjes op orde hebben. Ook al besteed je je website uit aan webdev bedrijven. Af en toe een update kan geen kwaad. En is andersom niet beter? Wachtwoord automatisch laten wijzigen en opsturen naar het bijbehorende email-adres, ipv. de gebruiker vragen hun wachtwoord te wijzigen?

Verwijderd @NeFoRcE • 21 oktober 2011 14:27

Er is aan de mensen verteld dat als ze hetzelfde password ook elders gebruiken, ze hun password ook daar moeten wijzigen, want het is gewoon geen veilig password meer.

hiekikowan

21 oktober 2011 11:05

vBulletin is toch wel een gerenomeerd forum-systeem... vreemd dat dit soort lekken dan nog mogelijk zijn...

Verwijderd @hiekikowan • 21 oktober 2011 14:28

De hack vond niet plaats op het forum, maar op de website.
vBulletin valt dus niets te verwijten.

Verwijderd @hiekikowan • 21 oktober 2011 11:24

Het is alleen bekend, maar als mijn software ook overal lekken zou hebben, zou die dat ook zijn

Verwijderd 21 oktober 2011 11:04

Het gaat toch alleen om een standaard template forum? vBulletin?

Dus in principe hebben ze niet echt de servers gehackt waar alle onderzoek op gedaan wordt. Storm in glas water?

Verwijderd 21 oktober 2011 11:11

Ik ben helaas ook lid van S@NL en ik merk ook dat ik sinds enkele dagen veel meer spam ontvang (ik heb nog niet gekeken hoeveel meer er wordt afgevangen door het filter).

Er jammer dit. Helemaal aangezien ik nu mijn "simpele" wachtwoord moet vervangen. Deze is niet het belangrijkst, maar wel het meeste werk aangezien ik die gewoon voor veel sites gebruik

Toch wel blij nu dat ik voor belangrijkere zaken altijd aparte wachtwoorden heb die wel af en toe wijzigen...

Verwijderd @Verwijderd • 21 oktober 2011 11:53

Ik ben helaas ook lid van S@NL en ik merk ook dat ik sinds enkele dagen veel meer spam ontvang (ik heb nog niet gekeken hoeveel meer er wordt afgevangen door het filter).

Net even gekeken, maar het mail adres dat Seti@NL heeft van me heeft nog helemaal geen spam ontvangen sinds het waarschuwingsmailtje.

Verwijderd @Verwijderd • 21 oktober 2011 13:51

Het kan ook prima toeval zijn hoor. Heb wel vaker van die "spam dagen".

Feit blijft wel dat je je wachtwoord niet meer kunt gebruiken.

Op dit item kan niet meer gereageerd worden.

Lees meer

IT-banen

Reacties (70)

Sorteer op:

Weergave: