Google: beveiliging Android-apps is niet op beveiliging gericht

Android Licensing Server, de 'beveiliging' die Google aanbiedt voor makers van betaalde Android-apps, is nog niet op beveiliging gericht. Dat zegt Google in een reactie op het nieuws dat de beveiliging gemakkelijk te omzeilen zou zijn.

De code was erop gericht om het ontwikkelaars gemakkelijk te maken de code in hun applicatie te stoppen, zo zegt de maker van Android. "De eerste release is uitgebracht met de simpelste, zo transparant mogelijke implementatie van een sample, die was geschreven zodat hij gemakkelijk is te begrijpen en aan te passen. De code is niet gericht op beveiliging."

Dat het bovendien zo eenvoudig is, ligt volgens Google ook aan de ontwikkelaars die het licentiesysteem in hun applicatie gebruiken. "Sommige ontwikkelaars gebruiken de sample 'as is' en dat maakt het gemakkelijker om aan te vallen." Google raadt ontwikkelaars aan om de code te 'verduisteren', een techniek die het kraken van de applicatie een stuk lastiger zou maken.

Dinsdag werd duidelijk dat de Android Licensing Service gemakkelijk te omzeilen is door de apk uit te pakken en de code aan te passen. De kwetsbaarheid van het licentiesysteem zit in het bestand LicenseValidator.smali, waarmee wordt gecontroleerd of de gebruiker de applicatie heeft gekocht. De controle vindt plaats bij het starten van de applicatie en dat gebeurt op het toestel zelf.

De truc is dat de code wijst naar een volgende actie als de licentie wel of niet op het toestel aanwezig is. Zo wijst de uitkomst 0x1, de code voor de constatering dat er geen licentie op het toestel is gevonden, naar de actie sswitch_de, de melding dat er geen licentie is gekocht. Door in de code de actie te veranderen in sswitch_d3, wat aangeeft dat de licentie is gecheckt en de applicatie dus mag doorgaan, kan de beveiliging worden omzeild. Opvallend is dat de applicatie wel 'weet' dat er geen licentie is gekocht.

Google belooft geen updates en geeft toe dat ontwikkelaars zich nooit volledig tegen het kraken van applicaties kunnen beschermen. "Dat is nooit mogelijk in een systeem waarop third party code mogelijk is." De zoekgigant richt zich er daarom op om het kraken van applicaties moeilijker en duurder te maken, waardoor mensen eerder geneigd zijn om 'gemakkelijk' te doen en de app te kopen.

Een aantal van de Android-gebruikers die gekraakte applicaties gebruiken, doet dat vanwege het gebrek aan betaalmethoden in de Android Market; daarin kan alleen met creditcard worden betaald en die hebben veel Europeanen niet. Toch kunnen ook mensen zonder creditcard zaken kopen bij downloadwinkels en webwinkels die alleen creditcards accepteren, zo legt tweaker Gamefreakin uit.

Reacties (65)

[Keypunchie]

oogle raadt ontwikkelaars aan om de code te 'verduisteren', een techniek die het kraken van de applicatie een stuk lastiger zou maken.

Security through obscurity? Raar advies.

[boe2]

En kan je dat ook onderbouwen waarom dat raar advies is of roep je nu gewoon wat populaire kreten om een fipo te halen? Alle vormen van encryptie kan je dan beschouwen als 'Security through obscurity'

[Reactie gewijzigd door boe2 op 26 juli 2024 03:55]

[mvdejong]

Er is bij encryptie een scheiding tussen de algoritme en de sleutels waarmee het algoritme wordt gevoed. Een criterium voor een goed encryptie-systeem is dat de encryptie nog steeds veilig moet zijn als het algoritme bekend is, zoals bij open-source encryptie-methoden. Het bekend zijn van het algoritme is zelfs een voordeel, omdat dan een zeer grote groep van minder en meer ervaren mensen het algoritme (en de implementatie ervan) kan analyseren en zonodig bekritiseren. Als er 1 sleutel bekend wordt, is er 1 bepaalde gebruiker kwetsbaar.

Security by obscurity slaat op encryptie-methoden (en andere vormen van beveiliging) waarbij het onbekend blijven van de methodiek (algoritme/implementatie) zelf noodzakelijk is voor de beveiliging. Als dan de methodiek bekend raakt zijn in een klap alle gebruikers kwetsbaar.

[Verwijderd]

Dat is een misverstand. Beiden zijn gebaseerd op het geheim blijven van iets. Goede beveiliging staat op 3 pijlers en is bijna niet te omzeilen ook al valt 1 van de pijlers om:
- Verificatie
- Authorisatie
- Administratie

Edit: De 3 A's: authentication, authorization and accounting.
Zie: http://en.wikipedia.org/wiki/AAA_protocol

Kijk naar de OV chipkaart. Ondanks dat je het saldo eenvoudig kan aanpassen is het door de administratieve controle toch mogelijk het systeem te beveiligen.

[Reactie gewijzigd door Verwijderd op 26 juli 2024 03:55]

[robvanwijk]

Dat is een misverstand. Beiden zijn gebaseerd op het geheim blijven van iets.

Nou ga je wel heel kort door de bocht. Tuurlijk moet er iets geheim blijven (nou ja, twee dingen: de manier om te decrypten en de plain text), anders kun je encryptie sowieso wel vergeten. Maar er is een wezenlijk verschil tussen het geheim houden van een algorithme (dat in elk apparaat aanwezig moet zijn) en het geheimhouden van een sleutel (een duidelijk afgebakende, kleine hoeveelheid data die je niet hoeft te verspreiden).

Leuk dat je zelf het voorbeeld van de OV chipkaart erbij pakt. De Mifare Classic waar die op gebaseerd is had namelijk ook zo'n security through obscurity beveiliging: het maakt gebruik van een proprietary algorithm dat oorspronkelijk geheim was. Werkt best goed, totdat iemand het kraakt. Die geheime algorithmes blijken wel vaak niet bijster sterk, zodra ze uitlekken... Tuurlijk is het moeilijker om RSA (om maar eens iets te noemen) te kraken als je zowel het algortihme als de sleutel moet achterhalen. Maar het algortihme openbaar maken heeft twee voordelen: het kan door anderen bekeken worden (zodat bekend is of er aanvallen op zijn) en als je vantevoren al weet dat het openbaar gaat worden dan denk je wel twee keer na voordat je er iets instopt wat de sterkte niet ten goede komt.

[Verwijderd]

Ik zou b.v. een SSL certificaat geen kleine hoeveelheid data willen noemen. Een encryptiesleutel voor een datablok op een Mifarekaart is twee bytes lang. Dat zou je zelfs kunnen onthouden zodat je de code nergens hoeft op te schrijven / bewaren.

Het grote nadeel van openbare algoritmes is dat het algoritme erg complex is. Dat is meteen het zwakke punt. Een complex algoritme heeft veel kans op fouten c.q. achterdeurtjes. Bovendien nodigt een complex algoritme uit tot een vals gevoel van veiligheid. Als je 1 van de drie pijlers uit mijn eerdere bericht weglaat, dan is de beveiliging veel minder effectief.

[Delgul]

RSA is anders (op 1 aanname na, en die is zeer waarschijnlijk waar) bewezen onkraakbaar, behalve door brute force. Dat is meer dan van bijna alle proprietary methoden gezegd kan worden.

Bovendien is RSA niet erg veel complexer dan een andere goede encryptie methode, of je moet natuurlijk XOR al een goede noemen ;-)

[Verwijderd]

Het algoritme is slechts 1 onderdeel. Als jij een simpele XOR gebruikt met de beperking dat er maar 3 pogingen mogen worden gedaan (b.v. je sim-kaart of je pin-pas), dan is de kans dat uit de 10000 mogelijkheiden de juiste binnen 3 pogingen wordt gekozen minimaal. Binnen een redelijke tijd kun je met brute force een even grote kans op een juiste code kijgen als je een RSA sleutel wilt kraken.

[cdwave]

XOR is een "prefecte" encryptie, mits de sleutel even lang is als het plaintext bericht dat ermee versleuteld wordt, en dat de sleutel voldoende entropie bevat (01234... is waarschijnlijk geen goede sleutel).

Die eerste eis is natuurlijk meteen de grote zwakte van XOR, want het veilig "versturen" van de sleutel is nu even moeilijk als het versturen van het bericht zelf...

[robvanwijk]

Die eerste eis is natuurlijk meteen de grote zwakte van XOR, want het veilig "versturen" van de sleutel is nu even moeilijk als het versturen van het bericht zelf...

Niet persé. Als ik een DVDtje op de diplomatieke post doe dan kan ik mijn ambassade zo 4 GB aan sleutel sturen. Als die onderschept wordt, nou ja lekker interessant, dan brand ik wel een nieuwe; die random data was niet geheim, daar heeft niemand iets aan. Zolang ik die sleutel niet gebruik om data te versturen totdat mijn ambassade bevestigd heeft dat de DVD goed is aangekomen (en dat het zegel niet verbroken is!) is dit wel degelijk nuttig. Je kunt er een tamper-evident kanaal mee "upgraden" naar een tamper-proof kanaal (of, zoals in het voorbeeld, een tamper-evident kanaal gebruiken om een gewoon kanaal (internet) te upgraden naar tamper-proof).

Voor mensen die meer info hierover zoeken; deze encryptie wordt meestal "One time pad" genoemd.

[robvanwijk]

Ik zou b.v. een SSL certificaat geen kleine hoeveelheid data willen noemen.

In verhouding tot een correcte implementatie van het hele SSL-protocol ("SSL.dll")? Oh jawel hoor, da's heel erg veel kleiner.

Het grote nadeel van openbare algoritmes is dat het algoritme erg complex is.

Valt reuze mee. Zoals Delgul al zegt is RSA helemaal niet zo ingewikkeld (het bewijs waarom het werkt wel, maar daar heb ik het niet over). Hetzelfde geldt voor Rijndeal (AES). Ja, het is een gruwelijke bak werk om met de hand te moeten doen, maar tegen je computer roep je gewoon for(i=0;i<256;i++) (tenminste, het waren 256 rondes, toch?). Ook de code in elk ronde stelt niet heel veel voor.

Dat is meteen het zwakke punt. Een complex algoritme heeft veel kans op fouten c.q. achterdeurtjes. Bovendien nodigt een complex algoritme uit tot een vals gevoel van veiligheid.

Maar in een [i]openbaar[/i[ algorithme zullen fouten veel sneller worden opgespoord, zodat je een goed idee hebt hoe veilig het precies is. Dat is het essentiële punt! Als een fabrikant zijn algorithme geheim houdt weet ik niks; voor hetzelfde geld is het een ceasar-"cipher" (qua sterkte vergelijkbaar met gewoon plain text sturen).

[Verwijderd]

Complexiteit is niet alleen de implementatie in code maar ook het wiskundige bewijs dat een encryptiealgoritme veilig is.

[ppl]

Administratieve controle? Die controle die toestaat dat mensen een OV-chipkaart op naam van Osama Bin Laden aan kunnen vragen e.d.? Die administratie waardoor men maanden lang op zoek is geweest om die pasjes te achterhalen tot een persoon (waarom niet blokkeren zodat ze onbruikbaar worden)? En dan nog te zwijgen over de problemen die mensen hebben bij het terugkrijgen van het teveel afgeschreven tegoed.

De administratie van de OV-chipkaart is toch wel 1 van de slechtste voorbeelden die je had kunnen nemen in dat opzicht. Het doet verder geen afbreuk aan je verhaal: security is gewoon heel wat meer dan alleen dingen niet vertellen of encryptie toepassen. Als je niet een complete set aan features implementeert ben je het haasje. Het niet vertellen wat je nou exact doet aan security is overigens wel 1 van de meest simpele en eenvoudige maatregelen die je kunt treffen. In geval van een Android app is het uitermate amateuristisch van Google dat de programmeur van de app de betreffende code dan maar moet verbergen. Dan is er gewoonweg iets fundamenteels fout, dan is het design gewoonweg niet goed en moet Google daar maar eens harder aan gaan trekken. Dit is meer je eigen verantwoordelijkheid op een ander afschuiven. Dat is nou net 1 van de slechtste dingen die je wat beveiliging betreft kunt doen.

[u_nix_we_all]

Obscurity is niet iets waar je op wilt vertrouwen, dat is zoiets als de sleutel onder de mat leggen. De eerste inbreker die daar toevallig kijkt, is binnen.

En er zijn ook volledig transparante encryptie-methoden die gewoon veilig zijn hoor.

Het is het verschil tussen de sleutel verstoppen, en weten aan wie je welke sleutel uitgegeven hebt IMHO.

[robvanwijk]

Obscurity is niet iets waar je op wilt vertrouwen, dat is zoiets als de sleutel onder de mat leggen. De eerste inbreker die daar toevallig kijkt, is binnen.

Da's een onhandige vergelijking omdat bij encryptie er een heel scherpe scheiding is tussen algorithme en sleutel. Security through obscurity gaat niet om het verstoppen van de sleutel maar om het verstoppen van (de werking van) het slot. Het is het verschil tussen een bewaker die niks zegt en alleen maar nors voor zich uit staart en de bewaker die vraagt "ken je de geheime handdruk?". Nou, dan weet je in elk geval alvast dat je geen (gesproken) wachtwoord hoeft te raden.
Je vergelijking met "weten aan wie je welke sleutel uitgegeven hebt" snap ik niet helemaal: normaal authenticeer je jezelf door die sleutel te hebben (of, in geval van two-factor: onder andere door die sleutel te hebben).

[kidde]

Wel een mooi voorbeeld:

"Wie de sleutel heeft mag binnen, wie de sleutel niet heeft mag niet binnen."
Maakt de krekker ervan: "Wie de sleutel niet heeft, mag binnen"

Zegt Google: "Moet je de 'sleutel' en 'binnen' andere namen geven, o ja, en niet onder de deurmat leggen. Misschien de bloempot?".
Way to go

[TIGER79]

in dit geval door obfuscation wat in mijn kringen in ieder geval nogal standaard is, al sinds J2ME...
linkje :
http://developer.android....sing.html#app-obfuscation

[Reactie gewijzigd door TIGER79 op 26 juli 2024 03:55]

[Verwijderd]

Ja, want gekraakte Java midlets kom je nooooit tegen op p2p netwerken... maar niet heus.

[Zer0]

En waar wordt beweerd dat het niet mogelijk is om obfuscated code te kraken? Er wordt alleen beweerd dat het moeilijker wordt mbv obfuscation, wat inderdaad zo is.

[TIGER79]

tsjah, je kan natuurlijk ook zelf dingen uitkramen... het ergens op baseren of een reactie op een uitspraak maken ligt je ook niet blijkbaar...

[humbug]

Obfusciation is een standaard methode om de code te beschermen. Zonder dat soort technieken is het simpel om de code te decompileren en er weer iets leesbaars van te maken. Security door een slot op de deur te zetten. Lijkt mij een vrij standaard advies.

[Delgul]

Onzin, want wie vertouw jij meer:

De kluizenbouwer die zegt: Hier heb je de tekening van mijn kluis. Kijk maar eens goed. Het design is zo perfect dat ie toch niet gekraakt kan worden.

Of de kluizenbouwer die zegt: Hier heb je een kluis. Je mag hem niet ontleden, want als je dat doet dan kun je zien hoe het werkt en is ie misschien zo gekraakt. Oh ja: Misschien is er al wel een inbreker die dit ding heeft ontleed, maar dat is dan wel tegen de wet hoor!!


Ik zou het wel weten. Reden waarom ik voor beveiliging meestal OSS gebruik ipv closed source producten.

[kidde]

Op zich wel, maar stel dat er alleen makkelijk kraakbare onveilige kluizen zijn waarvan de tekening bekend is, want dat is hier een beetje de situatie.

Wie vertrouwt u dan meer:
De bouwer die zegt: "Wegzetten en gebruiken",
of de bouwer die zegt: "Even beetje verbouwen, palletjes en asjes op een andere plek monteren, slotje achterstevoren en binnenstebuiten doen en sleuteltje andere vorm geven".

Ik zou het wel weten!

[Reactie gewijzigd door kidde op 26 juli 2024 03:55]

[John_Glenn]

Tja, DRM-technieken vallen volgens mij allemaal onder "security through obscurity". Broken by design enzo...

[Zer0]

Vertel eens wat DRM en "security through obscurity" met elkaar te maken hebben? AFAIK helemaal niks.

[naikon]

Dat heeft wel veel met elkaar te maken omdat zowel het algoritme als de key in handen zijn van de kraker. Deze hoeft "alleen" nog maar te begrijpen hoe het algoritme werkt en waar het zijn key(s) vandaan haalt om de content te decrypten.

[kidde]

Zo goed als alle DRM-implementaties zijn "closed source".

[Gideon_92]

beveiliging Android-apps is niet op beveiliging gericht

dus je beveiligt iets om het niet te beveiligen O_o

[watercoolertje]

Moet je het wel in de goede context zetten/lezen en niet enkel de sensationele header kopiëren!

"De eerste release is uitgebracht met de simpelste, zo transparant mogelijke implementatie van een sample, die was geschreven zodat hij gemakkelijk is te begrijpen en aan te passen. De code is niet gericht op beveiliging."

[Reactie gewijzigd door watercoolertje op 26 juli 2024 03:55]

[Magnetic_Man]

Maar daar komt het dan dus wel op neer. Ze hebben zogenaamde 'beveiliging' uitgebracht, die dus helemaal niet als beveiliging bedoelt was.

[Verwijderd]

Maar daar komt het dan dus wel op neer. Ze hebben zogenaamde 'beveiliging' uitgebracht, die dus helemaal niet als beveiliging bedoelt was.

Klopt en ze hebben daar dus ook goede redenen voor.
Ik zou willen dat tweakers iets minder headlines zou maken die meer op zijn plaats zouden zijn in Metro. Scheelt een stuk met dit soort reacties,

[Verwijderd]

Tja... als ik jou een pond gehakt geef en je vertel dat je daar makkelijk een gehaktbal van kan maken en deze aan kan passen aan jouw smaak.. en jij vervolgens dat pond gehakt gewoon in een pan gooit en rondom bruin braad.. dan moet je niet klagen dat het er 1. niet als een bal uit ziet en 2. niet echt bijzonder lekker smaakt.

Neemt niet weg dat Google ook best een uitgebreidere beveiligings guideline beschikbaar kan maken die misschien ook nog best te kraken is, maar niet op de manier van 'als je 1 kan kraken, kan je ze allemaal kraken'.

[mr.paaJ]

Met een eerste kleine drempel houdt je al een groot deel van je mogelijke klanten, de extra moeite om serieuze 'aanvallen' tegen te houden is vaak niet de moeite waard voor kleine apps (zeker niet in een standaard stukje code dat eigenlijk maar één keer ontcijfert hoeft te worden).

[Verwijderd]

Als die serieuzere aanvallers het voor zichzelf zouden houden niet, maar meestal vind je de resultaten daarvan wel terug op diverse p2p netwerken en usenet. En dan kan iedereen het gebruiken.

[SPee]

De kraakmethode is vrij makkelijk en makkelijk toepasbaar voor verschillende applicaties tegelijk. Voor de personen die dat écht willen, werkt die beveiliging dus niet. Die zoeken gewoon de exploits op.

Maar de vraag is: wil je veel moeite doen voor een app die hooguit €5,- kost?
Vele Android gebruikers zijn a-technisch en zullen zulke trucjes niet uithalen (weten niet hoe), dan zijn er ook veel die er de moeite niet voor nemen of de app het geld echt waard vinden. Als dit zoveel klanten zijn, dan zou het vrijwel de moeite niet zijn om extra ontwikkeltijd te steken in de beveiliging.

Hoe duurder de app, hoe groter het animo om deze te kraken. Dan zullen de makers ook (eigen) authorisaties toevoegen.

[sdevos13]

Slappe reactie van Google...
Natuurlijk is hun beveiliging wel op het voorkomen van het illegale downloaden van applicaties gericht. Ze hebben gewoon een makkelijk licentie systeem gemaakt en hoopte hier mee weg te komen, maar hebben echter gewoon gefaald in het snel creëren van een licentie systeem dat het minimaal tot de volgende uitgave van het systeem moest gaan uithouden.

Ze hadden gewoon moeten zeggen dat ze er nog mee bezig waren, niet dat de beveiliging niet gericht is op beveiligen

[RielN]

Alsof google niet nadenkt.
Wat een onzin reacties zijn dit.

[stefanos1990]

beveiliging Android-apps is niet op beveiliging gericht

Het probleem van die zin is dat iedereen er van uit ging dat dit ter beveiliging van apps zou dienen. Google heeft nu dus uitgelegd dat dit niet zo is.

Die zin moet je dus zo zien:
"Wat wij dachten dat het deed (beveiliging), blijkt het toch niet te doen."

[RielN]

het heet dan ook Licensing.

[The_Double]

Tweakers quote hier verkeerd, het voorbeeld van de implantatie was zo gemaakt dat hij makkelijk te begrijpen was, niet dat het de beste beveiliging was. de service die ze aanbieden is wel veilig (tot een zeker niveau uiteraard).

[Verwijderd]

Google zou bv. het betalen van apps makkelijker kunnen maken. Hier zijn zowel de ontwikkelaars als Google zelf mee gediend. Mja, zolang de gehackte app's ook reclame tonen, is de incentive wel wat minder.

[mashell]

Inderdaad. Als je de intentie hebt veel te verkopen moet betalen gemakkelijk zijn en op vele manieren kunnen. Natuurlijk moet ook de beveiliging op een serieus niveau zijn.

[MasterPa]

In theorie geef ik je gelijk. Maar ik denk niet dat de meeste mensen die nu gekraakte apps gebruiken daar zometeen voor gaan betalen als dat via Ideal of PayPal kan. Er zijn gewoon te veel mensen die gewoon gratis op de eerste rij willen zitten.

[World Citizen]

zoals ik he nu lees zou het dus betekenen dat ontwikelaars die de code aangepast hebben, of niet de standaard code gebruikt hebben, geen last hebben van dit probleem. Hun apps zijn niet zonder te betalen te installeren? Anders is de opmerking van google " google belooft geen updates" wel mis. Daarnaast lijkt het er in het artikel op dat google niet verantwoordelijk wil zijn voor de beveiliging in de apps... Wat ik erg vreemd vind.

Ik raad iedereen aan de bron van dit artikel te lezen... Ik moest toch wel lachen.

[Reactie gewijzigd door World Citizen op 26 juli 2024 03:55]

[Verwijderd]

Natuurlijk wil Google niet verantwoordelijk zijn voor de kwaliteit van beveiligingen die zij zelf niet schrijven. Als je de API dom toepast en je app wordt gekraakt kun je natuurlijk niet bij Google klagen.

[The_Worst]

In de tekst staat dat de applicatie 'weet' dat er niet betaald is voor de applicatie. Dit zou dan toch betekenen dat het mogelijk moet zijn om de applicatie alsnog te stoppen?

[cdwave]

Ja, door nog een "if (iWasPaidFor) ..." toe te voegen aan de code. Maar die kun je op dezelfde manier weer hacken als die eerste "if" natuurlijk. Twee keer hetzelfde truukje is makkelijk voor de hacker.

[Ghostface9000]

die zogenaamde 3V kaarten waar zijn die dan te koop ? Volgens de website niet in belgie of nederland...

[Verwijderd]

De site van Visa 3V in Nederland: https://www.3vcash.nl/

Edit: Oh ja.. MasterCard heeft ook zoiets.. zijn al een tijdje actief maar de site doet nog steeds een beetje shady aan http://www.easykard.nl/ . Verschil is dat dit meer een 'debit card' is die je zelf op moet laden met een bepaald bedrag, i.p.v. dat deze dus prepaid is. 3V is meer 'throw-away', zeg maar.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 19:34]

[LessRam]

En die 3Vcard kost nogal wat.......... https://www.3vcash.nl/wat_kost_het.html
EasyKard kost 49 Euro per jaar, als je weinig koopt misschien wat veel maar je weet waar je aan toe bent.
Nee doe mij maar een gewone creditcard, uiteindelijke kosten zijn wel wat lager dan 3V en Easy.

[Verwijderd]

En die 3Vcard kost nogal wat...

Mwoah... kijk, een vaste creditcard is natuurlijk goedkoper -als- je vaak wat koopt. Maar iDeal is dan weer -nog- goedkoper. Maar ja.. de hele wereld aan de iDeal zal niet zo 1-2-3 lukken.

Maar als je gewoon iets ziet op internet dat je simpelweg niet hier kan kopen, en ook niet op een site die toevallig PayPal ofzo ondersteunt, en je dus wel een CC betaalmiddel nodig hebt, en -ook- al niet iemand anders met een CC dat geld kan (of wil) geven zodat die het even voor je besteld...

Met een 3V kaart weet je ook - zelfs beter - waar je aan toe bent. Immers zit er een vast bedrag aan en kan je 'm niet 1-2-3 opwaarderen; als je meer geld nodig hebt zal je een andere/nieuwe kaart moeten kopen, overboeken als het een groter bedrag is, etc..

In vergelijking met een EasyKard is zo'n 3V kaart veel goedkoper, als je beseft dat je 'm koopt om iets sporadisch te kunnen kopen.. niet om er geen gebruik van te maken.
€37.00 - Het product dat je wil kopen.
1. €50.00 - De €50 kaart die je zal moeten kopen
2. €2.50 - de €2,50 toeslag op de kaart
3. €37,00 - De kosten van het product
4. €0,6475 - De 1,75% van €37,00 omdat je iets buiten de Eurozone koopt.
5. €5,00 - De kosten om het overgebleven bedrag op dit moment op je bankrekening te storten.
6. €44,15 - Wat je daadwerkelijk hebt betaald. ( €52,50 - (€50,00 - €37,00 - €0,65 - €5,00 = €7,35 teruggestort op bank) = €44,15 )
( mocht ik een addertje onder het gras hebben gemist, gaarne een reply-comment )

Nu kopen we dat product met de EasyKard...
http://www.easykard.nl/prepaid-card-kosten/
1. €98,00 - €49,00/jaar, verbintenis van 2 jaar
2. €15,60 - de €1,30 maandelijkse kosten (ja, bovenop de €49/jaar).
3. €1,00 om de kaart te activeren.
4. €37.00 - het geld dat je erop moet zetten om het product te kunnen kopen.
5. €0.555, de 1.50% van €37.00, omdat je iDeal hebt gebruikt om het erop te zeten.
6. €1,00, omdat je op internet iets hebt gekocht.
7. €1,0175, de 2,75% van €37.00 omdat het in een andere valuta was.
Totaal: €154,17 (optel som)

Je kan heel wat dingen kopen met een 3V (vooral als je dat wat vaker doet en al begint met een duurdere kaart waardoor je niet aldoor overboekingskosten zou hebben) voordat je de prijs van een EasyKard benadert.

Zelf zie ik er, voor de casual gebruiker, geen voordeel in. Als je een EasyKard aantrekkelijk vindt, dan is een gewone credit card veel meer aan te bevelen. Wil dat niet, dan is er altijd ook nog de MediusCard ( https://www.mediuscard.com/NL_nl/price ). Ongeveer gelijk aan de EasyKard, maar iets lagere jaarlijkse kosten en geen maandelijkse kosten (misschien dat daarom EasyKard wat shady aandeed..)

[ajakkes]

Maar het wordt nog gekker als je slechts 1 app wil kopen.
Prijs €2,- (Prijs van een gemiddelde goedkope app)
€2,- + €1,- + €5,- = €8,-
300%!!!!

Je voelt je haast verplicht om 10 apps te kopen om de €20,- terug te verdienen. (Binnen drie maanden).

Volgens mij is paypal en ideal toch een stuk goedkoper voor dit soort kleine aankopen in de android market. Zelfs als je 6 apps wil kopen.

Voor een dure app is het misschien een ander verhaal maar vindt ik 10% nog best veel.

[Verwijderd]

'tuurlijk, als je een appje van €2 wil kopen dan is in principe -alles- belachelijk. Een bankrekening heb je ook niet gratis.. waarom kan je niet gewoon een Google winkel binnenlopen en daar je €2 munt afgeven?

De discussie hierboven was meer aangaande de 3V kaarten en alternatieven binnen dat segment. -Buiten- dat segment kan je natuurlijk altijd Google lief aankijken en zeggen dat ze iDeal toe moeten voegen aan de Android Store, of aan Google Checkout. PayPal zit er niet zo 1-2-3 in aangezien Google Chckout daar nu eenmaal een concurrent van is en al wel in de Android Store te gebruiken is (ehm.. toch?)

[Jeroen-83]

Google is your friend. Elke primera winkel dus!!!

Mijn mening is schaf een credit card aan. Is echt super makkelijk op vakantie en voor internet aankopen. Als je er voor zorgt dat het aan het eind van de maand altijd afgeschreven kan worden betaal je geen rente. Alle aankopen zijn verzekerd. Enige nadeel is dat er kosten aan verbonden zijn (volgens mij iets van €30 per jaar bij de rabo)

[Verwijderd]

Door in de code de actie te veranderen in sswitch_d3, wat aangeeft dat de licentie is gecheckt en de applicatie dus mag doorgaan, kan de beveiliging worden omzeild. Opvallend is dat de applicatie wel 'weet' dat er geen licentie is gekocht.

Dan kun je de applicatie in demo mode zetten of direct stoppen, als de applicatie ziet dat de applicatie niet officieel gekocht is. Al dan niet met een error code.

[Reactie gewijzigd door Verwijderd op 26 juli 2024 03:55]

[eknem]

Haha....Right back @ you..

Na het lezen van het eerste artikkel dacht ik dit al. Maar fijn dat Google het nog even bevestigd. (tussen de regels door)
Google is groot geworden met het gedachte goed dat het niet meer van deze tijd is om de consument te laten betalen voor software. De enigste reden voor deze functionalieit is om de fabrikanten en ontwikkelaars (die het hele android verhaal toch uiteindelijk tot een sucses moeten maken) te vriend te houden. Dat google zijn vingers niet gaat branden aan de uitwerking hiervan is mijn inziens erg logisch, zeker gezien de filesofie achter het bedrijf.

En je hoeft echt geen top programmeur te zijn om dit handvat te gebruiken om je software naar huidige maatstafen te beveiligen.

En laten we wel wezen er bestaat geen beveiliging die niet te omzeilen valt. En die zal er ook nooit komen. Dus waarom zou daar uberhaupt nog tijd in steken?
Net als bij inbraak preventie van je huis geld dat je het de inbreker op zijn hoogst zo moeilijk mogelijk kan maken. In de hoop dat de inbreker deze moeite niet gaat nemen. Maar als ze er echt in willen dat kunnen ze dat ook.

Het groote verschil is dat ik het inbreken in iemands huis (prive domein) moreel onacceptabel vind. In tegen stelling tot het "illigaal" kopieeren en gebruiken van software.

[swampy]

Sigh leuk vandaag de dag om alles makkelijk te maken gooien ze alles open. Je address boek? Tja handig voor die applicatie die een clown laat dancen!

[Reactie gewijzigd door swampy op 26 juli 2024 03:55]

[Kixtart]

Het gaat erom dat er geen beveiliging is die controleert of de desbetreffende .apk gekocht is of niet. Het heeft niks te maken met het 'open gooien' van de telefoon zelf.

[gybrus]

Wel grappig dat de eerste firmware verzie van de psp ook zo werkte.