Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Je kunt ook een cookievrije versie van de website bezoeken met minder functionaliteit. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , reacties: 49, views: 23.726 •

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.

W3C (World Wide Web Consortium) logo nieuw zonder lettersTijdens 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)

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.

[Reactie gewijzigd door David Mulder op 27 december 2012 21:04]

Het probleem is dat als je code in javascript in de browser uitvoert, dit volledig te manipuleren is zonder ingewikkelde code injection. Om een stom voorbeeld te geven: niets let je om F12 te drukken, een breakpoint te zetten vlak voor de server call en vanuit de console dezelfde API aan te roepen om heel andere gegevens klaar te zetten. Als alles client side gedaan wordt maak je het een hacker een stuk gemakkelijker dan als je alleen resultaten kan behalen door beide machines te manipuleren of er tussenin te gaan zitten.

Je kan het vast ook wel redelijk veilig gebruiken, maar ik ben bang dat dit programmeurs verleidt tot zwakke oplossingen, met dit soort gevolgen:
http://webwereld.nl/nieuw...-eat-nl--eten-gratis.html
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.

[Reactie gewijzigd door elmuerte op 27 december 2012 18:34]

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.
(dit was een reactie op Durandal)

Het idee van encryptiealgoritmen is juist dat de code die de encryptie en decryptie doet volledig openbaar mag zijn (het is toch niet echt geheim hoe AES werkt), maar dat het kunnen lezen van versleutelde gegevens volledig afhangt van de geheimhouding van de sleutel. Als aan de zijde van de client de sleutel wordt gebruikt om de data te versleutelen en deze sleutel wordt nooit naar de webserver gestuurd, dan kan de webserver dus gewoon niet bij de data. Dat is toch wel echt een andere situatie dan wanneer het encrypten aan de kant van de webserver gebeurt, want dan kan de server wel bij de data.

Op een gegeven moment zou je je ook nog voor kunnen stellen dat de javascript code die de encryptie/decryptie doet gestandaardiseerd wordt en dat browsers gewoon de library ingebakken krijgen. Op die manier zou je in elk geval het probleem dat nu wordt aangekaart kunnen omzeilen.

[Reactie gewijzigd door sirdupre op 27 december 2012 21:57]

Op dit item kan niet meer gereageerd worden.



Populair:Apple iPhone 6Samsung Galaxy Note 4Apple iPad Air 2FIFA 15Motorola Nexus 6Call of Duty: Advanced WarfareApple WatchWorld of Warcraft: Warlords of Draenor, PC (Windows)Microsoft Xbox One 500GBTablets

© 1998 - 2014 Tweakers.net B.V. Tweakers is onderdeel van De Persgroep en partner van Computable, Autotrack en Carsom.nl Hosting door True

Beste nieuwssite en prijsvergelijker van het jaar 2013