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.760 •

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)

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 27 december 2012 20:28]

Waarom alleen de Windows API?
Dat weet je toch! Linux en Mac zijn niet te hacken en compleet virus-vrij. ;-)
Nee, da's alleen mac. Die is unhackable, compleet immuun voor virussen en ge kunt er uw haar mee kammen...
en fastfood bestellen
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).
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...
Nee, want de prive sleutel wordt bewaard door een trusted 3rd party (zoals verisign).
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.
Zowel de private als de public key zijn bekend op de webserver.
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.
Wat jij beschrijft is de taak van een Hardware Security Module (HSM), een TPM is voor clientzaken bedoeld als schrijfencryptie en het voorkomen dat malware zich in het systeem kan nestelen (denk aan rootkits).
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.
@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).
diginotar anyone? of waren we dat even vergeten?! never trust a 3rd party
SSL encrypt inderdaad ook, maar SSL is veel meer. Omdat SSL-certificaten alleen door je browser worden vertrouwd wanneer ze zijn uitgegeven door een trusted-party (zoals diginotar tot een tijdje geleden), garanderen ze dat je echt met mijn.ing.nl praat en niet met try.to.get.your.money.ru. SSL is daarom veel minder gevoelig voor misbruik. Het gaat alleen mis wanneer een vertrouwde partij als diginotar gehackt wordt. SSL heeft wel een paar nadelen:
- Een SSL certificaat aanvragen kost (vaak) geld
- Met meerdere domeinen op dezelfde server hosten is lastig (je moet meerdere ip-adressen hebben, of de domeinen moeten allemaal op hetzelfde eindigen zoals bij *.tweakers.net).

De cryptography-api heeft deze nadelen niet.
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.
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.
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 :?
Omdat je bepaalde gegevens al geencrypt wil voordat het op de server aankomt ?
Ook: moderne CPU's hebben specialistische encryptie-units om de benodigde encrypties zeer energie-efficient uit te voeren.
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 :P
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
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.
Maar daar is weer genoeg aan te beveiligen; hashen van de javascript, waarbij de correcte hash in de browser of het OS staat - zoals nu ook met SSL certificaten. Daarnaast, als de JS van een bank niet te vertrouwen is, zijn de banken van nu ook niet te vertrouwen; voor zover ik weet staat er altijd wel een scriptje op de pagina waar je je code in mag vullen. En zelfs als ze dat niet hebben, dan heb je nog browser-addons die met wat geluk er ook bij kunnen (alhoewel ik dat niet zeker weet, waarschijnlijk kunnen addons niet bij https-pagina's)
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!
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]

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:
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.
http://www.wired.com/threatlevel/2012/10/megaupload-mega/

[Reactie gewijzigd door Soldaatje op 27 december 2012 19:07]

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.
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.
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.
Het punt is dat die code pas handmatig gecontroleerd wordt als het kwaad al is geschiedt. Je sleutel is dan al bekend. Of controleer jij elke js-code die je download? En als die code alleen naar bepaalde clients gestuurd wordt? En alleen op bepaalde tijden?
Niemand leest die code (doe je dat wel eens?), en daarbij kan die code per keer en per gebruiker verschillen (of gemanipuleerd) zijn. Ondek dat maar eens.
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.
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.
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.
Je stelt "mits je js code niet is aangepast". Dat is nu juist de crux.

Je decryptiesleutel aan een onbekend stuk JS code geven (want dat doe je) is gewoon niet zo veilig als de data zelf lokaal en buiten de browser te encrypten alvorens deze naar de server te sturen.
Die JS aanpassing kan heel lokaal zijn en alleen voor jou. Dat is dus anders dan externe encryptiesoftware die door iedereen gedownload wordt maar wel door sommigen gechecked (OSS).

Wat de webmaster er aan heeft? Wie weet. Misschien hebben ze de Patriot Act wel op zijn bordje gegooid. Misschien is hij of de site op een andere manier gecompromitteerd.
(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]

Precies, bak het in de browser library in, dat is een 3e partij en niet in beheer van de website.

Je neemt verder aan dat de sleutel niet naar de webserver wordt verstuurd. Dat is ook de aanname die de gebruiker doet, maar juist een kwaadwillende webmaster of hacker past de JS code aan zodat deze wel wordt doorgestuurd.
De sleutel EN de data zijn op dat moment op dezelfde plek, in de verkeerde handen.
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.
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.
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.
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.
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.
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.
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]

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.
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.
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.
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.

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