is dit veilig?

[Verwijderd]

Hallo,

Ik heb 2 verschillende hostingabonnementen en wil van op een website van server1 automatisch laten inloggen op server2.
Ik heb een systeem voorzien waarbij server 1 een postrequest doet bij server 2 met 2 lange en complexe sleutels in de post (soort login-pw). Server 2 genereert een hash en stuurt die terug naar server 1. Server 1 redirect naar een pagina met de hash in een GET request waardoor de gebruiker automatisch ingelogd wordt. De hash wordt gechecked in de db en moet gebruikt worden binnen enkele seconden, anders vervalt hij. Tevens kan hij maar eenmalig gebruikt worden.
Dit lukt allemaal wonderwel, maar ik vroeg me af of dit een veilige manier is om in te loggen. Ziet iemand hier mogelijke beveiligingsproblemen in?

[Ypho]

Op zich is dit redelijk veilig, zolang een hacker niet weet hoe de lange complexe sleutel wordt gegenereerd.

Dit lijkt een beetje op Digest Access Authentication, wellicht kun je daar iets mee? Dat wordt gebruikt in onder andere Webservices, waar je ook communiceert tussen twee servers. (Wikipedia: Digest access authentication).

[Orion84]

Ik heb weinig kaas gegeten van het ontwikkelen van webapplicaties, maar vraag me even af of hier geen standaard oplossingen voor zijn die je kan implementeren, in plaats van zelf iets te bedenken?

Los daarvan, heb ik wel enig verstand van security, dus daarop inhakend: wat stellen die 2 (waarom 2?) lange en complexe sleutels voor? Hoe moet server 2 valideren dat die sleutels daadwerkelijk bij een succesvolle inlogpoging op server 1 horen?

Ik zou eerder verwachten dat server 1 aan server 2 een challenge vraagt, waarop server 2 een verse random string terug stuurt. Server 1 hasht die string samen met (de hash van) het wachtwoord van de gebruiker en gebruik dat resultaat vervolgens als sleutel in de redirect naar server 2. Server 2 kan dan controleren of dat inderdaad klopt door zelf ook de challenge en password hash te combineren en te vergelijken met wat er via de GET binnenkomt.

Aannemende dat beide servers over de user database beschikken met daarin dezelfde wachtwoordhashes.

Edit: en dat is dus ongeveer wat beschreven staat in dat DAA artikel dat hierboven gelinkt word, zie, er zijn gewoon standaard oplossingen voor

[ Voor 6% gewijzigd door Orion84 op 11-09-2015 09:57 ]

[Rukapul]

Er zijn natuurlijk SSO standaarden zoals SAML (Web SSO profile). Met wat kneden kun je dit ook nog wel op OAuth mappen. Maar in dit geval is dat allemaal overkill. Er is namelijk een trustrelatie tussen de servers (zelfde eigenaar etc).

Zelfs de oplossing van topicstarter is onnodig complex. Server 1 kan namelijk ook meteen een autorisatie assertion / token meegeven in de redirect naar server 2. Dat kan conform standaarden, bv SAML, maar ook door zelf iets te fabriceren zoals { payload, HMAC-SHA256(key, payload) } waarbij payload bijvoorbeeld { time, user } is en key een geheim wat alleen server 1 en 2 delen. Time gebruik je dan om het in tijd te beperken, maar kan ook anders opgelost worden waaronder single use zoals in de topicstart, maar dan zit je met issues rondom een refresh etc.

Even snel uit de losse pols, maar deze richting kan het vrij simpel en zonder de latency van een extra roundtrip.

[ Voor 15% gewijzigd door Rukapul op 11-09-2015 10:10 ]

[Janoz]

Die 2 complexe sleutels is leuk, maar de 2e sleutel voegt weinig toe. Wat beter is is om de toegang tot die hash generatie methode te beperken (bv dmv ip adres) zodat alleen server 1 deze aan kan roepen.

Ik heb zelf ook een dergelijke overdracht geimplementeerd. Een gebruiker werd doorgestuurd naar een andere server voor het downloaden van een groot bestand. Dit wordt door een apparte apache server afgehandeld die zo simpel mogelijk geconfigureerd was. Deze had dan ook geen toegang tot de sessieinformatie of authentiecatie informatie van de applicatie server en het is ook niet de bedoeling dat gebruikers opnieuw in moeten loggen. De uiteindelijke implementatie deed onderwater een request naar de aparte server (via het lokale netwerk) om aan te geven welk bestand aangeboden zou worden. Hierop kreeg de applicatieserver inderdaad een hash terug en deze werd meegegeven met de redirect. Deze hash was slechts 5 seconden geldig/ Van de download server was van buitenaf enkel die downloadlink beschikbaar.

Omdat het aanmelden en het verkrijgen van een hash via een vertrouwd kanaal ging was er helemaal geen noodzaak om hiervoor allemaal shared secrets of tokens te gebruiken.

[ Voor 71% gewijzigd door Janoz op 11-09-2015 10:09 ]

[H!GHGuY]

Is SSH forwarding iets voor jou? Dan heb je het hele security gebeuren extern gemaakt aan je applicatie en vertrouw je't toe aan iets wat ervoor gemaakt is.

[pedorus]

Verwijderd schreef op vrijdag 11 september 2015 @ 09:40:
Ik heb een systeem voorzien waarbij server 1 een postrequest doet bij server 2 met 2 lange en complexe sleutels in de post (soort login-pw). Server 2 genereert een hash en stuurt die terug naar server 1. Server 1 redirect naar een pagina met de hash in een GET request waardoor de gebruiker automatisch ingelogd wordt. De hash wordt gechecked in de db en moet gebruikt worden binnen enkele seconden, anders vervalt hij. Tevens kan hij maar eenmalig gebruikt worden.

Het verhaal is me net niet duidelijk genoeg. Laten we voorop stellen dat de communicatie tussen Server 1 en Server 2 veilig moet worden gemaakt, als de 2 sleutels uitlekken vervalt de beveiliging. Je zou het liefst aan beide kanten certificates hebben.

Janoz schreef op vrijdag 11 september 2015 @ 10:04:
Wat beter is is om de toegang tot die hash generatie methode te beperken (bv dmv ip adres) zodat alleen server 1 deze aan kan roepen.

ip-adres beveiliging alleen is in principe niet voldoende natuurlijk

Daarnaast snap ik niet waarom je een hash zou genereren ipv een een random sleutel met voldoende entropy. Scheelt ook nogal waarvan je die hash maakt.

En daarnaast zou je bijv. nog kunnen checken op CSRF als de extra inlogactie vanaf de gebruiker moet komen.

Ik ga natuurlijk uit van https-verbindingen tussen de gebruiker en de server.

[Verwijderd]

Bedankt voor de reacties. Interessant leesvoer!
Ik heb een aantal bedenkingen bij sommige van de voorgestelde oplossingen.
@Orion: Voor alle duidelijkheid: de beide servers hebben geen toegang tot dezelfde user database. De 2 lange sleutels zijn vaste strings. 2 omdat dat veiliger is dan 1.
@Rukapul: je oplossing gaat ervan uit dat beide servers de exact zelfde tijdsinstelling hebben. Ik denk niet dat dat gegarandeert kan worden, wel? Ook user is niet bekend bij server2.
@pedorus: waarom zouden de sleutels uitlekken? Wat bedoel je met certificates aan beide kanten? IP adres kan ik inderdaad nog toevoegen, dat lijkt me wel een goed idee. Dat CSRF ga ik bekijken.

Alvast bedankt allemaal om mee te denken.

[Boss]

En alles natuurlijk over een beveiligde verbinding :-)

[Rukapul]

Verwijderd schreef op woensdag 16 september 2015 @ 09:02:
@Rukapul: je oplossing gaat ervan uit dat beide servers de exact zelfde tijdsinstelling hebben. Ik denk niet dat dat gegarandeert kan worden, wel?

Correct, maar met NTP hoeft dat geen probleem te zijn. Desnoods draai je op de ene server de NTP server voor de ander. Een marge is daarnaast eenvoudig toe te staan.

Alternatief is gebruik van een sequence number.

Ook user is niet bekend bij server2.

Userid wordt meegegeven in het voorstel. Indien meer info nodig is dan kan dat opgevraagd worden middels een backend call.

[raptorix]

Let op dat je in een GET request die niet over SSL is, geen externe bronnen inlaat, deze zien dan namelijk de hash als Referer.