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. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 49 reacties

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)

Reactiefilter:-149047+138+25+30
Moderatie-faq Wijzig weergave
De methode is wel goed die je omschrijft.
Maar kan het niet op een dieper niveau afgedwongen worden om programmeer fouten te voorkomen? Zoals in de programmeertaal zelf. Kortom het gewoon standaard maken.
ik snap niet wat het probleem is, je hoeft de keys niet op te slaan in een database. je zou je public key in een header kunnen zetten en die voor de duur van de sessie behouden. Is de sessie afgelopen komt er een httpmelding die weer zegt de sessie was afgelopen hier heb je mijn public key geef mij jouw public key als je de volgende pagina opvraagd.
Eigenlijk moeten de gegevens al door de database ge-encrypted/de-crypted worden.
Dat zou standaard moeten zijn. Daarnaast nog via de programmeertaal.

Voordel is dat bij diefstal de data standaard is encrypted wat nu bijna nergens het geval is.
Overigens onderkennen de opstellers van de API weldegelijk beveiligingsproblemen met de API. Zie puntje 5.2 en 6 van de API documentatie. Wat ik wel in de de beschrijving van W3C mis is het scenario van elmuerte. Die hoort eigenlijk thuis in het kopje "Security considerations for endusers" maar dat hoofdstuk is niet in de draft aanwezig.
en fastfood bestellen
diginotar anyone? of waren we dat even vergeten?! never trust a 3rd party
In the end komt het neer op vertrouwen. Als je de aanbieder van de server niet vertrouwd en daarom alleen geŽncrypteerde data upload. Waarom zou je dan wel dezelfde aanbieder vertrouwen met het leveren van de software die de encryptie regelt (de cliŽnt software)? Dat die cliŽnt software een W3C API gebruikt is niet zo heel relevant. Aangezien de server leverancier de cliŽnt software heeft gebouwd weet deze aanbieder ook hoe je deze aanspreekt, of hoe je eventuele backdoors gebruikt (die deze aanbieder zelf heeft aangebracht).

Als je veilig wilt zijn moet het W3C encryptie API zich aan het cross-origin beleid houden. Dan kan een cliŽnt van trusted.com gebruikt worden en het versleutelde pakketje naar not-trusted.com gestuurd worden.

Kortom, als je de server niet vertrouwd, vertrouw dan ook niet de pagina die de gegevens versleuteld van diezelfde server. Iets dat gewoon common sense zou moeten zijn.
Allereerst: dank voor je uitleg, het maakt het iets duidelijker wat nu precies als het probleem ervaren wordt.

Ik denk echter dat het een vergezocht argument is. De situatie wordt er niet onveiliger op. Mensen die dat willen, kunnen nog altijd, net als nu, gebruik maken van een 3rd party, lokale encryptie voordat ze gebruik maken van webservices. Maar hoeveel mensen doen dat nu echt in de praktijk?

Ik denk dat in de praktijk grote schares mensen nu al gebruik maken van deze services zonder zich echt te bekommeren om de risicos. De data van deze mensen is ook nu al onveilig, veel onveiliger dan hij is als een dergelijke encryptie API wel wordt toegepast. In dit geval is namelijk alle data en alle sleutels van alle klanten bekend op de server, Šls die data al encrypted is opgeslagen. Dat betekent dat je bij een hack alle data in handen kan vallen van de hackers, in plaats van alleen de data van de personen die inloggen in de periode tussen het plaatsen van de door jou beschreven JS hack en het ontdekken en offline halen ervan. Dat scheelt nogal wat.

Je moet als gebruiker altijd vertrouwen hebben in de aanbieder van een dienst of software pakket. Je kan eenvoudigweg niet alles controleren. Dat geldt nu, en dat blijft gelden. Hoe weet je zeker dat er geen backdoor zit in de encryptiesoftware die je gebruikt? Hoe weet je zeker dat je OS veilig is? Het korte antwoord is: dat weet je niet, maar daar vertrouw je op.
Nee, want de prive sleutel wordt bewaard door een trusted 3rd party (zoals verisign).
Maakt niks uit.

Jij hebt het over een browser exploit, waardoor gevoelige windows dingen hackbaar zouden zijn. Deze hacks gebeuren meestal door Javascript code. Nu zou je eerst de Javascript kunnen encrypten, voordat het op de client komt (waar ik het nut niet van inzie), maar wil je het echt gebruiken (wat je wel wil met javascript), moet je het toch weer decrypten (mbv Javascript code, dus niet alle code kun je encrypted sturen, dus het is al sowieso nutteloos) en er een eval(..); overheen gooien (nogmaals: geen idee waarom je dit zou willen doen). En de code die kan exploiten is er gewoon weer.

En dan nog maak het niks uit, want een geinfecteerde server kan alle javascript die hij wil naar je sturen.

(Moraal van het verhaal: Houd je browser up-to-date).
De gehele SSL implementatie op XP ondersteund het niet. Daarmee alle browsers op XP die gebruik maken van de SSL API's van windows dus ook niet.

Voorlopig gaat SNI dus geen vogelvlucht nemen.
@Belgar:

Niet alleen wordt de private key niet bewaard door een 3rd party als Verisign, zoals reeds gemeld door anderen, hij is niet eens bekend bij ze.

Met de CSR stuur je alleen je public key op een checksum van de private key en een LDAP pad (waarbij het met name gaat om CN=naam.vande.site.com), dit wordt ondertekend met de private key van de CA. Die ondertekening is op zijn beurt te controleren met de public key van de CA (en die zit in de browsers / OS).
Maar datzelfde is ook allemaal mogelijk met desktop applicaties, code injection staat gelijk aan fake updates. Het enige wat je nog zou kunnen zeggen is dat javascript gevaarlijker is omdat de broncode niet gecomplieerd is en dus makkelijker te manipuleren... maar dat is dan security through obscurity... and volgens mij hebben we als security wereld geaccepteerd dat dat geen echte toegevoegde waarde heeft.
Nope, de prive sleutel wordt gewoon op de web-server bewaard. Bij het opzetten van de verbinding controleert je browser alleen of de uitgever een legitieme uitgever is en of de sleutel overeen komt met de FQDN.
Waarom alleen de Windows API?
Dat je met meerdere domeinen meerdere IP-nummers nodig hebt is al een tijdje achterhaald (zie: Server Name Indication).
Het wordt over het algemeen nog steeds gedaan omdat het makkelijker is en omdat hele oude browsers (pre IE 7) meerdere SSL hosts op 1 IP niet ondersteunen.
Klopt, al is SSL soms niet mogelijk op de server. Ik zie deze API graag tegenmoed.
NIet dat ik de client zou vertrouwen (die wordt nog steeds gechecked), maar om MIT-aanvallen moeilijker te maken op non-SSL servers.
Ik zie niet echt in wat het toevoegt aan SSL. Encryptie in javascript lijkt me vrijwel nutteloos. Als server mag je nooit de gegevens die van de client komen volledig vertrouwen, ook al zijn ze encrypted ... ze zijn immers mogelijk gemanipuleerd (desnoods middels Firebug). De gegevens zullen nog steeds gedecrypt moeten worden, gevalideerd en vervolgens weer opnieuw geencrypt.

[Reactie gewijzigd door HerrPino op 28 december 2012 09:08]

Op dit item kan niet meer gereageerd worden.



LG G4 Battlefield Hardline Samsung Galaxy S6 Edge Microsoft Windows 10 Samsung Galaxy S6 HTC One (M9) Grand Theft Auto V Apple iPad Air 2

© 1998 - 2015 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True