[Security] Server -> API communicatie, OAuth2 vs Basic vs ..

[Barryvdh]

Voor een API gebruiken wij momenteel Basic authentication over HTTPS. Deze API is puur voor Server -> API communicatie, niet voor losse gebruikers/resources (dus een service account). In principe is het gewoon een API key (32 tekens) die als username wordt meegestuurd, dus vergelijkbaar met een API token in de header.

Nu kregen we een opmerking dat Basic Auth niet zo veilig zou zijn, vanwege volgende zaken:
- Entropy van alleen apiKey (32 tekens) is minder dan entropy van username + password (2x 16)
- Statische key is niet veilig, beter per sessie een nieuwe key (access token), ivm meer risico MITM attacks

Als alternatief wordt aangeraden OAuth2 met short-lived access tokens, wat dan dus client_credentials scope zou zijn; https://tools.ietf.org/html/rfc6749#section-4.4

Nu is mijn vraag, is Basic Auth per definitie onveilig? Of onveiliger als OAuth2?

Is een MITM attack plausibel? Want dan heb je een groter probleem toch? En daarnaast heb je met short-lived access tokens een regelmatige request voor een access token, die ook op te vangen is dus.
Een grotere levensduur van access token -> minder kans op MITM onderschepping, maar langer misbruik mogelijk natuurlijk.

(Overigens is het geen probleem om OAuth2 te implementeren, maar er is natuurlijk een bestaande groep gebruikers die momenteel Basic Auth gebruikt en wil goede reden hebben om dat om te zetten)

[ Voor 4% gewijzigd door Barryvdh op 07-06-2018 10:54 ]

[Thijs8472]

Maar is het dan wel Basic-Auth, ik versta daaronder dat je dan een WWW-Authenticate: Basic header gebruikt, is voor het antwoord niet relevant overigens.

Het probleem van 'Basic Auth' is dat je een statische waarde in de requests naar je API hebt. Deze waarde kan hergebruikt worden in geval van MitM of wanneer deze waarde gecompromitteerd wordt (beheerder die ontslagen wordt etc). Iemand die deze waarde heeft heeft 'onbeperkt' toegang tot de API totdat deze waarde veranderd.

Door OAuth, of een ander sessie-mechanisme met gebruikersnaam/wachtwoord, te gebruiken ondervang je het hergebruik van deze tokens als gevolg van een MitM en daarmee kan je toegang tot de applicatie dus 'beperken' tot de duur van de sessie.

Afhankelijk van de schaalbaarheid van je API zou je kunnen overwegen een ander authenticatiemechanisme te implementeren of gebruik te maken van client certificaten of een IP ACL op de API. Met client certificaten kun je ook MitM mitigeren maar schaalt in mijn ervaring niet zo lekker net als een IP ACL.

[Barryvdh]

Bedankt voor je feedback!

Thijs8472 schreef op donderdag 7 juni 2018 @ 11:09:
Maar is het dan wel Basic-Auth, ik versta daaronder dat je dan een WWW-Authenticate: Basic header gebruikt, is voor het antwoord niet relevant overigens.

Ja, in dit geval wel. Maar het is inderdaad hetzelfde voor een custom (authorization) header.

Thijs8472 schreef op donderdag 7 juni 2018 @ 11:09:
Het probleem van 'Basic Auth' is dat je een statische waarde in de requests naar je API hebt. Deze waarde kan hergebruikt worden in geval van MitM of wanneer deze waarde gecompromitteerd wordt (beheerder die ontslagen wordt etc). Iemand die deze waarde heeft heeft 'onbeperkt' toegang tot de API totdat deze waarde veranderd.

Maar in het geval van OAuth2 met client credentials heb je dit ook toch? Want je moet regelmatig je access token vervangen (bij short-lived) en als iemand de client key/secret heeft, kan hij daarmee ook zelf een nieuw access token opvragen.

Thijs8472 schreef op donderdag 7 juni 2018 @ 11:09:
Door OAuth, of een ander sessie-mechanisme met gebruikersnaam/wachtwoord, te gebruiken ondervang je het hergebruik van deze tokens als gevolg van een MitM en daarmee kan je toegang tot de applicatie dus 'beperken' tot de duur van de sessie.

Maar je kan ook de request voor het access token onderscheppen toch? Dan kan je dus eigen tokens aanvragen.

Thijs8472 schreef op donderdag 7 juni 2018 @ 11:09:
Afhankelijk van de schaalbaarheid van je API zou je kunnen overwegen een ander authenticatiemechanisme te implementeren of gebruik te maken van client certificaten of een IP ACL op de API. Met client certificaten kun je ook MitM mitigeren maar schaalt in mijn ervaring niet zo lekker net als een IP ACL.

Klopt, IP restrictie is een optie die we overwegen. Er zit al zaken in zoals throttling en monitoring, maar dat is in principe hetzelfde bij OAuth2.

[Thijs8472]

Wat in mijn vorige post ontbrak maar wat wel belangrijk is, is dat er twee losstaande risico's zijn die ook als zodanig gemitigeerd moeten worden:

- Toegang tot je API door onbevoegden
- Man-in-the-Middle aanvallen door derden

OAuth2, IP restrictie of client certificaten zijn mitigerende maatregelen voor het eerste risico waarmee je de toegang, of de duur daarvan, tot de API kan beperken (bijvoorbeeld in het geval van MitM).

Als er een MitM uitgevoerd kan worden maakt het eigenlijk niet uit welk authenticatie mechanisme je gebruikt want dan zijn de credentials/tokens EN de data die uit de API komt gecompromitteerd. Helaas moet het mitigeren van MitM wel van twee kanten komen, i.e. de client moet controleren dat het certificaat van de de API vertrouwd is (CN/CA checken) en de API moet een correct certificaat hebben.

Bijvoorbeeld, als je kan garanderen dat je clients aan certificate pinning doen dan is het risico van het gebruik van 'Basic Auth' beperkt want MitM is niet meer mogelijk. Iemand die het token kent zou het dan nog kunnen gebruiken (ontslagen werknemer) maar als je ook nog aan IP restrictie doet verlaag je dat risico nog verder.

Het is nogal afhankelijk van de gevoeligheid van de API en het compromis tussen veilig en bruikbaar.

[Juup]

Basic auth (of een token) over https is wel redelijk veilig.
De entropy van een 32-char apikey is beter dan de entropy van 16-char username + 16-char wachtwoord omdat een username meestal niet random is.

[F_J_K]

offtopic:
Naar aanleiding van oAuth VS Basic Auth (HTTPS) MITM mogelijk?, nu met alias in P&B.

[Not Pingu]

Behalve OAuth zou een HMAC (signature mbv een preshared key) met een timestamp in het bericht ook beschermen tegen replay en MITM attacks en is wellicht makkelijker te implementeren.

Een HMAC is een hash over het gehele bericht. Als het bericht een timestamp bevat, heeft die ook invloed op de HMAC. Controleer serverside wel of de timestamp niet ouder dan 1-2 minuten is. Om problemen met tijdzones te voorkomen moet de timestamp in UTC zijn.

[ Voor 9% gewijzigd door Not Pingu op 07-06-2018 12:29 ]

[Barryvdh]

Not Pingu schreef op donderdag 7 juni 2018 @ 12:27:
Behalve OAuth zou een HMAC (signature mbv een preshared key) met een timestamp in het bericht ook beschermen tegen replay en MITM attacks en is wellicht makkelijker te implementeren.

Een HMAC is een hash over het gehele bericht. Als het bericht een timestamp bevat, heeft die ook invloed op de HMAC. Controleer serverside wel of de timestamp niet ouder dan 1-2 minuten is. Om problemen met tijdzones te voorkomen moet de timestamp in UTC zijn.

Klopt, dat zou mijn inziens een echte stap hoger, terwijl OAuth2 ruwweg op hetzelfde niveau lijkt te liggen. Als is de implementatie hier volgens mij weer net wat minder standaard voor dan OAuth2/Basic, als je werkt met standaard libraries. Dus vooral interessant als het bijv. om financiele transacties gaat enzo.

[CH4OS]

Wellicht zijn JSON Web Tokens (JWT) een optie? https://jwt.io/

[ Voor 14% gewijzigd door CH4OS op 07-06-2018 12:34 ]

[Barryvdh]

CH4OS schreef op donderdag 7 juni 2018 @ 12:33:
Wellicht zijn JSON Web Tokens (JWT) een optie? https://jwt.io/

JWT wordt voornamelijk gebruikt om client-side/zonder database ook eea. te kunnen valideren enzo toch? In dit geval (server -> api) zou het hetzelfde werken als een access token toch?

In het geval van users en apps etc snap ik het voordeel van JWT en OAuth2 overigens wel hoor

[DJMaze]

Je kan ook kiezen voor SASL SCRAM-SHA-256

Of een SSL/GPG public/private key pair op het wachtwoord en/of data.

[ Voor 30% gewijzigd door DJMaze op 07-06-2018 12:57 ]

[CH4OS]

Barryvdh schreef op donderdag 7 juni 2018 @ 12:42:
JWT wordt voornamelijk gebruikt om client-side/zonder database ook eea. te kunnen valideren enzo toch? In dit geval (server -> api) zou het hetzelfde werken als een access token toch?

De server is in dit geval toch een client? Waarom zou dat anders zijn, het blijft een 3rd party resource immers, dat bij jou info ophaalt. Leuk, dat dat voor jullie API vooral 'servers' zijn, maar dat maakt voor de opzet toch niets uit?

[ Voor 18% gewijzigd door CH4OS op 07-06-2018 13:01 ]

[Sandor_Clegane]

Basic auth is prima zolang je het maar over SSL doet. Als je niet in kan staan voor de SSL verbinding, heb andere en grotere problemen.

[Barryvdh]

CH4OS schreef op donderdag 7 juni 2018 @ 13:00:
[...]
De server is in dit geval toch een client? Waarom zou dat anders zijn, het blijft een 3rd party resource immers, dat bij jou info ophaalt. Leuk, dat dat voor jullie API vooral 'servers' zijn, maar dat maakt voor de opzet toch niets uit?

Nee klopt, maar het voordeel van JWT is dan dat het je lokaal (bijv. in je app) kan controleren of je token nog geldig is met alleen je token, of dat je extra informatie (permissies, info etc) kan toevoegen aan je JWT token, die je kan valideren door de signature te controleren.
In deze use-case zou je dan toch puur de JWT token als access token gebruiken, dat maakt het toch niet ineens beter, alleen anders?

[johnkeates]

Ga voor OAuth2, dat heeft sessie tokens en refresh tokens, of gebruik HMAC met timestamps. Statische auth is niet erg veilig, ook niet over TLS om dat je niet alleen tegen aanvallen buiten een TLS verbinding moet verdedigen maar ook binnen in. Security werkt het beste als je het in zo veel mogelijk lagen doet. Walled gardens, tunnels of bastions met soft cores gaat je niet de veiligheid bieden die je denkt.

[Barryvdh]

johnkeates schreef op donderdag 7 juni 2018 @ 13:31:
Ga voor OAuth2, dat heeft sessie tokens en refresh tokens, of gebruik HMAC met timestamps. Statische auth is niet erg veilig, ook niet over TLS om dat je niet alleen tegen aanvallen buiten een TLS verbinding moet verdedigen maar ook binnen in. Security werkt het beste als je het in zo veel mogelijk lagen doet. Walled gardens, tunnels of bastions met soft cores gaat je niet de veiligheid bieden die je denkt.

Alleen volgens https://tools.ietf.org/html/rfc6749#section-4.4.3

If the access token request is valid and authorized, the authorization server issues an access token as described in Section 5.1. A refresh token SHOULD NOT be included.

In dat geval draagt de access token request zich dus alsnog als statische key, alleen 1x per sessie ipv per requests, dat was een beetje het punt

Wat natuurlijk wel een voordeel is, is dat OAuth2 een standaard is, dus wat duidelijker/vertrouwder voor mensen.

Voor HMAC met timestamps/nonces is niet echt een vaste standaard toch? Wat bij OAuth2 ed. wel makkelijker is om de implementatie uit te leggen.

[Janoz]

Barryvdh schreef op donderdag 7 juni 2018 @ 13:26:
[...]

Nee klopt, maar het voordeel van JWT is dan dat het je lokaal (bijv. in je app) kan controleren of je token nog geldig is met alleen je token, of dat je extra informatie (permissies, info etc) kan toevoegen aan je JWT token, die je kan valideren door de signature te controleren.
In deze use-case zou je dan toch puur de JWT token als access token gebruiken, dat maakt het toch niet ineens beter, alleen anders?

Ook wanneer je hem alleen als accesstoken gebruikt heeft het voordelen. Je hebt immers alleen het server-secret nodig om het token te valideren. Dit heeft performance voordelen.

[Hydra]

Als het gaat om server-to-server communicatie waarbij je alleen van elkaar wil weten dat je met de juiste server praat: gebruik gewoon mutual TLS. Je gaat de ene kant op toch sowieso over HTTPS dus dan heb je voor de andere kant op maar een extra certificaat nodig.

OAuth of JWT tokens slaan voor dat soort situates de plank volledig mis.

In m'n werk ben ik verantwoordelijk voor de API integraties met een flinke hoop partners en de meerderheid daarvan gebruikt gewoon mutual TLS. Een kleine minderheid een eigen gebouwde oplossing die eigenlijk op hetzelfde neerkomt.

Daarnaast wordt OAuth te pas en te onpas gegrepen zelf als het helemaal niet van toepassing is. OAuth is eigenlijk alleen relevant als een gebruiker partij A toestemming moet geven om informatie naar partij B te sturen. Als je dat niet nodig hebt, dus een gebruiker heeft alleen met jou te maken, is OAuth overkill.

[ Voor 46% gewijzigd door Hydra op 07-06-2018 15:58 ]

[johnkeates]

Hydra schreef op donderdag 7 juni 2018 @ 15:54:
Als het gaat om server-to-server communicatie waarbij je alleen van elkaar wil weten dat je met de juiste server praat: gebruik gewoon mutual TLS. Je gaat de ene kant op toch sowieso over HTTPS dus dan heb je voor de andere kant op maar een extra certificaat nodig.

OAuth of JWT tokens slaan voor dat soort situates de plank volledig mis.

In m'n werk ben ik verantwoordelijk voor de API integraties met een flinke hoop partners en de meerderheid daarvan gebruikt gewoon mutual TLS. Een kleine minderheid een eigen gebouwde oplossing die eigenlijk op hetzelfde neerkomt.

Daarnaast wordt OAuth te pas en te onpas gegrepen zelf als het helemaal niet van toepassing is. OAuth is eigenlijk alleen relevant als een gebruiker partij A toestemming moet geven om informatie naar partij B te sturen. Als je dat niet nodig hebt, dus een gebruiker heeft alleen met jou te maken, is OAuth overkill.

Dat het makkelijk is of veel gebruikt wordt zegt niks over de correctheid. JWT heeft er verder niet zo veel mee te maken, maar gewoon standaard OAuth implementeren is een uitstekende oplossing. Dat je dat dan nog over TLS doet of kan doen doet daar niks aan af. Het zijn dan ook geen technologieen die op hetzelfde niveau werken.

[Hydra]

johnkeates schreef op donderdag 7 juni 2018 @ 17:21:
Dat het makkelijk is of veel gebruikt wordt zegt niks over de correctheid. JWT heeft er verder niet zo veel mee te maken, maar gewoon standaard OAuth implementeren is een uitstekende oplossing. Dat je dat dan nog over TLS doet of kan doen doet daar niks aan af. Het zijn dan ook geen technologieen die op hetzelfde niveau werken.

Wat is je punt? Je kunt als je wil wel tien lagen op elkaar stapelen. Maar je moet het wel allemaal onderhouden.

En nee, OAuth is geen "uitstekende" oplossing voor server to server. Best tool for the job, geen gouden hamers.

[ Voor 9% gewijzigd door Hydra op 07-06-2018 17:22 ]

[johnkeates]

Hydra schreef op donderdag 7 juni 2018 @ 17:22:
[...]


Wat is je punt? Je kunt als je wil wel tien lagen op elkaar stapelen. Maar je moet het wel allemaal onderhouden.

Het punt is dat mutual TLS niet standaard overal in zit of ingebouwd kan worden (tenzij je legacy shit als Java EE of pre-Core .NET spul schrijft) en OAuth wel.

TLS is alleen maar praktisch als common name validatie tussen twee servers, verder niks.

[ Voor 19% gewijzigd door johnkeates op 07-06-2018 17:24 ]

[Hydra]

johnkeates schreef op donderdag 7 juni 2018 @ 17:22:
Het punt is dat mutual TLS niet standaard overal in zit of ingebouwd kan worden en OAuth wel.

Waar kan het niet in ingebouwd worden dan? Da's dan nogal een probleem met je tool.

johnkeates schreef op donderdag 7 juni 2018 @ 17:22:
(tenzij je legacy shit als Java EE of pre-Core .NET spul schrijft)

Oh. Dus omdat je loopt te prutsen met NodeJS is het "legacy shit" als je software wel gewoon standaarden support. Gotcha.

[ Voor 34% gewijzigd door Hydra op 07-06-2018 17:24 ]

[johnkeates]

Hydra schreef op donderdag 7 juni 2018 @ 17:24:
[...]


Waar kan het niet in ingebouwd worden dan? Da's dan nogal een probleem met je tool.

"Je tool" is een beetje ambigue. We hebben het hier over Server->API communicatie, niet over 'een tool'. Bovendien gaat het nog steeds over API communicatie, niet over server-server connectie autenticatie.

Hydra schreef op donderdag 7 juni 2018 @ 17:24:
[...]


Waar kan het niet in ingebouwd worden dan? Da's dan nogal een probleem met je tool.


[...]


Oh. Dus omdat je loopt te prutsen met NodeJS is het "legacy shit" als je software wel gewoon standaarden support. Gotcha.

Misschien moet je het maar bij gamen houden als de wereld van software engineering te snel voor je gaat. De tijd dat je een mainfame moest huren en de 'tool' van de vendor had om mee te bouwen hebben we zo'n 10 jaar geleden achter ons gelate. Ga je mee naar 2018?

[ Voor 42% gewijzigd door johnkeates op 07-06-2018 17:28 ]

[Hydra]

johnkeates schreef op donderdag 7 juni 2018 @ 17:26:
"Je tool" is een beetje ambigue. We hebben het hier over Server->API communicatie, niet over 'een tool'. Bovendien gaat het nog steeds over API communicatie, niet over server-server connectie autenticatie.

Die API is ook gewoon een server. Het enige waarin je geinteresseerd bent is de identiteiten van beide servers (A moet weten dat ie met B praat en vice versa) en versleuteling van het verkeer. Aangezien je altijd via HTTPS werkt is dat extra certificaat maar een kleine stap.

Als je dat om een of andere reden een client gebruikt die het niet ondersteunt dan gebruik je gewoon echt hele verkeerde software.

Komt bij dat je altijd nog de termination aan beide kanten gewoon met Nginx kan doen bijvoorbeeld.

Misschien moet je het maar bij gamen houden als de wereld van software engineering te snel voor je gaat. De tijd dat je een mainfame moest huren en de 'tool' van de vendor had om mee te bouwen hebben we zo'n 10 jaar geleden achter ons gelate. Ga je mee naar 2018?

Lekker op argumenten knul.

[ Voor 21% gewijzigd door Hydra op 07-06-2018 17:30 ]

[johnkeates]

Hydra schreef op donderdag 7 juni 2018 @ 17:27:
[...]


Die API is ook gewoon een server. Het enige waarin je geinteresseerd bent is de identiteiten van beide servers (A moet weten dat ie met B praat en vice versa) en versleuteling van het verkeer. Aangezien je altijd via HTTPS werkt is dat extra certificaat maar een kleine stap.

Als je dat om een of andere reden een client gebruikt die het niet ondersteunt dan gebruik je gewoon echt hele verkeerde software.

Er wordt toch heel duidelijk over een API key gesproken, niet over identiteiten van beide servers. Dat die key misbruikt wordt in WWW-Authenticate maakt nog niet dat het op webserver niveau afgehandeld wordt.

[ Voor 48% gewijzigd door johnkeates op 07-06-2018 19:04 ]

[Hydra]

johnkeates schreef op donderdag 7 juni 2018 @ 17:29:
Er wordt toch heel duidelijk over een API key gesproken, niet over identiteiten van beide servers. Dat die key misbruikt wordt in WWW-Authenticate maakt nog niet dat het op webserver niveau afgehandeld wordt.

Je mist het punt volledig. Die API key 'bewijst' de identiteit van server A naar server B toe. De identiteit van server B naar server A toe is al bewezen dankzei het HTTPS certificaat. Ook de encryptie is al geregeld. Dit alles in de TS van @Barryvdh . Ik geef aan dat die API key nergens voor nodig is, je kunt prima de andere kant ook gewoon met een certificaat doen en je bent klaar. Dit zijn gewoon standaarden.

Het probleem is dat een hoop mensen de TS in verwarring brengen met zaken als OAuth en JWT, beiden prachtige tools als het gaat om identificatie van individuele gebruikers maar dat is volledig niet van toepassing hier. Dit is gewoon server to server.

[johnkeates]

Hydra schreef op donderdag 7 juni 2018 @ 17:35:
[...]


Je mist het punt volledig. Die API key 'bewijst' de identiteit van server A naar server B toe. De identiteit van server B naar server A toe is al bewezen dankzei het HTTPS certificaat. Ook de encryptie is al geregeld. Dit alles in de TS van @Barryvdh . Ik geef aan dat die API key nergens voor nodig is, je kunt prima de andere kant ook gewoon met een certificaat doen en je bent klaar. Dit zijn gewoon standaarden.

Het probleem is dat een hoop mensen de TS in verwarring brengen met zaken als OAuth en JWT, beiden prachtige tools als het gaat om identificatie van individuele gebruikers maar dat is volledig niet van toepassing hier. Dit is gewoon server to server.

Ik denk dat je het punt vooral zelf mist: JWT heeft hier inderdaad geen toepassing maar server-to-server communicatie of server-to-client (gaat om een API hier) gaat prima met OAuth + HMAC.

Het is een protocol dat goed werkt met de API's van Slack, AWS, Google, Microsoft, GitHub, GitLab, DHL, Artifactory, Stackify, DataDog, Unit4, Atlassian (zowel hosted als self-hosted), Exact Online, DockerHub enz. waarbij ze ook mutual TLS op basis van x509 certs hadden kunnen doen, maar dat niet gedaan hebben om dat het minder makkelijk is, minder flexibel, meer implementatietijd kost, minder breed gedragen wordt, en je er een PKI voor moet onderhouden of iemand moet betalen om het voor je te onderhouden.

De enige plekken waar we nog mutual TLS tegen komen zijn legacy applicaties, en verbindingen met bedrijven die 10 jaar per verandering nodig hebben zoals banken, verzekeringsmaatschappijen en de overheid. Van die partijen waar the next best thing SAML 1.1 is, wat ook al weer achter de feiten aan loopt. (Niet dat SAML slecht is, maar als je het ondersteunt, neem dan 2.0)

Voor een API die gebouwd is op Basic Auth in HTTP is het overschakelen naar iets op basis van mutual TLS niet rendabel en zeker niet 1-2-3 in productie te doen. Een applicatie-laag aanpassen om van HTTP auth naar OAuth te gaan is te doen, op protocol-niveau TLS inbakken aan de client kant is meer werk, en minder goed ondersteund. Neem Vecozo bijvoorbeeld, of de Duitse belastingdienst, niemand is daar bij met het eeuwige gezeik met x509 certificaten voor authenticatie. Zelfs x509 op basis van SmartCards is gewoon te veel gezeik qua operationeel werk voor een service die 'gewoon' zou moeten werken.

[mcDavid]

Hydra schreef op donderdag 7 juni 2018 @ 17:35:
[...]


Je mist het punt volledig. Die API key 'bewijst' de identiteit van server A naar server B toe. De identiteit van server B naar server A toe is al bewezen dankzei het HTTPS certificaat. Ook de encryptie is al geregeld. Dit alles in de TS van @Barryvdh . Ik geef aan dat die API key nergens voor nodig is, je kunt prima de andere kant ook gewoon met een certificaat doen en je bent klaar. Dit zijn gewoon standaarden.

Het probleem is dat een hoop mensen de TS in verwarring brengen met zaken als OAuth en JWT, beiden prachtige tools als het gaat om identificatie van individuele gebruikers maar dat is volledig niet van toepassing hier. Dit is gewoon server to server.

Dit idd. HMAC (al dan niet door middel van JWT) en Oauth hebben alléén echt toegevoegde waarde in gedistribueerde systemen. In dit geval zijn er veel makkelijkere oplossingen met minder overhead. Een VPN tunnel gebruiken en alleen binnen het gecontroleerde netwerk communiceren, zou in principe al afdoende zijn. Maar HTTPS is dan nog een stuk makkelijker, en waarschijnlijk minder gevoelig voor configuratiefouten.

@johnkeates het is geen wedstrijd om je gelijk te behalen. De api's die jij aandraagt worden allemaal zéér gedistribueerd gebruikt en zijn dus voorbeelden waar Oauth perfect voor geschikt zijn. Ze hebben zo te zien echter allemaal niets gemeenschappelijk met de setup waar TS het over heeft.

[johnkeates]

mcDavid schreef op donderdag 7 juni 2018 @ 17:54:
[...]


Dit idd. HMAC (al dan niet door middel van JWT) en Oauth hebben alléén echt toegevoegde waarde in gedistribueerde systemen. In dit geval zijn er veel makkelijkere oplossingen met minder overhead. Een VPN tunnel gebruiken en alleen binnen het gecontroleerde netwerk communiceren, zou in principe al afdoende zijn. Maar HTTPS is dan nog een stuk makkelijker, en waarschijnlijk minder gevoelig voor configuratiefouten.

@johnkeates het is geen wedstrijd om je gelijk te behalen. De api's die jij aandraagt worden allemaal zéér gedistribueerd gebruikt en zijn dus voorbeelden waar Oauth perfect voor geschikt zijn. Ze hebben zo te zien echter allemaal niets gemeenschappelijk met de setup waar TS het over heeft.

Laten we het omdraaien: HTTP Basic auth met een statische token is in elk geval niet goed genoeg. Op transport laag zowel je server als je client verbouwen gaat dan weer erg ver en creëert een bende operationeel werk, en operationele kosten. Voor een publieke API (daar gaan we maar even van uit) is het dus zaak om geen B2B achtige oplossingen door te duwen, maar wel op een redelijk niveau qua veiligheid te zitten.

Wat gedistribueerde systemen betreft: vooral JWT is daar zinvol, OAuth maar ook andere in-protocol authenticatie is daar dan weer niet specifiek 'extra' voor bedoeld. Daarbij is het ook niet perse relevant hoe gedistribueerd het systeem is als je alleen vanaf de buitenkant requests maakt naar een API.

[Barryvdh]

johnkeates schreef op donderdag 7 juni 2018 @ 18:14:
[...]


Laten we het omdraaien: HTTP Basic auth met een statische token is in elk geval niet goed genoeg. Op transport laag zowel je server als je client verbouwen gaat dan weer erg ver en creëert een bende operationeel werk, en operationele kosten. Voor een publieke API (daar gaan we maar even van uit) is het dus zaak om geen B2B achtige oplossingen door te duwen, maar wel op een redelijk niveau qua veiligheid te zitten.

Wat gedistribueerde systemen betreft: vooral JWT is daar zinvol, OAuth maar ook andere in-protocol authenticatie is daar dan weer niet specifiek 'extra' voor bedoeld. Daarbij is het ook niet perse relevant hoe gedistribueerd het systeem is als je alleen vanaf de buitenkant requests maakt naar een API.

En waarom is dat 'in elk geval niet genoeg' dan? In welke situatie zou OAuth2 met client_credentials + access tokens met 1 uur expiration wel betrouwbaar zijn, maar basic auth over https niet? Alleen je MITM window is vergroot, maar als je de basic auth kan onderscheppen, kan je ook de request voor access token onderscheppen toch?

[Sandor_Clegane]

Ik zou het, pun intended, lekker basic houden. Al die andere technieken zijn mooi, maar ook weer complex.
Mischien moet je weer extra libraries laden etc. etc.

[johnkeates]

Barryvdh schreef op donderdag 7 juni 2018 @ 18:51:
[...]


En waarom is dat 'in elk geval niet genoeg' dan? In welke situatie zou OAuth2 met client_credentials + access tokens met 1 uur expiration wel betrouwbaar zijn, maar basic auth over https niet? Alleen je MITM window is vergroot, maar als je de basic auth kan onderscheppen, kan je ook de request voor access token onderscheppen toch?

Om dat je MITM window kleiner is inderdaad, maar ook om dat een random packet capture je niet in staat stelt altijd de key te bemachtigen.

[Sandor_Clegane]

johnkeates schreef op donderdag 7 juni 2018 @ 19:01:
[...]


Om dat je MITM window kleiner is inderdaad, maar ook om dat een random packet capture je niet in staat stelt altijd de key te bemachtigen.

Een random packet capture kan niks met SSL. Als je al als MITM fungeert hebben we het al niet meer over een "Random packet capture".

[johnkeates]

Sandor_Clegane schreef op donderdag 7 juni 2018 @ 19:00:
Ik zou het, pun intended, lekker basic houden. Al die andere technieken zijn mooi, maar ook weer complex.
Mischien moet je weer extra libraries laden etc. etc.

Een methode die basic is, maar in dit geval waarschijnlijk wel genoeg is, is puur HMAC voor de authenticatie. Dat is veiliger dan een static basic auth maar simpel genoeg om in een enkele functie te stoppen.

[Sandor_Clegane]

johnkeates schreef op donderdag 7 juni 2018 @ 19:04:
[...]


Een methode die basic is, maar in dit geval waarschijnlijk wel genoeg is, is puur HMAC voor de authenticatie. Dat is veiliger dan een static basic auth maar simpel genoeg om in een enkele functie te stoppen.

Ik zie hier ook niet echt de toegevoegde waarde van om eerlijk te zijn.

[johnkeates]

Sandor_Clegane schreef op donderdag 7 juni 2018 @ 19:12:
[...]


Ik zie hier ook niet echt de toegevoegde waarde van om eerlijk te zijn.

Ik denk dat statische keys net zo goed als geen security beschouwd mogen worden.

[DJMaze]

MitM of niet, de zwakste schakel is altijd de server/client zelf.

Met Basic Auth heb je het wachtwoord plain.
Met elke andere vorm is hij encrypted, maar dat maakt niks uit.
Het "wachtwoord" gaat immers 1 op 1 naar de ander.

Ik heb websites gezien die in de browser het wachtwoord hashen en vervolgens naar de server sturen.
Qua "inloggen" maakt het geen zak uit omdat ik zelf een script kan schrijven die alle hashes op de website kan afvuren.

SSL een oplossing, maar dan kan MitM nog steeds (cloudfront is een goed voorbeeld).

HMAC signature zorgt er alleen voor dat de data niet gemanipuleerd kan worden, je kan het nog steeds lezen.

Als je alles encrypt met SSH/PGP/GPG sleutels (net als wat SSL doet) dan weet je 99.9% zeker dat de transactie veilig is.
Je enige "maar" hier is als de server zelf is gehackt en men je sleutels heeft.
Of deze beveiligingslaag wenselijk is hangt van de data af.

Persoonlijk gebruiken mijn "clients" de public key en ik een private key.

[ Voor 13% gewijzigd door DJMaze op 07-06-2018 20:49 ]

[Barryvdh]

DJMaze schreef op donderdag 7 juni 2018 @ 20:37:
MitM of niet, de zwakste schakel is altijd de server/client zelf.

Met Basic Auth heb je het wachtwoord plain.
Met elke andere vorm is hij encrypted, maar dat maakt niks uit.
Het "wachtwoord" gaat immers 1 op 1 naar de ander.

[..]

SSL een oplossing, maar dan kan MitM nog steeds (cloudfront is een goed voorbeeld).

Met Basic Auth / OAuth2 request voor access token / Api keys in de headers gaat het inderdaad plain, maar SSL is hierbij natuurlijk wel nodig. Weet niet wat Cloudfront met MitM te maken heeft? Cloudfront kan er alleen tussen zitten als ze een geldig certificaat hebben, dat kan een hacker normaal gesproken niet zomaar.

DJMaze schreef op donderdag 7 juni 2018 @ 20:37:

Ik heb websites gezien die in de browser het wachtwoord hashen en vervolgens naar de server sturen.
Qua "inloggen" maakt het geen zak uit omdat ik zelf een script kan schrijven die alle hashes op de website kan afvuren.

Ik weet niet precies wat je hier mee wil zeggen, maar is niet helemaal relevant voor server-side -> api. Daarnaast zit er als het goed op login een throttle zodat je niet kan bruteforcen.

DJMaze schreef op donderdag 7 juni 2018 @ 20:37:
HMAC signature zorgt er alleen voor dat de data niet gemanipuleerd kan worden, je kan het nog steeds lezen.

Klopt, maar je kan niet de key zelf uitlezen. Dus je kan alleen een zelfde request nogmaals doen, maar dit op op te vangen door unieke nonce of timestamp.

DJMaze schreef op donderdag 7 juni 2018 @ 20:37:

Als je alles encrypt met SSH/PGP/GPG sleutels (net als wat SSL doet) dan weet je 99.9% zeker dat de transactie veilig is.
Je enige "maar" hier is als de server zelf is gehackt en men je sleutels heeft.
Of deze beveiligingslaag wenselijk is hangt van de data af.

Persoonlijk gebruiken mijn "clients" de public key en ik een private key.

Als dat hetzelfde is wat SSL doet, wat is dan het voordeel?

[DJMaze]

Barryvdh schreef op donderdag 7 juni 2018 @ 21:00:
Als dat hetzelfde is wat SSL doet, wat is dan het voordeel?

Ik zei niet "hetzelfde", ik zei "net als".
Stel je API verbind met api.example.com, bij DNS poisoning kan het best zijn dat je opeens verbind met een andere server die ook een valide SSL certificaat heeft (maar dan van Comodo, LE, whatever).

Om dat tegen te gaan kan je dus het certificaat controleren, zoals Hydra zegt, en/of zelf de data beveiligen met een sleutel.

Aangezien een SSL certificaat max 3 jaar geldig is, kan het best zijn dat je API niet meer werkt na 3 jaar omdat het certificaat is vervangen.
Dit zie ik namelijk bijvoorbeeld terug bij iDeal. Ik heb door de jaren heen aardig wat CER bestanden van de verschillende banken ontvangen.
Om even aan te kaarten:
Mollie: verloopt 10/10/2019
Atos: 07/01/2017 (die moet ik dus vervangen, nog niet gedaan, oeps!)

Bij SSH/PGP/GPG bepaal je zelf hoelang de sleutel geldig blijft.

[ Voor 3% gewijzigd door DJMaze op 07-06-2018 21:40 ]

[johnkeates]

HMAC is niet zo zeer tegen het lezen, maar ter authenticatie. Als je je API aanroept met data: call + timestamp + api ID + hash(call, timestamp, api id, api key) dan kan de server hetzelfde berekenen om dat die de API key en API ID ook heeft. Door dat de API ID in de call zit kan je de user/client identificeren, en door dat het hele bericht + API key in de hash zit kan je zonder dat je de key kent het bericht niet vervalsen en kan de server om dat die de key heeft de hash narekenen en dus controleren.

TLS is meer voor privacy dan identificatie, hoewel je in theorie een Root CA zou moeten kunnen vertrouwen en er van uit moet kunnen gaan dat de private key van de server niet gelekt is...

TLS + HMAC is qua basic authenticatie en privacy een prima opzetje en vergt weinig verandering en code.

[Barryvdh]

Thijs8472 schreef op donderdag 7 juni 2018 @ 11:09:
Het probleem van 'Basic Auth' is dat je een statische waarde in de requests naar je API hebt. Deze waarde kan hergebruikt worden in geval van MitM of wanneer deze waarde gecompromitteerd wordt (beheerder die ontslagen wordt etc). Iemand die deze waarde heeft heeft 'onbeperkt' toegang tot de API totdat deze waarde veranderd.

Thijs8472 schreef op donderdag 7 juni 2018 @ 11:45:
OAuth2, IP restrictie of client certificaten zijn mitigerende maatregelen voor het eerste risico waarmee je de toegang, of de duur daarvan, tot de API kan beperken (bijvoorbeeld in het geval van MitM).

johnkeates schreef op donderdag 7 juni 2018 @ 19:01:
Om dat je MITM window kleiner is inderdaad, maar ook om dat een random packet capture je niet in staat stelt altijd de key te bemachtigen.

DJMaze schreef op donderdag 7 juni 2018 @ 21:38:
Stel je API verbind met api.example.com, bij DNS poisoning kan het best zijn dat je opeens verbind met een andere server die ook een valide SSL certificaat heeft (maar dan van Comodo, LE, whatever).

Nu klinkt het alsof SSL eigenlijk niet te vertrouwen is, maar een MitM aanval is eigenlijk alleen praktisch mogelijk als je toegang hebt tot ofwel het systeem van de client, ofwel van de API server (of de root CA)?

Want in dat geval zouden regulier inlogs op e-mail, facebook etc ook niet betrouwbaar zijn?

[DJMaze]

@Barryvdh het is nooit 100%, je kan er wel voor zorgen dat je zo dicht mogelijk tegen die 100% aan zit.

• Alleen TLSv1.2 en v1.3 aan zetten, dus zorgen dat SSLv1/2/3 en TLS 1/1,1 niet werken.
• Zorg dat alleen sterke encryptie methoden werken.
• Zorg dat je als client alleen het juiste certificaat accepteert
• Zorg dat je met het juiste IP-adres verbind en niet een andere

Bij e-mail, facebook, etc. kan je niet verwachten dat iedere Nederlander dat snapt en kan.
Daarom heb je voor e-mail S/MIME en OpenPGP.

Maar zoals ik al eerder zei: hoe belangrijk is het?

Ik verwerk credit card nummers, ik moet dus rekening houden met dat SSL lijstje en nog veel meer.
Alle nummers staan dus bijvoorbeeld ook met een 4096 key encrypted op de server, alleen de client kan ze decrypten.
Een hacker kan dus alleen bij de CC nummers als hij de private key op de client heeft bemachtigd EN het wachtwoord van die sleutel weet.

Voor Facebook is dit overkill, de data is niet belangrijk (tenzij je de Chinese overheid bent).

[Sokoo]

Waarom zet je niet een IdentityServer op? Kan je de flow van de tokens zelf bepalen en tevens kan je server er gebruik van maken én je gebruikers, zolang je maar de goede scopes definieert voor beide.

http://identityserver.io/

[Hydra]

Barryvdh schreef op vrijdag 8 juni 2018 @ 09:23:
Nu klinkt het alsof SSL eigenlijk niet te vertrouwen is, maar een MitM aanval is eigenlijk alleen praktisch mogelijk als je toegang hebt tot ofwel het systeem van de client, ofwel van de API server (of de root CA)?

Ja. Als je mutual TLS gebruikt moet je controle hebben over een CA in de chain en over de certificaten. Helemaal als je certificate pinning (sowieso een best-practice) gebruikt is het 'nogal' onwaarschijnlijk.

Het is ook weer een beetje afhankelijk van hoe waarschijnlijk het is dat je aangevallen wordt. Als je over die lijn financiele transacties doet, is het natuurlijk een goed idee om 'all out' te gaan kwa security. Cert pinning, IP whitelisting, etc. Defence in depth. Maar als het een stuk minder gevoelige info is, kan je ervoor kiezen minder van dit soort blokkade's op te werpen. Cert pinning en IP whitelisting leveren natuurlijk ook extra onderhoudswerk te maken. En als je vergeet een cert update mee te nemen, of een server hangt 'opeens' aan een ander IP (/in een andere range) dan werkt je integratie niet meer.

[ Voor 36% gewijzigd door Hydra op 10-06-2018 09:56 ]