[Web/PHP] Een goed cross-site inlogsysteem maken

[Alex)]

Ik ben voornemens om mijn eigen website (http://www.alex-web.nl) opnieuw op te gaan bouwen. Omdat veel kant-en-klaar-systemen zoals fora en CMS'en incompatible zijn met elkaar (je kunt met de gegevens van bijvoorbeeld WordPress niet inloggen op een SMF-forum), wil ik alles zelf gaan opbouwen. Echter wil ik ervoor zorgen dat er maar één keer hoeft te worden ingelogd op mijn site.

Nu is dit op zich niet zo moeilijk, dit is gewoon met sessies te realiseren. Maar: ik wil cross-site kunnen inloggen, en niet alleen via subdomains (http://forum.alex-web.nl, http://weblog.alex-web.nl etc), want dat is nog te regelen via cookie-path.

Wat ik wil is dat ik op alle sites die ik maak (zelfs al host ik het op een .cc-domein om maar wat te noemen) kunnen inloggen met één user en pass, en zodra ik daar ben ingelogd op alle sites. Een beetje zoals met het Microsoft Passport/Windows Live ID.

De taal die ik hiervoor op het oog heb is PHP, met daarachter MySQL als backend. In verband met bedrijfsnetwerken en wisselende IP's is het onvoldoende om een sessietabel te maken met daarin een IP-adres, er moet een cookie bij zodat de user echt op een specifieke machine is ingelogd. Hier zit echter ook het probleem: veel browsers (waaronder IE) blokkeren cookies van een derde site standaard, hierdoor is het dus onmogelijk om zonder herconfiguratie van IE (of een andere browser) cross-site te kunnen inloggen.

Omdat ik het niet meer weet wil ik hulp vragen aan de immer alwetende Tweakers: wat is de beste manier om, in PHP, een cross-site inlogsysteem te maken? En hoe kan ik dit het beste implementeren?


Ik heb dit topic niet in PRG geplaatst omdat ik nog geen enkele byte code heb en dit topic volgens de beschrijving van SEA beter in SEA past

[djc]

Ik zou eens naar OpenID kijken.

[Pooh]

Kun je niet veel simpeler gewoon een alexsecurity.com ofzo registereren, en elke site zo bouwen dat de logins en sessies daardoor worden afgehandeld?

[Alex)]

Dat is ook wel de bedoeling, maar wat ik nog niet weet is hoe ik het inlogsysteem en de sites het beste kan laten samenwerken.

[Verwijderd]

Misschien kun je hier eens naar kijken.

Ik ben overigens benieuwd naar mogelijke oplossingen

[AtleX]

Kijk eens naar het topic [PHP]Cross domain login, hoe?, daar staan ook een aantal goede ideeën in.

[masq]

Idee dat ik ooit op een ander forum heb gepost: ( AtleX: )

Één server (of domein) alle login logic af laten handelen. Bij een login genereer je een unique id.
Als server X wil inloggen of wil controleren of er ingelogd is wordt de user naar de centrale loginserver geleid, deze redirect weer naar server X met het unique id bijgevoegd (mits men succesvol heeft ingelogd of al ingelogd was uiteraard). Server X kan het unique id opslaan in zijn session data en gebruiken om bij de centrale server "remote" een login check te doen (dwz een HTTP request van server X naar de centrale loginserver, via SOAP of gewoon iets customs)

[Pete]

masq schreef op donderdag 02 november 2006 @ 18:35:
Idee dat ik ooit op een ander forum heb gepost: ( AtleX: )

Één server (of domein) alle login logic af laten handelen. Bij een login genereer je een unique id.
Als server X wil inloggen of wil controleren of er ingelogd is wordt de user naar de centrale loginserver geleid, deze redirect weer naar server X met het unique id bijgevoegd (mits men succesvol heeft ingelogd of al ingelogd was uiteraard). Server X kan het unique id opslaan in zijn session data en gebruiken om bij de centrale server "remote" een login check te doen (dwz een HTTP request van server X naar de centrale loginserver, via SOAP of gewoon iets customs)

Ok, dit werkt. Maar wat nu als een gebruiker naar een andere site gaat. Het liefst wil je meteen weten dat die gebruiker is ingelogd (ook voor die site). Niet dat de gebruiker eerst weer moet inloggen.

Wat ik mij afvroeg, kun je tijdens een redirect cookies meesturen? In dat zou je kunnen inloggen op de nieuwe site met eerst een redirect naar de loginserver -> deze leest zijn cookie en ziet dat je een user bent -> redirect je naar het andere domein met een loginid in de get -> deze pagina maakt een cookie van de loginid en redirect naar de intropagina. En daarna zou je idd de cookies kunnen valideren door het echte domein bij de inlogserver.

[masq]

phsmit schreef op donderdag 02 november 2006 @ 18:54:
[...]
Ok, dit werkt. Maar wat nu als een gebruiker naar een andere site gaat. Het liefst wil je meteen weten dat die gebruiker is ingelogd (ook voor die site). Niet dat de gebruiker eerst weer moet inloggen.

even iets verder uitgewerkt:

Domein X is het domein waarop alle login logic wordt afgehandeld.

De gebruiker is nog niet ingelogd, en wil vanaf domein Y inloggen:

1. domein Y redirect naar domein X
2. domein X handelt de login af en start een sessie met een uniek ID
3. domein X redirect terug naar domein Y met sessie ID als parameter
4. domein Y valideert het sessie ID bij domein X (remote, via SOAP bijvoorbeeld)
5. domein Y slaat het sessie ID op in een "lokale" sessie

Als de gebruiker vervolgens domein Z bezoekt dan is het stappenplan hetzelfde, alleen kan stap 2 overgeslagen worden omdat de gebruiker al ingelogd is.

Na het doorlopen van deze stappen hoeft een domein slechts bij elk bezoek stap 4 te herhalen. Wordt er ergens uitgelogd, dan valideert het sessie ID niet langer en kan de "lokale" sessie worden verwijderd.

[Alex)]

Mm, dat zou best eens kunnen werken... alleen, hoe werkt het wanneer domein Y geen uitgaande sockets aan kan maken? (denk aan safe mode etc)

[MBV]

ehm, dan ben je, in goed engels, screwed . Je kan dan namelijk niet meer valideren van welke gebruiker de sessie id was, dus je basisprincipe van authenticatie gooi je dan om zeep.
Enige wat je dan kan doen is iets wat vergelijkbaar is met PGP: je geeft de sessie ID door, user ID, en de tijd (op 10 sec nauwkeurig ofzo, die je niet meestuurt), en berekent daar een hash over. Met die hash kan je kijken of het secret klopt van de server. Met eventuele versleuteling van de rest van het bericht kan je zorgen dat mensen niet meer kunnen zien wie er doorgestuurd wordt.

Ik zou hier eens goed over na moeten denken, want ik ben er niet van overtuigd dat je hiermee je veiligheid waarborgt. Ik ben bang dat je secrest hier te snel mee te berekenen is. Maar ik ben bang dat je niet veel meer kan, als je niet achter de rug van de gebruiker om iets kan doen.

[Alex)]

Dat is bij mij gelukkig niet het geval, maar stel dat dat ooit wel zo is. Dan is het systeem dus minder bruikbaar. Misschien iets met forms en wat coderingen (blowfish) met als private key een hash van hostnames etc.

[Pete]

masq schreef op donderdag 02 november 2006 @ 20:25:
[...]


Als de gebruiker vervolgens domein Z bezoekt dan is het stappenplan hetzelfde, alleen kan stap 2 overgeslagen worden omdat de gebruiker al ingelogd is.

Maar hoe weet domein Z dat de user al ingelogt is? Er is geen cookie gezet op dat domein. Dus je moet zoiezo dan al redirecten naar domein X. En nu de opmerking van mij: kan X tijdens een redirect cookies lezen en setten? Anders is er geen mogelijkheid dat X (of Z) weet dat de gebruiker al ingelogt is.

[Erkens]

phsmit schreef op donderdag 02 november 2006 @ 21:54:
Maar hoe weet domein Z dat de user al ingelogt is? Er is geen cookie gezet op dat domein. Dus je moet zoiezo dan al redirecten naar domein X. En nu de opmerking van mij: kan X tijdens een redirect cookies lezen en setten? Anders is er geen mogelijkheid dat X (of Z) weet dat de gebruiker al ingelogt is.

Je moet dan ook een clientside redirect doen, dus bijvoorbeeld een refresh header sturen

[Alex)]

Wat je zou kunnen doen is een inlogknop maken die redirect naar de loginserver. De loginserver weet dat de user al is ingelogd en redirect de user terug naar domein Z, maar stuurt ook code mee naar domein Z zodat domein Z dat ook weet.

[Pete]

Erkens schreef op donderdag 02 november 2006 @ 21:55:
[...]
Je moet dan ook een clientside redirect doen, dus bijvoorbeeld een refresh header sturen

Maar dit kost veel tijd. En aangezien je dit voor iedere nieuwe bezoeker op de site moet doen (je weet tenslotten nog niet of deze per ongeluk ingelogd is) zal de eerste indruk van bezoekers zijn dat je site traag is. (en hoe zouden zoekmachines dit vinden)

Alex) schreef op donderdag 02 november 2006 @ 21:55:
Wat je zou kunnen doen is een inlogknop maken die redirect naar de loginserver. De loginserver weet dat de user al is ingelogd en redirect de user terug naar domein Z, maar stuurt ook code mee naar domein Z zodat domein Z dat ook weet.

Dit betekent dat een gebruiker alsnog eerst actie moet ondernemen op domein Z (namelijk op een inlogknop klikken). En volgens mij klikt geen enkele gebruiker op een inlogknop zonder eerst weer zijn inloggegevens te hebben ingegeven.

[masq]

Je kunt domein Y ook automatisch laten redirecten, voor pagina's/acties waar je ingelogd voor moet zijn. Bij sterk gepersonaliseerde websites ("welkom terug, $username!" op de frontpage) gaat dit natuurlijk niet werken.

Wellicht dat inloggen met behulp van Ajax je een redirect kan schelen

[avon]

AJAX clientside kan je niet cross scripten!...

Zou gewoon één MySQL database gebruiken om een uniek ID aan te maken, aan de hand van het IP adres en refer laten autoriseren.

[RobIII]

avon schreef op donderdag 02 november 2006 @ 23:27:
AJAX clientside kan je niet cross scripten!...

True

avon schreef op donderdag 02 november 2006 @ 23:27:
Zou gewoon één MySQL database gebruiken om een uniek ID aan te maken, aan de hand van het IP adres en refer laten autoriseren.

Referrer is makkelijk te spoofen. Daar moet je IMHO zowieso nooit meer mee doen dan gebruiken voor je stats.

[MBV]

Alex) schreef op donderdag 02 november 2006 @ 21:43:
Dat is bij mij gelukkig niet het geval, maar stel dat dat ooit wel zo is. Dan is het systeem dus minder bruikbaar. Misschien iets met forms en wat coderingen (blowfish) met als private key een hash van hostnames etc.

Gelukkig is dat niet het geval, anders zou je moeilijk moeten doen .

Welke scenario's moeten werken?
1. Gebruiker komt aan op www.x.nl, en logt in. Vervolgens klikt hij op linkje naar www.y.nl, en blijft ingelogd
2. Gebruiker komt aan op www.x.nl, en logt in. 5 min later komt hij op google ofzo www.y.nl tegen, en moet daar direct ingelogd zijn.
3. Gebruiker logt in, en komt een half jaar later terug bij een van de sites (denk aan GoT)

1 is geen probleem. 2 en 3 wordt bijna onmogelijk zonder redirects heen en terug, en zonder iets van een plugin in je browser, lijkt me. Hoe werkte passport wat dat betreft? _{Waarom gebruik je dat niet}

Je zou trouwens toch in een iframe/popup/whatever naar die inlogpagina kunnen gaan, die vervolgens teruggeeft aan zijn parent dat hij ingelogd is? Als dat kan, ben je wel ontzettend gevoelig voor XSS exploits, maar goed.

Wat ik trouwens ook wel heb gelezen is dat je PC's kan identificeren aan de hand van pakketnummers of client port-nummers ofzo. Behalve bij *BSD is dat vrij constant, en kan je die gebruiken om verschillende pc's achter NAT te identificeren. Maar dat lijkt me te onbetrouwbaar om voor inloggen te gebruiken

[ Voor 11% gewijzigd door MBV op 02-11-2006 23:58 ]

[Erkens]

phsmit schreef op donderdag 02 november 2006 @ 22:08:
Maar dit kost veel tijd. En aangezien je dit voor iedere nieuwe bezoeker op de site moet doen (je weet tenslotten nog niet of deze per ongeluk ingelogd is) zal de eerste indruk van bezoekers zijn dat je site traag is. (en hoe zouden zoekmachines dit vinden)

traag?
het is slechts 1 request extra met praktisch geen data, als dat traag is dan denk ik dat het tijd wordt om te investeren in een nieuwe server/bandbreedte

Over die searchengines heb ik ook even zitten nadenken, maar ik ben er nog niet helemaal uit hoe je die het beste kunt helpen...

Maar wellicht heb jij een brilliant idee?

[MBV]

zoekmachines kan je toch filteren? Geven zelf aan wat voor 'browser' ze zijn

[RobIII]

MBV schreef op vrijdag 03 november 2006 @ 00:02:
zoekmachines kan je toch filteren? Geven zelf aan wat voor 'browser' ze zijn

En dan kan ik dus door mijn UA string aan te passen doodleuk over de site wandelen?

[Erkens]

RobIII schreef op vrijdag 03 november 2006 @ 00:34:
[...]

En dan kan ik dus door mijn UA string aan te passen doodleuk over de site wandelen?

Opzich zou dat natuurlijk wel kunnen, je hebt dan gewoon dezelfde rechten als een niet ingelogde user.


Alleen hoe weet je alle UA strings van alle searchengines? Dat is dus niet te doen

[gvdh81]

- Je hebt het wel over koekjes op de client, maar je zou toch ook een filetje, record of zoiets dergelijks op de hoofdserver kunnen laten staan?
- Controleer nooit op IP, maar bijv. op hostname. En ja, als de hostname veranderd dan heb je pech. Ik zie bij GOT (active sessies) ook wel eens ooit dingen waarvan ik denk, "dat IP heb ik al lang niet meer".

Je zou het ook kunnen uitbreiden;
- Als de gebruiker cookies ondersteund, sla je een cookie op en controleer je daarop. Scenario 1 en 2 (MBV) moeten zoiezo geregeld kunnen worden.
- Heeft de gebruiker geen cookies, maar is de hostname en/of het IP nog steeds hetzelfde, zou je iets kunnen doen in de trend van half inloggen?: "Welkom terug Sjaak Trekhaak, voer je wachtwoord in om verder te gaan".

Volgens mij is het wel haalbaar.. En in reactie op waarom er geen gebruik gemaakt zal worden van Passport; Dit kost klauwen met geld, je hebt er een licentie voor nodig.

[Erkens]

gvdh81 schreef op vrijdag 03 november 2006 @ 08:14:
- Je hebt het wel over koekjes op de client, maar je zou toch ook een filetje, record of zoiets dergelijks op de hoofdserver kunnen laten staan?

Hoe wil je dan controlleren wie de client is? Dat zou je toch echt met een koekje of met url prutsen moeten doen.

- Controleer nooit op IP, maar bijv. op hostname. En ja, als de hostname veranderd dan heb je pech. Ik zie bij GOT (active sessies) ook wel eens ooit dingen waarvan ik denk, "dat IP heb ik al lang niet meer".

als je IP veranderd, dan veranderd je hostname ook iets met DNS enzo

[avon]

RobIII schreef op donderdag 02 november 2006 @ 23:53:

Referrer is makkelijk te spoofen. Daar moet je IMHO zowieso nooit meer mee doen dan gebruiken voor je stats.

Dat is wel waar, maar je zou een bepaalde handshake kunnen aanmaken.

[Pseudocode]

[Site 1] > Klik op de link om naar [Site 2] te gaan
[Site 1] > Wijzigt database regel [Pietje puk] wil naar [Site 2] - Timemark 8:38:00
[Site 2] > Pietje puk kom binnen op > Refer + IP + ID - Timemark 8:38:03

[/Pseudocode]

Knappe kip die dat spooft, faked whateverd!

Trouwens IP spoofing is toch zo ie zo 'bijna' onmogelijk?

Op die manier kan je er bijvoorbeeld voor kiezen een tijdsframe van minder dan 30 seconde
voor de handshake vast te leggen. En je zou alvast een 1 keer te gebruiken uniek ID kunnen meegeven.

[ Voor 9% gewijzigd door avon op 03-11-2006 08:51 ]

[MBV]

waarom geen Passport was met een knipoog, dat het geld kost snap ik ook wel. Maar je kan altijd kijken hoe het werkt. Ik dacht dat passport ook met redirects werkt: als je naar Hotmail gaat, ga je altijd langs passport.
@RobIII: Je wilt toch niet dat search engines gegevens kunnen zien die je niet kan zien zonder in te loggen? Dus ik zie er geen probleem in

[Erkens]

avon schreef op vrijdag 03 november 2006 @ 08:41:
Trouwens IP spoofing is toch zo ie zo 'bijna' onmogelijk?

Op die manier kan je er bijvoorbeeld voor kiezen een tijdsframe van minder dan 30 seconde
voor de handshake vast te leggen. En je zou alvast een 1 keer te gebruiken uniek ID kunnen meegeven.

totdat je mensen hebt met hetzelfde IP, of veranderende IP's per request...

[gvdh81]

je hostname hoeft niet te veranderen hoor, wat dacht je van domeinnamen die van IP veranderen?

[Erkens]

gvdh81 schreef op vrijdag 03 november 2006 @ 10:40:
je hostname hoeft niet te veranderen hoor, wat dacht je van domeinnamen die van IP veranderen?

domeinnamen/hostnames die van IP veranderen gebeuren praktisch nooit aan die client kant en zullen dus altijd verwijzen naar hetzelfde IP, ook al is dat dan een andere machine (dyn ip's)

[djc]

Kijk nou serieus eens naar OpenID, dat is hiervoor bedacht en er zijn al enorme hoeveelheden code beschikbaar om het te ondersteunen.