Datalek in app gaf toegang tot plaintext-wachtwoorden Apple ID kinderen

Een datalek van een app om kinderen te monitoren bleek plaintext-wachtwoorden van ouders en kinderen op te slaan op onbeveiligde servers. De onbeveiligde servers zijn inmiddels offline gehaald. Het is onbekend of kwaadwillenden misbruik hebben gemaakt van het lek.

Er stonden persoonsgegevens van tienduizend gebruikers op de servers, maar het is onbekend hoeveel duplicaten daar tussen zaten, meldt ZDNet. De plaintext-wachtwoorden gaven rechtstreeks toegang tot het Apple ID van de kinderen, want de app vereist het uitschakelen van tweetrapsauthenticatie. Daardoor konden kwaadwillenden met de gegevens inloggen. De app in kwestie is TeenSafe, dat naar eigen zeggen een miljoen gebruikers heeft en dat als bedoeling heeft om ouders inzage te geven in wat kinderen met hun iPhone doen.

ZDNet heeft contact opgenomen met diverse ouders van wie gegevens op de server stonden, die de juistheid van de gegevens en de wachtwoorden bevestigden. Een andere server bleek alleen testdata te bevatten. ZDNet kreeg de tip van een Britse beveiligingsonderzoeker.

Het opslaan van de wachtwoorden in plaintext staat haaks op de claim van Teensafe op de eigen site, waarop het bedrijf stelt encryptie te gebruiken om data op te slaan. De servers zijn offline. Het bedrijf zegt in een reactie meer informatie te openbaren als die beschikbaar komt.

Reacties (171)

"Het opslaan van de wachtwoorden in plaintext staat haaks op de claim van Teensafe op de eigen site, waarop het bedrijf stelt encryptie te gebruiken om data op te slaan." en hiervoor is de AVG/GDPR dus bedacht; dit soort bedrijven moeten (en mogen van mij) keihard worden aangepakt. Privacy en security moet echt veel serieuzer worden genomen.

Behaal je dat met AVG? Is een document met richtlijnen en een overheid die boetes uitdeelt zodra je iets over het hoofd hebt gezien. Súper leuk, ieder individueel bedrijf aansprakelijk stellen voor het omgaan met de gegevens van ieder individueel persoon.

Privacy en het beschermen daarvan moet daarom worden gelegd bij ieder individueel persoon. Je bent zelf verantwoordelijk voor het beschikbaar stellen van een omgeving welke een public key kan uitgeven. Die public key deel je met een entiteit zodat deze toegang kan krijgen tot delen van jouw data. Toegang wordt gelogged op het systeem zelf, dus je ziet letterlijk alles wat er gebeurt met je data. Ben je klaar met een entiteit? Gooi je de token weg.

[Reactie gewijzigd door jimmy_dg op 21 mei 2018 11:51]

Een document met richtlijnen? Het is een wet!

Technisch gezien is de AVG een Europese verordening, geen wet (er is wel een uitvoeringswet over ook). De GDPR gelezen hebbende snap ik niet zo goed wat het bezwaar is het een document met richtlijnen te noemen. Er staan een heleboel dingen in die in feite gewoon richtlijnen zijn. Er zit natuurlijk een bindende kant aan, maar juridisch gezien is dat niet ongewoon voor richtlijnen.

Door de EU overeenkomsten is de GDPR een wet. Ga je naar de rechter voor een probleem dan zal een AVG uitvoeringswet in NL opzij gezet worden als die strijdig is met de GDPR. Er staan weinig richtlijnen in net zoals in wetboek van strafrecht weinig richtlijnen staan. Er staat wat het doel is en wat de kaders zijn zoals bij elke wet is het niet specifiek.

GDPR is een Europese verordening die door NL middels AVG in een wet is omgezet. EU wetten bestaan niet; ieder land moet afzonderlijk de verordeningen en richtlijnen in wetten omzetten. Ook zaken die in strijd zijn met iets wat uit de EU komt worden niet per definitie overruled door een rechter. Genoeg voorbeelden waarbij de EU richtlijnen beter zijn voor burgers dan onze eigen implementatie.

EU wetten bestaan, een directive/richtlijn moet worden geintrepeteerd in een nationale wet, de data protection directive was dat, met grote nationale verschillen tot gevolg.

De GDPR/AVG is een regulation/verordening die letterlijk moet worden geimplementeerd. Bij verschillen is de regulation leidend. Ik vind de nederlandse termen misleidend.

https://en.m.wikipedia.org/wiki/Regulation_(European_Union)
A regulation is a legal act of the European Union[1] that becomes immediately enforceable as law in all member states simultaneously.[2][3] Regulations can be distinguished from directives which, at least in principle, need to be transposed into national law.

[Reactie gewijzigd door slaapkopje op 22 mei 2018 07:01]

Er staan ook dikke boetes tegenover niet naleven. Dat krijg je met een richtlijntje niet voor elkaar.

https://nl.wikipedia.org/wiki/Europese_verordening
https://europa.eu/european-union/eu-law/legal-acts_nl

[Reactie gewijzigd door karma4 op 21 mei 2018 17:14]

De AVG wordt in ieder land als nationale wetgeving geïmplementeerd, er staan harde eisen in en als je er niet aan houdt krijg je een boete. Ik vind dat wel wat meer dan richtlijnen.

Toegang wordt gelogged op het systeem zelf, dus je ziet letterlijk alles wat er gebeurt met je data.

Als ze die data per direct downloaden en op hun eigen systeem opslaan niet, en je hebt geen enkele garantie dat dat niet gebeurt. En áls je al verbied dat klantendata niet bij bedrijven zelf opgeslagen mag worden (wat, met de huidige stand van de maatschappij, een extreme maatregel zou zijn), hoe ga je dat handhaven? Met een wet, zoals de AVG.

Het is heel leuk om te filosoferen hoe het internet ontworpen zou moeten worden als we helemaal vanaf nul zouden beginnen, maar de wetgevende macht moet zich vooral bezig houden met de realiteit, en dat is toch heel wat anders.

Naast dat het ook niet gewenst is om niet data op je 'eigen server' hebt als bedrijf met klanten, wat moet je dan doen als een klant niet betaalt, je weet dan niets meer over deze klant als die het token weg zou gooien en jij dus een referentie naar iets hebt in je systeem waar je de rest van de data niet meer van hebt (zoals naw). Je kunt 'privacy' ook te ver doordraven..

Identificeerbare data voor business doeleinden, zoals bijvoorbeeld het zijn van een klant X bij bedrijf Y, zorgt ervoor dat je data (als klant X) voor maximaal 7 jaar bewaard dient te worden (door bedrijf Y). Betreft dan informatie die nodig is voor bedrijfsvoering, zoals wie was de klant, afgenomen dienst/product, prijskaartje, btw, etc.

Data van klant X die niet bewaard hoeft te blijven voor de bedrijfsvoering/belastingwet zijn dingen als: is het man/vrouw? bier gezopen afgelopen weekend? vriendjes met de koning?

Vereist wat meer diepgang, en verdiepen in, dan simpelweg roepen dat privacy doorgedraafd wordt...

[Reactie gewijzigd door rkeet op 22 mei 2018 15:58]

uhm, man/vrouw kan wel degelijk van belang zijn voor de bedrijfsvoering...

Een theoretisch prima idee, maar verwacht je van Jan met De Pet dat hij hiertoe in staat is... of gaan we dat doen via een cloudservice ?

Lekker alles centraal... als het dan fout gaat gaat het meteen goed fout

Mensen letten nu al niet op met hoe se met hun gegevens omgaan. Vaak ontwetendheid, vaak ook omdat men denkt niets te verbergen te hebben.

Mensen weten niet wat er met hun gegevens gebeurd. Dat veranderd niet als iedereen dat zelf beheerd. Als een bedrijf zegt: ik heb het nodig, dan zullen veel mensen denken: ok hier heb je het. Zonder echt te weten of het zo is. En veel mensen zijn ook niet in staat om het te overzien. Anders zouden mensen nu al veel zorgvuldiger omgaan met allerlei toestemmingen geven aan apps. Ik hen Android altijd vermeden omdat apps bij data/hardware willen wat ze niet aangaat. En dan kun je het niet installeren. Gelukkig veranderd dat.

Maar mensen zijn “noodgedwongen” (anders kon je geen app installeren) laks geworden en dat zie ik niet meer anders worden.

Privacy en het beschermen daarvan moet daarom worden gelegd bij ieder individueel persoon. Je bent zelf verantwoordelijk voor het beschikbaar stellen van een omgeving welke een public key kan uitgeven.

Zeg je nu echt serieus dat je wilt dat iedere persoon een eigen omgeving opzet om (persoons)gegevens te kunnen delen? De overgrote meerderheid van de mensen zou geen idee hebben van hoe ze dat moeten doen. Je kunt dat ook niet van mensen verwachten. Dat komt op hetzelfde neer als dat je van mensen verlangt dat ze wanneer ze ziek zijn dat ze zelf uitzoeken wat er mis is en zich op basis daarvan zelf behandelen.

Komop zeg, jij verwacht dat jan en alleman dat volhoudt?
Nee hoor, als je als bedrijf data wilt verwerken ben je als bedrijf verantwoordelijk voor een goede opslag.
Zo niet dan sluit je lekker de boel en begin je een simpele friet toko, nul gegevens en nul verantwoording.

Aangenomen dat het bedrijf in hun voorwaarden duidelijk maakt dat ze de Apple credentials nodig hebben voor de technisch correcte werking van hun programma en ze het datalek volgens de juiste procedures melden, hebben ze nog niets fout gedaan volgens de AVG.

Tenzij het blijkt dat ze al een hele tijd op de hoogte waren van het datalek.

De wachtwoorden waren plain-text opgeslagen, dat alleen is niet conform de eisen in de AVG.

Maarja, wat is 'plain-text'? als ik een wachtwoord 'encrypted' op sla dan kan dat voor een hacker nog steeds net zo goed zijn als plain-text omdat die het encrypted wachtworod zo makkelijk kan decrypten.

Plain text is plain text. Als iets in klare taal is weggeschreven. Zodra er ook maar enige vorm van versleuteling is, is het geen plain text meer.

klopt, maar ik bedoel dus, waar leg je de grens bij versleutelen van de gegevens?

Volgens mij is de gangbare standaard AES256 niveau?

Ook dat bedoeld SuperDre niet denk ik zo, zelfs wanneer je de sterkst mogelijke versleuteling toepast en de sleutel ernaast legt is het niet beter dan plain text. En de sleutel heb je bij dergelijke versleuteling ernaast nodig om de wachtwoorden te kunnen vergelijken.

De enig veilige oplossing is hashing, dat zou de vereiste moeten zijn. Maar dan nog, de ene vorm van hashing is de andere niet. Een simpele md5 zonder salt staat nog steeds zeer dicht bij plain text. Dus waar zou die grens gelegd moeten worden.

100% beveiliging bestaat niet natuurlijk. Verandert niets aan de zaak dat plain-text gewoon plain-text is. Alles wat geen plain-text is valt daar dus buiten, daar wordt de grens getrokken voor wat plain-text betreft.

Je kunt er van uit gaan dat niets veilig is, maar je kunt het wel zo veilig mogelijk maken.

Maarja, dan kom ik weer, WAT is zo veilig mogelijk? want iets wat nu veilig lijkt, kan morgen compleet onveilig zijn (nu wordt er al bv gesproken over dat de sterkste encryptie dmv quamtum computers in de nabije jaren in 1 instant decrypted kan worden). Dus wanneer moet men gaan upgraden?

Hashing kan in dit geval natuurlijk niet. Het hele idee is dat die applicatie het wachtwoord gebruikt om in te kunnen loggen bij Apple diensten (om te checken wat de kinderen uitspoken neem ik aan). Het *moet* dus te decrypten zijn.

Juist, en hashing werkt natuurlijk alleen als je een vergelijking moet maken bij inloggen, maar niet als het wachtwoord moet gebruiken om ergens anders in te loggen.

Wachtwoorden moet je dan ook niet encrypted opslaan. Je moet een hash opslaan van het wachtwoord. Hashen is niet omkeerbaar met een sleutel maar encryptie wel wat helemaal niet nodig is want het vergelijken van de hashes is al genoeg.

Hashen is niet omkeerbaar indien er ook wat peper en zout zijn toegevoegd. Anders: rainbowtables!

Hashen is niet omkeerbaar. Je kan natuurlijk wel hash collisions gaan berekenen maar de originele waarde krijg je nooit terug. Hoogstens een lijst van mogelijke originele waardes.

[Reactie gewijzigd door Barsonax op 22 mei 2018 22:37]

Ik ben met je eens dat je wachtwoorden niet encrypted op moet slaan als het gaat om wachtwoorden voor je eigen login, maar hashing gaat natuurlijk niet werken als je wachtwoorden moet opslaan voor extrerne systemen, en daar ontkom je vaak gewoon niet aan als je met externe systemen te maken krijgt.

Dat is geen excuus om die wachtwoorden op te slaan of op te sturen. Dan moet je maar iets als Oauth gaan gebruiken ipv het hele wachtwoord over te sturen.

Zeker met in gedachte dat een heleboel gebruikers wachtwoorden herbruiken is zo'n token een stuk veiliger. Daarbij zou je ook nog met permissions het systeem verder kunnen dichttimmeren.

Dan moet dat externe systeem natuurlijk wel met Oauth werken........ leuk dat jij het wil, maar de realiteit is toch anders..

De realiteit is dat je niet netjes met de gegevens van je gebruikers omgaat. Klinkt misschien hard maar het is wel waar.

Security is niet iets waar men achteraf pas over moet nadenken. Nogal makkelijk achteraf zeggen 'ja maar het systeem wat wij gebruiken ondersteunt dit niet'. Daar heb je als bedrijf toch zelf voor gekozen toen je voor dat systeem koos? Speelde security tijdens die keuze geen rol?

Jij vergeet alleen wel 1 ding, leuk dat jij toevallig altijd met de nieuwste technieken mag werken, maar bij genoeg bedrijven kan dat niet, en veel projecten zijn al jaren oud, lang voordat die technieken beschikbaar waren. Ook kan het zijn dat die technieken dus niet voldoen aan de vereiste specificaties.

Zoals ik al zei, de realiteit is anders, en niet zo simpel als dat jij doet voorkomen.

Wachtwoorden moet je dan ook niet encrypted opslaan. Je moet een hash opslaan van het wachtwoord.

Daar heb je alleen in dit geval niets aan. Die app gebruikt zo te zien de wachtwoorden om in te gaten te houden wat er gebeurt, en dus om in te loggen. Dan is een hash nutteloos.

Dat kan ook prima met een token.

Het verbaast mij wel dat hier zo makkelijk over wordt gedaan. Security staat weer duidelijk op de tweede plaats.

[Reactie gewijzigd door Barsonax op 22 mei 2018 16:38]

Dat kan ook prima met een token.

Het verbaast mij wel dat hier zo makkelijk over wordt gedaan. Security staat weer duidelijk op de tweede plaats.

Ik doe nergens makkelijk over. Ze loggen in op een systeem van een derde (Apple) die heel dit gebruik niet mogelijk heeft gemaakt.

Dan moet je dat systeem niet gebruiken want dat is onverantwoord.

"Doe anders je bedrijf gewoon weg".

Ok.

Beter dat dan dat je persoonlijke gegevens van mensen niet juist beveiligd.

Vind het excuus 'jamaar die ene api die wij gebruiken ondersteunt dat niet' een beetje slapjes.

De AVG spreekt dan ook niet zozeer van plain-text maar van een voldoende beveiligingsniveau, wachtwoorden die met huidige technieken makkelijk te achterhalen zijn door een cracker voldoen vanzelfsprekend niet aan een dergelijke eis, welke eigen definitie je ook aan plain-text hangt.

ja, maar wat IS ' voldoende beveiligingsniveau', wat jij nu veilig noemt kan best in de hacking community bekent staan als onveilig..
En tja, wat voor de ene cracker dus makkelijk te kraken is hoeft niet voor een andere te zijn, dus waar leg je de grens. Zeker omdat 'huidige technieken' soms al binnen dagen verouderd zijn, en dan heb je natuurlijk ook nog dat niet iedereen dagelijks zich bezighoudt met het bijhouden van de stand van zaken. Vaak implementeer je de huidige encryptie en kijk je er verder niet meer naar totdat er iemand toevallig eens zegt dat het niet meer veilig is ( nu weet ik al wat je wil gaan zeggen hoor.....).

Er zit zeker een marge binnen zo'n definitie waar er twijfel kan zijn over wat voldoende is, wachtwoorden die niet zijn versleuteld vallen redelijkerwijs niet binnen die marge.

Overigens heeft men ook de "verplichting" tot regelmatige (uit mijn hoofd minimaal 2x per jaar) herevaluatie van dergelijke maatregelen, het is wat dat betreft je eigen verantwoordelijkheid.

Die marge is overigens lang niet zo breed als je suggereert, hackers met brede financiele steun van staatsactoren zullen misschien kennis hebben van bugs of ontwerpfouten in bepaalde tools of chipers maar geen rechter zal verwachten dat een klein bedrijf met beperkte middelen dezelfde informatie heeft.
Het doel van de AVG is dan ook in hoge mate bewustwording.

Plain text wachtwoorden zijn al ongeveer 40 jaar not done. Zo ongeveer sinds /etc/password hooguit hashes bevat.

Niet dus, die AVG gaat niks toevoegen behalve ellende voor iedereen die er mee te maken heeft. Je dekt je in via voorwaarden en een verzekering en klaar die uitkeert als er wat aan de hand is. Denk maar niet dat er minder met data gerommeld gaat worden of dat er minder leaks zijn.

[Reactie gewijzigd door Saven op 21 mei 2018 19:09]

En die verzekering accepteert elke hobby-app-database?

Snap ik het goed dat je de app het wachtwoord van je appleID moet geven?

Yep, en dat is niet handig. Aan de andere kant, er zijn ook geen api's of iets om dit soort dingen uit te lezen bij Apple, terwijl de vraag naar management/beheer van icloud/iOS devices wel relevant is. Bedenk dat Apple nog een bedrijf is dat beveiligingsvragen gebruikt, terwijl andere grote bedrijven hier allang mee gestopt zijn. Beveiligingsvragen is de meest onveilige wachtwoordresetmethode die er bestaat en die finaal misbruikt is tijdens the fappening. Apple heeft nog een hoop te verbeteren aan hun 2FA implementatie, api's, gebruik van app wachtwoorden enzovoorts. Het is echt alsof je 5 jaar terug in de tijd gaat.

Dat maakt overigens niet goed dat 'Teensafe' deze grove fout maakt. Het is echter wel zo dat Apple het een beetje in de hand werkt door de ontbrekende focus op accountbeveiliging.

Bedenk dat Apple nog een bedrijf is dat beveiligingsvragen gebruikt, terwijl andere grote bedrijven hier allang mee gestopt zijn.

Microsoft heeft in de nieuwste versie van Windows 10 (1803) ook beveiligingsvragen geïmplementeerd, voor lokale accounts nota bene.

Oh kan je dat laten zien? Screenshotje ofzo? Denk dat je in de war bent met een wachtwoord hint.

https://zdnet1.cbsistatic...estions-local-account.jpg

Het is de nieuwe standaard als je Windows 10 1803 nieuw installeert vanaf de ISO.

Dit zit er al langer is, zijn gewoon vragen en bijbehorende antwoorden om te valideren of jij wel die gebruiker bent die zijn wachtwoord vergeten is. Als je je wachtwoord niet meer weet dan word je gevraagd een eerder wachtwoord in te vullen en tenminste één extra vraag in te vullen.

Met een hele grote kanttekening dat je daarvoor dus echt fysiek toegang tot een systeem moet hebben. Dat maakt de situatie wel degelijk anders.

Apple schakelt die vragen uit als jij 2fa inschakelt en beveiligingsvragen zijn niet direct fout.
Je hoeft geen echte antwoorden te geven..stel;
'Wat is de meisjesnaam van je moeder?'
Dan is er geen regel/controle oid als ik dan bijvoorbeeld als antwoord;
'F423nfiur7hfriAA' invoer.
Men vergeet eventjes dat de doelgroep voor Apple voornamelijk de consument is, niet een bedrijf.

Apple beschermt de kinderen tegen hun ouders.

Nee, je moet de app het ID en pw geven van het kind dat je wilt “bewaken”.
Hoe wil je anders iets controleren. Je zult toch bij het AppleID account moeten kunnen komen.

Of het handig is.... mogelijk zou Apple een soort van controle functie moeten bouwen voor minder jarige gebruikers. Geen idee.

Ja, ok, maar dat verandert mijn punt niet: het lijkt me niet verstandig je Apple ID aan een andere app te geven. Als je je kinderen in de gaten wil houden kun je toch net zo goed af en toe in de telefoon kijken?

Edit: net even gekeken wat je met die app kunt Dat gaat best wel ver vind ik. Als je ze zo slecht vertrouwt kun je ze beter geen telefoon geven. Dit lijkt op die aflevering van Black Mirror...

[Reactie gewijzigd door reablom op 21 mei 2018 13:30]

En leuke feitje: 2FA moet uit staan. Hoppa, veiligheid voor je kinderen is niet belangrijk. Het zijn immers maar kinderen...

Of het handig is.... mogelijk zou Apple een soort van controle functie moeten bouwen voor minder jarige gebruikers. Geen idee.

Gewoon checken of iemand op 29 februari is geboren...

Het afgeven van een username/password is helemaal niet nodig. Juist voor dat doel is OAuth(2) ontworpen. Jij geeft een bedrijf/website/applicatie een machtiging om namens jouw iets te doen.. Bij Thunderbird/Outlook is dat het benaderen van jouw mailbox, LucidChart kan op basis van deze machiging jouw Google Drive benaderen..

TeenSafe had dus naar de Apple OAuth moeten linken. Jij logt eenmaal in met het ID van je kind en accepteert vervolgens dat TeenSafe de gegevens mag benaderen/inzien en vervolgens wordt je terug gestuurd naar de applicatie met daarbij een authrorisatie code. Met deze code kan de app vervolgens een access token opvragen waarbij je meestal ook een refresh token ontvangt. Zodra de access token niet meer geldig is, kun je met de refresh token een nieuwe access token opvragen. Als ook de refresh token verlopen is, dan is weer een handmatige machtiging nodig.. Echter met OAuth2 heeft een applicatie/website nooit de originele login credentials nodig en OAuth was ook erg belangrijk om 2FA te introduceren..

Overigens gaat de AVG dit soort issues helaas niet voorkomen. TeenSafe gaf namelijk aan dat wachtwoorden encrypted/hashed werden opgeslagen. Als eind gebruiker heb je helaas geen mogelijkheid om te controleren of een website ook alles uitvoert zoals het dit beschreven heeft..

Aan de screenshot te zien, is dit weer een geval van plaintext wachtwoorden in de logs, net zoals laatst bij Twitter en Github het geval was.

Je kunt de wachtwoorden wel netjes gehasht/gecrypt in de database opslaan maar als je een logger hebt die domweg alle API requests logt, dan heb je alsnog plaintext wachtwoorden op je server staan. Dat die server onbeveiligd is, is natuurlijk extra dom.

Hashen gaat hier niet op, ze hebben je Apple ID ww nodig om in te kunnen loggen bij Apple in jouw naam. Dat is natuurlijk sowieso al een disaster waiting to happen

[Reactie gewijzigd door .oisyn op 21 mei 2018 15:57]

Apple ID’s zijn mail adressen. Die vind je overal. Maar als hierbij ook nog eens de wachtwoorden staan in dezelfde database.....

Sowieso zou ik een wachtwoord nooit doorgeven aan een 3e partij. Dat is inderdaad wachten op problemen.

maarja, hoe moet zo'n app dan automatisch inloggen?

oAuth of openID connect bijvoorbeeld.

Zo’n app zou niemand moeten gebruiken.

Een derde partij complete controle geven over je account (of die van je kinderen)? Dat zou toch niemand moeten willen.

Helemaal eens. Niet te geloven, er zijn 1 mln. mensen die zijn wachtwoorden zomaar doorgegeven naar een derde partij.

Heel veel meer dat 1 miljoen. Denk bv aan password apps zoals LastPass.

Dat is niet vergelijkbaar. Bij LastPass wordt de wachtwoordendatabase op de client (je pc, smartphone, etc.) versleuteld en ontsleuteld. De server slaat alleen de versleutelde vault op.

Ik weet niet hoe andere wachtwoordmanagers dat doen.

Klein maar belangrijk detail. Wachtwoorden encrypt je niet in je database maar je hashed ze. Encryptie is omkeerbaar met de juiste sleutel dus als ze die sleutel te pakken hebben heb je er helemaal niks aan.

Da's alleen als je wil kunnen inloggen. Als je het wachtwoord nodig hebt om in te loggen op een ander systeem, dan zul je toch echt het wachtwoord moeten kunnen bereiken.

Je gaat de wachtwoorden dus ook nog eens naar een ander systeem sturen? Hoe lek wil je het maken?

Vergiet, mandje, zeef, traanplaat... Zomaar wat in me opkomt.

Ik verklaar alleen wat ze doen. Ze hebben je wachtwoord nodig om zelf bij Apple als jou in te kunnen loggen. Hoe wenselijk dat is, laat ik helemaal aan de lezer over.

Als iemand die aan de deur komt met een speciale service: "Geef ons je huissleutel en wij waken over je kinderen." Nou da's superhandig toch?

Hier kan toch een bedrijf gewoon niet mee weg komen? Dit moet toch gewoon worden aangemerkt als onbehoorlijk bestuur?

Vraag ik me af. Kan je redelijkerwijs verwachten van het bestuur dat ze van zo'n lek op de hoogte hadden moeten zijn? Had het getest moeten worden? Was het een fout van iemand of was de programmatuur niet goed?

Ja, (je kan redelijkerwijs verwachten dat het bestuur van zo'n lek op de hoogte had moeten zijn).

'Foutje van een medewerker' is geen excuus want je mag verwachten dat een grote uitgeverij regelmatig iets aan controle doet op dit gebied.

Als een developer om debugredenen zo'n tooltje op een omgeving gooit en er via een andere weg een manier blijkt te zijn om ook bij die omgeving te komen (wellicht het grootste probleem hier), kan dit door een samenloop van omstandigheden komen die men bij controles mist.

Niet mooi, maar nee, je kunt niet redelijkerwijs zomaar verwachten dat een bestuur van zoiets op de hoogte is. Hangt verder ook nogal af van de omvang van het bedrijf.

Volgens mij moeten we het omdraaien: laat bedrijven bij het uitbrengen van software maar middels een rapportage/keurmerk oid. bewijzen dat de software veilig is. Je mag geen auto/vliegtuig/medisch apparaat bouwen zonder tot je snorharen in de certificeringen te zitten en als het misgaat krijg je dikke claims. Voor software mag iedere handige marketing bobbo een idee om laten zetten in een brak stukje software en dat met veel geschreeuw laten verkopen.
Dus draai het om: als je software niet volgens (nog nader te definieren richtlijnen) is opgezet mag het niet in de appstore. Scheelt ook de 5000 zaklamp applicaties.

Ja leuk, nog meer wetten, regels en extra kosten die enkel de grote jongens kunnen betalen. Daar zit elke zelfstandige softwareontwikkelaar ongetwijfeld op te wachten.

Nee. Maar als klant ben ik het inmiddels wel beu met de houding van software bedrijven (eula's, binding arbitration) in relatie tot de kwaliteit van het geleverde product. En ja, ik verdien zelf mijn brood hiermee. Het is tot daaraantoe dat programma's voor 10 man wocky zijn, maar als je app 10k+ keer gedownload is dan mag je wel iets meer eisen dan broddelwerk.

Dus draai het om: als je software niet volgens (nog nader te definieren richtlijnen) is opgezet mag het niet in de appstore. Scheelt ook de 5000 zaklamp applicaties.

Ik vrees dat het andersom gaat zijn; juist van die zaklamp apps (en in het algemeen, apps die ontzettend weinig doen) is het lekker makkelijk om aan te tonen dat het veilig is. Bij apps die wel daadwerkelijk een heleboel nuttige functionaliteit hebben wordt het meteen ontzettend veel lastiger om aan te tonen dat het aan bepaalde eisen voldoet.

laat bedrijven bij het uitbrengen van software maar middels een rapportage/keurmerk oid. bewijzen dat de software veilig is

Ter illustratie: bewijzen dat software vrij is van bugs is strikt genomen mogelijk, maar het is zo ontzettend veel werk dat het in de praktijk extreem zeldzaam is; ik ben in elk geval niet op de hoogte van een commercieel stuk software waarvoor dat gedaan wordt. En dan hebben we het nog niet eens gehad over de vraag wat "deze software heeft geen bugs" eigenlijk betekent. Een aantal dingen zijn duidelijk: geen oneindige loops, als je op een knop klikt moet de gevraagde actie uitgevoerd worden, als een antwoord wordt gegeven dan moet dat antwoord kloppen, ... Maar dat zijn lang niet de enige eisen. Hoe ga je bewijzen dat software vrij is van bugs als je niet exact weet welke bugs allemaal mogelijk zijn? Je kunt niet bewijzen dat een bug niet bestaat als je niet aan die bug gedacht had. Als ik Wikipedia mag geloven werd in 1998 voor het eerst over SQL-injectie gepraat. Dus je kunt in 1997 bewijzen dat je code geen bugs heeft (alle bekende bugs zitten er niet in), en dan in 1998 opeens toch kwetsbaar zijn voor SQL-injectie, want ja, van die bug had je de afwezigheid niet bewezen.

Aantonen dat beveiliging waterdicht is, is theoretisch zelfs onmogelijk. Als je vraagt om een wachtwoord dan vraag je uiteindelijk om een aantal bits, die allemaal overeen moeten komen met het "goede antwoord". Het is extreem onwaarschijnlijk, maar het is in theorie mogelijk dat je (puur vanwege geluk) meteen de eerste keer de goede bitjes ingeeft. In de praktijk zal het niet gebeuren, maar het betekent wel dat je niet kunt bewijzen dat een systeem veilig is.

Als je van de makers van apps gaat eisen dat ze aantonen dat hun code veilig is (iets wat zelfs gigantisch bedrijven als Microsoft en Google, met heel veel geld en getalenteerde software-ontwerpers, niet voor elkaar krijgen), dan kun je net zo goed je app store sluiten; ik zou verbaasd zijn als er één app is die het voor elkaar krijgt.

Ik ben bekend met formele software verificatie en de complexiteit hiervan. Ik wilde vooral het punt maken dat iedereen en zijn moeder software kan maken en publiceren zonder enige controle. In de echte wereld kan ik nog geen loempia bakken of een pak A4 papier in het schap te koop aanbieden zonder een hele sliert aan regels te moeten volgen. Waarom is het wel mogelijk om dit soort apps met de kunde van een kleuter in de App store van Apple te krijgen zonder repercussies?

In de echte wereld kan ik nog geen loempia bakken of een pak A4 papier in het schap te koop aanbieden zonder een hele sliert aan regels te moeten volgen. Waarom is het wel mogelijk om dit soort apps met de kunde van een kleuter in de App store van Apple te krijgen zonder repercussies?

Combinatie van twee redenen waarschijnlijk:

We hebben al duizenden (??) jaren winkels en loempia's; daarvan weten we inmiddels wel zo'n beetje hoe dat werkt. Software doen we pas een paar decennia; niet heel raar dat we nog aan het leren zijn hoe we daar precies mee om moeten gaan.

Er zullen vast niet heel veel politici volleerde loempia-bakkers zijn, maar de meesten zullen zich prima iets voor kunnen stellen bij eisen als "de keuken moet elke dag schoongemaakt worden" of "de koeling moet een temperatuur hebben van hooguit 4 C" (om maar even wat voorbeelden te noemen). Aan de andere kant denk ik dat je best wel een stel politici kunt vinden die werkelijk geen idee hebben waar je het over hebt als je begint te gooien met bit-lengtes van salts, minimum aantal iteraties van een hash-functie, dat soort dingen. En dan heb ik het alleen nog maar over hoe je met wachtwoorden om moet gaan. Als je ergens echt nul verstand van hebt, dan is het erg lastig om er goede regels voor op te stellen.

Zover ik weet worden politici sowieso niet gehinderd door kennis maar zijn ze afhankelijk van ambtenaren voor kennis en lobbien (en dan reken ik de verkiezingen daar ook onder) voor de aandachtsgebieden waar die kennis voor ingezet moet worden.
Het begint dus bij de lobby: als we voortaan alleen nog maar op partijen stemmen die dit soort thema's wel durven te benoemen ipv. pappen en nathouden dwing je de rest (zeg maar het huidige kabinet) ook in een positie om hier iets over te gaan roepen (en daar kun je dan voor of tegen zijn). Nu is het überhaupt geen thema en krijgt het geen aandacht. Behalve wat geneuzel met Mark Zuckerberg ondervragen (over voor de bühne optreden gesproken).

Leuk al die certificeringen, voor startups is zoiets bijna niet haalbaar, kneiterduur! Plus een certificaat is zeker geen garantie!

En een slager, bakker, drogist, groenteboer, restaurant. Zijn die ook geen startup geweest?

En wanneer je ziet hoeveel keurmerken, certificeringen, controles, et cetera krijgen voordat de deur open mag...

[Reactie gewijzigd door Wim-Bart op 22 mei 2018 04:08]

En aan wie ga je evenentueel die boete uitdelen? Aan het bedrijf dat brakke software heeft gemaakt of de autoriteit die bij het controleren dingen misschien over het hoofd heeft gezien.

Ook wil een certificeren niks zeggen. Bijvoorbeeld wanneer een bedrijf ISO 27001 gecertificeerd, wil niet zeggen dat ze de informatiebeveiliging op orde hebben. Dit wil zeggen dat een bedrijf er (op papier) mee bezig is

Als een developer om debugredenen zo'n tooltje op een omgeving gooit

Als een developer dat zou kunnen, dwz zo'n tooltje aan kan koppelen op een live omgeving die in contact komt met productie-data, dan betekent het dat het bedrijf in kwestie haar interne processen niet op orde heeft. Developers horen daar niet zomaar op eigen initiatief bij te kunnen.

(Een sterk onderdeel van de GDPR is trouwens dat je moet vastleggen wie er allemaal voor welke periodes toegang tot verzamelingen persoonsgegevens gehad hebben. Dat gaat het probleem waar bedrijven er nonchalant mee omspringen, hopelijk stevig aanpakken.)

[Reactie gewijzigd door R4gnax op 21 mei 2018 12:44]

Ik denk dat zulke dingen in bijna iedere omgeving wel kunnen als iemand de interne processen/protocollen negeert omdat er bijv. met grote spoed iets gedebugt moet worden en/of iemand ziet iets over het hoofd, je hebt met een recalcitrant iemand te maken die normaal niet zo over de schreef gaat maar nu wel, etc.

Maar je debugt toch zeker niet met productie data, al helemaal niet zo dicht bij 25 mei? En al helemaal niet als je service het leeg trekken van kinderen hun telefoon gedrag is? Daar zou toch een alarmpje af moeten gaan in tenminste 1 persoon's grijze massa.

Daar zou toch een alarmpje af moeten gaan in tenminste 1 persoon's grijze massa.

Gebeurt meestal ook wel, maar helaas moet een argument in die richting het maar al te vaak afleggen tegen "zo kan het goedkoper/sneller." Beveiliging - ook in het bedrijfsproces - blijft voor velen een kostenpost.

Natuurlijk kan er van alles mis gaan en dat blijkt ook om de haverklap op t.net

De kneep zit hem in hadden ze het moeten weten.

Het is ook niet zomaar een boekhandeltje of zo, het is een van de grotere uitgeverijen van de VS. edit: niet goed gelezen: Het is geen uitgeverij maar evengoed geen klein bedrijfje: Ze beweren zelf een miljoen ouders als klant te hebben.

Als zo'n bedrijf al niet aansprakelijk te houden is (want dat is toch de achterliggende gedachte), wie dan wél?

Apple ID's geven in potentie toegang tot iemands complete digitale hebben en houden, dan kun je niet met een foutje-bedankt onder zoiets uitkomen.

[Reactie gewijzigd door laptopleon op 21 mei 2018 22:03]

Aansprakelijkheid van het bedrijf is heel wat anders dan aansprakelijkheid van het bestuur!

Het bestuur is altijd eindverantwoordelijk van het bedrijf. Je kunt het bedrijf aanspreken op faals.
Is het direct verwijtbaar aan de personen in het bestuur dan kan dat doorlopen naar hoofdelijke aansprakelijkheid. Misschien is het niet exact gelijk maar het komt heel dicht bij elkaar.

Als bestuur kun je maatregelen nemen waardoor de kans op fouten als dit minimaal zijn: correcte code reviews binnen de teams, audits door extern bedrijf, het creeeren van een cultuur waarin security op #1 staat. Als je dat allemaal niets aan doet als bestuurder, dan hangt de veiligheid van een product met name van “toeval” af.

Hoe vaak lees je wel niet dat er security breaches zijn. Dan heb ik het niet alleen over dit soort ongein dat ze plaintext opslaan, maar ook over cryptoware etc. Dit zijn toch allemaal signalen dat je iets aan je security moet doen. Als je dan al geen eens de eerste stap hebt gezet door wachtwoorden ge-encrypt op te slaan dan vind ik dat laakbaar.

Ik ben wel met je eens of het management dit moet weten. Indien zij procedures hebben opgesteld waaruit blijkt dat ze wel wilde dat er encryptie kwam, dan is het een andere zaak. Dit pleit ze als nog niet vrij aangezien je als nog een keer paar periode kan testen of er wel echt de juiste beveiliging aanwezig is.

Ik heb gevoel dat programmeur of bedrijf veel steken laat vallen. Iedereen weet tegenwoordig dat persoonlijke gegevens en wachtwoorden niet onversleuteld opgeslagen kan worden.

Hoe kan dit tool toch zoveel security fouten tonen... dat is letterlijk budget of amateur werk.
En hoe het komt dat op website Teensafe zegt dat alles veilig is: de bedrijf of website builder is niet op de hoogte van zaken rond de tool (dus wat heeft programmeur gedaan) of bewust gekozen om fouten te maskeren (dus zaak goedpraten). Ouders hebben toch geen verstand van, denken ze.

Het is echt fout dat website anders zegt dan wat de tool werkelijk doet. Je kan bijna spreken van een scam.

Over scam gesproken: er zijn nog tientallen sites met vreemde tools (vooral driver en hulpmiddel sites) die ik niet kan vertrouwen. Ze komen nog steeds voor en ik vind jammer dat zulke sites niet meteen gesloten worden.

[Reactie gewijzigd door MrDummy op 21 mei 2018 17:07]

Mijn ervaring is dat beveiliging van kleinere databases neerkomt op wensdenken, want dat is het goedkoopst.

Naar buiten toe roept men 'we nemen de nodige maatregelen', terwijl intern de aanname bestaat dat men toch nooit een (interessant genoeg) doelwit zal zijn. Zeggen dat dit niet kan is professionele zelfmoord, want reken er maar op dat je daarna geen beslissingsbevoegdheid (of opdrachten) meer krijgt.

[Reactie gewijzigd door Cio op 21 mei 2018 21:18]

De developers denken er wel aan en zullen het vaak ook aangeven. Of de rest van de organisatie dat ook zo ziet is vaak wel de vraag....

Lijkt mij geen fouten, maar intentie- om al die data te verzamelen. Ik zou niet verbaasd zijn als alle fotos en texts opgeslagen - unencrypted - op die servers. Natuurlijk "allen jou heeft toegang". Geloof ons!
Als een tiener een pagina maakt die lijkt op apple login en op die manier het wachtwoord van een iemand ophaalt - dan is hij meteen een hacker.
Als een "bedrijf" hetzelfde doet met een miljoen mensen - het is maar een "programeer fout". Naive.

Ik vind het even onduidelijk. Is er nou ingebroken op de servers, of was de data 'exposed' naar buiten via een slechte API of iets dergelijks? Uit de screenshot lijkt het dat de logging (Celery is volgens mij iets met logging) en dan zou de claim dat de informatie encrypted opgeslagen is natuurlijk nog kunnen kloppen. Dat je het vervolgens omzeep helpt door het de unencrypten en weg te schrijven in een log.... tja ;-)

Celery is een asynchroon task processing framework voor voornamelijk Python applicaties. De screenshot is van Celery Flower, een monitoring/debug tool die je optioneel kan draaien om je taken en queues in de gaten te houden. Je ziet de bv wat de status is van de taken in de queue en welke inhoud het taakbericht heeft (de login gegevens in dit geval). Celery Flower draait standaard zonder login op een http poort. Je moet het zelf van authenticatie voorzien (bv via een webserver/proxy, wat geen ongebruikelijk patroon is), zeker als je het (wat waarschijnlijk hier het geval is) naar het internet openstelt. Er is trouwens geen reden voor om dat te doen.

Elke monitoring/debug tool zou de mogelijkheid moeten hebben om bepaalde calls (of onderdelen daarvan) uit te sluiten van logging. Dit voorkomt dat bij correcte configuratie functionaliteiten zoals "wachtwoord vergeten" gevoelige data lekken. Zelfs al is de logging alleen toegankelijk voor geautoriseerde gebruikers, zoals dat bij Twitter en Github het geval was.

Beter nog: maak de wachtwoord string in je code een eigen type en zorg dat deze nooit in plaintext (toString() oid) eruit kan komen. Dus override al deze methodes. Nu is het logging, volgende keer is het een ander aspect van je applicatie dat de data lekt. In mijn ervaring zijn dit soort "bugs" een gevolg van niet nadenken bij het bouwen en dan achteraf de gaten dicht gaan stoppen.

Het zou inderdaad een goeie oplossing zijn, maar is dat ook mogelijk bij in de gehackte applicatie?

Beter nog: maak de wachtwoord string in je code een eigen type en zorg dat deze nooit in plaintext (toString() oid) eruit kan komen. Dus override al deze methodes.

Prima idee... als je in een strongly typed taal werkt. Als je je code in bijvoorbeeld PHP schrijft (en nee, iPhone apps schrijf je niet in PHP, maar ik bedoel het in het algemeen), dan werkt dat niet. Daarnaast kun je, zelfs met die aanpak, niet alles voorkomen. Bijvoorbeeld in het geval van "Je code is gecrashed, hier is een dump van de stack toen het fout ging", krijg je waarschijnlijk alsnog een password te zien als het meegegeven is als functie-parameter.

Zowiezo werk je in een strongly typed taal. De rest is speelgoed Maar ook in PHP/JS lukt het wel op die wijze met een beetje nadenken. En stacktraces zoals ik ze ken bevatten alleen het code pad en niet de parameters. Web applicaties die een complete core-dump leveren ben ik ook nog niet tegengekomen.

Het gaat hier veelal om logging van inkomende requests. Deze hebben sowieso geen type.

Het zou dan de taak moeten zijn van de webserver om naar de applicatie niet een bag van strings aan te leveren maar een getypeerde interpretatie van het HTTP request. Dit soort sanitizing gebeurt nu in de applicatie en gaat daar ook nogal eens mis.

Of nog beter gebruik hashes van wachtwoorden en vergelijk die. Ook al lekt de hash dan kunnen ze er (mits juist gehashed) nog steeds niks mee.

Als gebruikt tik je geen hash in dus daar loopt het dan nog mis. Dat je in de DB geen cleartext ww. doet maar hashes spreekt voor zich (met salt uiteraard).

In dit geval heeft de onderliggende tool (Celery) een mogelijkheid om de wachtwoorden te masken (http://docs.celeryproject...-information-in-arguments). Maar zoals de documentatie zelf ook aangeeft, kun je beter andere oplossingen bedenken om je wachtwoorden door te geven aan een Celery taak.

Ouch, die is wel heel erg pijnlijk als je zegt encryptie te gebruiken. Ben benieuwd of er ook daadwerkelijk misbruik van is gemaakt.

Beetje dom ook van de gebruikers om mee te gaan met het verzoek om tweetrapsauthenticatie uit te schakelen.

[Reactie gewijzigd door Crp op 21 mei 2018 14:02]

Tja, niet iedere gebruiker is even handig met computers / smartphones (wellicht zelfs digibeet) en kan dus niet alle gevolgen overzien. Dergelijke gebruikers dan maar over 1 kam scheren en dom noemen is wat overdreven, vind je niet?

[Reactie gewijzigd door CH4OS op 21 mei 2018 15:07]

Er zit een verschil door de actie (een beetje) dom te noemen of de gebruiker zelf. Dus een beetje overdreven reactie.

De echte fout zit bij het ontwerpen en bouwen van de app, niet bij de gebruiker, die wellicht dingen voorgeschoteld zijn die niet waar zijn.

Dan is de gebruiker hoogstens naïef, de gebruiker dom noemen is in deze ook gewoon dom, die kan de problemen sowieso niet oplossen.

[Reactie gewijzigd door CH4OS op 21 mei 2018 17:20]

Haast net zo dom als virusscanners MITM attacks op je browser te laten uitvoeren om https verkeer te kunnen lezen (en doorsturen naar weet ik waar).

Toch wel slecht gesteld met een app als die eist om 2FA uit te schakelen. Dan moeten er eigenlijk al alarmbellen rinkelen wat mij betreft.

Anders werkt het niet. Het bedrijft logt in op jou account. Dat werkt niet als je 2FA hebt.
Maar het feit dat een ander bedrijf totale controle heeft over je account, staat daar niemand bij stil.... never nooit niet zou ik een 3e partij toegang geven tot mijn account.

Schendt dit ook niet allerlei voorwaarden van Apple? Die app eist rechtstreekse en volledige toegang tot het ID.

“want de app vereist het uitschakelen van tweetrapsauthenticatie.” - gaat er dan sowieso geen lampje branden dat die app waarschijnlijk meer de veiligheid ondermijnt dan helpt?

Waarschijnlijk is dit de enige mogelijkheid, omdat Apple te weinig mogelijkheden biedt voor externe ontwikkelaars.

Je kunt tegenwoordig wel app wachtwoorden aanmaken. Wat wel zo is, is dat Apple (uiteraard) een eigenwijze implementatie gebruikt voor 2FA, waar een Google, Microsoft en Facebook je gewoon een willekeurige authenticator laten gebruiken. Ik gebruik bijvoorbeeld de Microsoft authenticator voor Google. Voor Apple is het SMS of een iOS/macos device. SMS en de macos/ios meldingen werken alléén als je bereik hebt, terwijl je bij Google/Microsoft/Facebook ook offline tokens kunt genereren. Apple loopt dus erg achter op dit vlak.

Apple heeft inderdaad ook geen mogelijkheden tot een authenticatie/SSO achtige token en dat maakt het dus heel lastig om dit soort tools voor Applespullen te ontwikkelen. Wat toevallig ook een van de redenen is dat icloud zakelijk geen voet aan de grond kan krijgen. Overigens, daar richt Apple zich ook niet op natuurlijk.

Achter lopen is wel erg kort door de bocht... hierdoor kan ik wel zien welke gek er in probeert te loggen en ook waarvandaan.

Dat kan bij Google/Microsoft/Facebook ook hè.

Als iemand probeert in te loggen krijg ik daarvan de melding + locatie in beeld en moet ik goedkeuring verlenen.

Het grote verschil is dat de Apple methode werkt voor Jan Modaal.
Hoeveel normale mensen (dus niet-Tweakers) hebben 2FA aanstaan op hun Google/Microsoft/Facebook account? Met zo’n ‘handige’ tokenapp? En hoeveel Apple gebruikers hebben de iOS/macOS 2FA variant aanstaan? Ik ben er zeker van dat dat percentage aanzienlijk hoger is...

Voor Apple is het SMS of een iOS/macos device. SMS en de macos/ios meldingen werken alléén als je bereik hebt, terwijl je bij Google/Microsoft/Facebook ook offline tokens kunt genereren.

Leuk dat je die kunt genereren, maar daarna gebruik je die code om in te loggen op ‘Google/Microsoft/Facebook’, wat ... online services zijn?

Beetje nadenken hè, het kan best dat je mobile device geen verbinding of brakke verbinding hebt, terwijl je via een bekabelde verbinding ergens wilt inloggen.

Encryptie is niet hetzelfde als one-way hashing. Het kan met encryptie worden opgeslagen in plain-text. Als je schrijf encryptie hebt aanstaan, maak je al gebruik van encryptie... maar als je dan met een software foutje je data publiceert heb je niets aan die encryptie