Database ontwerp login pagina [HOW TO]

[digital-IMEI]

Hey mensen,

Laat ik beginnen met te zeggen dat ik weinig ervaring heb met databases dus don't shoot me als ik de plank totaal mis sla!

ik zit al een aantal dagen met een technische uitdaging.

Ik wil graag met php en mysql een login pagina op 3 factoren controlleren maar ik weet niet hoe ik hier een db op moet maken.

Situatie:
Ik wil een loginpagina maken die vanaf verschillende url's op te vragen is, daarnaast kan een gebruiker het recht hebben om meerdere url's in te loggen en dienen deze rechten per domein verschillend te zijn.

Optie 1:
1 tabel met alle gegevens.
Alle gegevens in 1 regel op te slaan door gebruik te maken van serialize. In die array de url en de bijbehorende rechten opslaan. Als er meerdere url's zijn een kolom toevoegen en daar de volgende url/array in gooien.

username

password

array url1

array url2

enz...

nadeel is als een gebruiker op veel verschillende url's rechten heeft je veel overbodige info ophaalt waar je verder niets mee doet.

Optie 2
1 tabel met alle gegevens en per url 1 regel
Alle gegevens per gebruiker en per url op 1 regel zetten.

username

password

url

recht1

enz...

Nadeel is dat een gebruiker (en dus ook het wachtwoord) vaker voorkomt. Om te voorkomen dat een gebruiker per url een ander wachtwoord heeft zou je het wachtwoord wel overal in 1 keer wijzigen als een gebruiker dit wijzigt zonder dat hij het merkt.

Ik heb geen idee hoe ik dit het beste kan oplossen op de meest efficiente en veilige manier.

dus de eisen zijn;
• login controlleren op username, password en url
• meerdere users per url
• meerdere url's per user
• rechten per user per url
• wachtwoord per user overal gelijk

Ik hoop dat iemand mij hiermee verder kan helpen of iedereen heeft.

offtopic:
overigens nu ik dit schrijf vraag ik me af of ik de rechten wel op de correcte manier opsla dus daar ga ik me ondertussen in verdiepen

[Voutloos]

Beide opties zijn totaal fout. Je hebt de complete top3 van basic database structuur fouten namelijk in je post staan: serialized data, genummerde kolommen en 1 tabel voor alles.

Zo, nu dat bot aangegeven is komt hier de nuance en een denkrichting: Prima als db's nieuw voor je zijn maar lees je aub in voor wat betreft de basics qua structuur, normalisatie en relaties. Je zal (minstens !) 3 tabellen nodig gaan hebben: 1 met de users, 1 met de sites, en 1 met de rechten per user per site.

[remco_k]

^^ Hij zegt nog, don't shoot me...

Maar ik trap nog even na.
En sla het password nooit plaintext op in de db.

[ Voor 40% gewijzigd door remco_k op 24-09-2009 21:34 ]

[digital-IMEI]

Voutloos schreef op donderdag 24 september 2009 @ 21:28:
Beide opties zijn totaal fout. Je hebt de complete top3 van basic database structuur fouten namelijk in je post staan: serialized data, genummerde kolommen en 1 tabel voor alles.

Zo, nu dat bot aangegeven is komt hier de nuance en een denkrichting: Prima als db's nieuw voor je zijn maar lees je aub in voor wat betreft de basics qua structuur, normalisatie en relaties. Je zal (minstens !) 3 tabellen nodig gaan hebben: 1 met de users, 1 met de sites, en 1 met de rechten per user per site.

Nou in ieder geval wel duidelijk

Eerst even de vraag waarom geen serialized data te gebruiken? Leek mij wel makkelijk

Relaties had ik al het één en ander over gelezen maar ik wilde juist (nu blijkbaar) tegen de normalisatie principes in alles in 1 db opslaan.

Waar zou die 4e tabel dan voor dienen? Om even een beeld te krijgen

Ik ga Wikipedia verder lezen...

remco_k schreef op donderdag 24 september 2009 @ 21:33:
^^ en sla het password nooit plaintext op in de db.

Zover was ik al Voorlopig MD5

[Kettrick]

Sjengcity schreef op donderdag 24 september 2009 @ 21:43:
[...]

Relaties had ik al het één en ander over gelezen maar ik wilde juist (nu blijkbaar) tegen de normalisatie principes in alles in 1 db opslaan.

Waarom precies ?

[Voutloos]

Sjengcity schreef op donderdag 24 september 2009 @ 21:43:
Eerst even de vraag waarom geen serialized data te gebruiken? Leek mij wel makkelijk

Bij de 1e de beste query die iets met die data moeten doen (bijvoorbeeld een specifiek recht zoeken) ben je al 10x zoveel tijd kwijt dan dat je nu bespaart.

Relaties had ik al het één en ander over gelezen maar ik wilde juist (nu blijkbaar) tegen de normalisatie principes in alles in 1 db opslaan.

Beetje vreemd aanzien in je lijstje zo ongeveer letterlijk staat dat users:urls een many to many relatie is. En die derde tabel zorgt daarvoor, want dat is een koppeltabel (zoekterm ).

[Boss]

En dan krijg je dus iets als:
Tabel1:
- (PK) UserID
- UserName
- Password

Tabel2:
- UserID
- URL
- rechten

[Janoz]

Boss schreef op vrijdag 25 september 2009 @ 08:56:
En dan krijg je dus iets als:
Tabel1:
- (PK) UserID
- UserName
- Password

Tabel2:
- UserID
- URL
- rechten

Dat lijkt me niet. Ten eerste kan een URL nu maar bij slechts 1 gebruiker horen. Daarnaast geeft het meervoud van rechten aan dat je weer geserialiseerde data in 1 kolom op wilt slaan.

Iets als
USER
- id
- name
- password
- ...andere meuk

USER_URL
- userid
- urlid
- recht

URL
- id
- url
- ...andere meuk

[digital-IMEI]

Janoz schreef op vrijdag 25 september 2009 @ 09:42:
[...]


Dat lijkt me niet. Ten eerste kan een URL nu maar bij slechts 1 gebruiker horen. Daarnaast geeft het meervoud van rechten aan dat je weer geserialiseerde data in 1 kolom op wilt slaan.

Iets als
USER
- id
- name
- password
- ...andere meuk

USER_URL
- userid
- urlid
- recht

URL
- id
- url
- ...andere meuk

Maar op deze manier zul je dus altijd 2 checks moeten uitvoeren of de login ok is toch?
Eerst zul je moeten kijken of de user en password ok zijn en daarna ga je kijken of hij rechten heeft voor de gegeven url. Maakt dat niet uit wat betreft de veiligheid?

[MuddyMagical]

Sjengcity schreef op donderdag 24 september 2009 @ 21:43:

[...]
Zover was ik al Voorlopig MD5

Leerpuntje van de Fok! hack: Niet in MD5 aub. Gebruik óf een SALT in combinatie met MD5 óf sla je wachtwoorden op in een SHA-1

[bonzz.netninja]

Sjengcity schreef op vrijdag 25 september 2009 @ 10:17:
[...]

Maar op deze manier zul je dus altijd 2 checks moeten uitvoeren of de login ok is toch?
Eerst zul je moeten kijken of de user en password ok zijn en daarna ga je kijken of hij rechten heeft voor de gegeven url. Maakt dat niet uit wat betreft de veiligheid?

Het is sowieso heel gebruikelijk (en goed) om authorisatie los te koppelen van authenticatie. Als je een systeem hebt waar je netjes ingelogd blijft dat check je alleen nog maar op authorisatie

[Voutloos]

Sjengcity schreef op vrijdag 25 september 2009 @ 10:17:
Maar op deze manier zul je dus altijd 2 checks moeten uitvoeren of de login ok is toch?
Eerst zul je moeten kijken of de user en password ok zijn en daarna ga je kijken of hij rechten heeft voor de gegeven url. Maakt dat niet uit wat betreft de veiligheid?

Nee. Het aantal queries heeft 0 invloed.

bonzz.netninja schreef op vrijdag 25 september 2009 @ 10:20:
[...]

Het is sowieso heel gebruikelijk (en goed) om authorisatie los te koppelen van authenticatie. Als je een systeem hebt waar je netjes ingelogd blijft dat check je alleen nog maar op authorisatie

Regel 1 van hashing: Gebruik in een security context altijd een salt. Zo, klaar.

[Janoz]

Sjengcity schreef op vrijdag 25 september 2009 @ 10:17:
[...]

Maar op deze manier zul je dus altijd 2 checks moeten uitvoeren of de login ok is toch?
Eerst zul je moeten kijken of de user en password ok zijn en daarna ga je kijken of hij rechten heeft voor de gegeven url. Maakt dat niet uit wat betreft de veiligheid?

Niet perse. Je kunt keurig in 1 query het inloggen controleren en gelijk alle rechten ophalen (keyword is 'join' en dat kun je ook met meer dan 2 tabellen doen)

[drm]

Janoz:
Dat lijkt me niet. Ten eerste kan een URL nu maar bij slechts 1 gebruiker horen. Daarnaast geeft het meervoud van rechten aan dat je weer geserialiseerde data in 1 kolom op wilt slaan.

Iets als
[snip]

offtopic:
Beetje flauw misschien, maar de URL had in BOSS zijn voorbeeld best een samengestelde primary key met UserID kunnen zijn, er even vanuitgaande dat "URL" het enige is wat je over een URL op wilt slaan.

[Voutloos]

offtopic:
Dan nog wil je niet een dergelijke key hebben. En je kan toch op je klompen aanvoelen dat je meer data van de locaties op moet slaan...

En de allereerste reply had al een compleet antwoord

[Verwijderd]

MuddyMagical schreef op vrijdag 25 september 2009 @ 10:18:
[...]

Leerpuntje van de Fok! hack: Niet in MD5 aub. Gebruik óf een SALT in combinatie met MD5 óf sla je wachtwoorden op in een SHA-1

Leerpuntje van GoT ( ): SHA-1 is ontworpen om snel te zijn. Gebruik een bcrypt library.

http://blog.phusion.nl/20...-with-jruby-and-ruby-1-9/
http://barkingiguana.com/...salt-pepper-and-rainbows/
http://gom-jabbar.org/art...t-to-store-your-passwords

[ Voor 20% gewijzigd door Verwijderd op 29-09-2009 09:16 ]

[RobIII]

quote: http://blog.phusion.nl/20...-with-jruby-and-ruby-1-9/

Theoretically it would take 4*10^35 years for a single MacBook Pro core to crack an SHA-1 hash, assuming that the attacker does not harness any weaknesses in SHA-1. To crack a bcrypt hash one would need 6*10^39 years, or 10000 more times. Therefore, we recommend the use of bcrypt to store passwords securely.

offtopic:
Ja joh, een factor 10.000 boeit nog op een getal met 35 nullen Het verhaal klopt wel, maar kiezen voor een "slow" algo omdat het dan beter zou zijn is bull; dat het vaak zo is maakt het nog geen regel.

[Verwijderd]

offtopic:
Waarom zou je het niet doen? Het hashen van 1 wachtwoord kost zo goed als geen extra tijd...
Ik zie geen argument tegen, alleen voor.

[RobIII]

Verwijderd schreef op dinsdag 29 september 2009 @ 09:25:

offtopic:
Waarom zou je het niet doen? Het hashen van 1 wachtwoord kost zo goed als geen extra tijd...
Ik zie geen argument tegen, alleen voor.

offtopic:
Ik ben niet tegen; ik vind het alleen de verkeerde basis om je besluit op te nemen. "Oh, het is trager dus zal 't wel goed zijn". Ik kan prima een algo verzinnen dat 5 minuten staat te stampen om een hash uit te poepen maar waarvoor misschien een split-second een collision gevonden wordt. Een algo kies je op z'n algemene veiligheid, dus waar de kans op collisions zo dicht mogelijk bij 0 ligt (en uiteraard geen andere flaws in zitten) en niet op z'n snelheid

[Verwijderd]

offtopic:
Uiteraard maak ik geen beslissing op grond van 'het is langzamer dus beter', ik kan ook een crypto uit de grond stampen die 2 uur loopt te stampen op een hash. Waarschijnlijk is dat 2 uur verspilde processortijd, maar het is wel langzaam Ik wil m'n suggestie best uitgebreid beargumenteren met een lap tekst, maar ik heb verschillende links gepost waar het onderwerp behandeld wordt.

[_Noldy]

Laat ik maar terugkeren daar the main issue at hand

Misschien is het makkelijker om nog even het doel van normaliseren op te stellen. Volgens mij is dat: ervoor zorgen dat wanneer er ergens in de wensen iets bijkomt (een recht, een url, een gebruiker) dat er zo min mogelijk aan de database veranderd moet worden en ervoor zorgen dat je database niet redundant wordt. Kortom dat gegevens maar op 1 plek worden opgeslagen om zo corruptie te voorkomen.

Eigenlijk wil je niets aan je database hoeven veranderen ooit nog, en daarbij helpt normalisatie. Echter het is een keuze of je iets in de 3NF wil zetten of in de BCNF. Je kan natuurlijk ook doordraaien.

[digital-IMEI]

Ok,

heb me eens verdiept in het normaliseren gebeuren en ben heel wat wijzer geworden.

Ik wil een loginpagina maken die vanaf verschillende url's op te vragen is, daarnaast kan een gebruiker het recht hebben om meerdere url's in te loggen en dienen deze rechten per domein verschillend te zijn.

Hieraan wil ik alleen nog toevoegen dat ik ook wil weten wie "owner" is van een url aangezien er ook meerdere gebruikers op 1 url rechten kunnen hebben.

Brengt me in de volgende situatie:

User Table
UserID	UserName	Password
1	Pietje	*********
2	Jantje	*********
3	Truus	*********

Permissions
UserID	URLID	Recht 1	Recht 2	Enz...
1	1	true	true	true
2	2	true	false	true
3	1	true	false	false
1	2	true	true	true

URL
URLID	URL	UserID (owner)
1	google.com	1
2	tweakers.net	1

In het bovenstaande geval zou Pietje zowel owner zijn van de URL google.com als tweakers.net maar terwijl ik dit schrijf vind ik dus nog een fout...
Nu zou die moeten kloppen.

Ga ik op deze manier een beetje de juiste richting op? Alvast bedankt!

[ Voor 18% gewijzigd door digital-IMEI op 11-10-2009 15:07 ]

[BM]

Je gaat een eind in de goeie richting. Ik zou wel nog een aparte tabel maken waarin je alle rechten op slaat, en deze dan ook met een ID (zoals User en URL) koppelen in de Permissions tabel. Mocht er dan ook een nieuw 'recht' bij komen is het simpelweg een kwestie van een nieuwe entry aanmaken in die tabel, en hoef je niet je hele Permissions tabel te veranderen

[digital-IMEI]

BM schreef op dinsdag 13 oktober 2009 @ 14:10:
Je gaat een eind in de goeie richting. Ik zou wel nog een aparte tabel maken waarin je alle rechten op slaat, en deze dan ook met een ID (zoals User en URL) koppelen in de Permissions tabel. Mocht er dan ook een nieuw 'recht' bij komen is het simpelweg een kwestie van een nieuwe entry aanmaken in die tabel, en hoef je niet je hele Permissions tabel te veranderen

Die snap ik niet helemaal... Als ik in dit geval in de permission tabel een extra kolom doe toevoegen met een default value komt het toch op hetzelfde neer?

In de permissions tabel is recht1 en recht2 enz... Iets wat ze wel/niet mogen...

[compufreak88]

Sjengcity schreef op dinsdag 13 oktober 2009 @ 19:20:
[...]

Die snap ik niet helemaal... Als ik in dit geval in de permission tabel een extra kolom doe toevoegen met een default value komt het toch op hetzelfde neer?

In de permissions tabel is recht1 en recht2 enz... Iets wat ze wel/niet mogen...

Het is niet alleen een kwestie van de tabel aanpassen, maar ook al je code zal er op aangepast moeten worden. Als je het in een aparte tabel zet, is het veel makkelijker om dingen toe te voegen. Heeft een beetje te maken met het open-closed princiepe. Dat komt er op neer dat als je iets wilt veranderen, je dat kunt doen door dingen toe te voegen, ipb bestaande code te veranderen.

[Alain]

compufreak88 schreef op dinsdag 13 oktober 2009 @ 23:09:
[...]


Het is niet alleen een kwestie van de tabel aanpassen, maar ook al je code zal er op aangepast moeten worden.

Volgens mij los je dit probleem niet op met een koppeltabel. Sterker nog, je introduceert nieuwe regels die niet op database niveau afgehandeld kunnen worden. Als recht1 verplicht een waarde moet hebben (of een default waarde heeft) zal dit ergens geregeld moeten worden.

Het is afhankelijk van de situatie hoe je dit probleem aanpakt. Er is geen universele oplossing.

[digital-IMEI]

Ok, ik kom verder maar ook weer niet. Moet helaas toch hulp gaan vragen.

Wat betreft het bovenstaande lukt het me om de rechten op basis van de UserID en URL op te halen met een JOIN LEFT query. Foreign keys heb ik ook bijna overal (hopelijk goed) aangemaakt maar wat betreft de rechten tabel zelf loop ik vast.

Waar ik overheen had gekeken was dat ik de de rechten los wil kunnen uitlezen, dat wil zeggen; Recht1, Recht2 enz. wil ik kunnen ophalen. Deze zullen dus ook in een tabel moeten komen te staan wat het volgende zou geven;

Permissions
UserID	URLID	Recht 1	Recht 2	Enz...
1	1	true	true	true
2	2	true	false	true
3	1	true	false	false
1	2	true	true	true

Rights
RightID (?)	Rights
1	Recht1
2	Recht2
3	Recht3
4	enz

Nu zou ik in de permissions tabel Recht 1 enz kunnen vervangen door RightID maar dat gaat ook niet werken.

Iemand die mij een beetje in de juiste richting kan sturen hoe ik die tabel met rechten het beste kan maken zodat hij het makkelijkste ge-update kan worden als dat nodig is?

/me gaat zich nog eens verder verdiepen in 3NF en dergelijke...

[MadKow]

Een aparte tabel met de verschillende voorkomende rechten lijkt me inderdaad goed. Je permissions tabel kun je dan opbouwen als:

User ID, Url ID, Right ID, Value

Waarbij value dan true/false is

[digital-IMEI]

MadKow schreef op woensdag 14 oktober 2009 @ 21:30:
Een aparte tabel met de verschillende voorkomende rechten lijkt me inderdaad goed. Je permissions tabel kun je dan opbouwen als:

User ID, Url ID, Right ID, Value

Waarbij value dan true/false is

Ik kan me vergissen maar dan kom je uit in een situatie waarbij je het volgende krijgt;

code:

User ID, Url ID, Right ID, Value, Right ID, Value, Right ID, Value, Right ID, Value

Dit verdient ook niet bepaald de schoonheidsprijs en heel gebruiksvriendelijk komt het ook niet direct op me over...

[RikTW]

Ik zou dan in deze laatste tabel [User ID, Url ID, Right ID] als primaire key definiëren: een combinatie user/url kan dan vaker voorkomen, 1 keer voor iedere Right ID

[digital-IMEI]

RikTW schreef op woensdag 14 oktober 2009 @ 21:40:
Ik zou dan in deze laatste tabel [User ID, Url ID, Right ID] als primaire key definiëren: een combinatie user/url kan dan vaker voorkomen, 1 keer voor iedere Right ID

Ah, nu wordt het me duidelijk! Alleen nog even kijken of er dan geen manier is om die UrlID ergens anders te droppen want die komt anders heel vaak dubbel voor... FOUT!

Stom, een recht heeft natuurlijk niet alleen betrekking op een user maar ook op de url waar de user vanaf doet inloggen... Die moeten dus altijd bij elkaar.

Duidelijk!

/me Duikt weer in phpmyadmin om alles nog eens na te lopen en aan te passen.

edit; toch nog even dubbel checken. Je krijgt dan een situatie dat als er WEL een entry is de gebruiker rechten heeft en als er GEEN entry is de gebruiker dus ook geen rechten heeft?
Ben altijd van het volgende principe uitgegaan; er is altijd een entry aanwezig en die geeft aan of iemand rechten heeft

[ Voor 40% gewijzigd door digital-IMEI op 14-10-2009 21:49 ]

[RikTW]

Kan allebij, je kunt toch alsnog de value kolom toevoegen aan deze tabel?

[bigbeng]

Sjengcity schreef op woensdag 14 oktober 2009 @ 21:45:
...
Ben altijd van het volgende principe uitgegaan; er is altijd een entry aanwezig en die geeft aan of iemand rechten heeft

Dat lijkt me een gewenste situatie, mogelijk moet je wel wat code aanpassen om hiermee om te gaan.

Mocht je toch een waarde willen hebben, dan kun je door vanuit de "rechten" tabel te outer joinen een waarde forceren voor permissies. Deze waardes zullen null zijn als de permissie niet bestaat.

Pseudo (ongetest):

SQL:

select <gewenste velden>, isnull(eenpermissie, false) as eenpermissie
from recht
left outer join permissie ON <recht_pk> = <permissie_recht_fk>

Met de isnull (of wat de equivalent in MySQL ook is) kun je dus null-waarden omzetten naar false.

Ik hoop dat het een beetje te begrijpen is.

[digital-IMEI]

bigbeng schreef op donderdag 15 oktober 2009 @ 00:40:
[...]


Dat lijkt me een gewenste situatie, mogelijk moet je wel wat code aanpassen om hiermee om te gaan.

Mocht je toch een waarde willen hebben, dan kun je door vanuit de "rechten" tabel te outer joinen een waarde forceren voor permissies. Deze waardes zullen null zijn als de permissie niet bestaat.

Pseudo (ongetest):

SQL:

select <gewenste velden>, isnull(eenpermissie, false) as eenpermissie
from recht
left outer join permissie ON <recht_pk> = <permissie_recht_fk>

Met de isnull (of wat de equivalent in MySQL ook is) kun je dus null-waarden omzetten naar false.

Ik hoop dat het een beetje te begrijpen is.

Duidelijk, thx!~

ben nu voor alsnog verder gegaan met "alleen het recht als hij voorkomt" en denk daar wel al heel ver mee te komen voor nu.