Computerbeveiliging
- Hoe je bad guys buiten de deur houdt
[Verwijderd]
09-08-2014, 10:53 door [Account Verwijderd], 10 reacties
Laatst bijgewerkt: 09-08-2014, 16:51
[Verwijderd]
Reacties (10)
In de transactiegegevens kan niets worden gewijzigd, dus de kaarthouder wiens gegevens zichtbaar waren, kon geen financieel nadeel ondervinden.”
Lol die gasten hebben zeker nooit gehoord van identiteit diefstal :P
Kon? Dit kan dus nog steeds, want ze zijn nu software aan het testen om dit lek te sluiten. Tjonge jonge, wat wordt het er toch allemaal professioneel van als je zaken uitbesteedt aan bedrijven. En zo klantvriendelijk en goedkoop.
Zijn ze niet in strijd met de WCC en de WBP bezig trouwens? Of telt dat niet als je betaald wordt door de overheid?
Oehoe overheid, marktwerking werkt alleen als de klanten wat te kiezen hebben, anders zijn ze beter af met een planeconomie!
Zijn ze niet in strijd met de WCC en de WBP bezig trouwens? Of telt dat niet als je betaald wordt door de overheid?
Oehoe overheid, marktwerking werkt alleen als de klanten wat te kiezen hebben, anders zijn ze beter af met een planeconomie!
Beetje een vaag en onduidelijk verhaal; want wat was nu exact het 'lek'?
Zelf geven ze aan dat het 'lek' niet reproduceerbaar is, maar wel dat het 'soms' mogelijk is om andermans gegevens in te zien.
Klinkt dus eerder als een probleem met een interne (sessie) sleutel generator die niet volledig (secure) random nummers uitgeeft. Dan doet de wet van de grote getallen de rest... Dus zeker fout; maar m.i. niet echt 'exploitable'...
Maar zonder meer technische achtergrond info blijft dit koffiedik kijken.
NB: wat me trouwens wel angstig maakt is dat ze de fout kennelijk al gevonden en gefixt hebben, maar tot dinsdag te tijd nodig hebben om deze naar productie te krijgen! Lijkt erop dat de prioriteit pas omhoog gegaan is na publicatie in de media - en dan nog eens plus vier dagen. Ik ken bedrijven waar zo'n melding (klant ziet andermans gegevens) dezelfde avond gefixt _moet_ zijn...
Zelf geven ze aan dat het 'lek' niet reproduceerbaar is, maar wel dat het 'soms' mogelijk is om andermans gegevens in te zien.
Klinkt dus eerder als een probleem met een interne (sessie) sleutel generator die niet volledig (secure) random nummers uitgeeft. Dan doet de wet van de grote getallen de rest... Dus zeker fout; maar m.i. niet echt 'exploitable'...
Maar zonder meer technische achtergrond info blijft dit koffiedik kijken.
NB: wat me trouwens wel angstig maakt is dat ze de fout kennelijk al gevonden en gefixt hebben, maar tot dinsdag te tijd nodig hebben om deze naar productie te krijgen! Lijkt erop dat de prioriteit pas omhoog gegaan is na publicatie in de media - en dan nog eens plus vier dagen. Ik ken bedrijven waar zo'n melding (klant ziet andermans gegevens) dezelfde avond gefixt _moet_ zijn...
Had niets anders verwacht dan dat dit zou gaan gebeuren. En ja, what's next?
En dan te bedenken dat men 1 Euro per kaartje bij moet betalen, wil iemand juist dit soort situaties voorkomen.
Pleur op, met die pokkekaart.
En dan te bedenken dat men 1 Euro per kaartje bij moet betalen, wil iemand juist dit soort situaties voorkomen.
Pleur op, met die pokkekaart.
Heel af en toe worden sessies verward. En de fix is net uit: https://issues.apache.org/bugzilla/show_bug.cgi?id=47714
Door Anoniem: Heel af en toe worden sessies verward. En de fix is net uit: https://issues.apache.org/bugzilla/show_bug.cgi?id=47714
Ik zie geen fix daar. Wel hints dat het probleem wel in de applicatie zal zitten en een algemene observatie die zou wijzen op (alweer) een architectuurfout. Met andere woorden, het is een type probleem dat al jaren bekend is maar af en toe weer opduikt omdat er mensen niet nagedacht hebben over wat ze nou eigenlijk aan het doen zijn.Overigens, "heel af en toe" maal "twee miljoen geregistreerde gebruikers" kan al gauw "dagelijks gedonder" betekenen.
Door Eric-Jan H te A.
Chrome x64 en inlogpagina zijn nog steeds geen vriendjes. Kan iemand dat bevestigen?
Chrome x64 en inlogpagina zijn nog steeds geen vriendjes. Kan iemand dat bevestigen?
Door Anoniem:
Ja ik zie alleen een hint dat het een applicatiefout betreft.
ik kan mij herinneren dat wij in het relationale databasesysteem DB2 van het grote en robuuste IBM ook tegen een dergelijke fout zijn aangelopen. Dat was voor de tijd dat DB2 zoiets als een "unique identifier" veld kreeg.
De ontwerper was er van uitgegaan dat een timestamp wel uniiek zou zijn. En hij had dat in zijn testomgeving met een bulktest ook bewezen. De timestamps lagen ver genoeg uit elkaar om er "zeker" van te zijn. De ontwerper had er alleen geen rekening mee gehouden dat de karakteristieken in een productieomgeving heel anders kunnen zijn in de vorm van aantallen threads, grootte van resourcepools en toegewezen cpu-tijd.
Het gevolg laat zich raden. De eerst volgende verbetering was om de combinatie key+timestamp dan maar "uniek" te verklaren. Een gok die tot de introductie van de "unique identifier" heeft gefungeerd.
Ik zie geen fix daar. Wel hints dat het probleem wel in de applicatie zal zitten en een algemene observatie die zou wijzen op (alweer) een architectuurfout
Ja ik zie alleen een hint dat het een applicatiefout betreft.
ik kan mij herinneren dat wij in het relationale databasesysteem DB2 van het grote en robuuste IBM ook tegen een dergelijke fout zijn aangelopen. Dat was voor de tijd dat DB2 zoiets als een "unique identifier" veld kreeg.
De ontwerper was er van uitgegaan dat een timestamp wel uniiek zou zijn. En hij had dat in zijn testomgeving met een bulktest ook bewezen. De timestamps lagen ver genoeg uit elkaar om er "zeker" van te zijn. De ontwerper had er alleen geen rekening mee gehouden dat de karakteristieken in een productieomgeving heel anders kunnen zijn in de vorm van aantallen threads, grootte van resourcepools en toegewezen cpu-tijd.
Het gevolg laat zich raden. De eerst volgende verbetering was om de combinatie key+timestamp dan maar "uniek" te verklaren. Een gok die tot de introductie van de "unique identifier" heeft gefungeerd.
Beetje vreemd. Een account wordt verwijderd en als gevolg daarvan ook de bijdrage van dat account.
Maar de reacties blijven in het luchtledige hangen.
Of je laat de bijdrage staan (desnoods met als account "Verwijderd")
Of je haalt ook de reacties weg.
Wel er even voor zorgen dat er geen account "Verwijderd" kan worden aangemaakt. ;-)
Maar de reacties blijven in het luchtledige hangen.
Of je laat de bijdrage staan (desnoods met als account "Verwijderd")
Of je haalt ook de reacties weg.
Wel er even voor zorgen dat er geen account "Verwijderd" kan worden aangemaakt. ;-)
Door Anoniem: Beetje vreemd. Een account wordt verwijderd en als gevolg daarvan ook de bijdrage van dat account.
Maar de reacties blijven in het luchtledige hangen.
Er bestaan meer caches dan die van Google en The internet Archive.Maar de reacties blijven in het luchtledige hangen.
OV-chipkaart lekt gegevens
09-08-2014, 10:53 door ( XXXX )
Laatst bijgewerkt: 09-08-2014, 16:51
Hallo security-forum-leden! Vandaag heb ik een verbijsterend stukje gelezen in het NRC. Een gedeelte hieruit:
De reisgegevens van mensen die een ov-chipkaart gebruiken en een account hebben op ov-chipkaart.nl zijn momenteel niet geheel veilig. Door een technisch probleem is het mogelijk dat reisgegevens, inclusief naam, adres, woonplaats en rekeningnummer soms zichtbaar zijn voor anderen en deels gewijzigd kunnen worden. Op ov-chipkaart.nl kunnen reizigers hun transactiegegevens inzien en hun saldo verhogen. Meer dan twee miljoen kaartgebruikers hebben er een account.
Het lek openbaarde zich onlangs toen een kaarthouder een nieuw account aanmaakte. Tot zijn verbazing kreeg deze persoon daarbij zicht op de reisgegevens van twee andere kaarthouders. Het ging om een anonieme kaartgebruiker en een man uit Arnhem. Van deze Arnhemmer waren ook zijn adresgegevens zichtbaar, plus e-mailadres en rekeningnummer. Bovendien konden deze gegevens nu worden gewijzigd.
Het lek openbaarde zich onlangs toen een kaarthouder een nieuw account aanmaakte. Tot zijn verbazing kreeg deze persoon daarbij zicht op de reisgegevens van twee andere kaarthouders. Het ging om een anonieme kaartgebruiker en een man uit Arnhem. Van deze Arnhemmer waren ook zijn adresgegevens zichtbaar, plus e-mailadres en rekeningnummer. Bovendien konden deze gegevens nu worden gewijzigd.
En leest u allen even mee: Translink wist van het lek, maar wat deed ze precies om de gebruikers te beschermen of te informeren????
Trans Link Systems, het bedrijf achter de ov-chipkaart, erkent het probleem. De kaarthouder kon volgens het bedrijf inderdaad het rekeningnummer en de adresgegevens van de andere kaarthouder inzien en wijzigen.
Zelf heb ik geen OV-chipkaart, maar 1 ding weet ik nu wel: ik ga er nooit gebruikt van maken.
Link: http://www.nrc.nl/nieuws/2014/08/09/gegevens-reizigers-chipkaart-niet-veilig/
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
IT Security Officer
Utrecht heeft jou nodig! Als Information Security Officer vertaal je beleid naar technische uitvoering. Dit is cruciaal voor het waarborgen van de informatiebeveiliging van onze inwoners. Je krijgt de kans om betrokken te zijn bij complexe projecten met de nieuwste technologieën en kunt jouw stempel drukken op innovatie. Solliciteer nu!
Digital Designer
Ben jij een Grafisch vormgever, UI-designer, Game-artist of gewoon een ‘self-proclaimed creative genius’, die op zoek is naar een leuke en uitdagende baan waarin je al je creativiteit kwijt kan?Je werkt samen met onze developers en UI/UX-designer aan onze Gamified Cybersecurity Challenges welke jij voorziet van de mooiste designs.
Cyber Security Trainer
"You know that feeling after you have been to the cinema and seen an exciting movie? It's the same after this training. I can only say that this is probably the BEST TRAINING that I've ever done!!!”
Are you ready for a challenge?
Senior Full Stack Developer
Als full stack developer bij Certified Secure maak je de mooiste cybersecurity challenges die onze deelnemers wereldwijd uitdagen en inspireren. Alle challenges zijn gebaseerd op actuele kwetsbaarheden, je komt dus telkens nieuwe technieken tegen, van machine learning tot web assembly, van Swift UI tot GCP.