Challenge-Response system tussen sites via URL

[rogierslag]

Intens thuis in beveiliging ben ik niet, maar wel redelijk in ieder geval. Vandaar dat ik wat vragen heb over een systeem wat we, op mijn werk, willen gebruiken om mensen van de ene geautoriseerde omgeving door te leiden naar een andere binnen een ander serverpark.

Het idee werkt zo:
1. Men logt in op een website
2. Onze clientsoftware genereert een link waarop men kan klikken en men op onze site komt. De link is onbeperkt geldig en kan worden doorgegeven (kun je zelf niks meer kopen alleen). Deze laatste twee zijn by-design omdat we hier geen problemen mee verwachten
3. Onze software controleert de link, voert hashes opnieuw uit en vergelijkt de resultaten: klopt het? Mooi! Anders jammer maar helaas.

De links werken als volgt.
1. Men krijgt van ons een shopnaam (identifying in ons systeem)
2. Men krijgt van ons een geheime sleutel (48 bits)
3. Ieder lid heeft, op de organisatiesite, een uniek nummer

Vervolgens creëert onze software een random stringhash, concate dit met de shopnaam, sleutel en nummer en hasht dit weer met SHA-512. Deze hash wordt, samen met de random stringhash, shopnaam en nummer via de GET-parameters naar onze server gestuurd. Onze server heeft dezelfde geheime sleutel voor de betreffende shop. De server neemt dezelfde hash (alle gegevens zijn bekend) en vergelijkt deze met de gestuurde. Indien ze gelijk zijn is het goed en kan het betreffende lidnummer verder gaan, anders volgt een foutmelding.

Mijn vragen:
1. Is dit inderdaad zo veilig als ik denk? (ik denk dat het voldoet gezien de shared key niet te achterhalen is dus de hash de rest van de data kan garanderen)
2. Zijn er dingen die ik vergeet?
3. Wat zijn in dit geval de nadelen voor een replay-attack omdat de link onbeperkt geldig is en doorgegeven kan worden? Men verliest dan simpelweg zelf het recht op het kopen van iets, maar dat was ook al met doorgeven. Zie ik iets over het hoofd?

De code, zoals die in beta is, staat natuurlijk OS op GitHub op https://github.com/in-ventID/externalShopAuthentication. Ik heb de PHP versie geschreven en vervolgens geport naar Java; beide versies zijn in principe hetzelfde en zouden dezelfde gaten moeten hebben

P.S. Ik bedenk me net dat ik simpelweg een timestamp mee kan sturen (en hashen) met daarin de generatietijd en deze vervolgens -10 tot +10 min geldig kan laten zijn (tijdsissues tussen servermarge)

[rogierslag]

bump bump bump bump. Mist iemand informatie?

[Thralas]

Oeh! Eindelijk iets anders dan 'help ik heb een virus'.

rogierslag schreef op dinsdag 10 september 2013 @ 23:42:
1. Is dit inderdaad zo veilig als ik denk? (ik denk dat het voldoet gezien de shared key niet te achterhalen is dus de hash de rest van de data kan garanderen)

Nee.

Lengte secret
Je shared secret is 48 bits. Waarom? 2⁴⁸ bits security is erg weinig; Ter vergelijking: DES biedt 2⁵⁶ bits of security en is inmiddels prima te bruteforcen. Uiteraard niet op een enkel desktop-pc'tje, but then again, extra bits kosten je niets. 128 lijkt me een mooi minimum.

Next..
Je code ziet er als volgt uit:

PHP:

$strAuthHash = hash('sha512', sprintf('%s-%s-%s-%s', $this->strShopName, $this->strSecretKey, $this->hash, $this->strUserId));

Ofwel:

code:

token = H(ShopName-SecretKey-Hash-UserId)

Plain hash
Je aanname dat de secret voorkomt dat iemand een geldige hash over gewijzigde data kan forgen faalt. Veel gangbare hashfuncties zijn vulnerable voor een length extension attack, zo ook SHA512.

Aangenomen dat de Hash-parameter gebruikt kan worden om de (originele) hash + userid + padding in te dumpen, kun je de hash extenden en een arbitrary user ID forgen bij een shopname waarvoor je een valid token hebt.

Bovendien is er een gangbare constructie om een cryptografische hashfunctie te gebruiken voor message authentication icm. een secret, zonder de gevaren van een plain hash: HMAC.

Boundary confusion
De order van de variabelen in je hashinput heb je waarschijnlijk willekeurig gekozen - het had er evenwel als volgt uit kunnen zien

code:

token = H(SecretKey-Hash-UserId-ShopName)

Wat is nu het verschil in hashoutput tussen {userid: 5, shopname: 4-shopping} en {userid: 5-4, shopname: shopping}?

Gecombineerd met de malle interpretatie van PHP een recipe for disaster. Misschien is zo'n attack in dit geval vrij onpraktisch, maar er zijn genoeg situaties denkbaar waar eenzelfde scheme wel praktisch exploitable is.

Een oplossing zou zijn om alle fields individueel te hashen, en daarna het concatenated geheel nogmaals.

2. Zijn er dingen die ik vergeet?

Ja. Ik mis aannames over de betrouwbaarheid van de 'signing' en 'verifying' parties in je systeem. Een kwaadwillende verifying party zou namelijk ook zelf valide tokens kunnen genereren. Is dat een probleem? Dan heb je een public key signature scheme nodig, ipv. shared secret message authentication

Ten tweede, wat is de functie van de 'hash' parameter?

3. Wat zijn in dit geval de nadelen voor een replay-attack omdat de link onbeperkt geldig is en doorgegeven kan worden? Men verliest dan simpelweg zelf het recht op het kopen van iets, maar dat was ook al met doorgeven. Zie ik iets over het hoofd?

Dat is moeilijk te beantwoorden zonder context.

Overigens, de titel is enigzins misleidend

[rogierslag]

Thralas schreef op zaterdag 14 september 2013 @ 15:10:

Lengte secret
Je shared secret is 48 bits. Waarom? 2⁴⁸ bits security is erg weinig; Ter vergelijking: DES biedt 2⁵⁶ bits of security en is inmiddels prima te bruteforcen. Uiteraard niet op een enkel desktop-pc'tje, but then again, extra bits kosten je niets. 128 lijkt me een mooi minimum.

Enigszins random gekozen eigenlijk. Het uppen van de hash naar 128 of 256 kost dan ook nauwelijks extra moeite. Zeker een wijziging die ik zal gaan doorvoeren. Nu ik erover nadenk heb ik een dergelijke lengte gebruikt omdat Facebook ongeveer hetzelfde gebruikt voor de secret key (amazon idem). Langer leek me dan ook niet nodig.

Next..
Je code ziet er als volgt uit:

PHP:

$strAuthHash = hash('sha512', sprintf('%s-%s-%s-%s', $this->strShopName, $this->strSecretKey, $this->hash, $this->strUserId));

Ofwel:

code:

token = H(ShopName-SecretKey-Hash-UserId)

Plain hash
Je aanname dat de secret voorkomt dat iemand een geldige hash over gewijzigde data kan forgen faalt. Veel gangbare hashfuncties zijn vulnerable voor een length extension attack, zo ook SHA512.

Aangenomen dat de Hash-parameter gebruikt kan worden om de (originele) hash + userid + padding in te dumpen, kun je de hash extenden en een arbitrary user ID forgen bij een shopname waarvoor je een valid token hebt.

Bovendien is er een gangbare constructie om een cryptografische hashfunctie te gebruiken voor message authentication icm. een secret, zonder de gevaren van een plain hash: HMAC.

Hiervoor is het dus eerder aan te raden om iets te doen als

code:

<?php
$token = hash_hmac('sha512','ShopName-Hash-UserId','SecretKey')
?>

Boundary confusion
De order van de variabelen in je hashinput heb je waarschijnlijk willekeurig gekozen - het had er evenwel als volgt uit kunnen zien

code:

token = H(SecretKey-Hash-UserId-ShopName)

Wat is nu het verschil in hashoutput tussen {userid: 5, shopname: 4-shopping} en {userid: 5-4, shopname: shopping}?

Gecombineerd met de malle interpretatie van PHP een recipe for disaster. Misschien is zo'n attack in dit geval vrij onpraktisch, maar er zijn genoeg situaties denkbaar waar eenzelfde scheme wel praktisch exploitable is.

Een oplossing zou zijn om alle fields individueel te hashen, en daarna het concatenated geheel nogmaals.

Binnen ons systeem mag een shopname enkel bestaan uit alfanumerieke tekens. Zodra er een shopname met een - voorkomt wordt deze al direct afgekeurd (in eerdere code). - is dan ook een speciaal teken en zou, denk ik, daarom geen problemen geven.

[...]


Ja. Ik mis aannames over de betrouwbaarheid van de 'signing' en 'verifying' parties in je systeem. Een kwaadwillende verifying party zou namelijk ook zelf valide tokens kunnen genereren. Is dat een probleem? Dan heb je een public key signature scheme nodig, ipv. shared secret message authentication

Ten tweede, wat is de functie van de 'hash' parameter?

Organisaties krijgen een uniek secret. Indien ze zelf, onterecht, valide tokens uitgeven benadelen ze zichzelf. Een deel van hun klanten kan dan namelijk niets meer kopen. Contractueel is dit afgedekt.
De hashparameter is enkel om wat entropie toe te voegen en het minder snel duidelijk kan zijn, door middel van rainbowtables, wat de secretkey is (zie het als een extra salt).

[...]
Dat is moeilijk te beantwoorden zonder context.

De context is dat wij verkoopdiensten leveren voor de mensen die deze functies implementeren. Indien iemand die recht heeft op een code zijn token weggeeft aan iemand anders zorgt dit er enkel voor dat de oorspronkelijk persoon geen dingen meer kan kopen. Er is dan niet meer verkocht, enkel aan iemand anders. Gezien er normaal gesproken ook doorverkocht kan worden is dit voor ons geen issue.

Welke titel zou je eerder voorstellen, dan vraag ik een mod hem te wijzigen?

En sowieso bedankt voor je uitgebreide reactie! Ben geen crypto-specialist namelijk

[ Voor 2% gewijzigd door rogierslag op 14-09-2013 19:45 . Reden: uitleg secret length fb en aws ]

[rogierslag]

ding dong!

[kodak]

Ik kan je aanbevelen om 24 deadly sins of software security eens te gaan lezen voordat je het wiel opnieuw probeert uit te vinden met zelfgemaakte authenticatiemethodes etc. Beveiligingssoftware is niet iets wat je even schrijft. Je haalt je anders heel wat problemen op de hals.

[Thralas]

rogierslag schreef op zaterdag 14 september 2013 @ 19:22:
Binnen ons systeem mag een shopname enkel bestaan uit alfanumerieke tekens. Zodra er een shopname met een - voorkomt wordt deze al direct afgekeurd (in eerdere code). - is dan ook een speciaal teken en zou, denk ik, daarom geen problemen geven.

Dat levert dan inderdaad geen problemen op icm. een HMAC. Feit blijft wel dat je dan een extra randvoorwaarde hebt (geen koppeltekens) voor de veiligheid van je algoritme...

Rest is nu helder.

Welke titel zou je eerder voorstellen, dan vraag ik een mod hem te wijzigen?

Volgens mij iets ala SSO een betere benaming; er is in ieder geval geen sprake van een challenge/response

kodak schreef op maandag 23 september 2013 @ 02:21:
Ik kan je aanbevelen om 24 deadly sins of software security eens te gaan lezen voordat je het wiel opnieuw probeert uit te vinden met zelfgemaakte authenticatiemethodes etc. Beveiligingssoftware is niet iets wat je even schrijft. Je haalt je anders heel wat problemen op de hals.

Blijft een goede stelregel. In dit geval heb ik het niet meteen afgeschoten omdat ik niet echt een alternatief weet. Er zijn wel standaarden als SAML en OAuth, maar volgens mij is dat niet geheel aansluitend op het doel van TS. En de complexiteit van die alternatieven verhoogt ook weer het risico op implementatiefouten...

[Rukapul]

Standaarden als SAML en OAuth (de web-profiles ervan) zijn vooral bedoeld om interactief credentials/tokens door te geven. Ik begrijp van topicstarter dat hij ook wil toestaan om out of band op een gemakkelijke manier dergelijke tokens te delen, bijvoorkeur in de vorm van een URL.

Er zijn al eindeloos veel fouten gemaakt met url-encoded credentials en dan met name de hashes zoals hierboven uitgelegd. Als 'beginner' is dat een risicovolle onderneming en zou je eigenlijk op kant en klare oplossingen moeten vertrouwen.

Als je toch zelf wat in elkaar fabriekt dan zou een 'opaque' oplossing waarbij je de hele zwik encrypt met AES-CBC oid en als base64 encoded parameter meestuurt inclusief een enkele andere parameter welke de sleutel identificeert. (Sowieso een lenge check opnemen en bij voorkeur ook nog een (H)MAC binnen de encryptie toepassen.) Maargoed, liever ook niet zoiets.

Gebruik van bv SAML is in zo'n geval in theorie ideaal. In praktijk valt het wat tegen want 1) de signature icm base64 encoding laat de lengte exploderen, 2) veel SAML implementaties zijn zo gaar als wat met niet alle functionaliteit geimplementeerd, 3) de HTTP GET binding voor een enkel SAML assertion is formeel niet gespecificeerd / eenvoudig te vinden, 4) veel libraries bevatten implementatie fouten of nodigen de integrator uit tot het maken van integratiefouten waarbij het meest voorkomende het niet controleren of de signer vertrouwd is en/of problemen met XMl signature parsing.

[raptorix]

Uberhaupt dit soort zaken via GET requests te doen is al dodelijk, de geldige url blijft gewoon in iemand's history staan, gaat zwerven in mailboxen, etc, etc. Ik weet niet hoe zwaar dit beveiligt moet zijn, maar ik zou zoals hier ook al aangegeven word niet het wiel opnieuw gaan uitvinden.