[Security] authenticatie over verschillende servers

[Goldme]

De situatie is als volgt:

Een externe partij heeft een website(Website 1). Op die website heeft hij users. Zijn authenticatiemethoden hebben wij geen controle over!

Wij hebben ook een website(Website 2). Nu willen we het zo maken dat als die externe partij een abonnement afneemt al zijn klanten op onze website mogen komen zonder zich eerst te hoeven authenticeren. Niemand mag op deze website komen als hij niet geauthenticeerd is.

Kijkende vanaf de perspectief van een klant van die externe partij:

Ik ben bezig op de website van die externe partij(waar ik een klant van ben). Ik klik op een knop en ik kom op Website 2 zonder dat ik hoefde in te loggen.

Ik probeer hier echter een goede constructie voor te maken maar het wil niet lukken.

Cookies zijn bijvoorbeeld niet bruikbaar omdat we met verschillende domeinen te maken hebben en dus de cookies niet beschikbaar zijn in andere domeinen.

De externe partij kan wel SSL verbinding maken met Website 2. Het is hier echter wel belangrijk dat de request(als de klant op Website 1 op een knop drukt) gebeurt zonder tussenkomst van de server van de externe partij maar rechtsstreeks naar Website 2 gaat. De reden hiervoor is dat de externe partij verplicht is een form op zijn pagina te hebben met een aantal gegevens die hij naar ons opstuurt via een post van die form.

Alvast bedankt.

[Alarmnummer]

Het lijkt me wel handig als je erbij verteld over welk platform(en) het gaat.

[Goldme]

Sorry. Mijn applicatie is ASP.NET. Die van de externe kan van alles zijn dus daar hebben we geen controle over.

[TheDane]

Er zal volgens mij sowieso iets moeten gebeuren op server1.

Ik zou dan denken aan een identificatiestring/hash die meegestuurd wordt naar server2 op het moment dat je op die knop klikt.

Op server2 moet je dan iets maken wat die identificatiestring kan verifieren ten aanzien van
• geldigheid
• al dan niet ingelogd-zijn van de gebruiker die erop klikt

Als je geen controle hebt over de applicatie die op server1 draait, moet je zorgen dat je controle krijgt over de mensen die die code gemaakt hebben. Er zal in ieder geval IETS gemaakt moeten worden op hun server.

[Goldme]

TheDane schreef op vrijdag 21 januari 2005 @ 10:00:
Er zal volgens mij sowieso iets moeten gebeuren op server1.

Ik zou dan denken aan een identificatiestring/hash die meegestuurd wordt naar server2 op het moment dat je op die knop klikt.

Op server2 moet je dan iets maken wat die identificatiestring kan verifieren ten aanzien van
• geldigheid
• al dan niet ingelogd-zijn van de gebruiker die erop klikt

Als je geen controle hebt over de applicatie die op server1 draait, moet je zorgen dat je controle krijgt over de mensen die die code gemaakt hebben. Er zal in ieder geval IETS gemaakt moeten worden op hun server.

Ja, maar dit impliceert dat iedereen die de identificatiestring heeft ook toegang krijgt tot mijn applicatie.

Aangezien de post vanaf de client direct naar website 2 moet zou dit impliceren dat die hash narr de client gaat en dan bij de post naar website 2 wordt gestuurd. Aangezien de client die hash heeft kan hij deze extracten en verspreiden waardoor iemand in principe op mijn applicatie kan komen terwijl dat niet mag. Die illegale bezoekers komen bij mij aankloppen met die hash, ik herken die hash als zijnde van 1 van mijn klanten en dus veronderstel ik dat degene die aanklopt een klant is van mijn klant en laat hem toe.

In principe kan Website 1 een string/sleutel meegeven, de vraag is echter hoe zorg ik ervoor dat die sleutel niet in verkeerde handen komt. Hoe zorg ik ervoor dat aleen mijn klant die sleutel heeft en hoe kan hij ervoor zorgen dat ook zijn klanten van die sleutel gebruik maken ZONDER dat die klanten de sleutel hebben!!

Dillema.

[TheDane]

Je kunt een challenge response mechanisme maken, maar hoe dan ook blijft je probleem aan de server1 kant liggen. daar moet toch echt wat gedaan worden.

Die identificatiestring moet overigens uiteraard wel random zijn, en per sessie gegenereerd worden. Een reeds gebruikte hash is dan dus niet meer bruikbaar.

Je zou nog een referercheck kunnen toevoegen op server2 , maar da's -uiteraard- ook niet waterdicht.

[Goldme]

TheDane schreef op vrijdag 21 januari 2005 @ 11:11:
Je kunt een challenge response mechanisme maken, maar hoe dan ook blijft je probleem aan de server1 kant liggen. daar moet toch echt wat gedaan worden.

Die identificatiestring moet overigens uiteraard wel random zijn, en per sessie gegenereerd worden. Een reeds gebruikte hash is dan dus niet meer bruikbaar.

Je zou nog een referercheck kunnen toevoegen op server2 , maar da's -uiteraard- ook niet waterdicht.

Zou je de gang van zaken stapsgewijs kunnen uitleggen hier? wat gebeurt er bij de challenge response mechanisme?

Aan de hand van wat voor data moet de identificatiestring aangemaakt worden?

[TheDane]

Goldme schreef op vrijdag 21 januari 2005 @ 11:14:
[...]


Zou je de gang van zaken stapsgewijs kunnen uitleggen hier? wat gebeurt er bij de challenge response mechanisme?

Aan de hand van wat voor data moet de identificatiestring aangemaakt worden?

Hmm allereerst, ik ben (nog) niet zo heeel erg thuis in deze materie, en 't grootste deel van mijn inspiratie heb ik ooit gevonden in deze topic:
[rml][ php] sessions zo veiliger?[/rml] , en dan met name Zoijar's posts


Maar in a nutshell:
op server 2 genereer je een random key. die concateneer je aan een identificatiestring, bijvoorbeeld "DitIsServer2". Daar maak je een hash van.

Op server1 bouw je een string van $auth_username + ident string van server 1.
Op server1 weet je de ident string van server2, en op server2 weet je de ident string van server1.

Bij iedere request vanaf server2 naar beveiligde pagina's, stuur je je gemaakte hash naar server1.
server1 voegt deze challenge toe aan zijn string, en als je daar geauthenticeerd bent, stuurt ie een ticket terug. In mijn geval van de vorm:

code:

$ticket = $auth_username.md5($challengevanServer2.$auth_username.$identStringvanServer1);

Server2 kan dat ticket analyseren, want hij heeft $auth_username in plaintext en de ident string van server1 is bekend.
Dus de vergelijking van zijn eigen gegenereerde hash en de response die hij terugkrijgt in ticket blijft over. Zijn deze 2 gelijk -> geauthenticeerd op server2.

[ Voor 5% gewijzigd door TheDane op 21-01-2005 11:43 ]

[Zoijar]

Als je data over wilt sturen, dan kan je die data, bv username, in plaintekst sturen; daar maak je een md5 hash van die je eronder plakt, en dat hele ding sign je met RSA (dus encrypt je op server1s private key). Zo heb je in ieder geval secure communication tussen de twee. Iedereen kan het wel lezen, maar het is niet mogelijk zelf zo'n packet te maken, of aan te passen. Alleen server1 kan dus inloggen, en server2 kan de correcte username lezen. Je kan het natuurlijk ook op server2's public key encrypten, dan kan niemand het lezen behalve server2...beter misschien wel. Wel moet je die hash er in laten staan, anders kan je het packet alsnog eventueel aanpassen. Probleem is ook dat je webserver soms als "nobody" draait, en je key files dan read-world access moeten hebben...dus je private key ligt voor het grijpen.

Het probleem nu is een aanval door zo'n packet te dupliceren (hoewel je die natuurlijk al moeilijk in handen krijgt, want het gaat van server1 naar server2, de client ziet dit nooit) dus moet je alsnog met challenges gaan werken.

TheDane's oplossing lijkt me dan ook het simpelste, behalve dat de server niet uit kunnen lezen om welke username het gaat. Volgens mij is dat het probleem toch? Dat ik hier op GoT ben ingelogd als zoijar, en dan hier op een knop 'fok' klik, en dat ik daar ook automatisch wordt ingelogd als zoijar?

Dan zou ik het toch zo doen: (S1 -> xxx betekent server1 stuurt xxx naar server2)

- Voeg op S1 en S2 in de user databse voor elke user een veld 'nonce' toe. Dit is een 64bit int getal, init op 0.

- S1 maakt een packet bestaande uit: username - usernonce - md5(username+usernonce)
- S1 -> privkeyS1(packet) (eventueel publickeyS2(privatekeyS1(packet)))
- S1 verhoogt database nonce voor user met 1.

- S2 krijgt packet van S1 binnen
- S2 publickeyS1(packet) levert username - usernonce- hash (eventueel privatekeyS2(publickeyS1(packet)))
- S2 checked of md5(username+usernonce) = hash, zoniet, die
- S2 checked of nonce >= database nonce voor user username
- S2 zet database nonce voor username op nonce+1

Je kan eventueel ook die md5 hash eruit laten, als je encrypt op S2-public. Die is ervoor, dat je geen packet kan aanpassen, dat uit meerdere RSA stukjes bestaat. Maar aangezien het bericht zo klein is, gaat dat toch niet op, en is de RSA op zich al secure tegen aanpassingen.

(je kan ook nog hier kijken http://www.infoanarchy.or.../Man-In-The-Middle_Attack voor een andere hack manier, die lastiger te omzeilen is, maar met een trusted key server wel te verhelpen is... alleen nooit helemaal, op een gegeven moment moet je vertrouwen dat iets secure is, en zegt wat het zegt dat het is. Daarom zou ik dit risico gewoon nemen.)

[ Voor 23% gewijzigd door Zoijar op 21-01-2005 15:03 ]

[curry684]

Goldme schreef op vrijdag 21 januari 2005 @ 11:14:
[...]

Zou je de gang van zaken stapsgewijs kunnen uitleggen hier? wat gebeurt er bij de challenge response mechanisme?

P&W FAQ - Hoe beveilig ik een website?

[Rukapul]

Ik zie hier een hoop leuk geknutsel, maar dit probleem is al opgelost en heet single sign-on en identity federation:
- Passport (dood)
- Liberty Alliance
Software voor Liberty Alliance is voor zover ik gehoord heb beschikbaar als open source implementatie en anders kun je op z'n minst naar de specificaties kijken.

Wellicht dat je wat aan wilt passen omdat privacy en instemming van de user van minder belang is in dit geval, maar de grote lijnen moeten bruikbaar zijn.

[ Voor 27% gewijzigd door Rukapul op 21-01-2005 15:55 ]

[Zoijar]

Rukapul schreef op vrijdag 21 januari 2005 @ 15:53:
Ik zie hier een hoop leuk geknutsel, maar dit probleem is al opgelost en heet single sign-on en identity federation:
- Passport (dood)
- Liberty Alliance
Software voor Liberty Alliance is voor zover ik gehoord heb beschikbaar als open source implementatie en anders kun je op z'n minst naar de specificaties kijken.

Wellicht dat je wat aan wilt passen omdat privacy en instemming van de user van minder belang is in dit geval, maar de grote lijnen moeten bruikbaar zijn.

Maar waarom zou je helemaal een ander paket gaan gebruiken, en nog aanpassen, terwijl het op te lossen is met wat simpele RSA encryptie, die standaard bij bv php al wordt geleverd? Wat ik net poste is geen geknutsel, het is ook echt veilig. Als je MITM wilt elimineren, zal je ook key finger prints moeten checken bij een bekende authenticatie server; maar dat lijkt me niet echt nodig in dit geval.

[Rukapul]

Zoijar schreef op vrijdag 21 januari 2005 @ 17:25:
[...]

Maar waarom zou je helemaal een ander paket gaan gebruiken, en nog aanpassen, terwijl het op te lossen is met wat simpele RSA encryptie, die standaard bij bv php al wordt geleverd? Wat ik net poste is geen geknutsel, het is ook echt veilig. Als je MITM wilt elimineren, zal je ook key finger prints moeten checken bij een bekende authenticatie server; maar dat lijkt me niet echt nodig in dit geval.

Ik had nog geen tijd gehad om jouw protocol te analyseren (zal er zo eens in detail naar kijken), maar het proces in deze thread als gehaal had wel een knutselgehalte omdat er hap snap wat technieken bijgehaald werden.

Overigens hoeft er niet per se een pakket gebruikt te worden. Liberty is een set van protocollen die berust op redelijk standaard crypto zoals hashes en public key en kun je dus gewoon in php realiseren. Door er eens naar te kijken kan TS voorkomen dat hij fouten maakt die daar zijn opgelost. Bovendien bevat Liberty een mapping naar HTTP zodat er meteen een oplossing is voor de problemen die in deze thread gesteld werden als je het op basis van cookies zou willen bouwen.

Edit:

Zoijar schreef op vrijdag 21 januari 2005 @ 13:17:
Het probleem nu is een aanval door zo'n packet te dupliceren (hoewel je die natuurlijk al moeilijk in handen krijgt, want het gaat van server1 naar server2, de client ziet dit nooit) dus moet je alsnog met challenges gaan werken.

Replay attacks los je al op met de nonces.
Overigens is het juist handig om het bericht van s1 naar s2 nu via de webbrowser van de client te doen (bv als POST parameter). De client kan 'm in theorie dus zien maar dat verandert de security aspecten van het protocol verder niet: het is veilig ten opzichte van elke actieve attacker dus ook de client (dit deel van het protocol teminste). Communicatie via de webbrowser van de client heeft hier als voordeel dat de gebruiker er niets van merkt en dat de s1-s2 en s2-browser sessies niet aan elkaar gelinkt hoeven te worden.

Volgens mij is dat het probleem toch? Dat ik hier op GoT ben ingelogd als zoijar, en dan hier op een knop 'fok' klik, en dat ik daar ook automatisch wordt ingelogd als zoijar?

Lijkt me wel. Dat is dus een vorm van single sign on. In dit eenvoudige geval is dus het enige wat noodzakelijk is dat s1 verklaart dat clientX bij hem is ingelogd/geauthenticeerd.

knip protocol

Protocol lijkt me in de basis ok mbt security. Ipv de oplopende nonces zou je evt challenge-response (message overhead) of timestamp (wel freshness, maar slechte bescherming tegen een meeluisterende attacker die ook meteen inlogt dus geen goede keuze) kunnen toepassen, maar als je die database toch al hebt gewoon zo doen idd.

Die md5 is inderdaad niet nodig en encryptie ook niet. Scheelt toch weer een beetje processing.

Overigens is het wel aan te raden om de identiteit van zowel server1 als server2 in het bericht op te nemen. Niet alleen is dat 'good practice', maar ook practisch, omdat de ontvanger weet tegen welke public key hij de signature moet checken.

(je kan ook nog hier kijken http://www.infoanarchy.or.../Man-In-The-Middle_Attack voor een andere hack manier, die lastiger te omzeilen is, maar met een trusted key server wel te verhelpen is... alleen nooit helemaal, op een gegeven moment moet je vertrouwen dat iets secure is, en zegt wat het zegt dat het is. Daarom zou ik dit risico gewoon nemen.)

Dit hoeft niet eens, want mitm attack in de pure betekenis voorkom je hier vrijwel automatisch omdat s1 en s2 elkaar kennen en elkaars pulic key kennen.

Overigens is er toch nog wel een probleem met het geschetste protocol: een actieve aanvaller kan het bericht tussen s1 en s2 onderscheppen en zelf doorsturen. Daarna heeft de attacker een sessie met s2 en kan gebruik maken van de diensten. Dit kan bv voorkomen worden door de identeit van de client (bv IP nummer) in het bericht op te nemen.

[ Voor 59% gewijzigd door Rukapul op 21-01-2005 22:54 ]