[Alg] 1 login voor 2 sites op andere domains *

[Verwijderd]

Een klein probleempje:
Er bestaan 2 websites, beide websites draaien op verschillende servers. Een bezoeker logt in op website1, hij krijgt oa. een session cookie waar in staat dat ie is ingelogd. Nu gaat de bezoeker via een link naar website2, hij moet nu weer inloggen, omdat website2 niet bij de session cookie van website1 kan.

Is dit 2 keer inloggen op een nette manier te voorkomen? Website1 en website2 moeten op aparte servers blijven draaien (met aparte domeinnamen e.d.). Website2 benadert voor te autenticatie van de bezoeker een database die op de server van website1 draait.

Waar ik zelf had aangedacht is het volgende:
bezoeker clickt op link om naar website2 te gaan, de link is in het formaat:
autologin?userdata=akjdkajdlk;jajdfkhsakjlfhhjkashfdklshafjklhsadfjh

Waarbij de "userdata" parameter dan de gebruikersnaam/wachtwoord van bezoeker bevat (geencrypt). De applicatie die onder "autologin" draait, decrypt dan de "userdata" parameter en kijkt in de database of de bezoeker kan inloggen. Zo ja, dan logt hij automatisch in.

Dit is een niet echt nette manier.. Zijn er nettere en gestandariseerde manieren bij voorkeur met een goede beveiliging?

Website1 is overigens een php applicatie en website2 is een j2ee applicatie.

[TeeDee]

Website 2 maakt gebruik van de db van Website 1?

Dan is de oplossing die je nu hebt het beste. Decrypten zou ik niet doen, want dat betekent dat je een sleutel nodig hebt. Als die sleutel bekend is/wordt hebbie de spreekwoordelijke poppen aan het dansen [/© Hans Teeuwen]

Geef bij de autologin de userid oid (niet passwords e.d.) mee dmv een MD5 hash oid. Sla die hash ook op in je db.

Als website 2 dan die login voor zijn neus krijgt, dan kan je die hash opzoeken in de db.

Let wel: als iemand dan bookmarked, dan kan dat ook weer problemen opleveren.

[Verwijderd]

Het is tegenwoordig amper meer op een andere manier te doen omdat de thrid-party cookies (cookies voor ander domein) geblockt worden door de nieuwe browsers.

Zelf maak ik gebruik van het systeem wat jij voorstelt en heb er nog nooit klachten over gehad (en met 25k bezoekers per dag hoor je dat gauw zat ), maar ook Hotmail en MSN werken op die manier.. eigenlijk het hele MS Passport systeem

[Verwijderd]

Yep, website2 benadert de db van website1 voor authenticatie.

Zou je kunnen uitleggen wat je met een md5 hash bedoelt?

Is deze niet makkelijk te onderscheppen, als ik bijvoorbeeld naar tcp kijk zie ik de GET requests langs komen, dus ook inclusief de md5hash string. Die kopier ik dan en dan kan ik gewoon inloggen zonder een gebruikersnaam/wachtwoord te hebben. Of is dit iets te snel door de bocht?

[djluc]

Is het niet mogelijk om een centraal inlogsysteem te maken, dus zeg maar site nr 3. Die host je gewoon bij een provider, het inloggen kan dan daar gebeuren. Het is dus mogelijk om daar een db bij te houden met alle logins, of natuurlijk de gegevens op een db op een van de servers 1/2 in te vullen.

Het probleem anders is namelijk dat je altijd de gegevens doorstuurd op een zichtbare manier, dat is nooit 100% te beveiligen.

[Woy]

Verwijderd schreef op 23 September 2003 @ 22:00:
Yep, website2 benadert de db van website1 voor authenticatie.

Zou je kunnen uitleggen wat je met een md5 hash bedoelt?

Is deze niet makkelijk te onderscheppen, als ik bijvoorbeeld naar tcp kijk zie ik de GET requests langs komen, dus ook inclusief de md5hash string. Die kopier ik dan en dan kan ik gewoon inloggen zonder een gebruikersnaam/wachtwoord te hebben. Of is dit iets te snel door de bocht?

Ja dit is in princiepe mogenlijk. Je moet dan ook niet gebruik maken van een normale md5 hash maar je moet gebruik maken van een Salted hash. Dit betekend in het kort dat je aan je userid een cryptografisch sterke string ( de salt )concatenate of opteld bij je userid en deze dan hasht. Deze salt sla je dan bijvoorbeeld op in je database en zogauw de user in is gelogd op de site kan je deze weer verwijderen. De volgende keer dat je hetzelfde truukje uit wilt halen maak je een random nieuwe salt aan. Hierdoor is de data die je meestuurt elke keer weer anders en is het dus niet simpel te faken omdat de waarde elke keer verschilt.

Is het niet mogelijk om een centraal inlogsysteem te maken, dus zeg maar site nr 3. Die host je gewoon bij een provider, het inloggen kan dan daar gebeuren. Het is dus mogelijk om daar een db bij te houden met alle logins, of natuurlijk de gegevens op een db op een van de servers 1/2 in te vullen.

Het probleem anders is namelijk dat je altijd de gegevens doorstuurd op een zichtbare manier, dat is nooit 100% te beveiligen.

met deze method los je nog steeds niks op want stel je bent ingelogd op site 3 dan moet je nog steeds op een of andere manier duidelijk maken aan site 1 en 2 dat er ingelogd is en dan zit je nog precies met hetzelfde probleem als wat je eerst had.

[ Voor 24% gewijzigd door Woy op 24-09-2003 18:03 ]