Encryptie van bestanden in 'file store'

[NickThissen]

Hi,

Ik ben momenteel een website aan het ontwerpen voor gebruikers van een online race spel. In dit spel kun je de afstelling van de auto (de 'setup') tot in detail zelf instellen en opslaan naar bestanden, om ze daarna te delen met andere gebruikers. Het idee van de website is om dienst te doen als een soort online opslag voor deze setup bestanden. Gebruikers maken en account aan en kunnen hun setups uploaden, waarna andere gebruikers ze weer kunnen downloaden.

Vaak zullen setups echter geheim moeten blijven binnen een groep / team (om niet alle details aan de competitie weg te geven). Daarom moeten er ook groepen aangemaakt kunnen worden binnen de website, waarvan gebruikers lid kunnen worden. Gebruikers in zo'n groep kunnen dan setups uploaden die alleen toegankelijk mogen zijn voor leden van die groep.

Dit is allemaal vrij eenvoudig te programmeren, maar het probleem is dat de setup bestanden wel gewoon fysiek op mijn webserver moeten staan. Daar zijn twee problemen mee:

1. Ik denk niet dat het enorm lastig zal zijn om zo aan setups te kunnen komen die niet voor jou bestemd zijn (bijvoorbeeld door gewoon de url te gokken).
2. Ik heb natuurlijk toegang tot mijn webserver, en dat zou een reden kunnen zijn voor teams om de website niet te gebruiken, bang dat ik de setups zou 'stelen'.


Probleem 1 is denk ik wel eenvoudig op te lossen, daar had ik twee ideeën voor:
a. De setup bestanden zijn '.sto' bestanden. Ik zou natuurlijk gewoon (via MIME-types ofzoiets dacht ik?) niet kunnen toelaten dat die bestanden direct gedownload kunnen worden. Heb ik het goed dat je op die manier zelfs met de juiste url niet aan de bestanden komt, of is dat te simpel gedacht?
b. Ik zou de bestanden kunnen encrypten met een simpele private key encryption. De key zou gewoon op mijn webserver staan (kan die gewoon in de ASP.NET code, of kan dat veiliger?) en setups worden encrypted opgeslagen en gedecrypt wanneer ze gedownload worden.

Zijn er andere oplossingen voor probleem 1, of klopt dit al helemaal niet?


Probleem 2 kan ik geen oplossing voor verzinnen. Zelfs als ik encryptie gebruik weet ik de key omdat die gewoon op de webserver staat, dus zou ik de bestanden zelf kunnen decrypten. Zelfs met een public/private key combinatie (waarbij de gebruiker zelf de decrypt key heeft en ik niet) zie ik niet hoe dat zou moeten werken, de setup file zal toch op de webserver gedecrypt moeten worden dus zal de webserver toch ooit de decrypt key nodig hebben. Ook houd niks me natuurlijk tegen om de setup eerst even stieken op te slaan voordat ik hem encrypt, dus ik kan moeilijk garanderen dat ik geen toegang heb tot de setups die mensen uploaden...


Wat voor mogelijkheden zijn hiervoor?

Bedankt!

[YopY]

Bij oplossing A heb je waarschijnlijk ook dat je de bestanden helemaal niet ter download kunt aanbieden, ook niet aan teamleden. Een optie is natuurlijk om downloads via een script te laten verlopen die het bestand inleest en doorgeeft aan de gebruiker indien de beveiligingschecks kloppen. Overigens is het niet downloadbaar maken van die bestanden een kwestie van webserverconfiguratie; plaats ze buiten de root van je webserver, of configureer je webserver dat een bepaalde map niet toegangkelijk is.

Mbt b, als je webserver gecompromitteerd wordt (bijvoorbeeld mensen komen bij de database of de geüploade setups) zal het hebben van een encryptiecode niet veel helpen; op z'n minst zouden de bestanden geëncrypt moeten worden met iets dat alleen bij de gebruikers bekend is. Ga er van uit dat jezelf / de website zelf de bestanden niet zonder gebruikersinvoer mag / kan decrypten.

Bij 1 zou ik dus bovenstaand toepassen; setups downloaden gaat via een script die eerst checkt of je het bestand wel downloaden mag.

Probleem 2 is lastig, maar niet onoverkomelijk; het beste wat je kunt doen is client-side encryptie, dwz dat gebruikers hun setups al kunnen encrypten voordat het op jouw server komt te staan. Of server-side encryptie met een duidelijke melding dat geuploade setups geëncrypt worden. Zoals gezegd, het tonen van de setups zal dan alleen kunnen nadat de gebruiker zijn key ingevuld heeft (dat kan bijvoorbeeld zijn password zijn, of een andere unieke key die, in combinatie met de private key (op jouw webserver) de content unlocked.

Maar ik ben geen security-expert; de bestanden zullen hoe dan ook op de website gedecrypt moeten worden in de 'klassieke' webapplicatie. Een alternatief is om de encryptie/decryptie helemaal aan de clientside te laten doen; de webserver stuurt het geëncrypte bestand naar de client-applicatie (kan een webapp zijn), de gebruiker wordt gevraagd om zijn key, en bakkes.

[Kalentum]

Oplossing 1 eens met Yopy: directory blokkeren of die STO bestanden ergens buiten de directorystructuur waar je webserver toegang tot heeft plaatsen.

Probleem 2: Zodra je ook maar iets met encrypten/decrypten op de server gaat doen kun jij er als beheerder bij. Niets weerhoudt je om door gebruikers bedachte private keys al dan niet stiekum af te vangen en op te slaan.

Dus je zal dan hoe dan ook client side moeten encrypten en decrypten. Opties:

- In de browser
- ActiveX/Java applet (daarmee kan je in principe toegang krijgen tot het filesystem van de gebruiker)
- Zelf een aparte applicatie maken om het encrypten/uploaden en decrypten/downloaden te regelen.

Over encrypten en decrypten in de browser. Lastpass doet dat in principe ook.
Op Stackoverflow.com staat iemand die hetzelfde probleem heeft maar dan met images:
http://stackoverflow.com/...javascript-within-browser
Hier staat ook de term 'Host proof hosting'. De file transfer service https://www.senditonthenet.com/ claimt ook host proof hosting te doen, waarbij een upload bestand eerst wordt encrypted voordat het naar hun server gaat. Geen idee hoe dat werk, maar je zou je daar eens in kunnen verdiepen.

[NickThissen]

YopY schreef op zondag 07 oktober 2012 @ 11:53:
Bij oplossing A heb je waarschijnlijk ook dat je de bestanden helemaal niet ter download kunt aanbieden, ook niet aan teamleden. Een optie is natuurlijk om downloads via een script te laten verlopen die het bestand inleest en doorgeeft aan de gebruiker indien de beveiligingschecks kloppen. Overigens is het niet downloadbaar maken van die bestanden een kwestie van webserverconfiguratie; plaats ze buiten de root van je webserver, of configureer je webserver dat een bepaalde map niet toegangkelijk is.

Mbt b, als je webserver gecompromitteerd wordt (bijvoorbeeld mensen komen bij de database of de geüploade setups) zal het hebben van een encryptiecode niet veel helpen; op z'n minst zouden de bestanden geëncrypt moeten worden met iets dat alleen bij de gebruikers bekend is. Ga er van uit dat jezelf / de website zelf de bestanden niet zonder gebruikersinvoer mag / kan decrypten.

Bij 1 zou ik dus bovenstaand toepassen; setups downloaden gaat via een script die eerst checkt of je het bestand wel downloaden mag.

Ik weet niet welk script je precies bedoelt, maar het beschikbaar stellen van een bestand als download heb ik al vaker gedaan, via ASP.NET kan dat heel eenvoudig (in principe gooi je de bytes gewoon in de response stream en geef je aan dat het om een file download gaat). Voor zover de gebruiker kan zien klikt hij gewoon een directe url aan naar de locatie van het bestand, maar achter de schermen draait er dus gewoon wat code dat het bestand inleest (op de server) en de bytes terugstuurt, de gebruiker heeft dan geen fysieke toegang tot het bestand. In dat geval is het dus eenvoudig om alleen bestanden te laten downloaden waarvoor de gebruiker toegang heeft (kwestie van checken of de groep/team overeenkomt).

Het probleem dat dan overblijft is dat de files nog steeds fysiek op de server staan, waar ik en/of een potentiele hacker ze zou kunnen stelen. Als de files encrypted zijn zou dat stelen dus geen nut moeten hebben. Probleem is dus dat de encryptie absoluut client-side moet gebeuren, wanneer ik het aan de server kant ga doen is het altijd mogelijk om de bestanden te lezen. De key (bijv het wachtwoord van de user) zou dan toch ergens moeten staan in een database oid, en als een hacker toegang heeft tot de bestanden zelf ga ik er ook maar vanuit dat hij de database kan zien. Dus de server mag geen weet hebben van de key die gebruikt moet worden om de bestanden te decrypten, want op dat moment kan een hacker er ook aan.

[b][message=39058882,noline]Probleem 2 is lastig, maar niet onoverkomelijk; het beste wat je kunt doen is client-side encryptie, dwz dat gebruikers hun setups al kunnen encrypten voordat het op jouw server komt te staan. Of server-side encryptie met een duidelijke melding dat geuploade setups geëncrypt worden. Zoals gezegd, het tonen van de setups zal dan alleen kunnen nadat de gebruiker zijn key ingevuld heeft (dat kan bijvoorbeeld zijn password zijn, of een andere unieke key die, in combinatie met de private key (op jouw webserver) de content unlocked.

Maar ik ben geen security-expert; de bestanden zullen hoe dan ook op de website gedecrypt moeten worden in de 'klassieke' webapplicatie. Een alternatief is om de encryptie/decryptie helemaal aan de clientside te laten doen; de webserver stuurt het geëncrypte bestand naar de client-applicatie (kan een webapp zijn), de gebruiker wordt gevraagd om zijn key, en bakkes.

We zijn het dus eens dat het encrypten client-side moet gebeuren, maar als ik het zo lees is dat nog niet zo heel eenvoudig.

De meest simpele vorm die ik kan bedenken is gewoon via javascript, als dat uberhaupt mogelijk is. Het bestand moet dan in javascript ingelezen worden voordat het naar de server gaat (ik denk dat deze stap limiterend is, kan dat uberhaupt..?) en versleuteld worden met een key die de gebruiker in moet geven. Die key mag dus niet naar de server verstuurd worden (maar hoe kan ik garanderen dat dat ook niet gebeurd...). Ik zie het nog niet zo gebeuren dat ik zoiets voor elkaar krijg

Een alternatief is natuurlijk om naast deze .sto bestanden ook gewoon zips of rars toe te laten, die de gebruiker dan zelf (voor uploaden) kan beveiligen met een wachtwoord. Nu weet ik niet hoe veilig deze beveiligde zip bestanden zijn (volgens mij zijn die relatief eenvoudig te kraken?) maar het is natuurlijk beter dan niets. Nadeel is dan natuurlijk dat de gebruiker zelf veel werk moet doen (zippen, wachtwoord erop en later weer unzippen met wachtwoord dat hij dan zelf aan de teamleden moet verspreiden).

[ Voor 5% gewijzigd door NickThissen op 08-10-2012 11:39 ]

[Hydra]

Afgezien van de zaken die je genoemd hebt zou je daarnaast ook nog GUIDs als de IDs van de setups kunnen gebruiken. Het is een stuk lastiger te proberen om alle setupts te downloaden als ze geen (default) oplopense nummerieke IDs hebben als 1001,1002, etc. maar GUIDs.

In princiepe heeft encrypten volgens mij niet zoveel zin. Als je zorgt dat de files niet rechtstreeks te downloaden zijn (dus niet binnen je HTTP root) maar gewoon via een script lopen dat zelf de data verstuurt (dus geen redirect doet) dan kan dat script prima eerst checken of iemand de juiste credentials heeft.

[Lone Gunman]

volgens mij is er niet echt een waterdichte oplossing voor je tweede probleem. Of je nou encrypt op de server of met javascript op de client, als beheerder kun je dit altijd omzeilen. Je kunt als beheerder namelijk gewoon de javascript code aanpassen die de encryptie op de client uitvoert. Een pragmatische oplossing is het aan de teams zelf overlaten: standaard vind er geen encryptie plaats en als teams je niet vertrouwen kunnen ze zelf de bestanden encrypten voor het uploaden.