'Reset-functie van Android laat gebruikersdata achter'

Beveiligingsonderzoekers van de University of Cambridge hebben in een tweetal papers kwetsbaarheden blootgelegd in het systeem om Android-toestellen te ontdoen van persoonlijke gegevens, zowel door middel van een 'factory reset' als door een 'wipe' via externe programma's.

De onderzoekers van de universiteit kochten een aantal tweedehands Android-telefoons om te controleren of het terugzetten naar fabrieksinstellingen inderdaad zorgde voor een volledig schone telefoon. Dat gaat in alle gevallen niet goed, schrijven de onderzoekers op hun weblog: alle mobieltjes laten in ieder geval fragmenten van oude data achter en bij 80 procent van de telefoons was het zelfs mogelijk de master-token te achterhalen, waardoor inloggen op het Google-account van de voormalig eigenaar mogelijk wordt.

Het andere onderzoek richtte zich op software die aangeboden wordt door derden, zoals antivirusbedrijven die apps bieden om een telefoon op afstand te blokkeren of wissen. Antivirussoftware die gebruik maakt van de in Android ingebouwde wijze om de telefoon terug te zetten naar fabrieksinstellingen faalt om begrijpelijke redenen, waardoor deze software van derden geen oplossing biedt voor het probleem.

Om de kwaliteit van de factory-reset-functie te testen, keken de onderzoekers naar 21 Android telefoons van vijf verschillende fabrikanten. De telefoons draaiden op diverse Android-versies, variërend van 2.3 tot 4.3. Aan de hand van de gevonden uitkomsten, schatten de onderzoekers dat tot vijfhonderd miljoen Android-toestellen de data-partitie niet goed wissen en tot 630 miljoen apparaten de interne sd-opslag niet goed schoonmaken. Gebruikers die hun opslag beveiligden met encryptie, hebben ook geen geluk: er blijft na een factory-reset genoeg informatie achter om uiteindelijk de encryptiesleutel te achterhalen.

Het probleem bij mobiele antidiefstal-apps bestaat door een slechte wipe-implementatie en beperkingen van de Android-api, en aanpassingen die aan het besturingssysteem gedaan zijn door de bouwer van de betreffende apparaten. 'Het is spijtig, maar een mobiele antidiefstal-app biedt geen betere wipe-functie en vormt geen alternatief voor de ingebouwde factory-reset', schrijven de onderzoekers in de andere paper. Volgens hen is momenteel de enige levensvatbare optie dat de fabrikanten zelf zorgen voor goede software om de fabrieksinstellingen te herstellen.

Het probleem ligt niet volledig aan de kant van Android; ook het flashgeheugen vormt onderdeel van het probleem. De beschikbare opslagcapaciteit van het flashgeheugen is groter dan wordt aangegeven, dit in verband met foutcorrectie en de manier van dataopslag. Nieuwe emmc's ondersteunen betere data-opschoningsmethoden. Verder moeten fabrikanten volgens de onderzoekers de gehele flashcapaciteit gebruiken en volledig laten zien in de bootloader en de herstel- en Android-kernels.

Gebruikers kunnen zelf ook zorgen voor betere beveiliging van hun apparaten, namelijk door hun apparaten te beveiligen met encryptie en daarbij wel een lange pincode te kiezen met zowel letters als cijfers voor hun eigen login. Om de encryptiesleutel te achterhalen, moet namelijk nog wel het gewone wachtwoord of pincode gekraakt worden. Hoe het zit met Android-versies van 4.4 en hoger, is niet bekend, maar de onderzoekers vermoeden dat daar een vergelijkbare problematiek speelt.

Android 4.x onder 4.4 draait nog op bijna 45 procent van de Android-toestellen blijkt uit data van Google zelf van 4 mei 2015. Zes procent van de mobieltjes maakt nog contact met de Play Store met een 2.2 of 2.3.x apparaat.

Reacties (58)

[Sfynx]

Gebruikers die hun opslag beveiligden met encryptie, hebben ook geen geluk: er blijft na een factory-reset genoeg informatie achter om uiteindelijk de encryptiesleutel te achterhalen.

Huh, een encryptiesleutel belandt toch alleen in RAM na invoeren ervan en niet leesbaar op niet-versleutelde storage? Dat is gewoon amateuristisch.

[thomasie]

Enabling Full Disk Encryption (FDE) on first use of the device would be more appropriate for ordinary users if devices support it. Enabling FDE only before performing
a Factory Reset (as suggested by Google) may only provide logical sanitisation, not thorough digital sanitisation (plain-text data could still be present on the flash as it is
over-provisioned). FDE was introduced in ICS (v4.0.x) so it cannot help the large number of affected GB (v2.3.x) devices. On one HTC phone running GB (v2.3.x), we found an encryption option, but it left all the data behind. We assume this was a vendor customisation and may only encrypt allocated space. FDE for the internal SD card is not supported on all phones, and not all v4.x devices support FDE on the data partition despite AOSP’s support. As a rule of thumb, only devices with an emulated internal SD card inherit the “encryption support” from the data partition when supported. On supported Android versions, the encryption key is stored encrypted with a key derived from a salt and a user-provided PIN (or password). This encrypted blob is referred to as the “crypto footer” in the AOSP source code. An attacker who gains access to the crypto footer has enough information to brute-force the user’s PIN offline. The footer is stored in a dedicated partition or in the last 16KB of the data partition – the exact location is configured by vendors through the “encryptable=” option of the Android fstab file. In either case, we found that the footer was not erased after a flawed Factory Reset. Consequently, to logically sanitise a device with encryption, it is essential to select a strong password to thwart offline brute-force attacks. As most people just use a 4-6 digit PIN, it would usually be trivial to brute-force.

Is het relevante stuk van de tekst.
De encryptiesleutel wordt dus niet gewist en kan doormiddel van brute force gekraakt worden. Dat is wel redelijk stom dat die sleutel niet gewoon gewist wordt aangezien je dus maar 16KB volledig hoeft te verwijderen om bijna te kunnen gaan garanderen dat de data nooit terug gelezen kan worden (brute forcen van 16KB is namelijk praktisch niet te doen, met 1 miljoen gokken per seconde duurt dat bijna 5000 jaar). Maar het als die data niet verwijderd wordt dan is het al een stuk makkelijker omdat bijna iedereen een pincode/veegbeweging gebruikt waarbij je simpelweg mogelijkheden hebt.

EDIT1: Deze manier van beveiligen (dus encryptie sleutel en die encrypten met je wachtwoord) wordt trouwens bij (bijna) alle full disk encryptie gebruikt. Het is namelijk veel sneller en het wipen van een schijf is ook veel makkelijker.

EDIT2: Android encryptie is trouwens sowieso niet echt heel bruikbaar omdat het wachtwoord voor unlocken hetzelfde moet zijn als het wachtwoord voor encryptie. Als je de telefoon dus vind zonder dat hij, correct, gewist is is het bijna altijd mogelijk om hem te brute forcen dmv het geheugen uit de telefoon te halen. En Google doet er niets aan.

[Reactie gewijzigd door thomasie op 23 juli 2024 07:58]

[HMC]

Dat is allemaal nogal kort door de bocht, in mijn opinie.
Nog steeds moet je een password weten. Het brute forcen van een wachtwoord is echt niet zo makkelijk en/of snel. Zeker niet op een phone.

Storm in een glas water.

Er zijn sowieso maar weinig mensen die hun Android-based phone encrypten.
En wat te encrypten? De films die je er op hebt staan?

[thomasie]

Brute forcen hoeft helemaal niet gedaan te worden door de telefoon. Dat kan ook prima gedaan worden door een pc nadat je het geheugen of uit de telefoon hebt gehaald of een image van de gebruikers data hebt gemaakt.

De meeste mensen hebben hun e-mail ook op hun telefoon staan of bedrijfsgeheimen die de concurrent graag wil hebben.
Sowieso is een gevoel van valse veiligheid creëren gevaarlijk, dan denk je dat je alles op je telefoon kan zetten want niemand kan erbij en dan blijkt het dat iedereen die het graag wilt erbij kan.

[HMC]

Daar ben ik het uiteraard helemaal mee eens, maar dat brute forcen makkelijk is, is echt niet waar.

[thomasie]

Dat staat dus letterlijk in het onderzoek. Dat aangezien bijna iedereen veeg bewegingen of pincodes gebruikt de lengte van wachtwoorden vaak maar tussen de 4 en 6 karakters ligt en dus is het makkelijk om te brute forcen:

Consequently, to logically sanitise a device with encryption, it is essential to select a strong password to thwart offline brute-force attacks. As most people just use a 4-6 digit PIN, it would usually be trivial to brute-force.

[HMC]

Als jij een phone handmatig weet te bemachtigen van iemand en deze dan aan je PC hangt, wil dat nog niet zeggen dat je de know-how hebt om dan te gaan brute forcen op passwords of vingerbewegingen van die phone.

En als je dat dan uiteindelijk wel kan, wat mij heel moeilijk lijkt, dan zal het nog steeds heel moeilijk zijn om verwijderde data te acherhalen.

Vergeet niet dat jouw pogingen om de passwords/vingerbewegingen ook nog eens eerdere geschreven, maar "ge-wipe'te" sectors op het geheugen overschrijven, dus dat is allemaal helemaal niets meer waard.

De data is gewoon weg. Wat betrefd is dit nieuws in mijn ogen dan oog flauwe kul/

Maar uiteraard kan ik het volledig mis hebben.

[thomasie]

Volgens het onderzoek moet het redelijk makkelijk zijn. Wat je doet is het flash geheugen kopiëren naar een SSD/HDD en dan proberen met een computer/virtual machine op Amazon oid die encryptie sleutel kraken.

Ok het is geen heartbleed, maar gevaarlijk is het wel. Zeker als je echt een gemotiveerd iemand tegenover je hebt.

[Sorcerer8472]

Ze hebben het ook over offline oplossen; gewoon de data 1 op 1 van het geheugenkaartje af halen en dan zelf iets schrijven om te bruteforcen.

Nee, niet iedereen kan het, maar iemand die een beetje op niveau kan programmeren kan al een heel eind komen, plus het is in theorie volgens mij ook prima mogelijk om hier scripts voor te schrijven die het moeilijkste werk voor je doen.

Verder weet ik niet of je ervaring hebt met het terughalen van verwijderde content, maar dit is vrij makkelijk als je bijv. een gewist SD-kaartje hebt. Als er gewone deletes zijn gedaan dan kun je bijna alles terughalen vrij gemakkelijk.

[HMC]

Behalve als je dus bezig bent geweest op die schijf (of kaart) na het gewist te hebben.

Regel 1 is daarbij: NIETS doen met die schijf. Alleen uitlezen.

[Reactie gewijzigd door HMC op 23 juli 2024 07:58]

[Sorcerer8472]

Ja, dat zeg ik: een 1-op-1 kopie maken en daarmee aan de slag gaan. Of readonly mounten.

[Eagle Creek]

Behalve dat deze sleutel toch ergens opgeslagen zal moeten worden om te voorkomen dat de sleutel elke keer verloren gaat dat de telefoon zonder stroom komt te zitten.

Dat kan een implementatievorm zijn om de sleutel te beschermen maar levert wel een praktisch probleem op. Ik kan mij dus wel voorstellen dat ook deze sleutel wel ergens in NVRAM terecht komt.

[sKweezr]

Je levert eigenlijk juist een goede oplossing. Als de sleutel alleen in het RAM wordt geplaatst (dus geen kopie op het non volatile geheugen), moet je je wachtwoord opnieuw invoeren als de telefoon helemaal zonder stroom kwam te zitten. It's not a bug, it's a feature. En nu nog terecht ook.

[thomasie]

Dat gebeurt bijna nooit zo bij Full Disk Encryption. Zowel LUKS als True Crypt doen het niet zo omdat het onveiliger of langzamer is.

Je kan namelijk met een keyfile voor dat bestand een langzame encryptie gebruiken waardoor brute forcen langzamer (en dus moeilijker) is terwijl je voor je hele disk snellere encryptie gebruikt maar met een hele lange key (zoals bij android dus 16KB) waardoor ontsleutelen snel gaat maar doordat de key lang en compleet random is, is brute forcen niet makkelijk. Dit is veiliger en dan snelle encryptie met alleen je wachtwoord en sneller dan langzame encryptie om je hele schijf gebruiken.

EDIT1: Voor meer informatie kan je de wiki van Arch Linux lezen die hebben een hele duidelijke uitleg: https://wiki.archlinux.or...#How_the_encryption_works

[Reactie gewijzigd door thomasie op 23 juli 2024 07:58]

[CyberDonky]

Sorry, maar het hele onderzoek wat University of Cambridge heeft gedaan is toch volstrekt zinloos? Het was al lang al bekend dat data terug te carven is en met wat recovery tools heb je alle data terug.
Ik zie geen ander antwoord dan wat allang bekend is.

Hier wat enkele links:
http://www.techtimes.com/...-personal-data-beware.htm
http://www.thewire.com/te...ly-wipe-your-data/374192/
en nog 10000 links.

Als je echt wil dat alle data verwijderd wordt, dan moet je gaan nullen. Dat kan met de programma's:
Bekendste: Darik's Boot and Nuke - http://www.dban.org/
Puppy Linux livecd - http://www.puppyos.com/
Killdisk - http://www.killdisk.com/

[Reactie gewijzigd door CyberDonky op 23 juli 2024 07:58]

[John Doos]

Ik denk dat het niet zozeer gaat om het feit of het terug te halen is of niet, maar er blijft gewoon privé data ACHTER.
Dus nogmaals, het gaat er niet zozeer om wat er terug te halen is dmv. welke methode dan ook.

[batjes]

Paper niet gelezen? Het is niet dat ze de verwijderde data zelf weten te achterhalen.
Wat ik eruit opmaak, uit zo'n data cell op een flash geheugen, is een stuk meta-data en error/coruptie correctie. En deze data wordt juist niet gewiped en daarom is er zo veel data terug te vinden.

[freaky]

Waar past die CD / bootable USB stick? Doen ze ook ARM? Hoe omzeil ik de bootloader om dat te draaien? En wellicht belangrijker, hoe voorkom ik dat m'n telefoon bricked is daarna?

En niet te vergeten, hoe start je dat spul via de google m'n telefoon is gejat/kwijt interface, gezien je geen toegang meer hebt tot je telefoon?

[Anoniem: 58763]

Laatst bij een huawai telefoon de SD-kaart verwijderd en een factory reset gedaan. Vervolgens de telefoon aan iemand gegeven die melde vrolijk dat al mijn foto's er nog op stonden.

[blorf]

Bij een hard reset van mijn computer blijft de data op de schijf ook gewoon bestaan. Waarom zou dat bij een smartphone dan weg moeten zijn?
Volgens mij moeten mensen eens wat beter door krijgen dat smartphones hardware zijn waar de eigenaar niet de volledge controle over heeft. Dat Google en de rest dat normaal vinden wil nog niet zeggen dat het dat ook is. Er klopt iets niet aan onze nieuwe generatie computers.

[loki504]

Maar ze adverteren wel met je bent ALLES maar dan ook echt ALLES kwijt. Maar niets in minder waar. En vind ik een slechte zaak.

[Anoniem: 58763]

Het bijzondere is dat je wel via alle kanten de indruk krijgt dat alle data weg is. Dit door meldingen die je daarvoor waarschuwen en door het feit dat je wel via een op een boot menu gelijkende procedure komt.

Bij een hard reset van de laptops die ik tot nu toe heb gehad wordt de hardeschijf overigens gewoon opnieuw gepartitioneerd. Dus dan is de data voor een leek niet echt makkelijk terug te krijgen.

Ben het volledig met je eens dat deze generatie van computers soms wat te veel controle wegnemen bij de gebruiker. Ik houdt er tegenwoordig ook rekening bij de aanschaf van mijn telefoons.

[computerjunky]

factory reset laat bij sommige merken/devices als dit via het os menu gedaan word gewoon de data erop staan en wist alleen instellingen van de OS partitie.
Doe je dit echter via recovery dan is alles daadwerkelijk leeg omdat ook de data partitie gewist word.

[John Doos]

"alle mobieltjes laten in ieder geval fragmenten van oude data achter en bij 80 procent van de telefoons was het zelfs mogelijk de master-token te achterhalen, waardoor inloggen op het Google-account van de voormalig eigenaar mogelijk wordt."

Dat is echt wel een flink probleem ja.
Echter na dat ik een telefoon koop van Persoon A, die gefactory reset is, en ik als Persoon B meld mezelf aan op mijn gmail account.
Gaat dan het oude "master-token" van Persoon A verloren, en word die vervangen door de master-token van Persoon B?

Anders is het simpel op te lossen lijkt me, gewoon een dummyaccount inloggen en dan weer factory resetten?

[VNA9216]

Het gaat niet om het feit dat je telefoon daarna gewoon weer inlogt op de oude account, maar het feit dat de gegevens nog ergens in het flash geheugen zitten.

even heel simpel gezegd:
Het probleem is, dat in tegenstelling tot veel andere soorten opslag, flash geheugen een extra controller er tussen heeft zitten waardoor het OS geen directe interactie met het flash geheugen heeft. Doordat de controller vaak probeert write cycles te spreiden over het hele geheugen (in verband met slijtage) en omdat data om het echt te wissen overschreven moet worden kan je eigenlijk niet garanderen dat alle blokken van het geheugen ook daadwerkelijk overschreven zijn. Immers als jij je data in blok A heb staan, maar blok A al te veel cycles heeft gehad, dan worden de volgende schrijfoperaties die voor het OS naar dezelfde locatie gaan om het te overschrijven in werkelijkheid heel ergens anders in het flash geheugen gezet. Het gevolg is dat de data dus voor het OS gewoon weg is, maar met de juiste tools als je pech hebt gewoon weer tevoorschijn kan worden getoverd.

Dit is echt een heel erg versimpelde uitleg, en er valt echt nog veeeeeeel meer over te zeggen met veel meer detail, maar dan kan je denk ik beter even rondzoeken online.

[Sorcerer8472]

De toegang van de telefoon onttrekken op Google is dan nog makkelijker in dat geval. Dat werkt 100% zeker. Dummy-account kan ook op een andere plek op het geheugen worden opgeslagen zodat de oude gewoon nog terug te vinden is.

[ralph075]

Dit was toch al langer bekend? Ik las dit artikel en dacht gelijk "dat wisten we toch al?".

Ik dacht het eerder hier gelezen te hebben, maar daar kan ik niks van terug vinden...
Op Information Week is het wel terug te vinden. Dat is een bericht van juli 2014.

[Jelle E]

Het is nu pas een jaar later, het is goed mogelijk dat het onderzoek destijds al liep. Je gaat niet simpelweg omdat een beveiligingsbedrijf er ook al een persbericht erover gepubliceerd heeft het onderzoek staken.

[Joecatshoe]

Dat het al langer bekend was, wil nog niet zeggen dat er geen onderzoek meer naar gedaan kan worden. Een beveiligingsfirma en een artikel op een website zijn namelijk geen betrouwbare bronnen. Nu is het dus ook wetenschappelijk onderzocht, peer reviewed en gepubliceerd.

En zoals hier boven gezegd: iets onderzoeken en gepubliceerd krijgen kost tijd. Periodes van meerdere maanden tot een jaar tussen begin van het onderzoek en daadwerkelijke publicatie zijn gebruikelijk.

[Reactie gewijzigd door Joecatshoe op 23 juli 2024 07:58]

[izegrin]

Hmm, playstore bezoek lijkt me niet de perfecte maatstaf om te bepalen welk percentage welke versie van android draait.
Ik denk dat de mensen die recent een toestel gekocht hebben meer op de store komen. Wie een oudere versie draait is misschien al app-verzadigd.

[Dorank]

Je toestel bezoek automatisch de playstore met de auto-update functie (staat standaard aan). Die functie zit er al in sinds ergens in 2010. Dus als je je G1 niet geupdate hebt en niet in de market bent geweest dan valt die inderdaad onterecht buiten de category actieve devices.

[izegrin]

Mijn toestel heb ik playstore vrij gemaakt.
Ik heb er geen android inlogprofiel op draaien. Nou ben ik natuurlijk tamelijk in de minderheid....

Play store gebruik ik helemaal niet met mijn telefoon; eventueel downolad ik er via de laptop een enkele app, maar de paar apps die ik heb komen vooral van F-droid en opera app store (o gruwel, die store is vergoogeld: zelfs voor het downloaden van opera browser krijg je een redirect naar google play ??!!

Verder heb ik een enorme hekel aan automatische updates van programma's.
Bijvoorbeeld: Mijn favoriete kaartenprogramma is orux maps. Maar...wel een oude versie.

In de nieuwste versies kan je van een aantal bronnengeen off-line kaarten meer downloaden. o.a. google en microfoft hybrid maps doen het in nieuwere versies van orux niet.
(iets met copyrights of zo, en dreigen met dat je app niet op google play mag als ze geen spyware/reclame mogen inbakken...)

[Dorank]

Leuk verhaal, maar iets totaal anders dan je in je oorsponkelijk post stelde/opmerkte.

Als je geen $store hebt tel je natuurlijk ook niet mee in de cijfers van $store. Dat is volkomen logisch. En als je in de Play Store auto updates irritant vindt schakel je die gewoon uit (globaal of alleen voor bepaalde apps).

[contrast]

De beste manier om data van je internal SD te wissen is door je huidge data te overschrijven met random data. Om er helemaal zeker van te zijn dat 99% echt weg is, kun je die data weer overschrijven. Zelf meerdere keren geprobeerd en er was geen enkel bestand te recoveren.

[Sorcerer8472]

Hoe doe jij dat dan op Android? Eerst factory reset zodat je persoonlijke data weg is en daarna grote bestanden erop gooien totdat het geheugen tot de nok toe vol zit (en je persoonlijke data waarschijnlijk écht is overschreven) en dan weer de data eraf?

[contrast]

Ja, inderdaad op die manier. Werkt perfect.

[Johan9711]

Het is logischerwijs verholpen bij Android 5.0 en hoger, omdat encryptie dan standaard aan staat. Dan kan je hooguit encrypted data omhoog halen, waar je niets aan hebt.

[ronaldmathies]

Alleen zetten veel mensen dat weer uit omdat het een enorme performance hit gaf. En dan nog, volgens het nieuwsbericht geeft ook dat geen garantie. En die vind ik nog veel kwalijker, schijnbaar is die encryptie van zichzelf dus ook niet erg veilig.

[Dorank]

Als je het artikel goed gelezen (en begrepen) had dan zou je gezien hebben dat de encryptie niet het probleem is (dm-crypt met een standaard AES128/CBC/essiv-sha256 (tegenwoordig is de standaard AES256/XTS-PLAIN64/SHA1 oa vanwege ditt)) maar het key management van de decrypty sleutel. Die staat wellicht op een plek die niet gewiped wordt met een standaard factory reset (voor toestellen zonder zinnige Trust Zone of TPM implementatie van de secure key storage), iemand met interesse in die sleutel kan dan een offline bruteforce uitvoeren. Als de gebruiker een PIN gebruikte dan ben je als attacker redelijk snel klaar.

[theduke1989]

Een tweaker zou dit allemaa wel weten, een non-tweaker daarin tegen zou het niet weten of kunnen weten. Maar zodra ik een smartphone verkoop kijk ik altijd eerst na of mijn complete internal (whatsapp/ facebook en noem zo maar op) allemaal verwijderd zijn. Zo niet verwijder ik deze handmatig.

Maat dit is inderdaad een big isseu. TWRP tools wissen meer dan een normaal wipe, maar nog niet voldoende in mijn optiek.

[Dorank]

Maat dit is inderdaad een big isseu. TWRP tools wissen meer dan een normaal wipe, maar nog niet voldoende in mijn optiek.

Wat zijn de TWRP tools? Als je namelijk vanuit TWRP een wipe doorvoerd is dat niets meer dan een mkfs. Je data blijft dan gewoon achter.

Als je al FDE gebruikte dan is de oplossing om FDE te her initialiseren (FDE disabelen en weer enabelen (in de hoop dat de implementatie daadwerkelijk de key aanpast)).

[telenut]

De vraag is ook: hoeveel moeite moet je er voor doen?
Data op een vastgelopen HD is ook te recoveren. Maar daarvoor moeten ze echt niet bij mij komen. Ik ga die dingen niet openschroeven om de platters er uit te halen etc.
Ik heb me hier al eens bezig gehouden met het terughalen van data op een android na een reset. En echt veel nuttige zaken kon ik toch niet terug halen. Geen enkele foto was nog deftig te bekijken.

[Dorank]

De vraag is ook: hoeveel moeite moet je er voor doen?
Data op een vastgelopen HD is ook te recoveren. Maar daarvoor moeten ze echt niet bij mij komen. Ik ga die dingen niet openschroeven om de platters er uit te halen etc.

Maar die ga je ook niet doorverkopen. Het is wel verstandig om de hd mechanisch te bewerken voordat je ze in de kliko gooit (ik sla er altijd een paar spijkers doorheen). Als je dan nog bang bent dat iemand de data uitleest (nog altijd mogelijk immers) dan heb je de opties:
-niet weggooien
-naar een gespecialiseerd bedrijf