IMAP om users in te loggen, veilig?

[Rekcor]

Mijn webapplicatie gaat gebruikt worden door mensen met een mailadres van onze organisatie. Dit mailadres is te benaderen via IMAP. Nu wil ik graag dat mensen in kunnen loggen met dezelfde username/pass als waarmee ze hun mailadres benaderen.

Is de volgende opbouw veilig? Gebruikers vullen een formulier in, wat wordt verstuurd via een AJAX-request via HTTPS. Vervolgens geeft de server 'true' of 'false' terug.

Dus zoiets als:

Client-side

JavaScript:

function login(username, pass) {
  jQuery.post("https://www.mycompany.nl/login.php", { "username": username, "password": pass },   function(result){
   if (result=='true') {
   alert('You are logged in!');
  }else{
   alert('Wrong username/pass!');
  }
}
} );

Server-side, https://www.mycompany.nl/login.php

PHP:

$username = some_function_to_get_safe_form_input($_GET['username']);
$password = some_function_to_get_safe_form_input($_GET['password']);

$mbox = @imap_open ("{imap.mycompany.nl:993/imap/ssl}", $username, $password);
if ($mbox){
echo 'true';
}else{
echo 'false';
}

[ieperlingetje]

toon eens wat login.php nog allemaal bevat?

[Rekcor]

ieperlingetje schreef op dinsdag 27 september 2011 @ 16:49:
toon eens wat login.php nog allemaal bevat?

Niets . D.w.z., die some_function_to_get_safe_form_input moet nog gemaakt worden, maar dat is een kwestie van slim Googlen. Het gaat mij hier meer om het concept, dus ik neem even aan dat $username === de username die gebruiker heeft ingetypt === een veilige string, zonder gekke xss-achtige dingen.

[wizzkizz]

Rekcor schreef op dinsdag 27 september 2011 @ 16:53:
die some_function_to_get_safe_form_input moet nog gemaakt worden, maar dat is een kwestie van slim Googlen

Tip: http://www.php.net/manual/en/function.filter-input.php

Dit is toch een "normale" inlogfunctie, maar dan gechecked tegen een IMAP server ipv een database? Ik zou eerlijk gezegd niet weten waar er een probleem zou zitten, als je alles over SSL beveiligde verbindingen stuurt (wat in je voorbeelden wel zo is). Ik vind het handig bedacht om het zo te doen, geen gezeur met extra wachtwoorden enzo.

Hopelijk dwingt je IMAP-server wel veilig wachtwoorden af, want anders is je webapp ook niet zo jofel te beveiligen natuurlijk.

[extra edit]
Ik weet niet hoeveel extra load je daardoor op je IMAP-servers verwacht, maar je moet wel voorkomen dat die daardoor onderuit gaan

[ Voor 54% gewijzigd door wizzkizz op 27-09-2011 17:01 ]

[Voutloos]

Grootste probleem van deze hele aanpak is dat deze nieuwe applicatie alle mail credentials krijgt. Wellicht allemaal goede intenties en zonder dat je het opslaat, maar het is een flinke verantwoordelijkheid...

edit:
Oei, kijk over de hele client/server side fout heen. Maar goed, als je die implementatie op orde krijgt, staat het grootste nadeel/probleem van je aanpak hierboven. En met zo'n fout als die in de topicstart mag je wel twee keer nadenken voordat je een loginsysteem bouwt, laat staan credentials van een ander systeem gaat verwerken...

[ Voor 47% gewijzigd door Voutloos op 27-09-2011 20:03 ]

[TJHeuvel]

Download eens Firebug, zet een breakpoint op regel 3. In je break window kan je al je locale variablen wijzigen, dus je hoeft enkel result op true te zetten en hoppa, je bent ingelogd!

Javascript is client-side, dat is niet te vertrouwen.

[ Voor 13% gewijzigd door TJHeuvel op 27-09-2011 17:06 ]

[ieperlingetje]

Probleem is zoals je het nu opzet (waarbij php enkel true of false returned) alle beveiliging logica client side gebeurd, terwijl je dit eigenlijk wil serverside laten gebeuren, via sessies en dergelijke meer.

[Remus]

Als je je client-side beveilingsproblemen hebt opgelost, dan zou ik je applicatie dusdanig wijzigen dat hij authenticeert tegen de server die de credentials beheert, niet de IMAP server. Ik neem aan dat die IMAP server zelf ook weer tegen een authenticatieserver praat (bijvoorbeeld LDAP). Je loopt nu een onwijs complex geheel te maken om in te loggen, terwijl daar waarschijnlijk al (kant-en-klare?) oplossingen voor zijn.

[Rmg]

TJHeuvel schreef op dinsdag 27 september 2011 @ 17:06:
Download eens Firebug, zet een breakpoint op regel 3. In je break window kan je al je locale variablen wijzigen, dus je hoeft enkel result op true te zetten en hoppa, je bent ingelogd!

Javascript is client-side, dat is niet te vertrouwen.

ja je bent "ingelogged" maar je mailbox is niet geopend omdat imap zegt fout wachtwoord

[Rekcor]

Bedankt voor de reacties! Dat met die 'true' en 'false' is in mijn geval niet zo'n probleem, aangezien het hier een test betreft, met een gelimiteerd aantal users, die ik bovendien ook ken.

Maar goed, het is natuurlijk beter om het direct goed te doen .

Poging twee:

Client-side

JavaScript:

function login(username, pass) {
  jQuery.post("https://www.mycompany.nl/login.php", { "username": username, "password": pass },   function(key){
   if (key=='false') {
   alert('Wrong username/pass!');
  }else{
  //store key for later use
  }
 }
} );

Server-side, https://www.mycompany.nl/login.php

PHP:

$username = some_function_to_get_safe_form_input($_POST['username']);
$password = some_function_to_get_safe_form_input($_POST['password']);

$mbox = @imap_open ("{imap.mycompany.nl:993/imap/ssl}", $username, $password);
if ($mbox){
  //return a key
  echo createKey();
}else{
  echo 'false';
}

function createKey() {
  $request_ip = $_SERVER['REMOTE_ADDR'];
  $salt = "some-long-string-here";
  $day = date('d'); //only grant access for today
 return md5($request_ip.$salt.$day.$username.$password);
}

Vervolgens stuurt de client met iedere request de key mee, die dan weer gechecked wordt.

Voutloos schreef op dinsdag 27 september 2011 @ 17:00:
Grootste probleem van deze hele aanpak is dat deze nieuwe applicatie alle mail credentials krijgt. Wellicht allemaal goede intenties en zonder dat je het opslaat, maar het is een flinke verantwoordelijkheid...

Maar als ik wil dat users met hun gewone account in kunnen loggen, krijgt mijn applicatie toch altijd die credentials?

[ Voor 0% gewijzigd door Rekcor op 28-09-2011 09:30 . Reden: $_POST ipv $_GET ]

[Rekcor]

Overigens, ik weet nog niet of ik gebruikers op deze manier laat inloggen. Maar stel dat ik het zou willen, en stel dat ik het via IMAP wil/moet doen, kan het dan op een veilige manier?

[TJHeuvel]

Het verschil is dat je nu ook bij hun email kan met dezelfde informatie, en je kan het wachtwoord niet 1-way encrypted opslaan. Je moet altijd weer terug kunnen naar het origineel, wat wel een grote security leak is.

Er is een probleem met je createKey functie, wat zou er gebeuren als ik vanavond om 23:59 inlog?

[kwaakvaak_v2]

Ingelogde gebruikers client side bijhouden is nooit een goed idee. Makkelijker is het om dat volledig server side te laten zien, en de client gebruiken voor de presentatie van de gegevens.

[Herko_ter_Horst]

Ik zou het anders regelen: zet een LDAP-server/AD neer, en laat zowel de IMAP server als je webapp daartegen autenticeren.

Dit is een standaardsituatie, waar je niet zelf het wiel voor moet gaan proberen uit te vinden, met het risico dat je een vierkant wiel krijgt.

[ Voor 39% gewijzigd door Herko_ter_Horst op 28-09-2011 09:37 ]

[Rekcor]

TJHeuvel schreef op woensdag 28 september 2011 @ 09:31:
Het verschil is dat je nu ook bij hun email kan met dezelfde informatie, en je kan het wachtwoord niet 1-way encrypted opslaan. Je moet altijd weer terug kunnen naar het origineel, wat wel een grote security leak is.

Waarom zou ik het wachtwoord op willen slaan dan? De hashed key + username sla ik ergens op, en bij iedere request kijk ik of de user een goede key heeft meegebracht.

TJHeuvel schreef op woensdag 28 september 2011 @ 09:31:
Er is een probleem met je createKey functie, wat zou er gebeuren als ik vanavond om 23:59 inlog?

Dan moet je over een minuut weer inloggen . Voor mijn toepassing is dat geen probleem.

[Rekcor]

kwaakvaak_v2 schreef op woensdag 28 september 2011 @ 09:32:
Ingelogde gebruikers client side bijhouden is nooit een goed idee.

Dit begrijp ik niet.

[Verwijderd]

Begrijp je wel wat de edit knop is? Ook is clientside makkelijker te manupuleren dan serverside.

[Rekcor]

Herko_ter_Horst schreef op woensdag 28 september 2011 @ 09:36:
Ik zou het anders regelen: zet een LDAP-server/AD neer, en laat zowel de IMAP server als je webapp daartegen autenticeren.

Ja, maar jij bent misschien niet een simpel web-devje in een uithoek van een erg groot bedrijf . Natuurlijk zou dat waarschijnlijk de beste oplossing zijn, maar ik ga nu even uit van mijn situatie, waarin ik geen toegang heb tot dit soort oplossingen. Natuurlijk kan de uitkomst vervolgens zijn, dat het gewoon niet (veilig) kan wat ik wil, maar dan heb ik het iig uitgezocht.

[AtleX]

Waarom wil je perse met AJAX inloggen? Skip dat, doe een normale POST en zet een sessioncookie. Dit is echt te gevoelig en te complex.

[Rekcor]

Verwijderd schreef op woensdag 28 september 2011 @ 09:41:
Begrijp je wel wat de edit knop is? Ook is clientside makkelijker te manupuleren dan serverside.

Sorry, maar ook deze reactie begrjip ik niet. Client-side is inderdaad gemakkelijker te manipuleren, maar wat zou je willen manipuleren dan? De key manipuleren levert m.i. niet zoveel op.

[kwaakvaak_v2]

Laat ik het omdraaien dan, waarom wil je perse aan de browser kant bijhouden waarom iemand ingelogd is?

Authenticatie tegen imap aan, in een intranet omgeving is een goed idee, sterker nog heb het zelf ook meerdere malen toegepast binnen bedrijfs netwerken. Makkelijk voor de gebruiker, een wachtwoord to rule them all etc.

Maar je moet aan je applicatie kant (lees PHP dus) bijhouden of iemand is ingelogd, en je display kant (HTML/JS etc) zo stateless mogelijk maken. Niet dat je nu gelijk een MVC moet implementeren. Maar het is veel makkelijker om iets te doen als :

code:

if(user_logged_in()){
 render('logged_in.html');
} else {
 render('login_box.html');
}

function user_logged_in(){
if isset($_SESSION['usertoken'){
 return true;
} 
return false;
}

(disclaimer, ja deze code is puur ter illustratie niet om te laten zien hoe l33t mijn coding skills zijn)

[Voutloos]

Rekcor schreef op woensdag 28 september 2011 @ 09:41:
[...]
Ja, maar jij bent misschien niet een simpel web-devje in een uithoek van een erg groot bedrijf .

Dus iets dat in een groot bedrijf goed geregeld moet zijn, en waar credentials van kritieke andere systemen gebruikt worden mag slecht geimplementeerd worden als het taakje toevallig bij een junior devver terecht komt?

(tussen de regels: taak hoort dan ook niet bij zo'n persoon neergelegd te worden. Tenzij supervisie en persoon zelf meer onderzoek doet.)

Ik wil het zo aardig mogelijk brengen, maar je lijkt momenteel niet geschikt voor de taak. Je mist heel wat basiskennis over authenticatie en security, dus zou eerst nog je kennis moeten bijspijkeren. Op zich doe je dat ook wel hier, maar besef wel dat je nog niet 'ff je taakje af kan maken'.

[ Voor 5% gewijzigd door Voutloos op 28-09-2011 10:31 ]

[steffex]

Voor dat je dit idee gaat implementeren, zou ik eerst eens gaan kijken of je users een privacy statement hebben ondertekend. Je verkrijgt namelijk toegang tot de mailbox van een user met die gegevens, dus in theorie kun je de privacy van de medewerker schenden. Dus als ze daarvoor geen akkoord hebben ondertekend (dmv bijvoorbeeld een clausule in het contract), zou ik hier heel voorzichtig mee zijn.

Verder lijkt het me een goed plan om het aantal inlog pogingen te limiteren, om zo te voorkomen dat iemand je IMAP server onderuit kan trekken.

Waarom zou je verder met keys willen werken om die elke request mee te sturen, php heeft daar namelijk standaard iets voor en heet session_id Gewoon lekker inloggen via IMAP-credentials, kun je verbinding maken, dan een session setten en je kunt aan de slag.

Het wel een goed idee om bij elke request te checken of de sessie nog actief is.

[Rekcor]

Voutloos schreef op woensdag 28 september 2011 @ 10:29:
[...]
Dus iets dat in een groot bedrijf goed geregeld moet zijn, en waar credentials van kritieke andere systemen gebruikt worden mag slecht geimplementeerd worden als het taakje toevallig bij een junior devver terecht komt?

Waarom deze toon aangeslagen? Ik ben alleen maar aan het kijken of iets mogelijk is, binnen een bepaalde set randvoorwaarden (IMAP/AJAX). Ikzelf, maar ook andere 'junior dewers', leren erg veel van dit soort topics.

kwaakvaak_v2 schreef op woensdag 28 september 2011 @ 10:02:
Laat ik het omdraaien dan, waarom wil je perse aan de browser kant bijhouden waarom iemand ingelogd is?

Omdat ik niet weet of de uiteindelijke gebruikers cookies mogen/kunnen opslaan. Maar stel dat het geval is, is 'jouw' oplossing dan veilig?

steffex schreef op woensdag 28 september 2011 @ 10:39:
Voor dat je dit idee gaat implementeren, zou ik eerst eens gaan kijken of je users een privacy statement hebben ondertekend.

Goed punt! Hier hadden we inderdaad al aan gedacht .

[kwaakvaak_v2]

Rekcor schreef op woensdag 28 september 2011 @ 10:49:


Omdat ik niet weet of de uiteindelijke gebruikers cookies mogen/kunnen opslaan. Maar stel dat het geval is, is 'jouw' oplossing dan veilig?

Een session is niet hetzelfde als een cookie. Sessions zijn een server side ding, met eventueel een referentie in een cookie.

En ja dat is veilig, in ieder geval een stuk veiliger dan client side een status zetten.

[Remus]

Rekcor schreef op woensdag 28 september 2011 @ 10:49:
[...]

Waarom deze toon aangeslagen? Ik ben alleen maar aan het kijken of iets mogelijk is, binnen een bepaalde set randvoorwaarden (IMAP/AJAX). Ikzelf, maar ook andere 'junior dewers', leren erg veel van dit soort topics.

Ik begrijp je probleem niet helemaal: Voutloos wijst je op een probleem in jouw redenering en - naar mijn mening - ook in jouw houding hier. Je bent ook nog eens bezig om basale security fouten te maken en daar wordt je gewoon krachtig op gewezen. Daarnaast ken jouw bedrijf zeer waarschijnlijk een beveiligingsbeleid die je nu met voeten treedt. Daar wijzen we je op om te voorkomen dat jouw bedrijf de volgende DigiNotar is die in het nieuws komt; maar jij lijkt dat allemaal in de wind te slaan onder het mom van 'ik ben maar een junior'.

[Herko_ter_Horst]

Rekcor schreef op woensdag 28 september 2011 @ 09:41:
[...]


Ja, maar jij bent misschien niet een simpel web-devje in een uithoek van een erg groot bedrijf . Natuurlijk zou dat waarschijnlijk de beste oplossing zijn, maar ik ga nu even uit van mijn situatie, waarin ik geen toegang heb tot dit soort oplossingen. Natuurlijk kan de uitkomst vervolgens zijn, dat het gewoon niet (veilig) kan wat ik wil, maar dan heb ik het iig uitgezocht.

Zoals Remus ook al zei: als het inderdaad een "erg groot bedrijf" is, lijkt het me sterk dat er niet al een LDAP/ActiveDirectory oplossing is binnen de organisatie. Weet je zeker dat de mailserver de "bron" is van de authenticatiegegevens? Kan best zijn dat de mailserver al gebruik maakt van LDAP/AD en jij dat dus ook kunt doen.

IMAP is geen protocol om authenticatie over te doen. LDAP is dat wel.

Overigens snap ik het issue m.b.t. privacy niet. Iedereen die het recht heeft/krijgt om een applicatie te deployen binnen een organisatie waarbij gebruikers moeten inloggen, krijgt (binnen de applicatie) de inloggegevens van de gebruiker in handen. Aangezien het hele doel van de applicatie is om voor de gebruiker dingen te doen, is er altijd de mogelijkheid om de inloggegevens te misbruiken. Als je de betreffende applicatie of medewerker die de applicatie maakt niet kan vertrouwen, heb je sowieso een probleem. Dat het hier toevallig om een IMAP server gaat, maakt dat potentiële probleem niet ineens groter of erger.

Ik ga toch ook niet roepen dat er een privacyissue is als ik met mijn domeinwachtwoord zowel op onze interne issue tracker als op mijn mail in kan loggen? Ja, in theorie kan de issue tracker applicatie met mijn gegevens inloggen op de mail server en mijn mail lezen. Maar dan kan ik beter helemaal bij het bedrijf weggaan, want dan is de applicatiebeheerder incompetent of corrupt en kan ik dus met goed fatsoen nergens "veilig" inloggen.

[ Voor 41% gewijzigd door Herko_ter_Horst op 28-09-2011 18:32 ]

[Rekcor]

Remus schreef op woensdag 28 september 2011 @ 15:36:
[...]


Ik begrijp je probleem niet helemaal: Voutloos wijst je op een probleem in jouw redenering en - naar mijn mening - ook in jouw houding hier.

Nee, Voutloos speelt het op de man, bijv. met zijn 'je lijkt niet geschikt'. En dat is nergens voor nodig, fnuikend voor ieder gesprek/iedere discussie en bovendien niet constructief.

Remus schreef op woensdag 28 september 2011 @ 15:36:
[...]
Je bent ook nog eens bezig om basale security fouten te maken

Onjuist: omdat ik inderdaad nog niet veel ervaring heb met authenticatie, post ik - voor ik ook maar 1 regel gecoded heb - hier een idee, en vraag ik of het veilig is. Vervolgens wijst iemand me op iets wat in een algemene situatie inderdaad niet veilig is, en probeer ik die fout te fixen. Wat is daar fout aan?

Wat ik graag hoor is: nee, dit is niet veilig vanwege a, b en c; of ja, dit is wel veilig. Ik zit niet te wachten op reacties als 'jij bent niet geschikt voor je taak', want daar leer ik niets van.

Remus schreef op woensdag 28 september 2011 @ 15:36:
Daar wijzen we je op om te voorkomen dat jouw bedrijf de volgende DigiNotar is die in het nieuws komt; maar jij lijkt dat allemaal in de wind te slaan onder het mom van 'ik ben maar een junior'.

Dat is erg lief van jullie, maar ik denk dat jullie de situatie ietwat overdrijven. Het gaat hier om een intranet toepassing, die ik wil uittesten met een door mij geselecteerde groep gebruikers, op een door mij bepaalde tijd in een door mij aangereikte omgeving (Android smartphones). Vandaar ook dat mijn initiële 'true' wat mij betreft prima kan, want mijn testgebruikers willen helemaal niet de boel flessen door via Firebug waarden te veranderen (ze hebben niet eens de beschikking over Firebug, noch een andere 'hacking tool').

Vervolgens was ik ook gewoon nieuwsgierig of inloggen met Javascript/AJAX via IMAP (hoewel misschien niet zo netjes) ook op een veilige manier kan, en zo ja, wat die veilige manier dan is.

Herko_ter_Horst schreef op woensdag 28 september 2011 @ 18:19:
[...]

Zoals Remus ook al zei: als het inderdaad een "erg groot bedrijf" is, lijkt het me sterk dat er niet al een LDAP/ActiveDirectory oplossing is binnen de organisatie. Weet je zeker dat de mailserver de "bron" is van de authenticatiegegevens? Kan best zijn dat de mailserver al gebruik maakt van LDAP/AD en jij dat dus ook kunt doen.

Bedankt! Maar is LDAP/AD per definitie veiliger, of is het alleen maar 'netter' om het zo te doen? Want ik begrijp dat 'proberen een IMAP verbinding te maken' niet netjes is als authenticatievorm, maar is het ook onveilig?

[Herko_ter_Horst]

Rekcor schreef op woensdag 28 september 2011 @ 19:55:
Bedankt! Maar is LDAP/AD per definitie veiliger, of is het alleen maar 'netter' om het zo te doen? Want ik begrijp dat 'proberen een IMAP verbinding te maken' niet netjes is als authenticatievorm, maar is het ook onveilig?

Het is niet "per definitie" veiliger, maar er zijn wel veel meer standaard, veilige oplossingen voor.

Als je begint met beveiliging, kun je veel beter uitgaan van een standaardsituatie in plaats van zelf iets te gaan bouwen tegen een protocol/server die daar niet voor bedoeld is.