Automatisch inloggen
Algemeen vraagje.
Hoe loggen jullie(veilig) en automatisch in op een website. Ik bedoel dus niet de eerste keer maar de volgende keren.
1° keer= login + paswoord
2° keer=????
Zelf sla ik wel de login/e-mail op in een koekje maar zeker niet het paswoord. wat me dus niet toelaat om automatisch in te loggen, maar wel om alvast de login in te vullen
Jan
Ik denk niet dat hij zoiets bedoelt. Volgens mij bedoelt ie net zoals hier op de site een "Onthoud mij" optie. Dus je logt de 1e keer in, je plaatst een vinkje bij "Onthoud mij" en de volgende keer ben je automatisch ingelogd. Ik denk dat hij dat bedoelt.
Het lijkt me tegenwoordig helemaal niet zo vreemd dat je meerdere vaste (maar verschillende) locaties hebt vanwaar je inlogt?
Ik gebruik een heel simpel stramien waarmee je op IP-basis logins onthoudt. Een noodzakelijke voorwaarde is dan wel dat dit IP niet verandert.
Het principe is als volgt: als je inlogt, kun je aangeven dat je je login wilt onthouden. Als je deze optie aanvinkt en succesvol inlogt wordt voor een bepaalde periode deze (succesvolle) login onthouden, en wel op de volgende manier:
Het enige wat ik aan de clientside opsla is één cookie (genaamd "remember_login" ofzo) met hierin één waarde: een random hash. Deze hash heeft verder geen enkele betekenis en is gewoon random: deze is niet gebaseerd op login-gegevens, je geboortedatum of de naam van je eerste huisdier. Random.
Aan de serverzijde houd ik een simpel database-tabelletje bij:
Code (php)
1
2
3
4
5
6
7
8
9
2
3
4
5
6
7
8
9
+-------------+---------------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+-------------+---------------------+------+-----+---------+----------------+
| rli_id | bigint(20) unsigned | NO | PRI | NULL | auto_increment |
| rli_expires | datetime | NO | | NULL | |
| rli_hash | varchar(255) | NO | UNI | NULL | |
| rli_ip | varchar(255) | NO | | NULL | |
| rli_user_id | bigint(20) unsigned | NO | | NULL | |
+-------------+---------------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+-------------+---------------------+------+-----+---------+----------------+
| rli_id | bigint(20) unsigned | NO | PRI | NULL | auto_increment |
| rli_expires | datetime | NO | | NULL | |
| rli_hash | varchar(255) | NO | UNI | NULL | |
| rli_ip | varchar(255) | NO | | NULL | |
| rli_user_id | bigint(20) unsigned | NO | | NULL | |
+-------------+---------------------+------+-----+---------+----------------+
Wanneer iemand de site bezoekt worden de volgende dingen gecontroleerd:
Als iemand de site bezoekt wordt gecontroleerd of iemand niet is ingelogd maar wel een remember_login cookie heeft geset.
Zo ja: lookup hash in combinatie met ip en binnen verloopdatum
Geen resultaat: unset cookie, deze was niet geldig (meer)
Wel resultaat: log gebruiker in en ververs eventueel de levensduur van het cookie en de tabel entry. Je kunt op dat moment ook besluiten om de hash te verversen zodat deze hash niet te lang "gefixeerd" blijft.
Volgens mij is deze methode simpel, veilig en transparant (geen security through obscurity). Het enige "nadeel" wat hier aan kleeft is dus het vaste IP.
EDIT: er komt dus een record in die tabel bij op het moment dat je succesvol inlogt en aangegeven hebt dat je onthouden wil worden, ook wordt dan het cookie met matchende hash geset.
Gewijzigd op 07/08/2015 13:03:22 door Thomas van den Heuvel
Dus als ik het goed begrijp ... we hebben een school met 2.000 leerlingen. Een van die leerlingen gaat hashes "gokken" totdat ie een keer raak heeft en dan is ie vanzelf ingelogd? Hmmm ... is dat wel veilig?
Twee punten:
- veiligheid is een tradeoff met een afnemende meeropbrengst; tis maar net hoe veilig je iets wil maken he...
- zoals aangegeven moet je je oplossing wel afstemmen op de situatie waarin je deze gebruikt
Ik ging er een beetje van uit dat het uitgangspunt "eenvoud" was, veel simpeler (in verhouding tot wat je er aan functionaliteit voor terugkrijgt) wordt het niet.
Ga lekker verder met het stapelen van complexiteit. Dan ben je al bezig met hetgeen ik aangaf over tradeoffs, maar volgens mij is dat niet helemaal aangekomen.
Hee ik heb een suggestie: voeg nog 20 hashes toe, dat raden ze nooooooooooooit!
But why stop there...
Grappig dat mijn oplossing meteen wordt afgeschreven op grond van een situatie waarin deze oplossing overduidelijk ongeschikt is (drogredening much?).
Zoals zoveel topics is deze ook alweer redelijk ontspoord. Ik geef antwoord op de vraag van de topicstarter en meteen wordt mijn oplossing onder een vergrootglas gegooid en gekoppeld aan een onzinnige situatie. Denk je dat ik hier niet zelf over nagedacht heb ofzo? ...
Security kun je nooit genoeg hebben, je moet zelf bepalen wanneer je dit punt hebt bereikt of waar je moet stoppen door externe factoren (geld, tijd etc.).
Het zou daarom wel handig zijn als de topicstarter aangeeft in welke specifieke situatie en voor welke toepassing hij deze functionaliteit wil gaan gebruiken, want ik weet niet of deze offtopic bs nog ergens naartoe gaat tot iets wat leidt tot het daadwerkelijk beantwoorden van de vraag.
Ozzie PHP op 07/08/2015 13:03:08:
@Thomas
Dus als ik het goed begrijp ... we hebben een school met 2.000 leerlingen. Een van die leerlingen gaat hashes "gokken" totdat ie een keer raak heeft en dan is ie vanzelf ingelogd? Hmmm ... is dat wel veilig?
Dus als ik het goed begrijp ... we hebben een school met 2.000 leerlingen. Een van die leerlingen gaat hashes "gokken" totdat ie een keer raak heeft en dan is ie vanzelf ingelogd? Hmmm ... is dat wel veilig?
Gokken kun je ook doen met passwords. De gemiddelde hash zal langer zijn dan het gemiddelde password en dus minder snel te bruteforcen. Bovendien, aangezien het een volkomen random sequentie van karakters is (en een password meestal niet) is het ook niet mogelijk te beredeneren wat de hash kan zijn, iets wat bij veel passwords wél kan.
Aangezien een inbreker doorgaans het huis zal kiezen waar hij het makkelijkst binnen kan komen, zal iemand die probeert de login te kraken dus eerder geneigd zijn zijn energie te stoppen in het raden van het password dan in het raden van de hash.
Daar komt bij: stel dat het je lukt de hash te raden. Dan kun je dus inloggen onder die ene gebruiker. Maar zodra die gebruiker zelf ook weer inlogt en daarmee een nieuwe hash aanmaakt, lig je er weer uit. Nog een argument dus om je aandacht te richten op het password, aangezien dat meestal ook minder vaak wijzigt.
Gewijzigd op 07/08/2015 13:56:36 door Willem vp
>> Hee ik heb een suggestie: voeg nog 20 hashes toe, dat raden ze nooooooooooooit!
Dat is natuurlijk onzin. Je maakt gebruik van 1 hash. Het is gewoon "raden" totdat je de juiste hash hebt. Gebeurt dat in een omgeving met hetzelfde IP-adres, wat tegenwoordig niet iets vreemds is, dan ben je de sigaar. Er is geen reden om je persoonlijk aangesproken te voelen. Ik geef enkel aan dat de gekozen oplossing wellicht niet helemaal veilig is. En jij kan dat dan goed praten door te zeggen dat in sommige situaties minder veilige oplossingen ook volstaan, maar dat vind IK dan juist weer een drogreden.
Laten we even zeggen dat met jouw oplossing in mijn cookie de hash abc staat. Ik hoef er dan maar een programmaatje op los te laten, en op een gegeven moment levert dat een hit op met 'abc'. Echter zouden we nog een extra kenmerk toevoegen, dus 2 controles, dan wordt het een stuk lastiger. Stel we hebben de hash 'abc' en we voegen een extra kenmerk 'xyz' toe, dan moeten beide waardes kloppen. Op het moment dat er een hit plaatsvindt met 'abc' en 'xyz' klopt niet, weet je dat er iets niet in de haak is. Op dat moment kun je die 'abc' hash per direct vernietigen. Mission accomplished.
Maar je eigen code refactor je ook vaak, daarom bestaat refactoring.
Houdt het D.R.Y en Refactor waar nodig.
Ben nog steeds van mening dat PHPhulp een goeie concurent kan krijgen, helaas heb ik geen tijd.
Nu weer on-topic. De oplossing met IPadres is een oplossing alleen is het lekkig ben ik van menig.
Ik zeg zelf een cookie plaatsen, en hoe je het ip gebonden kan doen.. geen idee.. cookie is denk toch het veiligst :$
AL je commentaar is gestoeld op de aanname dat iedereen op "hetzelfde" IP zit. En zelfs op een school heeft elke individuele computer nog steeds een eigen intern IP (EDIT: oh je ging er vanuit dat de site op internet stond - en wat nu als deze lokaal draait? OMG dan werkt het wellicht wel? Mits je altijd achter dezelfde PC zit... dit systeem past gewoon niet in jouw voorbeeld). Daarnaast ga je als leerling niet elke keer achter dezelfde computer zitten dus het hele principe waaronder mijn oplossing opereert is in deze opstelling niet van toepassing. Het daarom bestempelen van mijn oplossing als "niet veilig" is daarom gewoon ongegrond.
Ik wist ook niet dat we het over een intranet hadden, de topicstarter had het hier niet specifiek over. Als deze het dan over een website heeft dan denk ik altijd aan zo'n ding ergens op het internet.
Daarnaast worden twee "zwakke" punten genoemd:
- de sterkte van het wachtwoord
- brute forcen
Sorry hoor, maar volgens mij is dat niet een specifiek probleem van mijn oplossing en vormen beide aparte problemen (separation of concerns).
Als een gebruiker Hennie als wachtwoord "welkom123" kiest, sja, tegen de stupiditeit van gebruikers is eigenlijk geen kruid gewassen.
En dit gaat wederom weer over de eerdergenoemde tradeoff: hoeveel moeite wil je doen om iets "veilig" te maken? Eisen ten aanzien van de sterkte van het wachtwoord en het limiteren van inlogpogingen hebben niets maar dan ook niets met mijn bovenstaande oplossing te maken. Als je het leuk vindt kun je dat altijd nog toevoegen. Dan is het alweer veiliger.
Quote:
Daar komt bij: stel dat het je lukt de hash te raden. Dan kun je dus inloggen onder die ene gebruiker. Maar zodra die gebruiker zelf ook weer inlogt en daarmee een nieuwe hash aanmaakt, lig je er weer uit. Nog een argument dus om je aandacht te richten op het password, aangezien dat meestal ook minder vaak wijzigt.
Ook hier wordt er volgens mij vanuit gegaan dat je vanuit hetzelfde IP opereert?
Quote:
Op het moment dat er een hit plaatsvindt met 'abc' en 'xyz' klopt niet, weet je dat er iets niet in de haak is. Op dat moment kun je die 'abc' hash per direct vernietigen. Mission accomplished.
En een eerder geauthenticeerde gebruiker is dan ineens niet langer ingelogd. Mission accomplished?
Gewijzigd op 07/08/2015 15:20:55 door Thomas van den Heuvel
> - de sterkte van het wachtwoord
Wat ik daarmee wilde zeggen is dat juist omdat het password zwak is ten opzichte van jouw hash, de door jou beschreven methode geen verslechtering van de security zal geven.
> Ook hier wordt er volgens mij vanuit gegaan dat je vanuit hetzelfde IP opereert?
Nee. Ik refereerde naar jouw opmerking in je eerste post dat je bij een geslaagde inlogpoging je hash kunt verversen. Ongeacht of je wel of niet op hetzelfde IP-adres zit: als je bij elke inlog rehasht, zal iemand die je hash heeft gekraakt automatisch uitgelogd worden.
>> AL je commentaar is gestoeld op de aanname dat iedereen op "hetzelfde" IP zit.
Nee, dat zeg ik nergens. Ik geef alleen aan dat jouw oplossing niet zo veilig als mensen WEL vanaf hetzelfde IP-adres werken.
>> Ik wist ook niet dat we het over een intranet hadden, de topicstarter had het hier niet specifiek over.
We hebben het toch ook helemaal niet over een intranet? We hebben het zover ik weet over een website.
>> Ook hier wordt er volgens mij vanuit gegaan dat je vanuit hetzelfde IP opereert?
Ja, dat is dus wat ik aangaf als veiligheidsrisico. Dat in zo'n situatie jouw oplossing geen volledige veiligheid biedt.
>> En een eerder geauthenticeerde gebruiker is dan ineens niet langer ingelogd. Mission accomplished?
Beter dan dat iemand onbevoegd van zijn account gebruikmaakt. Bovendien zou je de sessie gewoon kunnen continueren, en dan moet ie alleen de volgende keer even opnieuw inloggen.
Toevoeging op 07/08/2015 15:31:42:
PS ... dit hele verhaal is niet als een aanval bedoelt hè! Juist door op een normale manier over dit soort dingen te praten, komen we samen tot mooiere oplossingen.
Ozzie PHP op 07/08/2015 15:30:26:
Thomas, zou je je best willen/kunnen doen om gewoon op een normale manier te converseren, zonder alle dikgedrukte letters, "OMG" en "Sorry hoor". Ik neem aan dat je in het dagelijks leven ook niet zo praat?
Dit is toch een webforum en geen stoffige computerclub? Welcome to the internets.
Ik praat zo als mensen mij daar aanleiding toe geven, prietpraat kan mijn toorn verwachten.
Of, zoals ze op het internet ook wel plachten te zeggen:
I am mean because you are stupid.
Gewijzigd op 07/08/2015 15:42:45 door Marthijn Buijs
Thomas van den Heuvel op 07/08/2015 15:39:52:
I am mean because you are stupid.
Aha, zit het zo? Dus je vindt mij dom?
Wellicht is een ander forum dan meer op z'n plaats voor je? Iedereen gedraagt zich hier normaal en als dat voor jou teveel is gevraagd, past een ander forum wellicht beter bij je.
Over het algemeen maak je wel zinnige opmerkingen, maar in deze thread sla je de plank gewoon mis.
Zonder het wellicht te weten bedien je je zelf van slinkse "discussie" tactieken: als je het argument niet op conventionele wijze in jouw voordeel kan beslechten doe je een beroep op fatsoen, omdat je hiervoor / en als je hierna een semi pissige opmerking jouw kant op krijgt, waarna je de gebeten hond kan spelen.
Niet wegnemend dat je gewoon ongefundeerde dingen aan het zeggen was. Maar de hele focus ligt dan op het feit dat er iemand beledigd is of zou zijn, maar niet dat die persoon poep aan het praten was.
Iemand kan zich wel eens vergissen, maar daar dan niet op terugkomen als duidelijk is dat dit het geval was, dat is geen discussiëren.