veiligheid multitenancy en MySQL login

[renevanh]

Ik ben aan het bouwen aan een 'mini-erp' om het zo maar even te noemen. Dit moet een SaaS product worden (via een VPS of cloud dienst).

De ontwikkeling doe ik op m'n huidige hosting die niet heel veel opties biedt. PHP, MySQL met PhpMyAdmin... en dat is het wel zo'n beetje.

Van dit systeem wil ik wat betreft de code meteen een multitenant systeem maken. Dus één code base. De databases zullen wel voor elke gebruiker afzonderlijk opgezet worden.
Er komt dus één loginscherm waar alle gebruikers inloggen. Dit valideert tegen database X, waarin login gegevens en klantgegevens staan. Ook de naam en pass van de MySQL database voor elke klant staat in deze tabel. Het loginscript trekt deze info eruit en maakt na een succesvolle login direct verbinding met de database van de betreffende user, database Y.

Nu had ik heel enthousiast het databasepassword encrypted opgeslagen in de database, maar dat vind MySQL niet leuk. Die werkt gewoon met plain text voor de validatie. De oplossing is om het wachtwoord als plain text op te slaan, maar dat brengt wel een risico mee: een hacker die op een of andere manier mijn klantendatabase zou binnen geraken zou ook direct toegang kunnen verkrijgen tot ALLE databases met data van mijn klanten.

Hoe zou ik dit het beste kunnen oplossen om de veiligheid op dit gebied te kunnen garanderen?

[Thund3r|IA]

Waarom zou je het database wachtwoord nog een keer los in de database willen opslaan? Is het dan niet handiger om gewoon voor elke gebruiker een mysql user aan te maken met het juiste wachtwoord en dan het door de klant ingevoerde wachtwoord ook gebruiken om verbinding te maken met de juiste database.

[renevanh]

Uhmm... ja, goed idee!

Dat ik daar zelf niet op gekomen ben zeg...
Fail.

{EDIT}

Wordt dan wel een uitdaging als de gebruiker het wachtwoord wijzigt, maar ook dat moet mogelijk zijn.
Als PhpMyAdmin het kan, kan ik het ook.

[ Voor 50% gewijzigd door renevanh op 03-11-2011 22:34 ]

[Thund3r|IA]

Het wachtwoord van een gebruiker wijzigen kan met het SET PASSWORD commando binnen MySQL.

[Miyamoto]

Is dit systeem ook nog handig met veel gebruikers? Als je maar 5 gebruikers hebt, ala. Maar als het om een systeem gaat met een 10-tal klanten, die weer een 100-tal gebruikers hebben?

Door de wachtwoorden van de gebruikers te kiezen, maak je het systeem misschien minder veilig dan dat je een sterk wachtwoord plain-text (of dmv two-way, maargoed, dat is puur visueel) opslaat? Je hebt dan maar 1 point of entry. Als ze daar binnen zijn, kunnen ze inderdaad overal bij. Als ze daar niet bij kunnen, heb je wel weer controle over de wachtwoord-sterkte en kun je de wachtwoorden periodiek veranderen.

Afhankelijk van je applicatie wil je ook niet een té strenge wachtwoord policy hanteren? Dus zul je gebruikers hebben met eenvoudige wachtwoorden, die dan dmv een brute force ook weer zo bekend zijn? Oke, je raakt dan maar 'n database van 1 klant kwijt (de kans op 'alle' databases wordt kleiner?), maar je bent sowieso de sjaak?

Oftewel: Kun je dit niet naar beide kanten goedpraten?

[Verwijderd]

En wat als 1 systeem meerdere gebruikers kan hebben, of komt dit nooit voor?

[renevanh]

Daar heb ik dus afgelopen dagen ook over zitten denken.

Meerdere gebruikers per klant kan, maar zullen er geen tientallen (laat staan 100-en) zijn. Eerder 2 of 3.
De software is dan ook gericht op kleine MKB'ers.

Je zou dan per gebruiker van een klant een login voor de MySQL database aan kunnen maken.
Maar... stel dat het stukje software een enorme klapper blijkt te zijn, dan zou dit de schaalbaarheid absoluut niet ten goede komen.

Aparte MySQL gebruikers betekenen daarnaast extra werk wanneer je een nieuwe klant moet invoeren of users moet toevoegen. Vanuit dat opzicht is het misschien wel goed te praten dat de wachtwoorden van de user databases in plain text opgeslagen worden. Dat is uiteindelijk bij elke MySQL database wel ergens het geval, PHP moet toch ooit eens verbinden.
Op dit moment ben ik even aan het verkennen of ik het dbconnect en het login script goed kan integreren zodat ik de database naam en pass niet in de sessie hoef op te slaan. Daarmee verkleind het risico zich al aanzienlijk denk ik.

In ieder geval heb ik nu meerdere opties om over na te denken, ook heel belangrijk.

[ Voor 8% gewijzigd door renevanh op 07-11-2011 19:19 ]

[MoBi]

Ik denk dat je het beste terug naar de tekentafel kan. Je kan een een waarde in je tabellen opnemen welke een "site" of installatie herbergt. Via de aanroep url van de inlog pagina kun je de "site" of installatie herleiden en de gebruiker gewoon tegen 1 maar alle queries met de "site" waarde in de query de db laten aan spreken.

Dit is ook schaalbaarder

[NetForce1]

MoBi schreef op maandag 07 november 2011 @ 21:51:
Ik denk dat je het beste terug naar de tekentafel kan. Je kan een een waarde in je tabellen opnemen welke een "site" of installatie herbergt. Via de aanroep url van de inlog pagina kun je de "site" of installatie herleiden en de gebruiker gewoon tegen 1 maar alle queries met de "site" waarde in de query de db laten aan spreken.

Dit is ook schaalbaarder

Het is nog maar zeer de vraag of dat een betere optie is. Je zult maar een keer een foutje maken met een query, liggen de gegevens van een van je klanten toch mooi op straat. Nu is dat natuurlijk altijd iets om rekening mee te houden, maar met gescheiden databases per klant heb je dat probleem toch een stuk minder.
Verder is het stukken lastiger om te splitsen naar verschillende servers / mysql-installaties als je gegevens van alle klanten bij elkaar mikt.

@TS: is het niet beter om zonder wachtwoord te werken? In PostgreSQL kun je configureren dat een bepaalde host met 'trust' kan authenticeren, dan hoeft men vanaf die host dus geen wachtwoord op te geven. Uiteraard moet je dan wel zorgen dat eea van buitenaf goed dichtgetimmerd is. Ik weet niet of dat met MySql ook kan.

Wat ook nog zou kunnen is een gebruiker aanmaken die alleen vanaf localhost kan connecten met de DB, dan is het imo geen probleem om het wachtwoord als plaintext op te slaan, je kunt er dan van buitenaf nl niks mee.

[ Voor 8% gewijzigd door NetForce1 op 07-11-2011 22:12 ]

[renevanh]

@MoBi: Dan spreek je dus over een 100% multi tenant systeem. Zeer verleidelijk, maar de vraag is of je klanten daar blij van worden. Mijn vermoeden is dat mijn klanten dat niet zien zitten en liever in een eigen, afgesloten database zitten waar de concurrent met geen mogelijkheid bij kan.
Ook al timmer je dat 100% dicht (wat mogelijk moet zijn), de data van de klanten staat toch erg dicht bij elkaar en daar zijn de klanten die het technisch inzicht ontberen niet blij mee. Daarom mijn keuze om met aparte databases te werken.
Overigens ligt dit specifieke onderdeel nog op de tekentafel. Ik heb nu een werkend prototype uitgaande van het MySQL wachtwoord in de database, maar dat is nog lang niet af, zeker niet op het gebied van veiligheid.

@NetForce1: De MySQL gebruikers kunnen uitsluitend vanaf localhost inloggen, dus dat probleem heb ik eigenlijk al opgelost. Echter bestaat er altijd wel een manier als je het wachtwoord weet. Stel dat de kwaadwillende hacker ook bedenkt dat het misschien via PhpMyAdmin kan (om maar eens iets te noemen)...
Daarom lijkt een 'trust' methode zoals in PostgreSQL mij niet verstandig. We spreken hier wel over vertrouwelijke bedrijfsinformatie, dus daar moet op z'n minst één maar bij voorkeur meerdere lagen beveiliging tussen zitten. Als het om een eenvoudig CMS systeempje zou gaan lijkt me die 'trust' authentificatie best wel handig, maar hier durf ik er toch niet aan.

[IceM]

Ik begrijp niet zo goed waarom je per database een aparte mysql login wilt gebruiken. Als ik je verhaal zo lees is de scheiding van data in verschillende databases vooral om tegen de klant te kunnen zeggen dat de data niet tussen de data van andere klanten staat en niet omdat je klanten direct op de database werken.

De data scheiden in verschillende databases zou je zo kunnen laten, daar is nog wel wat voor te zeggen. Ik zou alleen niet gaan werken met aparte mysql users per database. Binnen jou applicatie zou ik gewoon met 1 mysql gebruiker werken die bij alle databases kan. Voor het loginsysteem kun je dan een aparte database aanmaken met daarin een user/password/databasenaam tabel waarin je vast legt welke gebruiker eigenaar is van welke database. Bij een correcte inlog actie kun je dan de juiste database selecteren. Wanneer klanten in de toekomst alsnog direct toegang moeten hebben tot de database kun je altijd nog per database een aparte mysql login maken. Meerdere gebruikers per database is op deze manier ook afgevangen.

Zoiets krijg je dan (zonder in te gaan op passwordhashes/salts/encryptie etc, gaat om het idee)

code:

[db-erp]
    [tbl-users]
          [username]-[password]-[dbname]
            pietje, slkajlkjlkjl, db-pietje
            jantje, kjlskdljkj, db-jantje
            pietje2, slkdjflksjf, db-pietje
[db-pietje]
    [......]
[db-jantje]
    [......]