[PHP/MySQL] Het verwerken en opslaan van vertrouwelijke data

[Anoniem: 413552]

Goede avond,

Op dit moment ben ik me voor mezelf aan het oriënteren op het ontwikkelen van een website waarop door verschillende gebruikers vertrouwelijke gegevens zullen worden verwerkt en opgeslagen. Het veilig opslaan en verwerken van deze gegevens is dan ook erg belangrijk.

Helaas is zo goed als geen programma helemaal veilig en zijn bovendien er ook nog andere wegen die eventueel naar de data zouden kunnen leiden. Naast het fatsoenlijk programmeren (denk aan: sql injecties en cross site scripting voorkomen) is ook een fatsoenlijke implementatie en omgeving van de code en data belangrijk. Hiervoor heb ik in de eerste instantie het volgende, schematische, opzetje bedacht. In dit opzetje ga ik uit van een combinatie van PHP en MySQL.

• Om de data van de verschillende gebruikers gescheiden te houden en de toegang tot de data te beperken zal er voor iedere gebruiker een aparte database aangemaakt worden.
• In deze database staat ook het password (encrypted) van die betreffende gebruiker om in te loggen op de website
• Omdat het MySQL password ergens in een PHP bestand opgeslagen zal moeten worden had ik het idee om voor iedere gebruiker ook een eigen (virtuele) "webomgeving" aan te maken. In deze omgeving staat een "configuratie bestand" van de gebruiker opgeslagen met daarin in ieder geval het password en de gebruikersnaam voor de betreffende MySQL database.
• De rest van de (PHP) bestanden van de applicatie zullen via een symbolic link slechts virtueel in deze webomgeving aanwezig zijn.
• Verder wordt zal de verbinding in ieder geval via SSL moeten gaan.
• Voor het geval de database(s) (via een andere weg) toch op straat komt(en) te liggen zouden de gegevens in de database ook nog eens encrypted opgeslagen kunnen worden, maar dan moet er dus nog ergens een key worden bewaard om deze gegevens weer te decrypten. En verlies ik hierbij niet veel performance wanneer de data veelvuldig wordt opgevraagd?

Voor zover ik weet, en voor zover ik heb kunnen vinden, is er geen andere of veiligere optie om het MySQL password niet in een (PHP) bestand op te slaan, klopt dat?

Uiteraard is fatsoenlijke en veilige code en een juiste encryptie van passwords erg belangrijk, maar met bovenstaande opzet heb ik het idee al een aardige basis voor een veilige omgeving gelegd te hebben. Maar is dat wel echt zo? Zie ik niet iets over het hoofd of is deze oplossing zelfs al iets te omslachtig?

De keuze voor PHP en MySQL is vooral op mijn eigen ervaring en capaciteiten gebaseerd. In het realiseren van de website zou ik zoveel mogelijk zelf willen doen; dat is (slechts) mogelijk met een combinatie van PHP en MySQL. Wat betreft veiligheid, en bij de wat grotere systemen, wil er nog eens een "mysql vs. postgresql" discussie zijn. Zijn er los van die discussie grote bezwaren tegen het gebruik van een combinatie van PHP en MySQL in een systeem waarbij vertrouwelijke data wordt opgeslagen en bewerkt?

Alvast bedankt voor reacties en suggesties!

[Avalaxy]

Interessant, de vragen die jij stelt stelde ik mezelf de afgelopen week ook.

Hoeveel users ga je ongeveer hebben en hoe belangrijk is performance? Voor elke user een nieuwe database maken is denk ik niet te doen als je ~100.000 users hebt.

[Voutloos]

Mocht je het topic nog niet gezien hebben: [PHP] Gevoelige data opslaan heeft een aantal raakvlakken.

[kwaakvaak_v2]

Avalaxy schreef op zaterdag 02 juli 2011 @ 21:08:
Interessant, de vragen die jij stelt stelde ik mezelf de afgelopen week ook.

Hoeveel users ga je ongeveer hebben en hoe belangrijk is performance? Voor elke user een nieuwe database maken is denk ik niet te doen als je ~100.000 users hebt.

Met mysql is dat geen probleem, elke database is gewoon een set van files. Ik vraag mij alleen af wat je ermee wint om alle gebruikers een eigen tabel te geven. Als je server gehacked wordt hebben de hackers toch al toegang tot je omgeving, en kunnen ze de wachtwoorden die je voor al die db's gebruikt opvissen en eventueel de decryptie/encryptie sleutels ook. Dus is het eerder een zaak dat je er voor moet zorgen dat je de beveiliging van die server gewoon goed in orde hebt. Alle poorten die niet open moeten ook echt dicht zijn, en misschien zelfs wel zo ver gaan dat je enkel alleen via de directe console, of een bepaald IP adres bij de SSH tunnel mag. Werken met public/private key login ipv wachtwoorden etc.

[Voutloos]

Het losse DB idee is gok ik vooral bedoeld om de legitieme users van elkaar te scheiden, en niet zo zeer als beveiliging als alles al verloren is.

[cariolive23]

Kijk eens naar Security-Enhanced PostgreSQL, nog veiliger gaat het niet worden wanneer je kijkt naar de basis. De inrichting moet je uiteraard zelf doen, dat is de volgende stap. Je hebt hier (uiteraard) wel SE-Linux voor nodig, dat is logisch.

Met PostgreSQL versie 9.1 (is op dit moment nog in beta, productierelease zal hopelijk ergens in september/oktober zijn) heeft nog weer meer mogelijkheden voor SE, zie de handleiding. Controleer dan ook even of de beperkingen voor jouw situatie een probleem vormen. (lijkt me sterk, MySQL kent dit hele niveau van beveiliging niet)

En wanneer je de handleiding toch open hebt, check dan ook even de extensie pgcrypto. Hiermee kun je bv. met PGP de data beveiligen, kan niemand er meer wat mee zonder de sleutel te kennen.

Maar welke software je ook gebruikt, jij moet het veilig inrichten en gebruiken! Een auto kan nog zoveel kreukelzones hebben, wanneer jij het water inrijdt, zul je nog steeds verzuipen...

"By default, PostgreSQL is probably the most security-aware database available ..."
Database Hacker's Handbook

[YopY]

Aparte tabellen per gebruiker zou logisch klinken als je elke aparte gebruiker ook een eigen mysql user account maakt, maar dat maakt het niet automatisch veilig. Als het wachtwoord van de gebruiker gejat wordt, is het nog steeds weg. Als de DB username / password ergens opgeslagen staan (niet of zwak encrypted, of toegangkelijk via een apart gebruikersaccount) is het ook niet meer veilig. Beveiliging is maar zo sterk als de zwakste schakel, etc.

[Anoniem: 146875]

Onlangs heb ik iets soortgelijks gemaakt voor een kennis. Er zijn hier al eerder topics over geweest op tweakers en wat ik zelf belangrijk vond:

• Sla het wachtwoord op met salt en pepper. Salt is bijvoorbeeld: 'se90r34r.rkj32@', pepper kun je de lengte van het wachtwoord nemen. Bereken de sha512 waarde van (password + salt + pepper + password) en daarna weer de sha512 van het resultaat + password oid. Doe dit een keertje of 1000-5000 en je wachtwoorden zijn alleen nog te kraken met bruteforce.
• In .htaccess kun je elk request omschrijven naar een verplicht SSL request
• Blokker alle include files met .htaccess. PHP kan de bestanden dan nog includen maar een gebruiker kan ze niet openen vanaf een remote locatie.
• Zet MySQL alleen open voor localhost, of gebruik iptables om de database te blokkeren vanaf alle poorten behalve een
• Gebruik denyhosts om SSH-bots te blokkeren
• Een aparte database is niet veiliger dan een gedeelde tabel. Als het goed is heb alleen jij/PHP toegang tot die tabel

Ik hoop dat je er wat aan hebt!

[alienfruit]

Een van de oplossing die wij gebruikten was whitelisting in de firewall oftewel je kan er alleen maar bij als je ip adres in de firewall staat. Dit werkte prima en sommige klanten wilde het ook alleen op deze manier.

[Anoniem: 96523]

Ik heb zelf een applicatie gemaakt waar verschillende klanten gebruik van kunnen maken en waar de klant persoonsgegevens van klanten (van onze klant) in opslaan.

Wat ik heb gedaan komt ongeveer overeen met de opzet die jij hebt gemaakt.

Er is één locatie waar alle PHP staat, maar is toegankelijk vanaf verschillende subdomeinen (per klant uniek). Er is een aparte login database met de logingegevens voor alle klanten waar gebruiksnaam + wachtwoord + subdomain gecontroleerd wordt. Als dit klopt wordt de juiste database teruggegeven (niet herkenbare naam), een wachtwoord (voor database gebruiker) en een deel van een decryptie sleutel. Het andere deel staat ergens op de server in een bestandje.

Alle persoonsgegevens (naam, adres, email, etc.) zijn geëncrypt door MySQL.

Daarnaast maak ik gebruik van verschillende gebruikers en rechten van de database. De login database heeft bijvoorbeeld alleen leesrechten op de eigen database, en elke klant database heeft een eigen gebruikersnaam / wachtwoord met minimale rechten. Dus het is onmogelijk om dmv SQL injecties bij andere klanten te komen, hoewel injecties al tot het minimum zijn gebracht (gebruik van PDO, zo min mogelijk "open" queries, etc).

De enige manier om de databases te kunnen lezen is wanneer je root toegang hebt tot de server (en heel veel tijd), en dat is bijna onmogelijk.

[TJHeuvel]

Anoniem: 146875 schreef op maandag 04 juli 2011 @ 09:42:
Onlangs heb ik iets soortgelijks gemaakt voor een kennis. Er zijn hier al eerder topics over geweest op tweakers en wat ik zelf belangrijk vond:

• Blokker alle include files met .htaccess. PHP kan de bestanden dan nog includen maar een gebruiker kan ze niet openen vanaf een remote locatie.

Ik hoop dat je er wat aan hebt!

Je had ze ook gewoon buiten de webroot kunnen zetten

[Anoniem: 146875]

CyCloneNL schreef op maandag 04 juli 2011 @ 10:30:
[...]

Je had ze ook gewoon buiten de webroot kunnen zetten

Inderdaad ook een goede tip, had ik nog niet aan gedacht

[moozzuzz]

Anoniem: 146875 schreef op maandag 04 juli 2011 @ 09:42:
Sla het wachtwoord op met salt en pepper. Salt is bijvoorbeeld: 'se90r34r.rkj32@', pepper kun je de lengte van het wachtwoord nemen. Bereken de sha512 waarde van (password + salt + pepper + password) en daarna weer de sha512 van het resultaat + password oid. Doe dit een keertje of 1000-5000 en je wachtwoorden zijn alleen nog te kraken met bruteforce.

Dit lijkt me juist niet handig om meerdere malen de sha() over een resultaat te gooien. Kan je me dit even argumenteren?

[Rukapul]

moozzuzz schreef op maandag 04 juli 2011 @ 13:15:
[...]

Dit lijkt me juist niet handig om meerdere malen de sha() over een resultaat te gooien. Kan je me dit even argumenteren?

Het verhoogt de workload om een wachtwoord brute force te kraken. Het kan echter niet op tegen gewoon een fatsoenlijk sterk wachtwoord te kiezen (dat werkt immers exponentieel door in de tijd in plaats van als een vaste factor).

Meer info is ook te vinden in password key derivation functions. Een standaard daarvoor is PBKDF2 (zie o.a.
http://www.ietf.org/rfc/rfc2898.txt )

[CodeCaster]

moozzuzz schreef op maandag 04 juli 2011 @ 13:15:
[...]

Dit lijkt me juist niet handig om meerdere malen de sha() over een resultaat te gooien. Kan je me dit even argumenteren?

http://stackoverflow.com/...than-just-hashing-it-once

[ReenL]

• Sla het wachtwoord op met salt en pepper. Salt is bijvoorbeeld: 'se90r34r.rkj32@', pepper kun je de lengte van het wachtwoord nemen. Bereken de sha512 waarde van (password + salt + pepper + password) en daarna weer de sha512 van het resultaat + password oid. Doe dit een keertje of 1000-5000 en je wachtwoorden zijn alleen nog te kraken met bruteforce.

Nooit je password bij de sha-iteraties gebruiken. Dan hoef je alleen de laatste hash te brute forcen en dan staat het wachtwoord er gewoon plain text achter...

[Low-Tech]

Om zaken als brute force tegen te gaan is het zoals eerder genoemd belangrijk een sterk wachtwoord te kiezen. Wat verder helpt is het toevoegen van een maximaal aantal keren foutief inloggen.

[BCC]

Ik zou beginnen met de handleidingen van het CBP te lezen omtrent het verwerken van vertrouwelijke data. Je hebt namelijk een stuk meer wettelijke verplichting dan je wapenen tegen SQL injectie

Begin hier eens: http://www.rijksoverheid....rkerspersoonsgegevens.pdf

[Voor 33% gewijzigd door BCC op 04-07-2011 14:02]

[Jaap-Jan]

ReenL schreef op maandag 04 juli 2011 @ 13:43:
[...]

Nooit je password bij de sha-iteraties gebruiken. Dan hoef je alleen de laatste hash te brute forcen en dan staat het wachtwoord er gewoon plain text achter...

Bij hashes gaat het er juist om om collissions te krijgen, dat kan met brute force. Als ik een hash van bijvoorbeeld een woordenboek probeer te brute forcen en het lukt, dan hoeft dat niet te betekenen dat ik de originele versleutelde tekst terug krijg. Het kan gewoon een (veel kortere) string zijn die dezelfde hash oplevert.

Hashes zijn, in tegenstelling tot encyptie, niet bedoeld om de originele data weer terug te kunnen halen.

[Voutloos]

Dat weet ReenL ook wel, hij merkt enkel een fout in hetgeen hij quote op.

[Jaap-Jan]

Dan richt ik dat aan degene die hij quote en dat klopt het weer.

[Anoniem: 146875]

ReenL schreef op maandag 04 juli 2011 @ 13:43:
[...]

Nooit je password bij de sha-iteraties gebruiken. Dan hoef je alleen de laatste hash te brute forcen en dan staat het wachtwoord er gewoon plain text achter...

Er zijn twee problemen met deze opmerking:
1. de "laatste" hash is een combinatie van password + salt + pepper + 1000+ voorgaande hashes
2. de hash is 128 karakters. Die kun je in de praktijk niet bruteforcen

[eghie]

Anoniem: 146875 schreef op maandag 04 juli 2011 @ 15:23:
[...]

Er zijn twee problemen met deze opmerking:
1. de "laatste" hash is een combinatie van password + salt + pepper + 1000+ voorgaande hashes
2. de hash is 128 karakters. Die kun je in de praktijk niet bruteforcen

Wees er maar niet zo zeker van dat je in die praktijk niet kunt bruteforcen. Zeker met OpenCL en CUDA tegenwoordig en de grote clusters, kun je soms aardig wat bruteforcen waar vroeger van werdt gedacht dat je die NOOIT kon bruteforcen. Zeker als ze nog eens shortcuts in de algoritmen kunnen vinden om het bruteforcen sneller te maken, dan gaat dat een stuk harder. Ik ben wel met je eens dat het op moment geen doen is.

Je moet zorgen dat je de hele ketting van browser client, tot aan de database beveiligd. En de keys niet zomaar in een config file hebt staan ofzo. En je OS ook beveiligen. Dat is een hoop werkt om dat echt van begin tot eind goed te regelen. Zeker met een control panel die over het algemeen voor het algemeen gebruik zijn gemaakt en vaak niet heel goed erg goed dicht te timmeren zijn.


Hier een paar tutorials die je door kunt lopen, om eens kaal naar PHP te kijken icm beveiliging:
• http://www.phpfreaks.com/tutorial/php-security
• http://www.addedbytes.com/writing-secure-php
• http://www.codeproject.co.../SqlInjectionAttacks.aspx
• http://www.php-security.o...ur-dynamic-php/index.html
• http://php-security.org/2010/05/01/article-php-web-security/

[Voor 15% gewijzigd door eghie op 04-07-2011 19:59]

[Anoniem: 413552]

Tot nog dan toe staan er al een aantal goede tips in, her en der was ik zeker al van een aantal zaken op de hoogte, maar toch nog eens goed deze bevestigd te zien. Het genoemde topic waarin er wordt gesproken over data die 30 jaar bewaard zou moeten worden heb ik inderdaad ook al eens doorgelezen.

Om nog even iets meer informatie te geven: het zal in de eerste instantie om ongeveer 1000 gebruikers gaan.

Voutloos schreef op zondag 03 juli 2011 @ 03:20:
Het losse DB idee is gok ik vooral bedoeld om de legitieme users van elkaar te scheiden, en niet zo zeer als beveiliging als alles al verloren is.

Losse databases met eigen gebruikers zijn inderdaad bedoeld om ieder gebruiker van het systeem van elkaar te scheiden. Zo zal bij een sql injectie, mocht die er toch ergens insluipen, nooit alle data zomaar toegankelijk zijn.

YopY schreef op zondag 03 juli 2011 @ 19:14:
Aparte tabellen per gebruiker zou logisch klinken als je elke aparte gebruiker ook een eigen mysql user account maakt, maar dat maakt het niet automatisch veilig. Als het wachtwoord van de gebruiker gejat wordt, is het nog steeds weg. Als de DB username / password ergens opgeslagen staan (niet of zwak encrypted, of toegangkelijk via een apart gebruikersaccount) is het ook niet meer veilig. Beveiliging is maar zo sterk als de zwakste schakel, etc.

Je laatste opmerking is zeker waar. Verder zit er met de combinatie php/mysql wel mee dat de mysql username en password ergens in een php bestand opgeslagen zullen moeten worden. Of in ieder geval: veel betere alternatieven ben ik niet tegen gekomen. Hierdoor heb ik er vervolgens weer voor gekozen iedere gebruiker een eigen "webomgeving" (met eigen mysql account + db) te geven. Het is verder nog maar te bezien wat dit met performance gaat doen.

Waar ik me verder ook nog een beetje druk over maak is het moment dat zo'n database misschien wel toegankelijk zou zijn. Is het denkbaar om de data encrypted op te slaan en voor iedere bewerking weer te decrypten? En wat zou dat voor impact op de performance hebben?

BCC schreef op maandag 04 juli 2011 @ 14:00:
Ik zou beginnen met de handleidingen van het CBP te lezen omtrent het verwerken van vertrouwelijke data. Je hebt namelijk een stuk meer wettelijke verplichting dan je wapenen tegen SQL injectie

Begin hier eens: http://www.rijksoverheid....rkerspersoonsgegevens.pdf

Richtlijnen/regels van het CBP kwam ik al eens tegen. Gelukkig gaat het in dit geval niet zozeer om persoonsgegevens.

[Anoniem: 413552]

cariolive23 schreef op zondag 03 juli 2011 @ 08:49:
Kijk eens naar Security-Enhanced PostgreSQL, nog veiliger gaat het niet worden wanneer je kijkt naar de basis. De inrichting moet je uiteraard zelf doen, dat is de volgende stap. Je hebt hier (uiteraard) wel SE-Linux voor nodig, dat is logisch.

Met PostgreSQL versie 9.1 (is op dit moment nog in beta, productierelease zal hopelijk ergens in september/oktober zijn) heeft nog weer meer mogelijkheden voor SE, zie de handleiding. Controleer dan ook even of de beperkingen voor jouw situatie een probleem vormen. (lijkt me sterk, MySQL kent dit hele niveau van beveiliging niet)

En wanneer je de handleiding toch open hebt, check dan ook even de extensie pgcrypto. Hiermee kun je bv. met PGP de data beveiligen, kan niemand er meer wat mee zonder de sleutel te kennen.

Maar welke software je ook gebruikt, jij moet het veilig inrichten en gebruiken! Een auto kan nog zoveel kreukelzones hebben, wanneer jij het water inrijdt, zul je nog steeds verzuipen...


[...]

Een combinatie van SE PostgreSQL en SE-Linux klinkt in de basis erg goed, in ieder geval is er de focus op veiligheid. Echter heb ik geen ervaring met SE-Linux of PostgreSQL, waardoor het mijn eigen bijdrage in dit projectje misschien wel erg zal gaan beperken. Is het denkbaar om "slechts" een combinatie van MySQL en PHP voor dit doel te gebruiken, of ontbreekt het hierin toch echt aan veiligheid (en performance)?

[eghie]

Ik heb nog een handige template htaccess die je iig probeerd van wat basis SQL injectie te houden. Het is geen volwaardige beveiliging hoor, maar een extratje.


.htaccess

code:

# For installing a debugger/profiler:
# command line: pecl install xdebug-beta

# Protect hidden files from being viewed (also htaccess and stuff like that)
<Files .*>
    Order allow,deny
    Deny from all
    Satisfy All
</Files>

#See: http://stackoverflow.com/questions/2520566/how-to-make-this-htaccess-rule-case-insensitive
<Files ~ "\.(?i:sql|swp|inc|inc\.php|log|phps|ini|cfg|fla|log|sh|tmp|bak)$">
    Order allow,deny
    Deny from all
    Satisfy All
</Files>

<FilesMatch "\.(?i:ico|bmp|jpg|jpeg|png|gif|js|css|flv|avi|swf|webp)$">
    <IfModule mod_expires.c>
        ExpiresActive on
        ExpiresDefault "access plus 30 days"
    </IfModule>
    Header unset ETag
    FileETag None
    Header append Cache-Control "public"
</FilesMatch>
 
AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css application/javascript application/x-javascript  application/rss+xml application/atom_xml text/javascript

ServerSignature Off

# pass the default character set
AddDefaultCharset utf-8

#PHP Settings
php_flag magic_quotes_gpc off
php_flag allow_url_fopen off
php_flag register_globals off
php_flag enable_dl off

php_value session.gc_maxlifetime "28800"
#php_value session.save_path "/path/to/your/tmp/outside/your/webroot/but/inside/homedir"


#Rewrite access security
#See also: http://bodvoc.com/index.php?option=com_content&view=article&id=43:improving-your-joomla-htaccess-file&catid=2:joomla-security&Itemid=3
<IfModule mod_rewrite.c>
    RewriteEngine on

    #Block TRACE and TRACK requests
    RewriteCond %{REQUEST_METHOD}  ^(TRACE|TRACK) [NC,OR]
    
    # If using WebDAV, comment the following line
    RewriteCond %{REQUEST_METHOD}  ^(HEAD|OPTIONS|PUT|DELETE) [NC,OR]

    RewriteCond %{THE_REQUEST}     (\\r|\\n|%0A|%0D|%00) [NC,OR]
    
    RewriteCond %{HTTP_REFERER}    (<|>|'|%0A|%0D|%27|%3C|%3E|%00) [NC,OR]
    
    RewriteCond %{HTTP_COOKIE}     (<|>|'|%0A|%0D|%27|%3C|%3E|%00) [NC,OR]

    RewriteCond %{HTTP_USER_AGENT} (nikto|scan|winhttp|HTTrack|clshttp|archiver|loader|email|harvest|extract|grab|miner) [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} (<|>|'|%0A|%0D|%27|%3C|%3E|%00) [NC,OR]
    
    # If using localhost or 127.0.0.1 in your webapp, comment the following line
    #RewriteCond %{QUERY_STRING}    (localhost|loopback|127\.0\.0\.1) [NC,OR]
    RewriteCond %{QUERY_STRING}    (<|>|'|%0A|%0D|%27|%3C|%3E|%00) [NC]

    RewriteRule .* - [F]
</IfModule>