Hoe data opslaan zonder dat de admin die kan inkijken?

[Verwijderd]

Is het mogelijk om data op een manier op te slaan in een web based applicatie / database zonder dat de administrator van de database de data in leesbaar formaat kan bekijken of decrypteren?
De enige manier die ik zo kan bedenken is werken met een public-private key, maar hoe kan dat op een gebruiksvriendelijke manier die ook door absolute leken zonder problemen kan gebruikt worden, zonder dat er iets op de lokale PC van de gebruiker moet geïnstalleerd worden en zonder het risico te lopen dat de private key verloren raakt? Bovendien is het me niet duidelijk hoe een browser die private key zou kunnen doorkrijgen zonder gebruik te maken van extensies of andere programma's op de PC van de gebruiker.

Zijn er andere, meer gebruiksvriendelijke manieren om dit voor elkaar te krijgen?

Het is niet de bedoeling dat er data verloren gaat als de gebruiker iets zou vergeten of zijn PC zou crashen.

[tiriaq]

Wat je beschrijft bestaat niet, en als je het weet te maken kan je er heel rijk mee worden.
Het enige dat in de buurt komt is een integratie met bijvoorbeeld Dropbox en de private key daar op te slaan, maar ik vermoed dat gebruikers daar niet echt op zitten te wachten.

[pacificocean]

tiriaq schreef op woensdag 22 juni 2016 @ 20:21:
Wat je beschrijft bestaat niet, en als je het weet te maken kan je er heel rijk mee worden.
Het enige dat in de buurt komt is een integratie met bijvoorbeeld Dropbox en de private key daar op te slaan, maar ik vermoed dat gebruikers daar niet echt op zitten te wachten.

Ja hoor. In ieder geval Documentum kan dat. En ik verwacht dat er wel meer dms applicaties zijn die dat kunnen.

[Cartman!]

Je bedoelt zoiets als Mega ?

[Barryvdh]

Als je wil dat 1 gebruiker data kan opslaan die voor een andere gebruiker leesbaar is, kan je public/private keys gebruiken. Als de data alleen door de gebruiker zelf wordt opgeslagen/ingelezen, kan je ook symmetrische encryptie gebruiken (met AES bijv), dat kan makkelijker/sneller zijn.

Wat je zou kunnen doen in een encryption key (/private key) genereren (bijv. random string van 64 tekens) per gebruiker. Met die key kan je alle bestanden voor die gebruiker encrypten/decrypten. Je wil die dan natuurlijk niet leesbaar opslaan in de database, maar je zou die bijv. kunnen encrypten met het wachtwoord van de gebruiker. Dan kan een admin nooit bij de data, tenzij hij het wachtwoord weet (of de originele key).
Als een gebruiker zijn wachtwoord veranderd, decrypt je de key met het oude wachtwoord en encrypt je hem met het nieuwe.

Als iemand zijn wachtwoord vergeet ben je dan wel alles kwijt, maar als een admin het kan resetten is het nut ook een beetje weg natuurlijk.. Wat je dan wel kan doen is de originele key laten downloaden/uitprinten, zodat een gebruiker hem kan herstellen indien nodig.

Als je het gebruiksvriendelijk wil houden, onthoud je de key in zijn sessie ergens, maar dat kan ook weer uitgelezen worden. Maar als iemand al bij alle bestanden kan, kan hij natuurlijk ook makkelijk een backdoor installeren.

Vraag is een beetje wat belangrijker is, gebruiksvriendelijkheid of veiligheid..
Als je bijv. al je data encrypt met AES, met een applicatie key (ipv per gebruiker), kan de data ook niet gelezen worden zonder die key, dus alleen met een database heb je dan niks aan de data.

[ Voor 6% gewijzigd door Barryvdh op 22-06-2016 21:00 ]

[Thralas]

Bovenstaande suggesties werken alleen als je de beheerder vertrouwt - een 'oneerlijke' beheerder kan immers de code dusdanig aanpassen dat hij alsnog bij de data kan zodra een gebruiker eenmaal inlogt.

En dan kun je net zo goed de crypto aan de serverkant doen, stukken makkelijker.

[ajakkes]

Zolang de data eerst naar de cliënt gaat hoeft de server de code niet te hebben.

Maar ik heb wel eens vernomen dat het veelvuldig opslaan van kleine wijzigingen de encryptie zwakker maakt, al heb ik niet begrepen hoe het werkt. En de server ontvangt wel veel kleine wijzigingen.

Maar als je niet wil dat een ander bij je data kan moet je zelf de sleutel bewaken. En dus niet vergeten. Het is zo simpel.

Mega heeft alle encryptie naar de cliënt gebracht om zo geen toegang tot de data te hebben.

[Ventieldopje]

Met Amazon S3 kan het out of the box door je eigen keys te beheren. Ook kun je met S3 of andere cloud oplossingen encfs gebruiken met fuse maar dan zit je toch met client side oplossingen.

Daar ontkom je niet aan tenzij je server side encryption vertrouwt en zelf de sleutels in handen hebt (zoals bij S3).

[Gerco]

Uiteindelijk is wat je wilt onmogelijk waterdicht te krijgen. Je kan wel aardig dichtbij komen, maar zo lang iemand anders dan de eindgebruiker de controle over de code heeft zal het nooit waterdicht zijn.

Een werkbare oplossing kan zijn de opslag van de data en de opslag van de code bij andere partijen onderbrengen. Op die manier kan de code de data versleutelen op zo'n manier dat de beheerder van de data er niet bij kan. Tevens kan de beheerder van de code de data niet bekijken omdat dat bij iemand anders is ondergebracht.

Zo'n oplossing is best best wel te doen, maar het is natuurlijk niet 100%. Uiteindelijk kan de beheerder van de code altijd bij de data, al was het maar door de code zodanig aan te passen dat deze de data doorstuurt naar een andere locatie wanneer een gebruiker zijn/haar data gebruikt. Dat kun je alleen oplossen door de code nooit te updaten en lokaal bij de gebruikers te plaatsen. Niet echt een handige oplossing.

[Haan]

Een hele andere invalshoek, wellicht interessant om ook over na te denken: je kan ook kijken of je alle leesacties kunt loggen, dan kan je daarmee detecteren of iemand ongeoorloofd naar bepaalde data heeft gekeken.

[Alex)]

SQL Server heeft dit gewoon ingebouwd zitten: Always Encrypted.

edit: Always Encrypted gaat enkel op als je een goede scheiding hebt tussen beheerders, DBA's en ontwikkelaars. Als er één iemand is die meerdere petten draagt kan het niet echt werken, want dan zou de admin alsnog aan de keys kunnen komen.

[ Voor 48% gewijzigd door Alex) op 23-06-2016 11:57 ]

[Rmg]

Verwijderd schreef op woensdag 22 juni 2016 @ 20:07:
Is het mogelijk om data op een manier op te slaan in een web based applicatie / database zonder dat de administrator van de database de data in leesbaar formaat kan bekijken of decrypteren?
De enige manier die ik zo kan bedenken is werken met een public-private key, maar hoe kan dat op een gebruiksvriendelijke manier die ook door absolute leken zonder problemen kan gebruikt worden, zonder dat er iets op de lokale PC van de gebruiker moet geïnstalleerd worden en zonder het risico te lopen dat de private key verloren raakt? Bovendien is het me niet duidelijk hoe een browser die private key zou kunnen doorkrijgen zonder gebruik te maken van extensies of andere programma's op de PC van de gebruiker.

Zijn er andere, meer gebruiksvriendelijke manieren om dit voor elkaar te krijgen?

Het is niet de bedoeling dat er data verloren gaat als de gebruiker iets zou vergeten of zijn PC zou crashen.

Private keys met passphrase gebruiken. Dan kan je op zich de private key bij je data bewaren. Alleen Wachtwoord / Passphrase kwijt == Data onbereikbaar. En daar ontkom je eigenlijk niet aan als je het veilig wil houden.

[Gomez12]

Alex) schreef op donderdag 23 juni 2016 @ 11:55:
SQL Server heeft dit gewoon ingebouwd zitten: Always Encrypted.

edit: Always Encrypted gaat enkel op als je een goede scheiding hebt tussen beheerders, DBA's en ontwikkelaars. Als er één iemand is die meerdere petten draagt kan het niet echt werken, want dan zou de admin alsnog aan de keys kunnen komen.

Always encrypted heeft hier totaal niets mee te maken... Want dat zit niet op gebruikersniveau wat wel de vraag is...

[Verwijderd]

Bedankt voor alle antwoorden. Ik begrijp eruit wat ik al dacht: het is niet mogelijk om 3 op 3 te krijgen wat betreft:
- alle data privé te houden voor admin van het systeem
- het webgebaseerde systeem extreem gebruiksvriendelijk en fool-proof te houden voor de gebruiker
- verloren paswoorden / sleutels niet laten leiden tot data verlies

[Montaner]

Het gaat hierbij dus enkel om de dba'er? Deze heeft helemaal geen toegang/inzicht tot de applicatie en/of broncode?

Als je het systeem kan aanpassen is het vrij eenvoudig; gebruik een salt en encrypt/decrypt algoritme. Zodra je de salt hebt, is wel meteen alle data toegangkelijk... maar voor de dba'er ziet het er allemaal encrypted uit, en kan hij het niet decrypten zonder de salt. Zet de salt hardcoded in je applicatie, en klaar. Gebruikers merken er niets van, je hebt geen public keys, en geen mogelijkheid tot data verlies.

Zie ook bv. Wikipedia: Symmetrische cryptografie

[ Voor 10% gewijzigd door Montaner op 23-06-2016 12:42 ]

[Gomez12]

Haan schreef op donderdag 23 juni 2016 @ 10:27:
Een hele andere invalshoek, wellicht interessant om ook over na te denken: je kan ook kijken of je alle leesacties kunt loggen, dan kan je daarmee detecteren of iemand ongeoorloofd naar bepaalde data heeft gekeken.

Beetje admin kan die log-regels bewerken.

Maar ok, dan sturen we het naar een externe partij die het opslaat en waar niemand admin is. Beetje admin zet er dan gewoon een firewall tussen.

In wezen moet je ervanuit dat die admin op die server ook echt admin is en dus alles daar kan inzien en doen.

Oftewel als je iets wilt encrypten moet je het buiten die server doen, anders breng je bron en encryptiesleutel bij elkaar op een systeem waar iemand alles kan doen.

Verwijderd schreef op donderdag 23 juni 2016 @ 12:37:
Bedankt voor alle antwoorden. Ik begrijp eruit wat ik al dacht: het is niet mogelijk om 3 op 3 te krijgen wat betreft:
- alle data privé te houden voor admin van het systeem
- het webgebaseerde systeem extreem gebruiksvriendelijk en fool-proof te houden voor de gebruiker
- verloren paswoorden / sleutels niet laten leiden tot data verlies

Het kan wel enigszins, maar dat is wel kostbaar.
Je zou bijv kunnen werken met 3 identieke usb-sticks per klant met daarop de encryptie-key en een JS-iets wat de data encrypt. Dan vind je encryptie lokaal plaats en kan de admin er niets meer van zien.

USB-sticks zijn heerlijk fysiek en direct merkbaar als die weg zijn.
3 Zodat er 2 in de kluis gelegd kunnen worden en er maar 1 gebruikt wordt.
Als die ene dan stuk gaat dan kan nr 2 uit de kluis gehaald worden en gebruikt, nr 3 kan naar jullie opgestuurd worden voor duplicatie (zodat er weer 2 in de kluis liggen)
Mocht nr 3 dan alsnog door PTT vernield worden dan is er altijd nog een nr 2 die ook gedupliceerd kan worden, maar dit betekent wel ongemak voor de gebruiker (want die kan niet zelf verder werken)

[Orion84]

trix0r schreef op donderdag 23 juni 2016 @ 12:39:
Het gaat hierbij dus enkel om de dba'er? Deze heeft helemaal geen toegang/inzicht tot de applicatie en/of broncode?

Als je het systeem kan aanpassen is het vrij eenvoudig; gebruik een salt en encrypt/decrypt algoritme. Zodra je de salt hebt, is wel meteen alle data toegangkelijk... maar voor de dba'er ziet het er allemaal encrypted uit, en kan hij het niet decrypten zonder de salt. Zet de salt hardcoded in je applicatie, en klaar. Gebruikers merken er niets van, je hebt geen public keys, en geen mogelijkheid tot data verlies.

Zie ook bv. Wikipedia: Symmetrische cryptografie

Wat doet een salt in dat verhaal? Gewoon de symmetrische encryptiesleutel binnen code bewaren die niet toegankelijk is voor de DBA lijkt me voldoende om jouw voorstel te implementeren. Salts zijn een oplossing om hashing sterker te maken, met encryptie heeft dat weinig van doen.

[k995]

Verwijderd schreef op donderdag 23 juni 2016 @ 12:37:
Bedankt voor alle antwoorden. Ik begrijp eruit wat ik al dacht: het is niet mogelijk om 3 op 3 te krijgen wat betreft:
- alle data privé te houden voor admin van het systeem
- het webgebaseerde systeem extreem gebruiksvriendelijk en fool-proof te houden voor de gebruiker
- verloren paswoorden / sleutels niet laten leiden tot data verlies

Het kan dus wel ; de aplicatie eigenaar hoeft immers niet de DBA'er of niet de persoon verantwoordelijk voor de hardware te zijn.

Als JIJ de applicatie onder controle hebt dan maakt het weinig uit (mits goed geschreven) wie de hardware beheert of waar de data staat.

[Mikkie001]

Als je niet wil dat de beheerder de data kan lezen, dan kan je ook op zoek gaan naar een andere (interne) beheerder, die je de data wel toe kan/wil vertrouwen.

Het is niet echt een technische oplossing, maar toch....

[Montaner]

Orion84 schreef op donderdag 23 juni 2016 @ 12:44:
[...]

Wat doet een salt in dat verhaal? Gewoon de symmetrische encryptiesleutel binnen code bewaren die niet toegankelijk is voor de DBA lijkt me voldoende om jouw voorstel te implementeren. Salts zijn een oplossing om hashing sterker te maken, met encryptie heeft dat weinig van doen.

Met de salt bedoelde ik de sleutel .. ben nog niet wakker.
_{En het is al bijna 13.00?!}

[Gomez12]

Orion84 schreef op donderdag 23 juni 2016 @ 12:44:
[...]
Gewoon de symmetrische encryptiesleutel binnen code bewaren die niet toegankelijk is voor de DBA lijkt me voldoende om jouw voorstel te implementeren.

Het klinkt zo simpel... Maar daadwerkelijk is het vaak nog een puzzel om encryptiesleutels goed in code te krijgen hoor.

Je hebt er namelijk niets aan als een decompiler die sleutel gewoon letterlijk toont.

[Orion84]

Het ging mij vooral op Salt vs. Sleutel. Dat je geen van beiden zomaar even simpel op een veilige manier in code verwerkt is inderdaad een goed punt. Het ligt er vooral aan tegen wie je wilt beschermen.

Als je zorgt dat je devvers (die wel bij de code kunnen) niet bij de data kunnen en dat je DBA (die wel bij je data kan) niet bij de code kan, maakt het een stuk minder uit dat de key leesbaar in de code staat.

Maar dat helpt je dan weer niks tegen het scenario waarbij een hacker zowel een dev als een DBA account buitmaakt.

Een ander niet te onderschatten uitdaging is: werkt je applicatie nog fatsoenlijk als je data handmatig versleuteld in de database staat? Je database queries werken dan mogenlijk niet meer zo simpel (SQL de sortering laten doen bijvoorbeeld is totaal nutteloos als je data versleuteld is).

[ Voor 21% gewijzigd door Orion84 op 23-06-2016 12:53 ]

[Montaner]

Het is natuurlijk altijd een vraag van kosten en baten, en niet heel eenvoudig. Ik mis nog steeds van TS de echte scope... ik ga er vanuit dat het simpelweg zorgen is dat de DBA'er persoonlijk de data niet kan inzien. Niet bescherming van buitenaf (hackers etc.).

Als het mogelijk is om een symmetrische sleutel in te bouwen, dan is stap 2 kijken waarop het toegepast kan worden. Tekst en bedragen lijken mij daarbij het belangrijkste. Timestamps, ID's, etc. kan je plain houden text houden, en daarop sorteren. Sorteren op tekst is sowieso een beetje meh, en zou eventueel ook in de programmeertaal kunnen zonder veel performance verlies (alfabetisch sorteren wat veel voor komt bv.).

[ Voor 3% gewijzigd door Montaner op 23-06-2016 13:03 ]

[Gomez12]

Orion84 schreef op donderdag 23 juni 2016 @ 12:50:
Een ander niet te onderschatten uitdaging is: werkt je applicatie nog fatsoenlijk als je data handmatig versleuteld in de database staat? Je database queries werken dan mogenlijk niet meer zo simpel (SQL de sortering laten doen bijvoorbeeld is totaal nutteloos als je data versleuteld is).

Dit is nog wel een goed punt om naar te gaan kijken, want het is maar net afhankelijk van je encryptie of een woord op zichzelf wel hetzelfde ge-encrypt wordt als hetzelfde woord in een zin (voor bijv zoek-query's).

trix0r schreef op donderdag 23 juni 2016 @ 13:02:
Sorteren op tekst is sowieso een beetje meh, en zou eventueel ook in de programmeertaal kunnen zonder veel performance verlies (alfabetisch sorteren wat veel voor komt bv.).

In de programmeertaal ga je dan al heel snel tegen problemen aanlopen (bijv een artikellijst met 1 miljoen artikelen die wil je gepaged uit de dbase halen en niet compleet om dan client-side weer te gaan sorteren).

Alleen je kan ook hierop weer tussenoplossingen gebruiken. Als je selectief velden gaat encrypten dan kan je voor bijv een sortering veelal wel weer een extra char(1) veld aanmaken met daarin het 1e character van de unencrypted text, dan trek je niet elke keer je hele database in je applicatie als je iets wilt sorteren, maar idealiter 1/26e.

Het vereist allemaal enkel wel extra code-werk en uren en bug-testing.

[gosse adema]

Ik heb geen idee wat je budget is. Maar kijk eens naar "Oracle Database Vault".

Misschien hebben andere database leveranciers soortgelijke oplossingen.

[Ventieldopje]

Hebben we het nu over een DB of bestandsopslag? Maakt nogal een verschil... ik meende ook dat het om een DB ging totdat ik allemaal FS opties voorbij zag komen. Dat verandert de boel..

[Vigilate]

Zit hier eigenlijk met de zelfde vraag (ongeveer). Ik ben sinds een paar maanden bezig met een wachtwoordkluis en zoek ook een methode om de private en public key op een goede manier te laten werken.

Omdat het voor mijzelf is en niet voor publiek bereikbaar is; heb ik de sleutel opgeslagen in een sessie met encryptie van de standaard pincode, de gebruikersnaam en een opgeslagen salt die weer ge-encrypt is met het wachtwoord (heel omslachtig eigenlijk).

Zeer benieuwd wat er verder qua oplossingen worden aangedragen.

[Alex)]

Gomez12 schreef op donderdag 23 juni 2016 @ 12:27:
[...]

Always encrypted heeft hier totaal niets mee te maken... Want dat zit niet op gebruikersniveau wat wel de vraag is...

De aanvankelijke vraag ging om het voorkomen dat een DBA de data kan inzien. Dat lukt met Always Encrypted, mits je DBA niet bij de encryptiesleutels kan.

[Verwijderd]

Nee, de oorspronkelijke vraag ging om het voorkomen dat de applicatieontwikkelaar de data kan inzien.

[pacificocean]

Verwijderd schreef op donderdag 23 juni 2016 @ 19:14:
Nee, de oorspronkelijke vraag ging om het voorkomen dat de applicatieontwikkelaar de data kan inzien.

Dan laat je de applicatie ontwikkelaar toch gewoon niet met de echte data werken. Een kwestie van een goede otap straat inrichten.

[Verwijderd]

Je mist het hele punt. Uit het oogpunt van de gebruiker moet het duidelijk zijn dat niemand anders zijn data kan bekijken.
edit: met applicatieontwikkelaar bedoel ik het bedrijf, niet de individuele ontwikkelaar/ontwikkelteam

[ Voor 29% gewijzigd door Verwijderd op 23-06-2016 20:16 ]

[johnkeates]

Er is geen manier om te doen wat je wil. Aan de ene kant moet het makkelijk in gebruik zijn en moeten leken er mee werken, en moet het ook makkelijk zijn om de data te ontcijferen bij een verloren key. Dan heb je dus eigenlijk geen enkele manier om het veilig te implementeren, want met een simpele username+password combinatie kom je er niet, en zonder client-side crypto met veilige key distributie gaat je hele veiligheidsplan niet op.

Als je data wil coderen en daarna bij andere clients wil kunnen decoderen maar zonder dat de admin dat kan, dan mogen de keys dus nooit de server passeren. Dat betekent dat je met pubkey moet werken zodat private keys buiten bereik van de admin blijven. Elke client moet dus keypairs maken en voor elke bestandsdeling een key exchange doen, het bestand eerst met de eigen private key decoderen, dan met de pubkey van de persoon die het bestand wil hebben weer coderen, en dan het bestand sturen, zodat de ontvanger het met zijn/haar private key kan decoderen. Nu is dat technisch niet heel moeilijk, maar het is niet compatible met leken. Je kan het niet zo simpel maken dat ze hun keys mogen vergeten of bijv. vanuit de browser kunnen werken. Je zal op z'n minst een client side crypto engine en key storage moeten maken.

Even inloggen met je eigen account op een andere PC is er niet bij, een web interface ook niet.

gosse adema schreef op donderdag 23 juni 2016 @ 13:19:
Ik heb geen idee wat je budget is. Maar kijk eens naar "Oracle Database Vault".

Misschien hebben andere database leveranciers soortgelijke oplossingen.

Die zijn zo lek als een mandje. Bij elke DEF CON wordt wel een serie nieuwe brakke lekken in de implementatie blootgelegd. Het probleem is niet dat het in theorie niet zou kunnen, maar om dat de implementatie niet kosteneffectief op een goed niveau gebracht kan worden en Oracle het daarom niet doet en liever elke exploit los patcht. Daarnaast is de data gewoon leesbaar on-disk opgeslagen en kan en admin er dus gewoon bij.