W3C verdedigt web cryptography-api
Het encrypten en decrypten van gegevens via javascript is geen slecht idee. Dat zei een medewerker van het World Wide Web Consortium op de CCC-beveiligingsconferentie. De W3C werkt aan een api waarmee dat mogelijk wordt, maar critici zetten er vraagtekens bij.
Tijdens een presentatie op een congres van de Chaos Computer Club in Hamburg, waar Tweakers aanwezig is, erkende W3C-medewerker Harry Halpin dat het gebruik van javascript voor encryptie controversieel is. "Maar het is geen slecht idee", aldus Halpin. In september kwam een eerste conceptversie uit van een javascript-api waarmee in de browser encryptie kan worden gebruikt. Daarmee kunnen bijvoorbeeld gegevens worden ver- en ontsleuteld en hashes worden gegenereerd.
Een van de bezwaren die critici hebben bij de api, is dat de webserver in die api bij het regelen van de encryptie alle controle in handen krijgt. Die is immers verantwoordelijk voor het serveren van de javascript-code die wordt gebruikt om de api aan te roepen, en is daarom gevoelig voor misbruik. Onder meer beveiligingsgoeroe Bruce Schneier heeft zich, hetzij in een andere context, negatief uitgelaten over deze manier van encryptie: wordt de host - in dit geval de webserver - gehackt, dan liggen bijvoorbeeld de encryptiesleutels op straat.
Halpin zet daar echter vraagtekens bij. "Waarom zou je dan nog update-mechanismen gebruiken?", vraagt hij zich af. Wordt de server die de updates serveert immers gehackt, dan kan de code die gebruikers op hun systemen installeren ook worden misbruikt. Daarnaast tekent hij aan dat apparaten ook in verkeerde handen kunnen vallen, bijvoorbeeld door diefstal of verlies.
Tegelijkertijd erkent de medewerker van het W3C dat de api nog niet perfect is; daarom riep hij bezoekers van de CCC op om de specificatie kritisch te bekijken. Ook gaat de api veel problemen niet oplossen, zoals aanvallen op beveiligde verbindingen.
De api kan volgens Halpin onder meer van pas komen bij het verwerken van two-step-authenticatie, waarbij naast een wachtwoord een extra waarde moet worden opgegeven, die bijvoorbeeld door een smartphone-app wordt gegenereerd. Ook het versleutelen van berichten en ondertekenen van documenten moet met de api vanuit de browser kunnen worden geregeld. Sommige websites gebruiken nu al eigen implementaties van cryptografie in javascript; gebruik van de api is volgens Halpin betrouwbaarder.
Reacties (49)
Omgekeerd kan ook. Malware in de browser haakt nu in op Windows APIs om gegevens, voordat ze versleuteld worden, te kapen. Als de gegevens IN de browser DOM al versleuteld worden (dat is een laag hoger dan de Windows API) hebben we daar weer een slag geslagen (de data is al versleuteld voordat het aangeboden wordt aan de Windows APIs / malware). Al is dat maar een kwestie van tijd natuurlijk voordat malware ook ik de DOM de boel kaapt middels geïnjecteerde scripts.
[Reactie gewijzigd door erikloman op donderdag 27 december 2012 20:28]
Met SSL is dat toch precies hetzelfde? Als de webserver die de site host gekraakt wordt ligt de key van dat certificaat ook op straat. Waarom zou dat bij deze manier van encryptie ineens een probleem zijn...
Ze spreken over smartphone apps: Waarom zou je de beperke reken en batterij capaciteit verspillen aan deze zware wiskundige berekeningen terwijl je aan de andere kant genoeg rekenkracht hebt 
Als ik het goed begrijp zou dit betekenen dat een bank als de Rabobank de "Random Reader", nu een apart aparaatje, zou kunnen implementeren in de browser en met JavaScript lokaal wordt uitgevoerd. Het risico wat je dan loopt is dat de server van de bank gehacked wordt en de JavaScript code aangepast wordt.
Het lijkt me echter dat als de bank gehacked wordt zonder dat ze het merken je al een groot probleem hebt. De bank is dan gewoon slecht bezig en dit betekent niet dat deze hele encryptie methode slecht is. Bovendien kan ik me herinneren dat door een hack vorig jaar ergens een hoop van die Secure/Smart Keys ineens niet meer veilig waren, wat vergelijkbaar is met een Random Reader; two-step authentication "offline" uitvoeren is dus ook niet 100% veilig.
Op zich lijkt het me ook wel handig dat je al die extra authenticatie apparaatjes dadelijk niet meer per se nodig hebt, maar ik zou dergelijke encryptie alleen gebruiken bij betrouwbare veilige partijen, anders heb je er niets aan. Banken zouden toch veilig moeten zijn
Het lijkt me echter dat als de bank gehacked wordt zonder dat ze het merken je al een groot probleem hebt. De bank is dan gewoon slecht bezig en dit betekent niet dat deze hele encryptie methode slecht is. Bovendien kan ik me herinneren dat door een hack vorig jaar ergens een hoop van die Secure/Smart Keys ineens niet meer veilig waren, wat vergelijkbaar is met een Random Reader; two-step authentication "offline" uitvoeren is dus ook niet 100% veilig.
Op zich lijkt het me ook wel handig dat je al die extra authenticatie apparaatjes dadelijk niet meer per se nodig hebt, maar ik zou dergelijke encryptie alleen gebruiken bij betrouwbare veilige partijen, anders heb je er niets aan. Banken zouden toch veilig moeten zijn
Dat een gehackte webservers mogelijk clients voor het lapje houdt, is een non-argument. Dat is ook zo als deze technologie niet gebruikt wordt.
Mij lijkt het dat elke toegevoegde beveiligings-laag misbruik lastiger maakt. Het enig waar wel echt kritisch op toegezien moet worden is dat zo'n laag geen problemen in andere lagen kan veroorzaken.
Ook mag je niet alle eieren in één mand leggen; een verstandige keuze van verschillende technologieën die verschillende aanvalsmethodes (zo sterk mogelijk) bemoeilijken is een absolute must.
Nu de kat al op de koord zit, maakt men wat mij betreft best snel werk van een kwalitatieve en goed ondersteunde api, zodat webontwikkleaars wat betreft security alvast niet aan hun eigen kunnen zijn overgeleverd!
Mij lijkt het dat elke toegevoegde beveiligings-laag misbruik lastiger maakt. Het enig waar wel echt kritisch op toegezien moet worden is dat zo'n laag geen problemen in andere lagen kan veroorzaken.
Ook mag je niet alle eieren in één mand leggen; een verstandige keuze van verschillende technologieën die verschillende aanvalsmethodes (zo sterk mogelijk) bemoeilijken is een absolute must.
Nu de kat al op de koord zit, maakt men wat mij betreft best snel werk van een kwalitatieve en goed ondersteunde api, zodat webontwikkleaars wat betreft security alvast niet aan hun eigen kunnen zijn overgeleverd!
Veel reacties hierboven begrijpen niet wat het probleem is.
Stel, er is een webservice die encrypted data opslaat op z'n servers. De gebruiker heeft de decryptie sleutel, de eigenaar van de server niet. Dus, de eigenaar van de server kan de data die op zijn systeem staat niet lezen. Dit is een gewenste opstelling, en wordt ook veel gebruikt. (e.g. bestanden encrypten via PGP en die in de DropBox account plaatsen).
Het probleem met deze methode is dat je die data dus niet in je browser kan bekijken, er is dan weer een externe tool nodig om de data te decrypten.
De crypto API die in nieuws artikel besproken wordt geeft de mogelijkheid om vanuit de browser, via JavaScript, data te encrypten en decrypten. Dat lijkt fantastisch, maar dit is wel een security risico. Want het geeft de eigenaar van de webservice de mogelijkheid om via jou browser de data te decrypten en on-encrypted weer terug te sturen. De gebruiker merkt hier niks van. De eigenaar van de webservice kan dit doen doordat hij de bron van de encrypted data is, en de logica aanlevert voor het decrypten van de data, en hierdoor dus ook toegang heeft tot de decrypted data.
(Note: eigenaar van webservice kan vervangen worden door: browser plugin developer, hacker van de webservice (via JS injection e.d.))
Er is dus niet echt security aanwezig, maar voor de niet wetende gebruiker is deze er wel. En dat misplaatst vertrouwen is waar veel crypto experts problemen mee hebben.
Stel, er is een webservice die encrypted data opslaat op z'n servers. De gebruiker heeft de decryptie sleutel, de eigenaar van de server niet. Dus, de eigenaar van de server kan de data die op zijn systeem staat niet lezen. Dit is een gewenste opstelling, en wordt ook veel gebruikt. (e.g. bestanden encrypten via PGP en die in de DropBox account plaatsen).
Het probleem met deze methode is dat je die data dus niet in je browser kan bekijken, er is dan weer een externe tool nodig om de data te decrypten.
De crypto API die in nieuws artikel besproken wordt geeft de mogelijkheid om vanuit de browser, via JavaScript, data te encrypten en decrypten. Dat lijkt fantastisch, maar dit is wel een security risico. Want het geeft de eigenaar van de webservice de mogelijkheid om via jou browser de data te decrypten en on-encrypted weer terug te sturen. De gebruiker merkt hier niks van. De eigenaar van de webservice kan dit doen doordat hij de bron van de encrypted data is, en de logica aanlevert voor het decrypten van de data, en hierdoor dus ook toegang heeft tot de decrypted data.
(Note: eigenaar van webservice kan vervangen worden door: browser plugin developer, hacker van de webservice (via JS injection e.d.))
Er is dus niet echt security aanwezig, maar voor de niet wetende gebruiker is deze er wel. En dat misplaatst vertrouwen is waar veel crypto experts problemen mee hebben.
[Reactie gewijzigd door elmuerte op donderdag 27 december 2012 18:34]
Als ik het goed begrijp ligt dit helemaal aan de javascript-code.
Als die code legitiem is dan worden de sleutels niet over het internet gestuurd ofzo maar blijft alles alleen in de browser draaien.
Het risico zit dus in de server die de code aanlevert en of die code te vertrouwen is.
De webserver levert alleen de encrypted data aan en de javascript-code om deze te ontsleutelen, het ontsleutelen en versleutelen gebeurt met een alleen voor de gebruiker bekende sleutel.
Het voordeel is dat er geen aparte tooltjes of software nodig is in de vorm van plugins die dit moeten doen, waarbij je ook het risico hebt dat ze vervangen zijn door malware door een update-programma.
Deze techniek is overigens niet nieuw, ze willen er nu alleen een standaard API van maken.
MegaUpload zal hier ook gebruik van maken:
Als die code legitiem is dan worden de sleutels niet over het internet gestuurd ofzo maar blijft alles alleen in de browser draaien.
Het risico zit dus in de server die de code aanlevert en of die code te vertrouwen is.
De webserver levert alleen de encrypted data aan en de javascript-code om deze te ontsleutelen, het ontsleutelen en versleutelen gebeurt met een alleen voor de gebruiker bekende sleutel.
Het voordeel is dat er geen aparte tooltjes of software nodig is in de vorm van plugins die dit moeten doen, waarbij je ook het risico hebt dat ze vervangen zijn door malware door een update-programma.
Deze techniek is overigens niet nieuw, ze willen er nu alleen een standaard API van maken.
MegaUpload zal hier ook gebruik van maken:
http://www.wired.com/threatlevel/2012/10/megaupload-mega/Dotcom, and his Mega partner Mathias Ortmann say the difference is that now those files will first be one-click-encrypted right in a client’s browser, using the so-called Advanced Encryption Standard algorithm. The user is then provided with a second unique key for that file’s decryption.
[Reactie gewijzigd door Soldaatje op donderdag 27 december 2012 19:07]
Verhelderende uitleg, ik snap nu beter dat het wel nut zou kunnen hebben. Ik heb zelf namelijk nog een idee voor een webapplicatie waarmee ik de data eigenlijk alleen versleuteld op de server wil hebben. Ik wil dus niet bij de data van gebruikers kunnen. Door de sleutel dus bij de browser te laten, kan de de risico's en gevolgen van een hackpoging verkleinen.
Jou redenatie dat je het toch wel door kan sturen naar de webserver is natuurlijk terecht, maar je bent sowieso in een applicatie omgeving bezig en dus in de omgeving van de browser en webserver. Daar heb je als gebruiker weinig controle over, dat is nu eenmaal zo in zo'n opstelling. Ik zie ook niet voor me dat dit zou kunnen veranderen en dat dit veiliger zou kunnen.
Echter, vanuit het oogpunt dat je een veiligere dienst af wil leveren als webontwikkelaar, kan het wel zeker nut hebben.
Jou redenatie dat je het toch wel door kan sturen naar de webserver is natuurlijk terecht, maar je bent sowieso in een applicatie omgeving bezig en dus in de omgeving van de browser en webserver. Daar heb je als gebruiker weinig controle over, dat is nu eenmaal zo in zo'n opstelling. Ik zie ook niet voor me dat dit zou kunnen veranderen en dat dit veiliger zou kunnen.
Echter, vanuit het oogpunt dat je een veiligere dienst af wil leveren als webontwikkelaar, kan het wel zeker nut hebben.
Nee, want de prive sleutel wordt bewaard door een trusted 3rd party (zoals verisign).
Omdat je bepaalde gegevens al geencrypt wil voordat het op de server aankomt ?
Ik vind je voorbeeld nogal vergezocht, maar plausibel. Ik dacht zelf aan andere toepassingen van de crytography-api zoals browser based hashen, authenticatie, versleutelen van local data storage of het toepassen van cryptography in single page applications.
Juist maar in dit geval leg je EN de geencrypte data EN de decryptie/sleutel in de handen van de website. Dat is gevaarlijk en wil je gescheiden houden.Als ik het goed begrijp ligt dit helemaal aan de javascript-code.
Als die code legitiem is dan worden de sleutels niet over het internet gestuurd ofzo maar blijft alles alleen in de browser draaien.
Het risico zit dus in de server die de code aanlevert en of die code te vertrouwen is.
De webserver levert alleen de encrypted data aan en de javascript-code om deze te ontsleutelen, het ontsleutelen en versleutelen gebeurt met een alleen voor de gebruiker bekende sleutel.
Zowel de private als de public key zijn bekend op de webserver.
En zoals de naam doet vermoeden is de public key publiek beschikbaar voor de clients om zo dat sessie te versleutelen. De server ontsleutelt deze vervolgens met private key en stuurt info versleuteld met diezelfde key.
En zoals de naam doet vermoeden is de public key publiek beschikbaar voor de clients om zo dat sessie te versleutelen. De server ontsleutelt deze vervolgens met private key en stuurt info versleuteld met diezelfde key.
Je kan wel degelijk bij de data, want je beheert de javascript code die de decryptie doet.
Waar het de/encrypten plaats vindt doet niet veel ter zake.
Dit is trouwens ook een conclusie die de rechter kan trekken, als het om auteursrechten gaat.
Waar het de/encrypten plaats vindt doet niet veel ter zake.
Dit is trouwens ook een conclusie die de rechter kan trekken, als het om auteursrechten gaat.
Nee, volgens mij niet want javascript draait alleen in de browser en mag dan geen sleutel terugsturen natuurlijk, of dit wel of niet gebeurt ligt aan de code die handmatig gecontroleerd kan worden.
Dus wat jij zegt kan maar hoeft niet en is niet de bedoeling alleen in het geval van een infectie natuurlijk.
De data wordt alleen in de browser dus lokaal versleuteld/ontsleuteld en de server levert alleen het algoritme plus de versleutelde data aan en de browser versleuteld de data weer voordat het geupload wordt naar de server.
Dit is naar mijn mening net iets veiliger omdat de code in te lezen is door de gebruiker, als die Javascript kan lezen natuurlijk.
Dus wat jij zegt kan maar hoeft niet en is niet de bedoeling alleen in het geval van een infectie natuurlijk.
De data wordt alleen in de browser dus lokaal versleuteld/ontsleuteld en de server levert alleen het algoritme plus de versleutelde data aan en de browser versleuteld de data weer voordat het geupload wordt naar de server.
Dit is naar mijn mening net iets veiliger omdat de code in te lezen is door de gebruiker, als die Javascript kan lezen natuurlijk.
ja maar waarom? Wat zou je als webmaster er aan hebben om in je eigen code te gaan zitten rommelen zodat je lekker in de files van je gebruikers kijken kan? Slaat nergens op. Als je het echter van de andere kant bekijkt zul je zien dat het juist wat veiliger is. Server stuurt browser data + methode om data te ont- / ver-sleutelen en zegt "veel geluk er mee".
De browser ont- / ver-sleutelt de data, dat houdt in dat er nog maar op één plek de data in gezien kan worden mits de js niet aangepast is: De browser tussen het ont-en ver-sleutelen van de data. Dat houdt in dat je al de user moet hacken of je moet toegang krijgen tot de server. Echter in de huidige situatie is het ook bij beide gevallen game-over. Je haalt hier echter wel man-in-the-middle attacks mee onder uit want die zien alleen nog maar versleutelde data.
En als je het dan zelfs zeer veilig wilt doen lever je de bestanden / javascript vanaf de server OOK geencrypteerd aan en laat je de browser die ook lekker versleutelen met een uniek verkregen sleutel eerder in de sessie.
Wat denk je dat een hacker doet als hij ziet: Hey! Een decryptie sleutel! Koel, ik ga wachten tot er versleutelde data komt. Die komt dan in de vorm van de versleutelde data en de dan dus versleutelde javascript, hij unlockt het pakket en komt vervolgens een lap javascript en...oh..nog meer versleutelde bestanden...*zucht*.
Simpele redenatie, en om dan het punt nog eens verder te ontwrichten; Je focused je hier alleen maar op een "dropbox"-esc situatie. Dit zou je zeker ook toe kunnen passen op andere gebieden, denk inderdaad aan two-step authenticatie en wachtwoorden niet meer in plain-text over hevelen etc. etc. etc.
De browser ont- / ver-sleutelt de data, dat houdt in dat er nog maar op één plek de data in gezien kan worden mits de js niet aangepast is: De browser tussen het ont-en ver-sleutelen van de data. Dat houdt in dat je al de user moet hacken of je moet toegang krijgen tot de server. Echter in de huidige situatie is het ook bij beide gevallen game-over. Je haalt hier echter wel man-in-the-middle attacks mee onder uit want die zien alleen nog maar versleutelde data.
En als je het dan zelfs zeer veilig wilt doen lever je de bestanden / javascript vanaf de server OOK geencrypteerd aan en laat je de browser die ook lekker versleutelen met een uniek verkregen sleutel eerder in de sessie.
Wat denk je dat een hacker doet als hij ziet: Hey! Een decryptie sleutel! Koel, ik ga wachten tot er versleutelde data komt. Die komt dan in de vorm van de versleutelde data en de dan dus versleutelde javascript, hij unlockt het pakket en komt vervolgens een lap javascript en...oh..nog meer versleutelde bestanden...*zucht*.
Simpele redenatie, en om dan het punt nog eens verder te ontwrichten; Je focused je hier alleen maar op een "dropbox"-esc situatie. Dit zou je zeker ook toe kunnen passen op andere gebieden, denk inderdaad aan two-step authenticatie en wachtwoorden niet meer in plain-text over hevelen etc. etc. etc.
Impliceert dit voorstel echt dat de webserver een JS encryptielibrary moet aanleveren? Volgens mij is het juist de bedoeling om een standaard te creëeren voor een in de browser ingebouwde API.
Daarmee omzeil je ook het probleem van de noodzaak om je private keys in handen te geven van een externe API.
Dan is bijv. het signen van formulierdata mogelijk, maar blijft nog steeds het probleem bestaan dat het aanroepen van die in-browser API toch weer moet gebeuren vanuit code die door de server wordt verstrekt. Als we uitgaan van het voorbeeld van het encrypten van bestanden dan ziet dat er in pseudocode zo uit:
file = GetSelectedFile();
encryptedFile = BrowserEncryptionApi.Encrypt(file, keyIdentifier);
SendFile(encryptedFile);
Niks dat de server ervan weerhoudt om tussendoor de unencrypted file nog even te versturen.
Daarmee omzeil je ook het probleem van de noodzaak om je private keys in handen te geven van een externe API.
Dan is bijv. het signen van formulierdata mogelijk, maar blijft nog steeds het probleem bestaan dat het aanroepen van die in-browser API toch weer moet gebeuren vanuit code die door de server wordt verstrekt. Als we uitgaan van het voorbeeld van het encrypten van bestanden dan ziet dat er in pseudocode zo uit:
file = GetSelectedFile();
encryptedFile = BrowserEncryptionApi.Encrypt(file, keyIdentifier);
SendFile(encryptedFile);
Niks dat de server ervan weerhoudt om tussendoor de unencrypted file nog even te versturen.
Maar de private key kan natuurlijk wel beschermd worden door hardware, bijvoorbeeld een Trusted Platform Module. Het geheim is dan misschien wel lokaal te misbruiken door malware op de server, maar niet te kopiëren voor gebruik elders.Zowel de private als de public key zijn bekend op de webserver.
Wat betreft je idee over de rabo bank, dat klopt niet, want de reader is bedoeld als een second factor (tenminste, bij de rabo bank is dat het geval volgens mij, bij bijv. de abn amro is het de enige vector (en dus redelijk gevaarlijk)).
Maja, ik ben zelf voor verschillende producten bezig geweest met web security en durf te zeggen dat ik redelijk goed op de hoogte ben... maar ik kan noch grote voordelen of nadelen zien van deze API. De voordelen liggen volgens mij vooral aan de kant van echte html5 _applicaties_ (denk bijvoorbeeld aan pastebin die data zou encrypten voordat het naar de server word gestuurd zodat de eigenaar van de server zich ten alle tijden in onschuld kan wassen) waar deze functionaliteiten nu ook al worden gebruikt (via zwaar inefficiente handmatige implementaties) en het nadeel is eigenlijk alleen dat mensen het fout gaan gebruiken of denken dat het het het per definitie veiliger op word (bijv. het idee om een wachtwoord gehashed op sturen om te voorkomen dat een man-in-the-middle het uitleest, maar wat eigenlijk totaal niet opschiet omdat een man-in-the-middle natuurlijk de code van de site kan aanpassen... maar toch ik wel mensen met dit idee zien rondlopen (en in oude applicaties zelfs geimplementeerd gezien) ). In ieder geval, ik weet wel een paar situaties waar dit handig zou kunnen zijn geweest, maar in vergelijking met veel andere API's is deze volgens mij redelijk insignificant.
En trouwens, de gegeven kritiek dat de browser meer gevoelig zou zijn als een desktop client die hetzelfde doet slaat nergens op, want in een desktop client kun je net zo goed backdoors of updates hebben, exact zoals in de browser gebeurt. Waar het waarschijnlijk in zit is dat men (de "crypto" experts) een gevoel hebben dat er een verschil is tussen desktop applicaties en browser applicaties.
Maja, ik ben zelf voor verschillende producten bezig geweest met web security en durf te zeggen dat ik redelijk goed op de hoogte ben... maar ik kan noch grote voordelen of nadelen zien van deze API. De voordelen liggen volgens mij vooral aan de kant van echte html5 _applicaties_ (denk bijvoorbeeld aan pastebin die data zou encrypten voordat het naar de server word gestuurd zodat de eigenaar van de server zich ten alle tijden in onschuld kan wassen) waar deze functionaliteiten nu ook al worden gebruikt (via zwaar inefficiente handmatige implementaties) en het nadeel is eigenlijk alleen dat mensen het fout gaan gebruiken of denken dat het het het per definitie veiliger op word (bijv. het idee om een wachtwoord gehashed op sturen om te voorkomen dat een man-in-the-middle het uitleest, maar wat eigenlijk totaal niet opschiet omdat een man-in-the-middle natuurlijk de code van de site kan aanpassen... maar toch ik wel mensen met dit idee zien rondlopen (en in oude applicaties zelfs geimplementeerd gezien) ). In ieder geval, ik weet wel een paar situaties waar dit handig zou kunnen zijn geweest, maar in vergelijking met veel andere API's is deze volgens mij redelijk insignificant.
En trouwens, de gegeven kritiek dat de browser meer gevoelig zou zijn als een desktop client die hetzelfde doet slaat nergens op, want in een desktop client kun je net zo goed backdoors of updates hebben, exact zoals in de browser gebeurt. Waar het waarschijnlijk in zit is dat men (de "crypto" experts) een gevoel hebben dat er een verschil is tussen desktop applicaties en browser applicaties.
[Reactie gewijzigd door David Mulder op donderdag 27 december 2012 21:04]
Datzelfde is ook van toepassing op een dropbox client die de data encrypt, want wat jij omschrijft is dat er OF een backdoor in de code zit OF dat ze een update pushen die de functionaliteit toeveogd. Wat dus *exact* hetzelfde is als in de browser.
Op dit item kan niet meer gereageerd worden.
Onderwerpen
Populair: Tablets Samsung Websites en communities Mobiele telefoons Google Sony Games Microsoft Consoles Microsoft Xbox One
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
