Onveilige inlogmethode? Mening gevraagd!

[rodie83]

Beste tweakers,

Enkele tijd terug kwam ik op mijn werk erachter dat het mogelijk is op onze HR portal (productie) automatisch in te loggen door achter de URL het volgende neer te zetten:

?j_user=GEBRUIKERSNAAM&j_password=WACHTWOORD

Dit lijkt mij een nogal ongelukkige manier om in te kunnen loggen, omdat het vereist dat het wachtwoord (unshielded) in de URL wordt opgenomen. Van de portal maken duizenden mensen gebruik en in dit portal zijn voor elke gebruiker verschillende mutaties mogelijk en PD inzichtelijk. Gevoelige informatie dus.

Wat mij betreft behoeft het weinig verbeelding om de veiligheidsrisico's te zien die kunnen voorkomen als mensen deze inlogmethode zouden gebruiken (mensen die de link opslaan in hun favorieten, anderen die dat kunnen zien, enzovoorts).

Wat vinden jullie hiervan? Is dit handig, veilig of moet het naar jullie mening helemaal niet mogelijk zijn?

[djluc]

Meestal wil je een soort challenge opzetten. Dus met een code die dit soort zaken onmogelijk maakt. Daarnaast zijn ze zichtbaar (iemand loopt langs en ziet het) daarom wordt het meestal met een POST request verzonden, jij toont een GET request. Al met al klinkt het niet echt veilig.

Is de verbinding SSL of niet?

[Bigs]

Dit kan inderdaad wel beter ja. Inloggen met een POST request voorkomt de problemen met bookmarks en geschiedenis die jij noemt. Echter moet je dan nog steeds SSL gebruiken om het versleuteld te versturen (wat mij altijd wenselijk lijkt, of het nu intern is of niet).

[djluc]

Zeker op deze schaal en met dit soort gegevens lijkt een ssl certificaat niet misstaan, een echte verplichting zal het wellicht niet zijn maar het mag zeker verwacht worden dat er veilig gewerkt wordt.

[rodie83]

djluc schreef op maandag 11 oktober 2010 @ 10:55:
Meestal wil je een soort challenge opzetten. Dus met een code die dit soort zaken onmogelijk maakt. Daarnaast zijn ze zichtbaar (iemand loopt langs en ziet het) daarom wordt het meestal met een POST request verzonden, jij toont een GET request. Al met al klinkt het niet echt veilig.

Is de verbinding SSL of niet?

Dank voor het antwoord. Enorm technisch ben ik niet, maar ik kan je wel vertellen dat het een SSL verbinding is. Overigens, als je eenmaal zo bent ingelogd veranderd de URL ook niet: die blijft vrolijk op *url*/?j_user=*****_password=***** staan.

Wat bedoel je overigens met een POST request verzenden, als ik vragen mag?

[SvMp]

Het antwoord lijkt mij eenvoudig: Dit moet helemaal niet mogelijk zijn.

Wordt er ingelogd via HTTP of HTTPS? Indien via HTTP, dan is sniffen wel heel eenvoudig.

Ik beschouw het als een bad practice om wachtwoorden als plaintext in de database op te slaan. Een incryptie toepassen is in deze situatie al zinloos, omdat de wachtwoorden hoe dan ook in de logfiles van de server terecht komen.

Daarnaast is dit funest voor de beveiliging als er van de website gebruik wordt gemaakt vanaf een PC waar meerdere mensen op hetzelfde account werken. De history raadplegen is al voldoende.

Auto-inloggen zou ik via een cookie doen, zoals ook bij websites gebeurt als je "blijf ingelogd" aanvinkt.

[ Voor 8% gewijzigd door SvMp op 11-10-2010 11:05 ]

[PeterSelie]

rodie83 schreef op maandag 11 oktober 2010 @ 11:01:
[...]


Dank voor het antwoord. Enorm technisch ben ik niet, maar ik kan je wel vertellen dat het een SSL verbinding is. Overigens, als je eenmaal zo bent ingelogd veranderd de URL ook niet: die blijft vrolijk op *url*/?j_user=*****_password=***** staan.

Wat bedoel je overigens met een POST request verzenden, als ik vragen mag?

Als ik je antwoorden zo lees denk ik dat dit probleem momenteel bij de verkeerde persoon ligt. Is er niemand binnen (of buiten) het bedrijf die technisch verantwoordelijk is voor het systeem?

We kunnen je uitleggen wat het e.e.a. is, maar of jij het vervolgens op kan lossen / kan implementeren is een tweede. Met bovenstaand(e) probleem / klacht kan je beter bij de verantwoordelijke partij aankloppen.

[PeterSelie]

SvMp schreef op maandag 11 oktober 2010 @ 11:04:
Wordt er ingelogd via HTTP of HTTPS? Indien via HTTP, dan is sniffen wel heel eenvoudig.

Ik beschouw het als een bad practice om wachtwoorden als plaintext in de database op te slaan. Een incryptie toepassen is in deze situatie al zinloos, omdat de wachtwoorden hoe dan ook in de logfiles van de server terecht komen.

Daarnaast is dit funest voor de beveiliging als er van de website gebruik wordt gemaakt vanaf een PC waar meerdere mensen op hetzelfde account werken. De history raadplegen is al voldoende.

Auto-inloggen zou ik via een cookie doen, zoals ook bij websites gebeurt als je "blijf ingelogd" aanvinkt.

Via HTTPS? Via SSL inderdaad, zoals hierboven beschreven.

Overigens is de history raadplegen niet voldoende, dan moet men wel met bovenstaande manier hebben ingelogd. Wat ik begrijp van de TS is dat er zo ongelogd kán worden maar de gegevens niet per definitie al via GET verstuurd worden.

[jbdeiman]

@Rodie83
De vraag die ik bij iedereen mis (Hmm, toch niet Hierboven denkt iemand hetzelfde als ik In PHP termen: $_REQUEST['username'] e.d.):

- Is het normaal gesproken, als je via de normale weg inlogt, ook zichtbaar in de URL?

Dit in verband met een (mogelijk) eenvoudigere oplossing voor het oplossen van de zichtbaarheid in de URL, en toch in kunnen loggen.

[ Voor 15% gewijzigd door jbdeiman op 11-10-2010 11:11 ]

[rodie83]

SoaDmaggot schreef op maandag 11 oktober 2010 @ 11:05:
[...]

Als ik je antwoorden zo lees denk ik dat dit probleem momenteel bij de verkeerde persoon ligt. Is er niemand binnen (of buiten) het bedrijf die technisch verantwoordelijk is voor het systeem?

We kunnen je uitleggen wat het e.e.a. is, maar of jij het vervolgens op kan lossen / kan implementeren is een tweede. Met bovenstaand(e) probleem / klacht kan je beter bij de verantwoordelijke partij aankloppen.

Klopt hoor. Ik heb het wel aangekaart bij degene die dat hier weer bij de juiste mensen kan neerleggen, maar die was weinig overtuigd van het feit dat dit onveilig was. Dat bracht me aan het twijfelen, en vandaar dat ik de vraag eens hier wou stellen, nog niet eens zozeer om een oplossing te vragen, maar gewoon om een mening te horen van mensen die er daadwerkelijk verstand van hebben

[rodie83]

jbdeiman schreef op maandag 11 oktober 2010 @ 11:10:
@Rodie83
De vraag die ik bij iedereen mis (Hmm, toch niet Hierboven denkt iemand hetzelfde als ik ):

- Is het normaal gesproken, als je via de normale weg inlogt, ook zichtbaar in de URL?

Dit in verband met een (mogelijk) eenvoudigere oplossing voor het oplossen van de zichtbaarheid in de URL, en toch in kunnen loggen.

Nee, absoluut niet. Na het normaal inloggen blijft de URL hetzelfde als de URL die gebruikt wordt om sowieso op de inlogpagina te komen.

Overigens is de history raadplegen niet voldoende, dan moet men wel met bovenstaande manier hebben ingelogd. Wat ik begrijp van de TS is dat er zo ongelogd kán worden maar de gegevens niet per definitie al via GET verstuurd worden.

Inderdaad áls er via bovenstaande manier wordt ingelogd is in de history het ww terug te vinden. Dit is uiteraard niet het geval als er gewoon wordt ingelogd.

De nuancering is wel, dan ben ik vergeten te melden, dat er waarschijnlijk geen of zeer weinig gebruikers zijn die sowieso weten dat ze zo zouden kunnen inloggen. Maar goed, dat maakt het niet minder onveilig natuurlijk

[ Voor 34% gewijzigd door rodie83 op 11-10-2010 11:18 ]

[Bigs]

Gaat het eigenlijk om een commercieel verkrijgbaar pakket of om een in-house ontwikkelde oplossing?

Wees trouwens wel voorzichtig met het aankaarten van dit probleem, je zult niet de eerste klokkenluider zijn die z'n baan verliest omdat hij door het management niet begrepen wordt. Er hoeft maar 1 iemand te roepen dat je een hacker bent die gevaar oplevert voor het bedrijf en je staat zo op straat ik zeg het maar even .

[ Voor 62% gewijzigd door Bigs op 11-10-2010 11:21 ]

[Davio]

Ach, misschien moet je om hem te overtuigen eens zijn eigen inloggegevens presenteren.

Sowieso moet je je als verantwoordelijke schamen en direct je ontslag indienen als je denkt dat dit wél veilig is. Maar ja, bij sommige bedrijven wordt Jan de adminstratieve medewerker die in zijn vrije tijd wel eens met computers knutselt nou eenmaal gepromoveerd tot systeem- / netwerkbeheerder in plaats van dat ze iemand aannemen die er écht verstand van heeft.

Maar goed, om terug te komen op jouw zaak: Het lijkt erop alsof de inloggegevens gewoon gecheckt worden met PHP register_globals aan of iets dergelijks, waardoor je dus met zowel GET als POST in kunt loggen. En de normale manier zal dan wel POST zijn met een formpje, maar zo kan het dus ook.

Ik zou in jouw geval de verantwoordelijke toch ten strengste aanbevelen om:
1. Alleen inloggen via POST mogelijk te maken door $_POST[blaat] uit te lezen en niet $blaat.
2. Een captcha te gebruiken tegen scriptmisbruik: http://www.phpcaptcha.org/ (natuurlijk niet 100% waterdicht, maar wél redelijk)

[Janoz]

Dit lijkt me een standaard JEE implementatie met form based authenticatie. Er is geen onderscheid tussen get en post, maar het standaard formulier wordt met post verstuurd. Omdat het ook via SSL gaat is er bij normaal gebruik geen enkel security probleem. Dat probleem komt pas wanneer mensen daadwerkelijk op deze manier in gaan loggen.

[barfieldmv]

Het is een ongelukkige manier om te kunnen inloggen, maar zolang het niet gebruikt word is het niet onveilig.

Zelf zou ik er een melding van maken en voor de rest lekker laten liggen. Zodra iemand anders over de schouder van de gebruiker kan meekijken naar de url is de security toch al om zeep geholpen. (keylogger van usb schijf is in 5 tellen geinstalleerd )

Wat je natuurlijk altijd kan vragen is wat de wachtwoord/beveiligings guidelines zijn binnen het bedrijf en deze doorlezen, daar staat waarschijnlijk in dat het verboden is om je wachtwoord en inlog op post-it of scherm te tonen. . Daarmee heb je nog een sterkere zaak om het aan te kaarten.

[Zyppora]

rodie83 schreef op maandag 11 oktober 2010 @ 11:10:
Ik heb het wel aangekaart bij degene die dat hier weer bij de juiste mensen kan neerleggen, maar die was weinig overtuigd van het feit dat dit onveilig was.

Loop eens bij de beste man binnen en vraag hem eens om in te loggen, terwijl jij meekijkt. En dan naar zijn password in de URL wijzen 'hey wat is dat?'

[Kompaan]

Als jik het zo lees, is het inlogggen via de getoonde GET request niet de standaard manier, dus het enige wat ze hoeven te doen is die manier uitschakelen, correct?

Mijn mening is dat dit helemaal niet mogelijk moet zijn, zeker als er al een betere manier beschikbaar is.

[Verwijderd]

Wellicht dat je beter sessies kunt gebruiken in plaats van cookies. Hiervoor heb je op de client maar 1 kleine cookie nodig met 1 sessie ID. Je kunt deze cookie zelfs flaggen als http_only zodat de cookie in ieder geval is beschermd tegen XSS-aanvallen. Alle identity data sla je dan op in de sessie op de server. Op deze manier heb je altijd een koppeling tussen client en applicatie zonder dat je naar de URL moet gaan kijken.

Ten tweede adviseer ik je ten alle tijde POST te gebruiken, zodat de gegevens bij het inloggen niet in de URL worden meegestuurd maar in een apart pakketje. Als je dat combineert met SSL, is dat natuurlijk alleen maar beter.
In PHP moet je dan niet de superglobal $_GET gaan uitlezen, maar de superglobal $_POST. Verder verloopt de authentication hetzelfde.

Zie ook deze links: PHP Sessions, PHP POST superglobal.

Succes!

/edit Wordt dat wachtwoord in de URL eigenlijk as is verstuurd () of gaat er nog een clientside md5() overheen?

[ Voor 5% gewijzigd door Verwijderd op 13-10-2010 11:28 ]

[Janoz]

Verwijderd schreef op woensdag 13 oktober 2010 @ 11:27:
Wellicht dat je beter sessies kunt gebruiken in plaats van cookies. Hiervoor heb je op de client maar 1 kleine cookie nodig met 1 sessie ID.

Je kunt deze cookie zelfs flaggen als http_only zodat de cookie in ieder geval is beschermd tegen XSS-aanvallen. Alle identity data sla je dan op in de sessie op de server. Op deze manier heb je altijd een koppeling tussen client en applicatie zonder dat je naar de URL moet gaan kijken.

Waar haal je vandaan dat hier alles in cookies opgeslagen wordt? Het gaat hier gewoon over een authenticatie actie die waarschijnlijk normaal via POST gaat, maar ook werkt middels een GET request.

Ten tweede adviseer ik je ten alle tijde POST te gebruiken, zodat de gegevens bij het inloggen niet in de URL worden meegestuurd maar in een apart pakketje. Als je dat combineert met SSL, is dat natuurlijk alleen maar beter.

Er wordt POST gebruikt, alleen accepteert de server de parameters ook als GET.

In PHP moet je dan niet de superglobal $_GET gaan uitlezen, maar de superglobal $_POST. Verder verloopt de authentication hetzelfde.

Zie ook deze links: PHP Sessions, PHP POST superglobal.

Het gaat hier helemaal niet over php. Gezien de gebruikte techniek lijkt het eerder op een J2EE omgeving.

Succes!

/edit Wordt dat wachtwoord in de URL eigenlijk as is verstuurd () of gaat er nog een clientside md5() overheen?

De TS verstuurd handmatig dit zelf geconstrueerde GET request. De applicatie gebruikt zeer waarschijnlijk gewoon een POST form.

[DiedX]

Wordt de applicatie ook buiten een intranet gebruikt? Of is het alleen intern?

[Verwijderd]

Janoz schreef op woensdag 13 oktober 2010 @ 12:11:
[...]

Waar haal je vandaan dat hier alles in cookies opgeslagen wordt? Het gaat hier gewoon over een authenticatie actie die waarschijnlijk normaal via POST gaat, maar ook werkt middels een GET request.


[...]

Er wordt POST gebruikt, alleen accepteert de server de parameters ook als GET.

[...]


Het gaat hier helemaal niet over php. Gezien de gebruikte techniek lijkt het eerder op een J2EE omgeving.

[...]

De TS verstuurd handmatig dit zelf geconstrueerde GET request. De applicatie gebruikt zeer waarschijnlijk gewoon een POST form.

Dank voor de goedbedoelde verbeteringen.

[Lethalis]

Hoewel de bestaande inlogmethode onveilig zou kunnen zijn (valt waarschijnlijk wel mee), blijft het de vraag of jij je daarmee moet bemoeien.

Op mijn werk staan zoveel (legacy) systemen die met plain passwords werken en waar je met een paar handgrepen alle rechten hebt. De vraag blijft alleen wel:
- Wie heeft er belang bij?
- Hoe gevoelig is de informatie?
- Wat zijn de (financiele) gevolgen?
- Hoeveel geld kost het om de bestaande situatie te wijzigen?

En dan blijkt vaak dat het wijzigen van de bestaande situatie veel meer tijd en geld kost dan het opvangen van incidenten die in de praktijk nauwelijks voorkomen.

Vanuit technisch oogpunt is het natuurlijk vreselijk, maar vanuit de business gezien vaak acceptabel.

Een POST over SSL is overigens prima. De variabelen staan niet in de URL en de form data gaat door de SSL tunnel waardoor je met een packet sniffer niets ziet.

Kompaan schreef op dinsdag 12 oktober 2010 @ 08:48:
Als jik het zo lees, is het inlogggen via de getoonde GET request niet de standaard manier, dus het enige wat ze hoeven te doen is die manier uitschakelen, correct?

Mijn mening is dat dit helemaal niet mogelijk moet zijn, zeker als er al een betere manier beschikbaar is.

Aan de andere kant komt niemand normaal gesproken op het idee om een GET te doen en de grapjassen zoals TS die het wel doen zorgen ervoor dat de veiligheid hun eigen account gecompromitteerd wordt

[ Voor 42% gewijzigd door Lethalis op 13-10-2010 16:27 ]

[Soultaker]

Ik zat me de eerste tien posts af te vragen of het inloggen nu "kon" of "moest" op deze manier. Het blijkt dus het eerste te zijn: je kúnt je zo authenticeren, maar normaal gesproken ga je naar een login pagina die die data gewoon POST en vervolgens komen ze niet in de URL terecht.

In dat geval zou ik zeggen: niets aan de hand. Als je als gebruiker zelf je wachtwoord in de URL gaat zetten dan vráág je ook om problemen, los van of de server die data nu wel of niet gebruikt om in te loggen. Ik kan mijn wachtwoord hier ook op het forum posten als ik dat zou willen; dat maakt het nog geen lek in de website.

[Remus]

Bij mijn vorige werkgever had de software juist met opzet een vergelijkbare authenticatie mogelijkheid; dat maakte het makkelijk om externe systemen ook - geauthenticeerd - bepaalde informatie in te schieten zonder dat er een aparte webservice entrypoint gerealiseerd hoefde te worden; zolang ze HTTP post konden doen werkte het.