Front-end encryptie - veilig (genoeg)?

[b2vjfvj75gjx7]

Momenteel ontwikkel ik (een soort van) embedded software.

Ik zeg "een soort van", omdat het officieel niet embedded is;

Het is een app, geschreven in HTML / JS met een Cordova-wrapper (die zorgt er voor dat de "app" functioneert binnen een platform-agnostische browserview).

Feitelijk bouw je dus een soort mini-website, maar heb je (dankzij Cordova) wel toegang tot hardware API's van de device waarop alles draait (al is dat in dit geval niet van belang).

De app wordt uiteindelijk geïnstalleerd op een x-aantal tablets (Android 4, 5 / 6 en Windows 10 (phone / tablet).

Al deze devices zijn fysiek niet toegankelijk, behalve het touch-screen; de hardware-buttons zijn simpelweg fysiek gesloopt, of op andere wijze ontoegankelijk gemaakt (speciale case, die bv. de tablets in een soort teflar-rubbed hoesje plaatst).

Kortom; de software draait in een app - op een device dat enkel een touchscreen kent.

Via de touchscreen kan men keuzes maken - deze keuzes worden geregistreerd en lokaal opgeslagen in de local-storage (HTML5 equivalent van een cookie) van de app.

Nadat de data is opgeslagen, wordt er via HTTPS verbinding gemaakt (over een afgesloten en beveiligd WIFI kanaal) met een remote-server.

De app stuurt (via AJAX) vervolgens de data naar server - en nu komt het...

...ik wil de data niet als plain-text verzenden; het is weliswaar niet privacy-gevoelig, maar beter safe than sorry.

Om die reden heb ik gezocht naar een basis-vorm van encryptie; ik ben echter beperkt tot wat de app op lokaal niveau kan doen;

De app is 100% javascript, qua functionaliteit - dus ik kan geen PHP / ASP / .NET encryption libraries aanroepen.

Nu heb ik een encryptie-methode gevonden (open source) die als volgt werkt;

Je hebt een private-key, bv "4!2#3A~f_:qXa" - en die is voor alle devices hetzelfde (de app wordt universeel uitgerold, dus elke device ontvangt dezelfde app én dus dezelfde "private-key".

Tegelijk kan de operator (via het touch-screen) een extra key invoeren, die dus wel per device anders is; "~$$Xa_fa?3".

Dit levert dus een sleutel op, van (bv.) 32 tekens (deels uniek per device, deels shared - maar de volledige key is altijd uniek).

Met deze key kan ik de data versleutelen. De data bevat een eenvoudige, numerieke array van gestures / swipes / touches op het touchscreen, bv [1, 2, 16, 3, 5, 1, 5 , 4].

Het gaat dus om deze string die naar de server verzonden moet worden, en het liefst dus encrypted. Via de encryptie-library levert bovenstaande array iets op als dit;

KQ7QgfewNxsgtY15xKv6f+eqGtMxNQFvjwrTF7QmfaN8bK8O7usQp5cYpShZt0hTtXZhjeCplTo149bXC/ylmr9IPVP6sGCIIUaTUsQJzBbE8+qcd/wqvEvVK78lDmZtaS2oBrZEd9UV4Qk15iPp1S11VMBLVgu7yfhhT7RUbmlPbLSJQ9BVhDy3Sd5OmR86htonIw==

Aan de kant van de server kan men die string weer decrypten, door zowel de private-key als universal-key te mergen en deze string er door heen te halen.

Als er ook maar één van de 32 tekens uit de sleutel niet klopt - levert het een onleesbare string op, dus de key moet 100% matchen met de afzender.

Het werkt perfect... maar hoe veilig is deze werkwijze?

Overigens kan ik natuurlijk wel melden welke encryption-library ik gebruikt heb - maar ik wil eerst zo neutraal mogelijk achterhalen of bovenstaande string überhaupt (met enkel de vermelde kennis) gebroken kan worden.

Je kan natuurlijk de tablet fysiek van de muur rukken, de .APK / .XAP er uit zien te pulken - deze decompilen, het standaardwachtwoord achterhalen, proberen om het unieke wachtwoord te achterhalen (dat kan enkel via het touchscreen, als je binnen x-seconden een pattern van 16 swipes doet in een unieke volgorde), etc...

Ik heb het idee, dat als je bovenstaande string al kan achterhalen (networksniffer, lekke database, etc...) maar je de volledige key niet kent - het toch redelijk secure is?

Natuurlijk, het blijft javascript - dus zowel key als encryptie zitten "in" de app, maar door omstandigheden kan dit niet anders.

Het gaat hier ook niet om Fort Knox-data, anders zou ik het niet eens uitgevoerd hebben - maar ik wil het wel zo veilig mogelijk verzenden allemaal...

Overigens worden de apps niet via de stores gedistribueerd, maar via gesloten kanalen en worden ze op afgesloten plekken op de devices gezet. Deze worden daarna gesealed en nog voorzien van extra software die alles locked (je kan op geen enkele manier buiten de app komen, de devices restarten, het OS benaderen, etc...).

---

- edit - De app wordt geïnstalleerd bij een klant, die vervolgens zijn / haar klanten de app laat gebruiken om informatie te achterhalen.

Dus de klanten van de klant voeren de data in (via het touchscreen), de klant zelf ontvangt deze weer (via een dashboard aan de kant van de server).

De klant zelf mag de data natuurlijk wel inzien, het gaat er meer om dat de klanten van de klant / toevallige passanten die fysiek toegang tot de tablet hebben, niet ongezien alle data kunnen uitlezen / sniffen / opvangen / etc...

[ Voor 5% gewijzigd door b2vjfvj75gjx7 op 10-06-2016 13:48 . Reden: Werksituatie toegevoegd (klant, klanten, etc...). ]

[Ventieldopje]

De app stuurt (via AJAX) vervolgens de data naar server - en nu komt het...

...ik wil de data niet als plain-text verzenden; het is weliswaar niet privacy-gevoelig, maar beter safe than sorry.

Eigenlijk wil je een soort HTTPS over HTTPS doen? Normaliter wordt client-side encryption toegepast om data veilig op te slaan op de server. Daarbij heeft de client vaak een eigen key zodat de hostende partij echt niet bij de data kan. Wat je nu probeert te doen lijkt me een ontzettende verspilling van tijd en moeite.

Als het gaat om data lokaal opslaan, dan is het wat anders maar dat lijkt mij hier niet aan de orde.

De klant zelf mag de data natuurlijk wel inzien, het gaat er meer om dat de klanten van de klant / toevallige passanten die fysiek toegang tot de tablet hebben, niet ongezien alle data kunnen uitlezen / sniffen / opvangen / etc...

Je gebruikt toch HTTPS? Het hele idee daarvan is dat het veilig over het lijntje gaat Sniffen of manipuleren gaat dus niet..

[Sleepkever]

b2vjfvj75gjx7 schreef op vrijdag 10 juni 2016 @ 13:38:
...

Nadat de data is opgeslagen, wordt er via HTTPS verbinding gemaakt (over een afgesloten en beveiligd WIFI kanaal) met een remote-server.

...ik wil de data niet als plain-text verzenden; het is weliswaar niet privacy-gevoelig, maar beter safe than sorry.

Als jij de data via https verzend verzend je het sowieso niet als plain text

Ik snap je zorgen, als je echter zorgt dat je https verbinding goed is, dan is er verder weinig aan de hand.
Zorg dat je certificaten goed zijn en zorg ervoor dat je applicatie ook daadwerkelijk die certificaten valideert of deze valide zijn (geen self signed toestaan, certificaat matched bij domein, etc). Als je dat doet heb je de meeste man in the middle attacks al voorkomen.
Waarschijnlijk gebeurt dit by default al, je kan dit makkelijk zelf een keer proberen door een proxy op te zetten en je applicatie daardoorheen te forceren. Of een keer een server uit proberen met een invalide (self signed) certificaat.

Alle encryptie daar boven op is leuk maar verder niet heel interessant meer.
Ik zie sowieso al een fundamentele flaw in de flow die jij beschrijft. Zowel de server als de client hebben dezelfde "private" key en universal key. Hoe krijg je die van de ene plek naar de ander? Worden die eerst in plaintext mee verstuurd aan het begin van de communicatie? Dan ben je natuurlijk nog geen steek verder want dan stuur je het bericht misschien wel versleuteld op, maar de sleutels in datzelfde bericht mee.

Wellicht is het leuk om je een keer in te lezen in Asymmetrische Cryptografie waar SSL (en dus HTTPS) gebruik van maken.

[ACM]

b2vjfvj75gjx7 schreef op vrijdag 10 juni 2016 @ 13:38:
...ik wil de data niet als plain-text verzenden; het is weliswaar niet privacy-gevoelig, maar beter safe than sorry.

In dat geval zou ik vooral moeite doen om je https-opzet goed te doen. Als je dat niet voldoende vindt, zou je met clientside certificaten kunnen werken (standaardfeature van https), die je dan per device uitdeelt. Wel meer gedoe, maar ook wat meer veiligheid; vooral dat ook niemand meer zonder een certificaat bij je systeem wat kan doen.

De app is 100% javascript, qua functionaliteit - dus ik kan geen PHP / ASP / .NET encryption libraries aanroepen.

Maar wellicht kan je wel de Web Cryptography API gebruiken?
Zoals gezegd is het waarschijnlijk nogal dubbelop, ik zou vooral moeite steken in het juist implementeren van HTTPS. En dat gezegd hebbende, de standaardfunctionaliteit is misschien al de juiste wijze.

Nu heb ik een encryptie-methode gevonden (open source) die als volgt werkt;

Het grootste probleem van javascript-cryptography is dat er eigenlijk geen garantie is dat de code niet gemodificeerd is. Met browsers heb je dat ook niet echt, maar in javascript kan je vrij triviaal functionaliteit aanpassen als 'aanvaller'. Er zijn minimaal twee gebruikelijke manieren om dat te faciliteren:
- de man in the middle, dit voorkom je vrij goed met https
- via exploits op de devices... maar dan is effectief toch alles al standaard verdacht

[b2vjfvj75gjx7]

Sleepkever schreef op vrijdag 10 juni 2016 @ 14:32:
[...]

Als jij de data via https verzend verzend je het sowieso niet als plain text

Ik snap je zorgen, als je echter zorgt dat je https verbinding goed is, dan is er verder weinig aan de hand.
Zorg dat je certificaten goed zijn en zorg ervoor dat je applicatie ook daadwerkelijk die certificaten valideert of deze valide zijn (geen self signed toestaan, certificaat matched bij domein, etc). Als je dat doet heb je de meeste man in the middle attacks al voorkomen.
Waarschijnlijk gebeurt dit by default al, je kan dit makkelijk zelf een keer proberen door een proxy op te zetten en je applicatie daardoorheen te forceren. Of een keer een server uit proberen met een invalide (self signed) certificaat.

Alle encryptie daar boven op is leuk maar verder niet heel interessant meer.
Ik zie sowieso al een fundamentele flaw in de flow die jij beschrijft. Zowel de server als de client hebben dezelfde "private" key en universal key. Hoe krijg je die van de ene plek naar de ander? Worden die eerst in plaintext mee verstuurd aan het begin van de communicatie? Dan ben je natuurlijk nog geen steek verder want dan stuur je het bericht misschien wel versleuteld op, maar de sleutels in datzelfde bericht mee.

Wellicht is het leuk om je een keer in te lezen in Asymmetrische Cryptografie waar SSL (en dus HTTPS) gebruik van maken.

Ik weet weinig / niets van beveiliging / encryptie (dat laat ik liever aan anderen over).

Het gaat inderdaad per definitie over een (goed) beveiligde HTTPS-lijn, met goede certificaten.

Echter, de data wordt niet alleen verzonden (van een tablet op het kantoor van een willekeurige klant, naar de server van mijn opdrachtgever), maar ook bewaard in een database (bij de opdrachtgever).

Natuurlijk is die database ook beveiligd (niet door mij, maar door iemand die er wel verstand van heeft).

Als iemand ongeoorloofd toegang tot de database weet te krijgen (die overigens niet publiekelijk via een browser bereikbaar is), dan wil ik toch voorkomen dat men iets met de data kan doen.

Ze mogen van mij alle tables / cells inzien - maar zolang alle opgeslagen data encrypted is, kan je er niet mee... tenminste - dat is eigenlijk mijn vraag.

Dus het gaat niet enkel om het versturen, maar ook om het bewaren en achteraf in kunnen zien.

Wat betreft die flow - ik ben inderdaad op zoek naar flows in mijn denkwijze.

Klant en opdrachtgever delen dezelfde key (tenminste; de opdrachtgever weet welke key de klant invoert in zijn app), maar deze kennis wordt niet verzonden op welke wijze dan ook.

De opdrachtgever haalt een nieuwe klant binnen, fietst (met een dure auto) naar de klant, hangt daar de tablet + app tegen de muur en voert de private-key in.

Daarna start de app op, kijkt welke key hij moet gebruiken en begint alles te verzenden (enkel de data, niet de key!).

Mijn opdrachtgever fietst (met een dure auto) weer terug naar zijn kantoor en ontvangt daar alle data van zijn klant. Om het te kunnen lezen, gebruikt hij dezelfde key als hij heeft ingevoerd op de tablet.

Natuurlijk zijn het complexe keys en zullen er uiteindelijk honderden van aangemaakt worden; maar die bewaard hij weer op een andere lokatie, in een Keepass / Lastpass safe of iets dergelijks.

Waar het mij om gaat is dat de opgeslagen data "soort van" encrypted verzonden / opgeslagen / geparsed wordt en niet voor jan en alleman direct inzichtelijk.

Overigens gaat het niet om privé-gegevens, financiële data, etc... dan had ik het wel uitbesteed - het gaat meer om inzichten van hoe mensen klikken op een tablet (soort UX (usability experience) / AE (accessibility experience) / UI (user interface) onderzoek, zeg maar).

Maar ik wil voorkomen, dat als de database ooit uitlekt, men kan roepen dat het direct leesbaar was...

[b2vjfvj75gjx7]

ACM schreef op vrijdag 10 juni 2016 @ 14:53:
[...]

In dat geval zou ik vooral moeite doen om je https-opzet goed te doen. Als je dat niet voldoende vindt, zou je met clientside certificaten kunnen werken (standaardfeature van https), die je dan per device uitdeelt. Wel meer gedoe, maar ook wat meer veiligheid; vooral dat ook niemand meer zonder een certificaat bij je systeem wat kan doen.


[...]

Maar wellicht kan je wel de Web Cryptography API gebruiken?
Zoals gezegd is het waarschijnlijk nogal dubbelop, ik zou vooral moeite steken in het juist implementeren van HTTPS. En dat gezegd hebbende, de standaardfunctionaliteit is misschien al de juiste wijze.


[...]

Het grootste probleem van javascript-cryptography is dat er eigenlijk geen garantie is dat de code niet gemodificeerd is. Met browsers heb je dat ook niet echt, maar in javascript kan je vrij triviaal functionaliteit aanpassen als 'aanvaller'. Er zijn minimaal twee gebruikelijke manieren om dat te faciliteren:
- de man in the middle, dit voorkom je vrij goed met https
- via exploits op de devices... maar dan is effectief toch alles al standaard verdacht

Thx - het beveiligen van de database / opzetten van HTTPS verbinding wordt gedaan door een gecertificeerde partij (voor wat het waard is...).

Aan mij de nobele taak een app te bouwen (in Cordova, dus 100% javascript - deze keuze is ingegeven door vele factoren) die de data verzameld en verstuurd.

Om het niet plain te verzenden / af te leveren bij de database, heb ik dus moeten kiezen voor een front-end encryptie die gebruik maakt van TEA.

Wikipedia: Tiny Encryption Algorithm

http://www.movable-type.co.uk/scripts/tea-block.html

Dit werkt perfect, op basis van een secret-key - en is volgens mij afdoende... wellicht probeer ik Roomser dan de paus te zijn - maar het inbouwen er van was een uur werk, dus qua tijd maakt het weinig uit.

Hoe de klant de data vervolgens opslaat in zijn database, is aan de andere partij; wellicht dat zij er wéér een Rainbow / Salted / Hashed algoritme overgooien en ben ik gewoon dom bezig...

...overigens is het hele proces ook een stuk klantbegeleiding - zelfs als het nergens over gaat, kan het een (vals) goed gevoel geven dat men aan de beveiliging heeft gedacht; het gaat hier dan niet om de echte / functionele beveiliging, maar meer marketingpraat rondom het product (waar je nooit op moet vertrouwen).

[ Voor 6% gewijzigd door b2vjfvj75gjx7 op 10-06-2016 15:04 ]

[b2vjfvj75gjx7]

ACM schreef op vrijdag 10 juni 2016 @ 14:53:
[...]

In dat geval zou ik vooral moeite doen om je https-opzet goed te doen. Als je dat niet voldoende vindt, zou je met clientside certificaten kunnen werken (standaardfeature van https), die je dan per device uitdeelt. Wel meer gedoe, maar ook wat meer veiligheid; vooral dat ook niemand meer zonder een certificaat bij je systeem wat kan doen.


[...]

Maar wellicht kan je wel de Web Cryptography API gebruiken?
Zoals gezegd is het waarschijnlijk nogal dubbelop, ik zou vooral moeite steken in het juist implementeren van HTTPS. En dat gezegd hebbende, de standaardfunctionaliteit is misschien al de juiste wijze.


[...]

Het grootste probleem van javascript-cryptography is dat er eigenlijk geen garantie is dat de code niet gemodificeerd is. Met browsers heb je dat ook niet echt, maar in javascript kan je vrij triviaal functionaliteit aanpassen als 'aanvaller'. Er zijn minimaal twee gebruikelijke manieren om dat te faciliteren:
- de man in the middle, dit voorkom je vrij goed met https
- via exploits op de devices... maar dan is effectief toch alles al standaard verdacht

http://caniuse.com/#feat=cryptography had ik onderzocht - echter het moet draaien vanaf Android 4 (tot nu) en Windows 8 (tot nu)... dus dat ging hem niet worden...

[Verwijderd]

b2vjfvj75gjx7 schreef op vrijdag 10 juni 2016 @ 15:05:
[...]


http://caniuse.com/#feat=cryptography had ik onderzocht - echter het moet draaien vanaf Android 4 (tot nu) en Windows 8 (tot nu)... dus dat ging hem niet worden...

Daarvoor heb je toch Crosswalk?

[b2vjfvj75gjx7]

Verwijderd schreef op vrijdag 10 juni 2016 @ 15:14:
[...]


Daarvoor heb je toch Crosswalk?

Had ik ook voorgesteld, maar het is niet toegestaan plug-ins te installeren in de app;

Het moest zo kaal en basic mogelijk zijn... zelfs jQuery was geen optie (dus alles is plain-vanilla JS geworden).

Sterker nog; de app is voorzien van een zelfgeschreven framework waarbij alle content / design en functies extern worden ingeladen; de app wordt nooit meer geupdate via een .XAP of .APK maar enkel via een set data-instructies vanaf een server...

De app zelf is ook maar 250kb, ofzo (meeste is overhead van Android of Windows zelf) - de hele code is 5kb groot...

Die code verbindt vervolgens met een externe server, identificatie vindt plaats / hand-shacking protocol en daarna update de app zichzelf / leert hij direct nieuwe functies aan...

...om die reden wilden we ons niet afhankelijk maken van plug-ins / services van derden.

Het is nu zelfs zo gemaakt, dat de app alle instructie-set opslaat in localStorage (plain text) en dat aanroept als zowel de stroom als internet uitvalt;

Bij een nieuwe opstart, kan hij dan - zonder internet - toch alle instructies uitvoeren door de localStorage te parsen naar functionele scripts;

Op het moment dat er weer internet is, wordt dit gezien en download hij nieuwe instructies; opgeslagen data wordt dan uit de cache gehaald en verzonden naar de server.

Het moest zo fool-proof mogelijk zijn... een web-based app zonder internet, en een tablet zonder stroom (het zijn speciale tablets die stroom halen uit een telefoonlijn, geloof ik - iig. geen standaard electra-netwerk)...

Al met al een leuke puzzel; de "encryptie" was meer een extraatje van mijn kant, een sluitpost - zonder dat ik het een sluitpost wil laten zijn

[ Voor 4% gewijzigd door b2vjfvj75gjx7 op 10-06-2016 15:26 ]

[Orion84]

Hoe wil je precies client side data versleutelen en die versleutelde data richting database sturen, terwijl je aangeeft dat je alleen aan de app werkt en het hele server gebeuren van een andere partij komt?

Ik neem aan dat de data die jij vanuit de app in de database zet ook weer toegankelijk moet zijn voor andere systemen die met die data aan de slag gaan? Dan kan je natuurlijk niet zomaar data die versleuteld is met een door jouzelf bedachte versleuteling in die database zetten, want daar kan dan verder niemand wat mee.

Als je je al druk wilt maken over of die data misschien versleuteld in de database zou moeten staan, dan is dat iets wat je moet bespreken met de partij die de serverkant (en andere applicaties?) beheert.

Voor wat betreft het versleuteld opslaan in de local storage: daar heb ik niet echt kaas van gegeten, maar ik zou zeggen: bekijk even welke risico's er nu eigenlijk precies zijn met die data (hoe zou iemand er bij kunnen komen) en kijk ook even welke mogelijkheden de betreffende tablets bieden voor versleutelen van de opslag.

[Verwijderd]

b2vjfvj75gjx7 schreef op vrijdag 10 juni 2016 @ 14:57:
Als iemand ongeoorloofd toegang tot de database weet te krijgen (die overigens niet publiekelijk via een browser bereikbaar is), dan wil ik toch voorkomen dat men iets met de data kan doen.

Tsja...je kunt nooit 100% zeker zijn - op de server staat ook de code die in staat is de encrypted infomatie uit de database te decrypten, dus als ze FTP-toegang weten te krijgen ben je alsnog het bokje.

Op een gegeven moment moet je gewoon vertrouwen op de methodes die voor bepaalde onderdelen gebruikelijk (en afdoende) zijn en er van uit gaan dat daarmee het geheel afdoende beveiligd is.

Zorg dus dat je database niet extern te benaderen is, en ga niet lopen emmeren met encryptie van de inhoud.

imho.

[b2vjfvj75gjx7]

Verwijderd schreef op vrijdag 10 juni 2016 @ 15:34:
[...]

Zorg dus dat je database niet extern te benaderen is, en ga niet lopen emmeren met encryptie van de inhoud.

imho.

Volgens mij is dat wel een goeie - bedankt! (overigens valt de database niet te benaderen en wordt alles dus via HTTPS verzonden via een afgesloten netwerk).

Wellicht sloop ik de hele "encryptie" er weer uit - maar dan heb ik het in ieder geval onderzocht!

[Verwijderd]

Even uit nieuwsgierigheid, als je het wilt/kunt vertellen - waarom is de data zo gevoelig dat je dit allemaal overweegt?

[Hydra]

Het probleem met encryptie is dat als je er weinig van af weet en er maar dingen bij gaat klussen de kans groot is dat je een schijnveiligheid creëert, of nog erger, de beveiliging zwakker maakt. Je werkt al via HTTPS dus is een man-in-the-middle attack lastig (niet onmogelijk).

Een extra encryptielaag heeft geen zin; die valt of staat al met of je HTTPS verbinding secure is. Zelfs met public-private key encryptie zou een man-in-the-middle attack gewoon betekenen dat ze je een andere (eigen) key zouden sturen. Je schiet er niks mee op.

[BarôZZa]

Een hoop technisch geneuzel hier, maar het lijkt erop dat het concept en van clientside encryptie/end to end encryption in veel gevallen niet geheel wordt begrepen.

Clientside encryptie is nuttig als je wil dat de server niet de data kan decrypten. Je wil dus in geen enkel geval de key naar je server sturen. Dit is nuttig voor zaken als een wachtwoordmanager (zoals Lastpass), waarbij je de wachtwoorden lokaal decrypt met een masterpassword of om bestanden van gebruiker naar gebruiker te versturen (zoals bij Mega) waarbij de versturende en ontvangende partij via een derde weg de key uitwisselen, bij MEGA bijvoorbeeld door een speciale url waarbij de key alleen door browsers wordt opgepakt. MEGA kan op die manier beweren dat ze simpelweg niet weten wat gebruikers op hun server zetten. De uitdaging daarbij is dus om de keys bij de ander te zien krijgen en eventueel om keys in sync te houden als je bijvoorbeeld meerdere sessies hebt.

De manier waarop je het nu hebt opgezet lijkt meer alsof je een toegangskey op elk unieke device zet die je later weer zou kunnen uitzetten (maar waarbij je niet weet of deze is gekopieerd). Met database encyptie is verder ook niets mis, maar dat is afhankelijk van de implementatie en beveiligt op de datalaag (namelijk voor het geval dat ze wel bij de data kunnen, maar niet bij het wachtwoord). In de meeste gevallen vullen deze lagen elkaar aan en sluiten ze elkaar niet uit.

Het is dus ook geen vervanging voor HTTPS, het is beveiliging op een andere laag waarbij het doel moet zijn dat jij als faciliterende partij op geen enkele manier de data van je gebruikers kan inzien. HTTPS moet dus nog steeds gebruikt worden om de verbinding te beveiligen(anders lek je nog steeds informatie over waar het bijvoorbeeld naartoe gaat). Maar zodra je weer allerlei keys gaat beheren op een server en data daar gaat decrypten, dan snap je simpelweg de concepten niet zo goed en dat betekent dat je niet genoeg verstand hebt om de veiligheid van je gebruikers te garanderen.

ACM schreef op vrijdag 10 juni 2016 @ 14:53:
Maar wellicht kan je wel de Web Cryptography API gebruiken?
Zoals gezegd is het waarschijnlijk nogal dubbelop, ik zou vooral moeite steken in het juist implementeren van HTTPS. En dat gezegd hebbende, de standaardfunctionaliteit is misschien al de juiste wijze.


[...]

Het grootste probleem van javascript-cryptography is dat er eigenlijk geen garantie is dat de code niet gemodificeerd is. Met browsers heb je dat ook niet echt, maar in javascript kan je vrij triviaal functionaliteit aanpassen als 'aanvaller'. Er zijn minimaal twee gebruikelijke manieren om dat te faciliteren:
- de man in the middle, dit voorkom je vrij goed met https
- via exploits op de devices... maar dan is effectief toch alles al standaard verdacht

Je geeft eigenlijk juist aan waarom het juist heel veilig kan zijn(als aanvulling op, niet ter vervanging). Als je via SSL het netjes naar de gebruiker verstuurt, dan weet je dat het aan de gebruikerskant is gemodificeerd. Dat beveiligingsrisico bestaat altijd en in dat geval kan je er uberhaubt niks meer tegen doen.

Een andere manier zou overigens een XSS lek op je server kunnen zijn als je een webclient hebt.

Maar de grote garantie is dat data simpelweg niet door de server te decrypten is en je als gebruiker je dus minder zorgen hoeft te maken dat iemand de server hackt en al je documenten heeft. Ook als beheerder van de server/dienst kan dat heel fijn zijn.

In ieder geval is het verre van dubbelop omdat ze totaal verschillende dingen doen.

Beveiliging kan je vaak ook wat eenvoudiger bekijken trouwens:

- Als iemand de laptop van je gebruiker jat of er een backdoor opzet, heeft diegene dan toegang dat de gegevens van de service?
- Als iemand je databaseserver meeneemt, kan diegene dan alle gegevens inzien van je gebruikers?
- Als iemand zowel de databaseserver als de hostingserver incl broncode meeneemt, zijn de gegevens van je gebruiker dan nog veilig?