[PHP] Bestanden encrypted opslaan

[Dutch_guy]

Ik ben op zoek naar mogelijkheden om bestanden (jpg, pdf, xls, etc) die nu buiten de web root folder staan extra te beveiligen. De applicatie is in PHP gemaakt.

En met beveiligen bedoel ik, wat als de server gehackt wordt, hoe voorkom ik dan dat deze bestanden geopend kunnen worden.

Op dit moment uploaden medewerkers de bestanden zelf. Mijn idee is om tijdens de upload de bestanden te encrypten met openssl of iets dergelijk. De medewerker moet ook met een sleutel de bestanden weer kunnen decrypten en zodoende de bestanden kunnen openen.

Is zoiets überhaupt haalbaar. De sleutel moet immers ergens worden opgeslagen en als de server gehackt is dan ligt die ook op straat.

Zit ik op het juiste spoor of doen anderen dit op een heel andere manier?

[DexterDee]

Als je de bestanden encrypt zonder een key op de server achter te laten, dan kun je ze dus ook niet decrypten en bijvoorbeeld laten tonen / downloaden in een browser.

Zonder de exacte use-case te kennen kun je met asymmetrische keys in theorie de public key van de gebruiker op de server bewaren en gebruiken om de bestanden te encrypten direct na het uploaden. Client side kun je de private key van de gebruiker dan weer gebruiken om de bestanden te decrypten.

Hoogstwaarschijnlijk zijn er wel slimmere oplossingen als de precieze use-case duidelijk is. Misschien wil je nog wat meer achtergrondinformatie geven?

[downtime]

Dutch_guy schreef op dinsdag 18 april 2023 @ 17:21:
Ik ben op zoek naar mogelijkheden om bestanden (jpg, pdf, xls, etc) die nu buiten de web root folder staan extra te beveiligen. De applicatie is in PHP gemaakt.

En met beveiligen bedoel ik, wat als de server gehackt wordt, hoe voorkom ik dan dat deze bestanden geopend kunnen worden.

Op dit moment uploaden medewerkers de bestanden zelf. Mijn idee is om tijdens de upload de bestanden te encrypten met openssl of iets dergelijk. De medewerker moet ook met een sleutel de bestanden weer kunnen decrypten en zodoende de bestanden kunnen openen.

Is zoiets überhaupt haalbaar. De sleutel moet immers ergens worden opgeslagen en als de server gehackt is dan ligt die ook op straat.

Zit ik op het juiste spoor of doen anderen dit op een heel andere manier?

It depends. Vind je het acceptabel dat medewerkers zelf decryptiekeys beheren en hun data kunnen verliezen als ze die decryptiekey niet goed bewaren? Of moet het, net als bij een password, mogelijk zijn om een key te resetten als de medewerker die vergeten is? En hoe zit het als een medewerker ziek wordt of overlijdt? Is het acceptabel als de bestanden dan voor niemand meer toegankelijk zijn?

Dat bepaalt namelijk of je een encryptiekey lokaal moet opslaan of niet. Als je al het risico naar de medewerker kunt schuiven, omdat het bedrijf dataverlies in zulke situaties acceptabel vindt, dan is er geen behoefte aan een encryptiekey op de server.

[Dutch_guy]

Het gaat in principe om 1 medewerker die de key dan krijgt.

Maar, diezelfde key is toch ook nodig op de server. Ik moet immers de bestanden op de server encrypten na uploaden.

[pennywiser]

Kan je niet beter selinux of acl gebruiken?

[remyz]

Dutch_guy schreef op donderdag 20 april 2023 @ 12:32:
Het gaat in principe om 1 medewerker die de key dan krijgt.

Maar, diezelfde key is toch ook nodig op de server. Ik moet immers de bestanden op de server encrypten na uploaden.

Niet als je asymmetrische keys gebruikt. Op de server gebruik je de public key om het bestand te versleutelen. De gebruiker kan het bestand dan met de private key ontsleutelen. Het probleem is wel, zoals eerder geschreven is, dat je erop vertrouwt dat iemand (de gebruiker) zijn sleutel niet kwijtraakt. Zonder sleutel kom je niet bij de data. Je moet goed nadenken hoe je dat probleem gaat tackelen.

[Ozzie]

Dutch_guy schreef op donderdag 20 april 2023 @ 12:32:
Het gaat in principe om 1 medewerker die de key dan krijgt.

Maar, diezelfde key is toch ook nodig op de server. Ik moet immers de bestanden op de server encrypten na uploaden.

Client side encryptie doen in de frontend mbv javascript. Alleen de server kan dan ook echt niks met die bestanden, behalve opslaan.

[chielsen]

Als de server het moet decrypten dan kan een hacker dat dus ook.
Wat wel vaak wordt gedaan is de key in het geheugen opslaan waardoor het lastiger is voor de hacker om erbij te komen (bijv alleen bij het bestandssysteem).

[Voutloos]

Even een realitycheck: Je kan het niet zelf bouwen, je huurt niemand in, je hebt de materie niet geheel onder de knie.

Waarom moet het dan iets nieuws zijn ipv dat je een bestaande dienst afneemt? Puur en alleen omdat je per se je eigen naam op wil plakken? Als zakenrelatie zou ik blijer worden dat je je trots op zij zet en uitlegt dat je dit stukje via gerenommeerde partij X doet.

[ThomasG]

Je kunt kijken naar de Web Crypto API.

Let wel op dat er een grote waarschuwing bij staat:

Warning: The Web Crypto API provides a number of low-level cryptographic primitives. It's very easy to misuse them, and the pitfalls involved can be very subtle.

Even assuming you use the basic cryptographic functions correctly, secure key management and overall security system design are extremely hard to get right, and are generally the domain of specialist security experts.

Errors in security system design and implementation can make the security of the system completely ineffective.

Please learn and experiment, but don't guarantee or imply the security of your work before an individual knowledgeable in this subject matter thoroughly reviews it. The Crypto 101 Course can be a great place to start learning about the design and implementation of secure systems.

[Anoniem: 80910]

Ik gebruik php en een database, 2 servers. 1 heeft de sleutel, andere heeft de data. Daarvoor gebruik ik geen open ssl nog maar dit composer package: defuse/php-encryption. Wellicht heb je hier wat aan. Je zult sowieso minimaal 2 servers nodig hebben. 1 voor de data en 1 voor de keys. Ze moeten dus minimaal 2 servers hacken voor de data. Als je het nog veiliger wil maken, zorg je voor 30 keyservers en hash je de data met 30 keys. Als je andere encryptie wil gebruiken zoals open ssl heb je 3 servers nodig. 1 voor private key, 1 voor public key en 1 voor data.

[Voutloos]

Anoniem: 80910 schreef op donderdag 20 april 2023 @ 16:48:
Ik gebruik php en een database, 2 servers. 1 heeft de sleutel, andere heeft de data. […] Ze moeten dus minimaal 2 servers hacken voor de data.

De PHP server kan bij de DB. Enkel de PHP server hacken volstaat dus al.

---

Maar zoals altijd, iedereen gaat door met random details aan iemand die het totaalplaatje niet begrijpt. Sterkte, maar ik raad je aan om in ieder geval mijn eerste post gelezen te hebben.

Om maar nog een aspect te noemen: Wat is het threat model precies? Bepaalde threats kan je niet tegengaan zonder serieuze inspanning, kosten en vermindering van usability.

Als je bang bent voor een fout in eigen code, waardoor buiten de root data gelekt wordt, ben ik behoorlijk pessimistisch of méér code het op gaat lossen.

[ Voor 27% gewijzigd door Voutloos op 20-04-2023 17:25 ]

[Anoniem: 80910]

Voutloos schreef op donderdag 20 april 2023 @ 17:20:
[...]
De PHP server kan bij de DB. Enkel de PHP server hacken volstaat dus al.

---

Maar zoals altijd, iedereen gaat door met random details aan iemand die het totaalplaatje niet begrijpt. Sterkte, maar ik raad je aan om in ieder geval mijn eerste post gelezen te hebben.

Om maar nog een aspect te noemen: Wat is het threat model precies? Bepaalde threats kan je niet tegengaan zonder serieuze inspanning, kosten en vermindering van usability.

Als je bang bent voor een fout in eigen code, waardoor buiten de root data gelekt wordt, ben ik behoorlijk pessimistisch of méér code het op gaat lossen.

De php server kan connecten naar de db, en naar de keyserver. De db en keyserver kennen elkaar niet. De db heeft encrypted data, de keyserver de keys. Het password en username laat je encoden door de keyserver en sla je op de php server. Volgens mij ben je er dan.

[HenkEisDS]

Voutloos schreef op donderdag 20 april 2023 @ 14:29:
Even een realitycheck: Je kan het niet zelf bouwen, je huurt niemand in, je hebt de materie niet geheel onder de knie.

Waarom moet het dan iets nieuws zijn ipv dat je een bestaande dienst afneemt? Puur en alleen omdat je per se je eigen naam op wil plakken? Als zakenrelatie zou ik blijer worden dat je je trots op zij zet en uitlegt dat je dit stukje via gerenommeerde partij X doet.

Dit.

Heeft de klant niet ook gewoon Microsoft, Google of whatever drive waar je bestanden veilig kunt opslaan? Dan kun je vanaf je onveilige website daar naar verwijzen en klant hoeft alleen met SSO in te loggen.

[Janoz]

Anoniem: 80910 schreef op vrijdag 21 april 2023 @ 10:01:
[...]


De php server kan connecten naar de db, en naar de keyserver. De db en keyserver kennen elkaar niet. De db heeft encrypted data, de keyserver de keys. Het password en username laat je encoden door de keyserver en sla je op de php server. Volgens mij ben je er dan.

En dan hacked iemand de php server en kan hij/zij overal bij.

[Dutch_guy]

Voutloos schreef op donderdag 20 april 2023 @ 14:29:
Even een realitycheck: Je kan het niet zelf bouwen, je huurt niemand in, je hebt de materie niet geheel onder de knie.

Waarom moet het dan iets nieuws zijn ipv dat je een bestaande dienst afneemt? Puur en alleen omdat je per se je eigen naam op wil plakken? Als zakenrelatie zou ik blijer worden dat je je trots op zij zet en uitlegt dat je dit stukje via gerenommeerde partij X doet.

Je doet heel veel aannames? Ik stel een vraag om dit zelf te ontwikkelen en hoe andere bedrijven dit doen. Als er een bestaande dienst is, prima. Security mag geld kosten. Dus als je een suggestie hebt dan hoor ik het graag.

Feit is dat de applicatie in-house is ontwikkeld en dat als de bestanden eenvoudig encrypt kunnen worden dit bijdraagt aan de beveiliging.

[pennywiser]

Janoz schreef op vrijdag 21 april 2023 @ 10:32:
[...]

En dan hacked iemand de php server en kan hij/zij overal bij.

Ik denk dat daar een grotere taak ligt, dan lokaal bestanden te versleutelen. Verklein je aanvalsvlak. Iedereen, elke website serveert files naar buiten, ik begrijp de usecase hier niet goed. Waarom moet dat hier perse encrypted worden. @Dutch_guy We moeten aannames doen, omdat je weinig details geeft. Welk OS gebruik je bv?

[Dutch_guy]

HenkEisDS schreef op vrijdag 21 april 2023 @ 10:19:
[...]


Dit.

Heeft de klant niet ook gewoon Microsoft, Google of whatever drive waar je bestanden veilig kunt opslaan? Dan kun je vanaf je onveilige website daar naar verwijzen en klant hoeft alleen met SSO in te loggen.

Onveilige website?

Webapplicatie is reeds beveiligd met DUO 2fa. Gaat mij erom dat als de server gehackt wordt, deze bestanden niet geopend kunnen worden.

Uploaden naar Onedrive geeft zeker een veiliger gevoel.

Het is lastig. Deze documenten mogen officieel niet te lang bewaard worden, maar een andere wet schrijft ons voor dat deze 7 jaar lang bewaard moeten blijven. Ik zou ze offline kunnen bewaren, daarentegen moeten ze ook makkelijk te raadplegen zijn bij een controle. Via de huidige webapplicatie is dan het eenvoudigst.

[Patriot]

Dutch_guy schreef op vrijdag 21 april 2023 @ 14:36:
[...]


Onveilige website?

Webapplicatie is reeds beveiligd met DUO 2fa. Gaat mij erom dat als de server gehackt wordt, deze bestanden niet geopend kunnen worden.

Uploaden naar Onedrive geeft zeker een veiliger gevoel.

Het is lastig. Deze documenten mogen officieel niet te lang bewaard worden, maar een andere wet schrijft ons voor dat deze 7 jaar lang bewaard moeten blijven. Ik zou ze offline kunnen bewaren, daarentegen moeten ze ook makkelijk te raadplegen zijn bij een controle. Via de huidige webapplicatie is dan het eenvoudigst.

Als je ze sporadisch hoeft in te zien kun je gewoon asymmetrische encryptie toepassen met een private sleutel die je niet op de server opslaat, maar apart moet invoeren als er sprake moet zijn van inzage. Dat is qua ux misschien niet het allermakkelijkst, maar als je het maar relatief zelden hoeft in te zien lijkt me dat geen probleem.

[pennywiser]

Wegschrijven naar externe storage met roterende SSH keys gebruik makende van automation (Ansible).

[Dutch_guy]

pennywiser schreef op vrijdag 21 april 2023 @ 14:33:
[...]

Ik denk dat daar een grotere taak ligt, dan lokaal bestanden te versleutelen. Verklein je aanvalsvlak. Iedereen, elke website serveert files naar buiten, ik begrijp de usecase hier niet goed. Waarom moet dat hier perse encrypted worden. @Dutch_guy We moeten aannames doen, omdat je weinig details geeft. Welk OS gebruik je bv?

Simpel, kijk naar de KNVB, hadden ze een probleem gehad als de bestanden encrypt waren?

Ik wil waar mogelijk doen wat ik kan. Hele applicatie is straks ook alleen nog maar via Application Proxy te benaderen via uitsluitend machines die enrolled zijn in Intune.

[Voutloos]

Dutch_guy schreef op vrijdag 21 april 2023 @ 14:26:
[...]


Je doet heel veel aannames? Ik stel een vraag om dit zelf te ontwikkelen en hoe andere bedrijven dit doen. Als er een bestaande dienst is, prima. Security mag geld kosten. Dus als je een suggestie hebt dan hoor ik het graag.

Je vertelt ook echt helemaal niets, dus ja, aannames.

Feit is dat de applicatie in-house is ontwikkeld en dat als de bestanden eenvoudig encrypt kunnen worden dit bijdraagt aan de beveiliging.

Als het heel eenvoudig was, stond het wel in elke tutorial. Helaas pindakaas.

Dutch_guy schreef op vrijdag 21 april 2023 @ 14:36:
[...]
Onveilige website?

Dat was hypothetisch. Stel dat je een probleem hebt dan… precies zoals je eigen threat model poneert.

Webapplicatie is reeds beveiligd met DUO 2fa.

Je stelt hier beveiligd zijn gelijk aan 2FA? Dat is goed incompleet. 2FA lost zeker een aantal authenticatie issues op, maar helpt geen fuck bij tal van andere issues. Voor 9 vd 10 issues in de huidige OWASP 10 is het geen… *kuch* factor. Nog even los van social engineering en eigen unieke bugs die niet een top 10 foutje zijn.

Dutch_guy schreef op vrijdag 21 april 2023 @ 14:45:
[...]
Simpel, kijk naar de KNVB, hadden ze een probleem gehad als de bestanden encrypt waren?

Met realistisch encryptie zou ik uitgaan van wel!
En dit is cruciaal: Hackers hebben geduld, en detecteren is helemaal niet zo eenvoudig. Als de decryptie wel af en toe gebeurt, zou ík aannemen dat je wel de pineut bent op een gegeven moment.

Breng het vooral terug naar deze simpele stelling:
Toegang tot server = game over.
Shit, wat nu:
- Scenario 1: Alles offline halen, auditen en vanaf veilige backup herstellen. Keys roteren etc.
- Scenario 2: Niets aan het handje want de decrypt gebeurt … oeps toch wel af en toe.

Dus denk eens echt na over deze threat en wat je moet doen een lees dan pas verder.

Dus wat geeft de doorslag bij scenario 1?
Detectie en kunnen bewijzen wanneer het nog veilig was.

Security is niet zwart-wit. Het is niet enkel 2FA, of encryptie, of intune. Van de hele uitdaging heb je maar 3 kleine vakgebiedjes half genoemd.

[mrmrmr]

Met zoiets als owncloud is bestandsencryptie een add-on. De key staat op de server.

The encryption application does not protect your data if your ownCloud server is compromised

Bron

In data/files_encryption/OC_DEFAULT_MODULE staan private en public keys.

Dat kan beter, maar het is niet makkelijk.

Als alleen de maker van de bestanden de bestanden hoeft in te zien is versleuteling bij de client het beste (end-to-end). Als het met meerderen gedeeld moet worden moet de encryptie opnieuw worden gedaan met de public keys van alle gebruikers waarmee het bestand gedeeld wordt. Met de private keys kunnen de bestanden worden ontsleuteld.

In de praktijk wordt nog vaak security through obscurity toegepast met een methode die intrinsiek niet veilig is, maar in de praktijk toch wel voldoende kan blijken te zijn. Het kost aanvallers moeite te doorgronden hoe ze bestanden kunnen ontsleutelen, hoewel PHP dat makkelijker maakt aangezien de code te lezen is.

[MueR]

Voutloos schreef op vrijdag 21 april 2023 @ 22:07:
Breng het vooral terug naar deze simpele stelling:
Toegang tot server = game over.

Deze waarheid kan ik niet genoeg onderstrepen. Je kunt een hoop leuke dingen bedenken, maar in feite is alles klaar als iemand toegang krijgt tot je server.

[Anoniem: 80910]

Je zult dan via de keyserver de bestanden moeten decrypten en dat uitvoeren met een wachtwoord. Dat betekend dat je niet direct de bestanden kan openen. Maar inderdaad wat voutloos zegt je php server kan overal bij dus dat decrypten daar moet je events aanhangen, max. Aantal etc mailen indien ...

Ik zat zelf ook al te denken aan een keyserver maken. Wel leuke opdracht omdat veilig te krijgen en te monitoren. Ik begin ermee waarschijnlijk rond augustus mee

[mrmrmr]

MueR schreef op zaterdag 22 april 2023 @ 00:15:
[...]

Deze waarheid kan ik niet genoeg onderstrepen. Je kunt een hoop leuke dingen bedenken, maar in feite is alles klaar als iemand toegang krijgt tot je server.

In de praktijk is dat echter niet zo. Webservers op internet worden massaal gecompromiteerd en aanvallers gaan geen tijd besteden aan het decrypten van data. Vaak komt er geen mens bij aan te pas. De aanvallen zijn geautomatiseerd en dienen voor het serveren van phishing sites, proxies, spam en malware hosting. Het aantal servers dat malware serveert is vrij klein ten opzichte van het aantal gecompromiteerde servers. Spam en phishing komt wel veel voor.

Een uitzondering vormen de wat meer geavanceerde aanvallen, zoals ransomware. Maar ook die gaan niet veel tijd besteden aan het decrypten van data. Er zijn immers ruim voldoende andere slachtoffers die hun data niet versleutelen of waarbij gewoon in een geauthenticeerde sessie van de gebruikers ontsleutelde bestanden kunnen worden gekopieerd. De belangrijkste categorie aanvallers die er wel tijd aan besteden zijn hobbyisten ('hackers'), politie- en inlichtingendiensten. Dat is een relatief zeldzame categorie.

Conclusie: ook al staat de key op de server, het kan wel degelijk bijdragen aan het verlagen van het risico dat leesbare data op straat komt te liggen. De mate van benodigde beveiliging hangt af van de risico-analyse.

[downtime]

mrmrmr schreef op zondag 23 april 2023 @ 02:09:
[...]

In de praktijk is dat echter niet zo. Webservers op internet worden massaal gecompromiteerd en aanvallers gaan geen tijd besteden aan het decrypten van data. Vaak komt er geen mens bij aan te pas. De aanvallen zijn geautomatiseerd en dienen voor het serveren van phishing sites, proxies, spam en malware hosting. Het aantal servers dat malware serveert is vrij klein ten opzichte van het aantal gecompromiteerde servers. Spam en phishing komt wel veel voor.

Sowieso is er een reden waarom je geen processen, zoals een webapplicatie, als root/admin op een server wilt draaien. Als er dan toch een exploit wordt gevonden beperkt het de schade die de aanvaller kan aanrichten. Het is daarom veel te kort door de bocht om te beweren dat het “klaar” is als iemand toegang tot je server krijgt.