ERP -> database per klant -> hoe login gegevens veilig stellen
Bij het inloggen wordt er gekeken aan welke database de klant is toegewezen.
Echter stuit ik op een probleem naar veiligheid.
Je kan een database maken met de login gegevens van elke database per klant maar wanneer je dan een db_connect.php zou aanmaken per klant heb je alsnog de login gegevens in plaintext nodig.
Stel dat je dan alsnog gehackt wordt dan ben zowel jij als je klanten de pineut.
Hoe wordt dit aangepakt?
De programmeertaal is PHP in combinatie met Mysql
Alvast bedankt voor jullie input.
Als je zorgen maakt om veiligheid: Extern auditbedrijf inhuren!
Plain logingegevens in een database is al not-done.
Gewijzigd op 27/03/2024 21:36:10 door - Ariën -
@Bart, ik zie twee problemen waar je tegenaan loopt.
Het eerste is dat je inlogt in de database server met de database account van je PHP-applicatie. Waarschijnlijk heb je voor de applicatie zelf meta-informatie en configuratiegegevens in de database, en bewaar je sessies in de database.
Daarbij wil je dat gebruikers kunnen inloggen.
Een veelvoorkomende oplossing is dat je dit helemaal in PHP wilt oplossen. Maar dat hoeft niet. Je kunt inloggen met de account van de applicatie, om vervolgens over te schakelen naar de account van de gebruiker (nadat deze met succes is ingelogd), via SET SESSION AUTHORIZATION. Enige is dat het niet in MySQL werkt, wel in serieuzere databases zoals PostgreSQL waarmee PHP prima kan werken.
Ik heb dit zo in mijn applicatie opgelost. Tegelijkertijd heb ik de wens om de applicatie-account los te koppelen van het inlogproces, zodat er geen applicatie-account meer nodig is. Dat is waarschijnlijk een rechten-kwestie in de database.
Wat ik in ieder geval niet kan aanraden is om zelf een rechtensysteem in PHP te gaan bouwen, dat is veel te tijdrovend en complex om het helemaal goed te doen. En het bestaat al in de database en het is helemaal getest, dus waarom zou je daar zelf nog tijd aan besteden?
Het tweede probleem is dat je wachtwoorden zegt te gaan opslaan als gewone tekst. Dit is inderdaad een groot risico en zelfs strafbaar.
Je dient wachtwoorden te hashen en alleen de hash op te slaan in de database. Hiervoor heeft PHP twee eenvoudige functies: password_hash() en password_verify(). Het standaard bcrypt hashing algoritme is tegenwoordig niet meer aan te bevelen (ook in verband met quantum computers), het beste dat je in PHP kan doen is gebruik maken van Argon2id.
Ik heb bijvoorbeeld nog geen uitbreiding gezien in PHP naar Kyber, een algoritme op 'post quantum computer' of PQC sterkte.
Kijk vooral bij de OWASP Cheat Sheet voor Passwords voor alle details omtrent veiligheid. Kijk ook bij de andere sheets, zoals die van PHP Configuration, Session Management, XSS prevention en alle andere die van toepassing zijn op jouw applicatie.
Gewijzigd op 28/03/2024 07:50:28 door Ad Fundum
----
Waarom per klant 1 database?
Hier is waarom:
1 database per klant geeft mij de flexibiliteit die nodig is om wensen van grote klanten uit te voeren die mede een impact kunnen hebben op de database.
1 database per klant geeft mij de mogelijkheid om 1 of meerdere databases te verhuizen naar een andere server zodat continuïteit en snelheid nog steeds geboden worden
1 database per klant geeft meer veiligheid/rust
----
Hoe ga ik ermee om als er updates dienen te gebeuren?
Updates kunnen alle databases treffen of enkele en dat is dan een kwestie van alles netjes bij te houden.
Zeker geen extra last.
Plain logingegevens in een database is al not-done.
Plain login gegevens zou ik nooit doen in een database maar ik maak mij wel zorgen omdat in het database connect bestand wel de login gegevens in plain text staan.
Indien de server gehackt wordt is het een kleintje om alle bestanden in te kijken lijkt me dan weer.Je hebt vanuit de root immers toegang om het bestand te lezen anders zou er niets werken toch?
@Ad Fundum,
Misschien had ik mij niet helemaal duidelijk gemaakt. Heel de applicatie zal webomgegving php worden. Ik vermoed dat je hierbij dacht dat ik vanuit een app op de gsm zou verbinden enz. , dat is namelijk niet het geval :)
Ik wens op een veilig manier middels de gebruikersnaam ,wachtwoord en klantsleutel wanneer men inlogt werkt met de juiste database.
Ik kan dit lijkt mij alleen maar doen als ik gebruik maak van meerdere dbconnect bestanden ( elke klant 1)
Maar uiteraard stoot ik hierbij wel op een probleem dat het wachtwoord en username dan wel in plaintext in het bestand staan...
Hoe kan je een map beveiligen dat zelfs wanneer je gehackt bent dat de hacker alsnog niet aan die map kan om de bestanden uit te lezen?
Of op welke manier zou ik het meerdere databases concept wel veilig kunnen maken?
Alvast bedankt voor jullie antwoord.
Ik ga ook uit van een PHP webbased omgeving.
Wat je wilt is geen probleem. Voor de applicatie kan je prima een sleutelbestand maken waarin je per verbinding de hostnaam, het poortnummer, de databanknaam, het account en het wachtwoord opslaat.
Kijk je naar PostgreSQL, die kan uit zichzelf gebruik maken van een verborgen bestand .pgpass , opgeslagen in de 'home' map van de applicatie-account. Het bestand zou alleen te lezen moeten zijn door de applicatie-account (in te stellen via chmod) en voor extra veiligheid is het goed om de /home map te versleutelen, of de hele partitie of schrijf te versleutelen met bijvoorbeeld LUKS.
Controleer dat PostgreSQL de wachtwoorden opslaat met scram-sha-256, dit is de standaard in nieuwere versies, in oudere moest je dit zelf aanpassen.
Het .pgpass bestand heb je alleen nodig als je de applicatie-firewall van PostgreSQL via pg_hba.conf zo hebt ingesteld dat er een wachtwoord nodig is. Je kunt er bijvoorbeeld ook voor kiezen dat de account waarmee de PHP-applicatie draait, juist géén wachtwoord nodig heeft om in te loggen, maar bijvoorbeeld standaard vertrouwd wordt. Het is dan wel zaak dat je applicatie niet draait op het standaard account van de webserver (bijvoorbeeld 'www-data')
Je wilt ook de verbinding tussen de PHP-applicatie en de database versleutelen, zodat er niet meegelezen kan worden. Dit regel je met een eigen CA-certificaat en private sleutel, en kan je aanmaken via openssl:
Code (php)
1
2
2
openssl genpkey -genparam -algorithm ec -pkeyopt ec_paramgen_curve:secp521r1 -out ecparam.pem
openssl req -new -newkey ec:ecparam.pem -x509 -noenc -days 365 -out ca-cert.pem -keyout ca-key.pem
openssl req -new -newkey ec:ecparam.pem -x509 -noenc -days 365 -out ca-cert.pem -keyout ca-key.pem
Met het CA-certificaat kan je andere certificaten tekenen, zodat je later kunt controleren of een aangeboden certificaat is getekend door het CA-certificaat. Dus of je een met TLS beveleigde verbinding vertrouwt. Het CA-certificaat houd je zelf, het getekende certificaat stel je in op de database. De server.key en server.crt zijn voor de database, en kan je configureren via postgresql.conf:
Code (php)
1
2
2
openssl req -newkey ec:ecparam.pem -noenc -keyout server.key -out server-req.pem
openssl x509 -req -days 3650 -set_serial 01 -in server-req.pem -out server.crt -CA ca-cert.pem -CAkey ca-key.pem
openssl x509 -req -days 3650 -set_serial 01 -in server-req.pem -out server.crt -CA ca-cert.pem -CAkey ca-key.pem
Als je alles eenmaal veilig hebt opgezet, heeft je PHP-applicatie een veilige verbinding met de database. Maar dan moet je ook nog wat als een gebruiker wil inloggen via jouw applicatie. Er van uitgaande dat je alleen PHP gebruikt zonder andere authenticatiemechanismen, kan je volstaan met een eigen "account" tabel waarmee je authenticatie regelt via PHP. Heb je een gebruiker geauthenticeerd, dan kan je in de database omschakelen naar de database account van de gebruiker met SET SESSION AUTHORIZATION, zodat de database de autorisaties regelt. Hiermee kan je het fijnmazige autorisatiesysteem van de database gebruiken met onder meer RLS, wat praktisch ondoenlijk is in PHP.
Dit is de oplossing zoals ik hem zelf heb geimplementeerd in mijn PHP-applicatie.
Een alternatief idee is dat je helemaal geen applicatie-account nodig hebt. Dit idee heb ik nog niet volledig kunnen uitwerken, omdat ik aanliep tegen de beperking dat SET SESSION AUTHORIZATION niet werkt binnen een SECURITY DEFINER functie. Mijn idee was om per sessie een extra account in de database aan te maken met de rechten van de ingelogde gebruiker, waarbij de accountnaam de sessie ID zou zijn, met natuurlijk een korte prefix. Zodat je met een paar UDF's sessiebeheer in de database zou kunnen doen in plaats van met PHP. Maar die vlieger gaat niet op. (Het is overigens sowieso veiliger om sessies in de database op te slaan, met een eigen sessie-implementatie of via de SessionHandlerInterface.)
Het beste wat ik nu kan bedenken is om de applicatie-account en de tabellen nodig voor authenticatie en sessies geheel te scheiden van de database van de gebruiker. Maar dan loop je tegen de beperking aan dat je geen uitzondering kunt maken voor noodgevallen met een red envelope procedure. Dus blijf ik met de situatie dat er altijd een applicatie-account nodig is.
Ik hoop dat iemand die dit tot hier leest een betere oplossing heeft?
Last but not least: vergeet ook niet om de webserver te voorzien van een TLS-certificaat, en check of je domeinnaam veilig is via internet.nl .
Wanneer je ondanks deze maatregelen toch wordt gehackt, dan heb je in ieder geval voldoende je best gedaan om hackers te weren, en kan je niet zomaar aansprakelijk gesteld worden wegens nalatigheid. Tenminste, als je ook de andere best practices, die in de IT-sector als bekend worden verondersteld, hebt geïmplementeerd. Hiervoor verwijs ik nogmaals naar de Cheat Sheets zoals gepubliceerd door OWASP.
Gewijzigd op 01/04/2024 09:29:34 door Ad Fundum
Hartelijk bedankt voor je wel uitgebreide uitleg :)
Ik ga hiermee aan de slag en hoop binnen zeker een jaartje al de eerste stappen van mijn systeem te kunnen ontplooien.