Automatisch inloggen

Ik zit de denken aan een hash in de database die linkt met het account.

Social networks gebruiken, zoals Facebook of Twitter.

@Aar

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.

Wat ik wel knetter irritant vind aan de "login onthouden" op deze site is dat als je ergens anders (een andere pc, een andere browser, een andere vaste locatie) inlogt de eerste login niet meer onthouden wordt.

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:

+-------------+---------------------+------+-----+---------+----------------+
| 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.

@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?

Dan kan je ook nog een hash maken op basis van gebruikersnaam en aan de hand van die 2 hashes toegang geven of niet, toch?

@Ozzie het noemen van één tegenvoorbeeld van een situatie waarin deze oplossing mogelijk geen soelaas biedt is geen reden om deze oplossing op voorhand af te schrijven.

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.

En dan wat maarten zegt ... bijv. een username of id als 2e value erbij? Dat lijkt me al veiliger. Enkel een hash lijkt me voor een potentiële kwaadwillende iets te makkelijk.

Ok.

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?

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.