Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Ticketscript-database gaf toegang tot data kwart miljoen concertbezoekers

Door , 68 reacties, submitter: dazydude

Ticketscript had een database met daarin persoonlijke gegevens van naar schatting 250.000 bezoekers van concerten en andere evenementen achter een standaard 'admin'-wachtwoord staan. Zo waren namen, telefoonnummers en e-mailadressen van kaartjeskopers in te zien.

Het systeem van Ticketscript was via http toegankelijk en met het admin-account konden wachtwoorden van dat account en andere accounts veranderd worden. Dat ontdekte beveiligingsonderzoeker Sijmen Ruwhof, die op navraag van het Avro/Tros-programma Opgelicht op zoek ging naar kwetsbaarheden in systemen van bedrijven. Ook andere accounts bleken een standaardwachtwoord te gebruiken: gelijk aan de accountnaam.

Ruwhof constateerde dat hij toegang had tot gegevens van de personen die toegangskaarten hadden gekocht voor 1100 evenementen, waaronder van de Dutch Design Week en de Tesco Wine Fair. Hij maakt een voorzichtige schatting dat het om tussen de 200.000 en 300.000 personen gaat.

Ruwhof heeft Ticketscript ingelicht over de kwetsbaarheid die daarop de derde partij die het systeem beheerde, opdracht heeft gegeven het probleem op te lossen. Een jurist van Ticketscript claimt dat er geen sprake is van een datalek, omdat de beveiligingsonderzoeker slechts een beperkt deel van de data heeft ingezien en er verder geen ongeoorloofde toegang geweest zou zijn. Hierdoor zou het probleem niet bij de Autoriteit Persoonsgegevens gemeld hoeven worden.

Reacties (68)

Wijzig sortering
Een jurist van Ticketscript claimt dat er geen sprake is van een datalek omdat de beveiligingsonderzoeker slechts een beperkt deel van de data heeft ingezien en er verder geen ongeoorloofde toegang geweest zou zijn. Hierdoor zou het probleem niet bij de Autoriteit Persoonsgegevens gemeld hoeven worden
Misschien moet die jurist dan even naar een bijscholingscursus :X Dit is zo'n beetje de definitie van een datalek. Dan nog zou het verstandig zijn om het in ieder geval te melden, dan moet de AP maar beoordelen hoe ernstig het is.

[Reactie gewijzigd door Haan op 21 december 2016 08:00]

Precies. De autoriteit persoonsgegevens meldt op haar website over een datalek het volgende:

Bij een datalek gaat het om toegang tot of vernietiging, wijziging of vrijkomen van persoonsgegevens bij een organisatie zonder dat dit de bedoeling is van deze organisatie

Volgens mij had de heer Ruwhof toegang tot de persoonsgegevens van klanten van Ticketscript, zonder dat dit de bedoeling is van de organisatie. Een cursus zou de jurist niet misstaan..
Waarom heb ik toch het gevoel dat er in de loop van de dag een persbericht van AP gaat volgen.....
De jurist doelt erop dat ze data voor de helft hebben ingezien en niet helemaal.

Kijk je kan wel een straatnaam hebben maar geen postcode en huisnummer wat heb je dan aan die informatie.

Wij weten helaas niet wat er gelekt is en moeten de jurist maar vertrouwen. Mochten instanties het niet vertrouwen dan komt er vast nog wel een onderzoek
... en moeten de jurist maar vertrouwen...
Uit bovenstaande opmerkingen van verschillende reageerders blijkt nu juist dat je in dit speciefieke geval de jurist helemaal niet kán vertrouwen. Hij praat zijn werkgever naar de mond omdat dat goed uitkomt.

Een datalek moet áltijd worden gemeld.
Er staat wel een belangrijke uitleg op de website van de AP.

"Moet ik alle datalekken melden bij de Autoriteit Persoonsgegevens?

Nee. U hoeft een datalek alleen te melden als dit leidt tot ernstige nadelige gevolgen voor de bescherming van persoonsgegevens. Of als een aanzienlijke kans bestaat dat dit gebeurt."

Als ik de reactie van Ticketscript op de Tros Radar website lees lijkt het er op dat daar geen sprake van is. Mits en daar ga ik even vanuit dat men heeft gekeken wanneer er met account "Admin" is ingelogd.

Ik heb op de meeste systemen die een login kennen 3 accounts die net als alle andere gelogd worden maar waarop nooit een login zou moeten plaatsvinden. Gebeurd dat wel zitten we binnen een paar min een aantal man o.a. rechtop in bed.
Sja je vraagt je af of een developer die niet het benul heeft om passwords te hashen, wel het benul heeft om fatsoenlijke logging te implementeren. Misschien wel hoor, maar het klinkt nogal krom.
Tja ik denk dat het wel helder is hoe men moet denken over passwords maar goed het ene sluit het andere niet uit.

Het is sowieso al een vraag wie of wat die 3e partij is. Hoeft niet perse de ontwikkelaar van de software te zijn. Hoeveel Hosts met "beveiligde" servers zijn er wel niet die echt niet kijken of de Joomla, Wordpress of Drupal versie en plug-ins wel goed onderhouden worden.

Ik maakte pakweg 10 jaar geleden nog templates voor Joomla en WP destijds bij een bedrijfje. Bedrijfje bestaat al lang niet meer en ik vermoed via een Google topic search, Twitter, linkedIn werd ik een half jaar terug nog benaderd door een klant van destijds met het verhaal dat de website voor de zoveelste keer gehackt was.

Toch even gekeken wat er aan de hand kon zijn ook al doe ik er al jaren niks meer mee. Blijkt dat het nog altijd op een Joomla 2.5 versie draait en de meeste "plugins" van die tijd nog wel werken maar niet meer bestaan / ge-update worden. Oplossing van de "USA" Host. Gewoon een back-up terug zetten.

Ze zou een nieuwe website laten maken. Geen idee wanneer dat gaat gebeuren al heb ik me twijfels of dat gaat gebeuren. Er zal toch iets aan migratie van gegevens moeten worden gedaan vermoed ik.
Die developer hangt misschien wel hele dagen de beste stuurman aan wal uit op Tweakers en heeft geen tijd meer om z'n werk goed te doen :-)
Uit bovenstaande opmerkingen van verschillende reageerders blijkt nu juist dat je in dit speciefieke geval de jurist helemaal niet kán vertrouwen. Hij praat zijn werkgever naar de mond omdat dat goed uitkomt.
Ze tonen ook aan dat je IT'ers niet moet vertrouwen als het om juridische kwesties gaat. Beide vakgebieden werken met logica en regels maar de logica van juristen is heel anders dan die van IT'ers.
Een datalek moet áltijd worden gemeld.
Niet waar.

Uit de it Richtsnoeren Meldplicht Datalekken van de Autoriteit Persoonsgegevens parafraseer ik het volgende:
  • Wat is een datalek?
    Een beveiligingsincident waarbij persoonsgegevens verloren zijn gegaan, of onrechtmatige verwerking redelijkerwijs niet uit is te sluiten.
  • Melden aan het AP verplicht?
    Melden aan het AP is verplicht als het gaat om persoonsgegevens van gevoelige aard, of als er om een andere reden sprake is van (een aanzienlijke kans op) ernstige nadelige gevolgen voor de bescherming van de verwerkte persoonsgegevens.
  • Melden aan betrokkene verplicht?
    Melden aan de betrokkene is verplicht als niet alle gelekte gegevens (goed) waren versleuteld, of heeft het datalek om andere redenen waarschijnlijk ongunstige gevolgen voor de persoonlijke levenssfeer van de
Het is dus niet zo dat ieder beveiligingsincident ook een datalek is en het is ook niet zo dat ieder datalek gemeld moet worden.
Ze hebben de data voor de helft ingezien. Dat maakt het toch niet minder erg, en is toch nog steeds een datalek?
  • Als hij doelt op maar de helft van de gebruikers, is het dan minder erg voor diegene waarvan de data wel is buit gemaakt? Natuurlijk niet.
  • Als hij doelt op maar de helft van de gegevens, dan heb je volgens mij niet door wat die halve gegevens waard kunnen zijn.
Immers, stel dat hij alleen de namen, telefoonnummers, mailadressen en gehashte passwords kon inzien:
  • Door de gebruikersnamen zelf te hashen, kan je achterhalen wie allemaal hun gebruikersnaam als wachtwoord gebruiken. Al die accounts zijn vervolgens per direct te misbruiken.
  • Met alleen een mailadres en correcte naam is het zeer makkelijk een geloofwaardige phishingmail te maken, waardoor je ook van andere mensen hun wachtwoord buit kan maken.
Ik denk dus dat die jurist inderdaad beter een cursusje kan doen. Wat een druiloor :+
huisnummer + postcode is genoeg,

net als een naam en postcode, de straat heb je dan per definitie ook al, en een klein rondje langs de huizen met een pak folders op je arm en je weet waar die gene woont....
Het feit dat een (white hat) hacker bij de data kan komen, is op zich natuurlijk nog geen bewijs dat er ook data is gelekt. Dus dat ben ik wel met die jurist eens.

Dat neemt niet weg dat het enorm slordig is en dat deze fout ook een verder onderzoek vereist om te beoordelen dat er ook daadwerkelijk geen datalek is geweest via andere 'hacks' (om dit nou een hack te noemen...).
Op de website van de Autoriteit Persoonsgegevens staat het volgende als voorbeeld.
Voorbeelden van datalekken zijn: een kwijtgeraakte USB-stick met persoonsgegevens, een gestolen laptop of een inbraak in een databestand door een hacker.
Klinkt als het laatste voorbeeld, toch? Ook al gaat het om een white hacker.
inbraak is toch iets anders dan insluipen ;) Als je de deur laat openstaan kan een verzekering ook lastig gaan doen bij diefstal (zie het dan maar is te bewijzen als je geen camerabeelden hebt)
Gewoon http, admin wachtwoord, is er dan wel logging om het niet lekken aan te kunnen tonen?

Toch niet bepaald een sterk staaltje. Het minste wat ze kunnen doen is een wachtwoord reset, omdat er een mogelijkheid tot is geweest.
Een externe (whatever color) hacker had toegang tot de database en kon gebruikersnamen in combinatie met wachtwoorden zien van meerdere personen.

Daarmee was er toegang tot persoonsgegevens zonder dat het de bedoeling was van de organisatie.

Tenminste, ik hoop niet dat het de bedoeling is van deze organisatie dat hackers in de database komen 8)7
Feit is volgens mij dat een white hat hacker dingen heeft gezien die niet voor zijn ogen bedoeld waren. Hoe heeft hij anders die schatting kunnen maken? Lijkt me niet uit zijn duim gezogen. Het is niet zo dat hij bij data kan komen, maar voor een dergelijke schatting moet je bij de data zijn gekomen.

Daarnaast is de autoriteit persoonsgegevens een stuk specifieker dan jij. Er zou hier geen twijfel mogen zijn. Dit is een datalek.

BeToBe in 'nieuws: Ticketscript-database gaf toegang tot data kwart miljoen c...
Het feit dat een (white hat) hacker bij de data kan komen, is op zich natuurlijk nog geen bewijs dat er ook data is gelekt. Dus dat ben ik wel met die jurist eens.
Bij een beetje goed data lek blijven er geen sporen achten zodat men een lek heel lang kan gebruiken. Een "goede" hacker met kwade bedoelingen zal er dus voor zorgen dat het lijkt alsof er nooit toegang is geweest.

Bovendien is er nooit te zeggen dat er geen toegang is geweest want een open/lekkende database met admin priveleges is per definitie verdacht.
Fijne jurist inderdaad. Doet normaliter alleen echtscheidingen of tuinhekken waarschijnlijk. Compleet ongeschikt dus.
Alles om de reputatie van zijn client te redden, datalek is nou eenmaal een zeer beladen term tegenwoordig.
Volgens de jurist is mijn fietsband niet meer lek als ie helemaal leeggelopen is, er kan immers geen lucht meer uit ontsnappen.
En dan te weten dat verzoeken tot verwijderen van je gegevens niet uitgevoerd werd (je kreeg even later gewoon weer spam van ze).

Irritante partij dus.
Dit moet dan ook wel een advocaat van de duivel zijn }>
Ik heb in 2014 contact gehad met Ticketscript omdat ik een evenement wilde organiseren. Ik heb toen aangekaart dat er plaintext wachtwoorden gebruikt werden (ook per email) en dat ik me daar niet comfortabel bij voelde (wat kan er nog meer mis zijn?). Ik heb toen ook besloten om verder af te zien van het organiseren van een evenement via Ticketscript. Ik heb daar toen wel aan de bel getrokken en een mail wisseling gehad met Ticketscript.

Mijn mails werden niet serieus genomen:
Ik begrijp je overwegingen, maar zoals gezegd zijn er nog nooit vragen of opmerkingen over dit onderwerp gekomen.
Ik heb uiteindelijk zelf een scriptje geschreven voor mijn simpele evenementje en er verder niet meer bij nagedacht. Kwalijke zaak dat ze er niks mee gedaan hebben.

[Reactie gewijzigd door Bolk op 21 december 2016 10:14]

Ik heb in 2014 contact gehad met Ticketscript omdat ik een evenement wilde organiseren. Ik heb toen aangekaart dat er plaintext wachtwoorden gebruikt werden (ook per email) en dat ik me daar niet comfortabel bij voelde (wat kan er nog meer mis zijn?).
Dat alleen al zou reden genoeg moeten zijn voor de Autoriteit Persoonsgegevens om even een aanvullend onderzoekje te doen naar Ticketscript. Gewoon meteen pats-boem tik op de vingers. Dit is geen incidentje blijkbaar, dit is nalatigheid. Kan die luie jurist van ze ook eens even in de benen komen .
Ik heb hen ooit ook gemaild over de matig geconfigureerde HTTPS afhandeling van hun site. Nooit reactie op ontvangen.
Scores lijken wel verbeterd:
https://www.ssllabs.com/s...l?d=shop.ticketscript.com (C)
https://www.ssllabs.com/s...?d=shop3.ticketscript.com (A)

[Reactie gewijzigd door Opperpanter2 op 21 december 2016 22:33]

Ik heb in 2007 ook een lek gemeld bij ticketscript. Destijds was het mogelijk om alle verkochte kaartjes in pdf-vorm te downloaden met daarop persoonsgegevens.

De kaartjes (en persoonsgegevens) hadden dus doorverkocht kunnen worden. En een overzicht van mensen die op specifieke avonden/weekenden niet thuis zijn is natuurlijk ook erg handig voor het inbrekersgilde...

Het is toen wel gefixt in een dag na melden maar slordig was het wel. Blijkbaar hebben ze de security en bescherming van je gegevens nu nog steeds niet op 1 staan.

[Reactie gewijzigd door W1LL3M op 21 december 2016 22:01]

misschien moeten we de authoriteit persoonsgegevens een bauntyprogramma laten uitzetten.

systeem lijkt me simpel:
> hacker meldt zich met een lek,
> de APG verifieert de hack / het data lek,
> vervolgens stelt ze de betreffende partij op de hoogte, en betaald de hacker uit
> uiteindelijk int ze die vergoeding bij de verantwoordelijke partij, en legt zonodig nog een extra boete op.

problem solved.
AP stelt een deel van de vergoeding beschikbaar aan de White Hat hacker. Dat zou mooi zijn.
Bij een overtreding van de Wet Bescherming Persoonsgegevens kan de Autoriteit Persoonsgegevens al een behoorlijke bestuurlijke boeten opleggen. Hoewel ik denk dat zo'n bountyprogramma in principe niet verkeerd is, spoort het mensen wel aan om overal lekken te gaan zoeken iets wat niet per se enkel positief is. Er moet daarnaast wel goede controle zijn op wie deze exploits melden, omdat er anders kan bestaat op 'double-dipping' en ze de exploit alsnog doorverkopen aan kwaadwillende partijen.
Wel erg "lame" om je website te laten draaien onder de standaard passwords, bedrijf of persoon die de site gemaakt heeft moet zich echt schamen.

Verder een interessante reeks waarbij helaas niet dieper op de techniek wordt in gegaan, zou het leuk vinden als er meer inhoudelijk naar de techniek of de opsporing methodes gekeken zou zijn. Nu stond het veelal in het teken van "opa en oma" die op slinkse wijze geld afhandig gemaakt zijn.
Als ze precies de methodes zouden laten zien, wordt het Internet daarna weer compleet verziekt door script kiddies. Uiteindelijk is de consument dan weer de dupe, dus laten we dat maar niet doen!
Het internet wordt niet verziekt door script juffieskiddies, maar door eigenwijze, betweterige en technisch beperkte programmeurs die niets willen aannemen van anderen en daardoor keer op keer de fout in gaan.

[Reactie gewijzigd door mind123 op 21 december 2016 10:43]

Daar ben ik het mee eens. Maar moeten we dan die sysadmins maar een lesje leren door iedereen's gegevens zo maar te gaan lekken? Nee. En dus moeten deze methodes niet zomaar op straat liggen.
Dit zijn alleen geen echte hack skills. Dit kan elke blinde Russische hacker van drie jaar oud zonder internet verzinnen.

We laten ook Wegmisbruikers en overvallen op tv zien. Dan dit ook.
Dit zijn alleen geen echte hack skills.
Klopt, en dat is dus precies het probleem! Als de methodes letterlijk op straat zouden liggen, zouden allemaal 14 jarige jongens, zonder moreel besef, deze lekken gaan zoeken en lekker alles op internet gaan donderen. Uiteraard zonder het te melden.

Vergelijk je dit nou letterlijk met Wegmisbruikers en overvallen op TV? :z
Hij bedoelt dat het geen hack skills zijn omdat het weinig met hacken te maken heeft. Een wachtwoord raden valt onder de 'normale' vorm van inloggen. Bij hacken vind je een manier om in het systeem te komen of een handeling uit te voeren die daar oorspronkelijk niet voor bedoeld is, dat is hacken. Daar is hier geen sprake van, dit is gewoon een ontzettend slecht wachtwoord (en plain http is natuurlijk ook niet slim).
maar door eigenwijze, betweterige en technisch beperkte programmeurs die niets willen aannemen van anderen en daardoor keer op keer de fout in gaan.
Daar geloof ik niet in. Ik ben het met je eens dat er veel programmeurs zijn die slechte kwaliteit leveren maar niet om de redenen die jij noemt. Ik zie andere oorzaken die belangrijker zijn.
- Opleiding. Veel IT'ers hebben nooit een formele opleiding gehad maar hebben alles zelf geleerd. Daardoor zitten er fundamentele gaten in hun kennis waardoor de ze blind zijn voor bepaalde problemen.
- Geld. Goede IT is verschrikkelijk duur. Je kan tegenwoordig haast niet meer zonder IT maar om het echt goed te doen is bijna altijd te duur. Op zich is dat niet uniek aan IT, als je een bedrijfswagen koopt zul je ook moeten accepteren dat een Ferrari te duur is, maar in de IT is beveiliging de sluitpost die als eerste sneuvelt als het te duur wordt.
- Geschiedenis. Een enorme erfenis aan oude software die vanwege bovenstaande redenen fundamenteel niet goed in elkaar zit. Eigenlijk zou het beter zijn om dat soort software te vervangen maar dat is wederom vreselijk duur en het levert (in ieder geval op korte temijn) weinig op.
- Regelgeving. Tot voor kort was er geen enkel toezicht op de kwaliteit en veiligheid van software. De overheid bemoeide zich er niet mee en dus was het heel gewoon om beveiligingsproblemen geheim te houden of te ontkennen. Daarnaast is het vrijwel onmogelijk om garantie te krijgen op software of een leverancier aansprakelijk te stellen voor slechte software.
- Gevolgen. Als laatste is het een probleem dat de meeste beveilingsincidenten weinig gevolgen hebben op korte termijn, dat de slachtoffers meestal externen zijn, klanten ipv van medewerkers van het personeel, en dat het voor de slachtoffers haast onmogelijk is om te achterhalen waar het fout is gegaan. Het gekraakte bedrijf merkt er niks van de de credit cards van hun klanten geplunderd worden, en de klanten zien alleen dat hun credit card nummer gelekt is maar weten nooit welke website het gelekt heeft.
Natuurlijk is het een combinatie van verschillende factoren. De punten die jij aangeeft zijn ook zeker van toepassing. Maar, als ik een developer aanspreek op zijn verantwoordelijkheden en een botte reactie terugkrijg, dan heeft dat iets meer te maken met opleiding, geld, geschiedenis of wat dan ook. Dan ben je gewoon een domme botte hork die ze direct moeten ontslaan.
Het idee is juist dat je je beveiligt tegen dat soort simplistische aanvallen. Lezen de scriptkiddies het niet hier, dan wel ergens anders. Security by obscurity gaat je echt niet helpen als de beveiliging niet op orde is.
Ja dat weet ik wel! Maar dat is geen reden om die methodes dan maar op straat te gooien! En dan zijn Jan en Truus die net hebben leren internetbankieren weer de dupe. Dat is helemaal geen oplossing en brengt alleen maar ellende.
Een wachtwoord raden stamt al uit de tijd van de Romeinen. Niet echt iets nieuws zeg maar.

Overigens is het achterwege houden van de methodes een slechter idee dan ze "op straat gooien". Het idee van het publiceren is dat website beheerders de sites gaan beveiligen dankzij de informatie over de methode. Hou je het achterwege dan komen de "scriptkiddies" er echt wel achter én blijven een hoop sites kwetsbaar omdat niemand het weet. Dan zijn Jan en Truus nog veel vaker de dupe.
en er verder geen ongeoorloofde toegang geweest zou zijn.
Gegeven de professionaliteit van wat we gezien hebben moet je je afvragen:
Op basis van welke (beveiligde) audit logs?

Dit is gewoon marketing praat en damage control. Slechte damage control dan nog.
Nee precies. Dan krijgen we straks te horen: "Nee hoor, geen lek. Uit de access logs blijkt dat alleen "admin" heeft ingelogd op het systeem. En aangezien dat de beheerder is, is er niets aan de hand. Dus..."
8)7
Er is een enorm verschil tussen "admin" op een website en "admin" (of root) op een server. Ik ga ervan uit dat er een interessanter nieuwsbericht was gemaakt op het moment dat er daadwerkelijk toegang tot de hele server was verkregen. De logs lijken me dus niet aangetast, en dan kan je prima vaststellen wie er allemaal toegang heeft gehad. Niet dat ik hier iets mee goedpraat maar je moet ook niet overdrijven.

Ik sta trouwens ook in hun systeem en ik heb daar een speciaal e-mailadres voor. Ik heb daar nog geen spam op ontvangen dus waarschijnlijk is er niks gelekt.

[Reactie gewijzigd door DataGhost op 21 december 2016 09:24]

Sorrie, ik was de [sarcastic] tags vergeten.

Snap heel goed dat daar verschil tussen zit. Het is alleen zo dat als je admin rechten hebt in een web omgeving je over het algemeen bij alle data van de omgeving kan en dat het vervolgens moeilijk vast te stellen is dat er iemand oneigenlijk toegang heeft gehad op het moment dat iemand gewoon op de reguliere manier kan inloggen op de omgeving. :)
Ik heb de uitzending gezien en schrok enrorm van de reactie van ticketscript. Ze wouden de lek pas horen toen de camera weg was. Het interesseerde hun geen eens dat er lek was, maar zo lang ze maar niet in slecht dacht licht zou komen. Zulke bedrijven moeten meteen goed worden bestraft. Ze denken eerst aan hun imago, dan het oplossen van het lek. Het lek was trouwens een beginners fout, namelijk voor je admin paneel een gebruikersnamen admin hebben met daarbij het wachtwoord admin. Dit soort fouten hoor je niet te maken als je groot bedrijf bent en een groot aantal gevoelige data beheerd.

Linkje van de uitzending:
http://www.npo.nl/opgelic...2%3A2%2C%22max%22%3A20%7D

[Reactie gewijzigd door Xieoxer op 21 december 2016 08:06]

Ik kom het helaas met enige regelmaat tegen. Je wordt voor gek versleten, het probleem moet niet overdreven worden, en je moet je er maar vooral niet mee bemoeien. Een bedankje kan er niet vanaf oog.

Onbeschofte horken zijn het. Ik flikker ze dan ook direct uit het klantenbestand.
u: admin p: admin en hiermee kreeg men toegang tot alles.

Als je daar achter komt is dat dan echt een hack te noemen? Gewoon nalatigheid lijkt mij.
Gezien de business waarin ik actief ben, zou dit voor mij reden genoeg zijn om iemand op staande voet te ontslaan.
Lijkt mij ook, gisteren was het op TV namelijk en er werd behoorlijk luchtig over gedaan. Ik ben zelf ook jaren actief binnen banken en veel met Oracle gewerkt en je gaat schrikken hoe vaak de basis wachtwoorden (System/manager en sys/changeoninstall) gewoon de default waren.

Als je met security te maken hebt dan is dat een doodzonde en idd ontslag op staande voet!
Even serieus hoe dan ? De partij die het systeem beheerder neem je nu toch niet meer serieus.

Als je als sysadmin Iets naar buiten openzetten met het standaard admin password lijkt me dat je gewoon incompetent voor deze functie bent.

Sowieso verander je altijd het standaard password bij een systeem wat je in gebruik gaat nemen. Mag hopen dat deze partij zijn password beleid aanpast en dat ondertussen voor al zijn klanten heeft gedaan. Ticketscript zal vast niet de enigste zijn met dit systeem.

[Reactie gewijzigd door HKLM_ op 21 december 2016 08:39]

Er is bij mij altijd ingehamerd dat ik ook de het admin account kopieer>hernoem en een standaard admin account aanmaakt welk niks kan. Natuurlijk houd je daar een pro niet mee buiten maar zeg de prutsers wel.

Als je dan ook nog het standaard wachtwoord behoudt ben je niet heel goed bezig.
Eigenlijk moet de maker van de website je geen keus geven. Het is eigenlijk een ontwerpfout dat het mogelijk is om standaard inloggegevens een website te draaien. Hoeveel moeite is het om bij installeren of opleveren van een website verplicht een account aan te laten maken door de gebruiker/klant.
Ben ik het met je eens. Die optie zou erin moeten zitten, maar dat lijtk me toch ook weer een extra ding wat je als professional zélf zou moeten doen. Je kunt aan Microsoft wel zeggen van ik host mijn site vanuit een server2012 en daarin moeten zij dus zoiets activeren dat je direct je WW verandert voordat hij online kunt gaan. Ja mogelijk.
In Linux hetzelfde, je kunt prima een apache servertje installeren en vanuit daar je website hosten moet je dan naar 'Apache' bellen om die optie erin te zetten?
Ze gaan ervan uit dat je weet waar je mee bezig bent en dus dit soort dingen vermijd.
Ik doel eigenlijk meer op de gene die de website bouwt en niet op de gene die server software heeft geschreven. Veel dingen die professional zou moeten doen doen ze helaas niet... Gelukkig zijn er wel veel CMS/E-Commerce scripts die bij installatie je al een account laten aanmaken. Vroeg was het veel meer standaard wachtwoorden werk. Jammer genoeg wordt toch nog vaak de foute keuze gemaakt.
Het programma leek mij niet interessant, maar nu ik dit zo lees ga ik het toch eens terug kijken.

http://www.npo.nl/opgelicht-cybercrime/20-12-2016/AT_2061426
Schandalig dat dat vandaag de dag nog kan. Wat me vooral stoort is de arrogante houding die Ticketscript vervolgens aanneemt.
Een jurist van Ticketscript claimt dat er geen sprake is van een datalek omdat de beveiligingsonderzoeker slechts een beperkt deel van de data heeft ingezien en er verder geen ongeoorloofde toegang geweest zou zijn. Hierdoor zou het probleem niet bij de Autoriteit Persoonsgegevens gemeld hoeven worden
Wat een aparte manier van beredeneren. Ten eerste, de hoeveelheid data die ingezien is maakt natuurlijk niets uit. Ten tweede, wie zegt dat hij maar een beperkt deel van de data heeft ingezien? Data van ál je klanten zichtbaar voor een externe persoon is wat mij betreft de definitie van een datalek. De arrogante houding die ze vervolgens aannemen, maakt me een beetje angstig voor de toekomst met die partij.

Op dit item kan niet meer gereageerd worden.


Nintendo Switch Google Pixel XL 2 LG W7 Samsung Galaxy S8 Google Pixel 2 Sony Bravia A1 OLED Microsoft Xbox One X Apple iPhone 8

© 1998 - 2017 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Hardware.Info de Persgroep Online Services B.V. Hosting door True

*