vBulletin Cookie Verschlüsselung

[mgutt]

Zitat von DokuLeseHemmung

Du meinst, wenn ich meinen Laptop mal woandershin mitnehme, dann tuts das Dauerlogin nicht mehr, weil du das als Angriff wertest?
Verrückt!

Guter Einwand. Habe ich gar nicht dran gedacht. Was wäre, wenn ein Hinweis auf der Seite erscheinen würde von wegen "Du hast den Anbieter für Deinen Internetzugang gewechselt. Bitte bestätige den Wechsel mit Deinem Passwort:".

[mgutt]

Zitat von vt1816

Du hast zum Beispiel AOL vergessen. Da kann jede Anfrage von einer anderen IP-Adresse kommen.

AOL hat:
cache-frr-ab06.proxy.aol.com

Mein Code extrahiert entsprechend:
"ol.com"

Daher ist der Wechsel der IPs unerheblich (im Allgemeinen bei allen Anbietern). Deswegen wollte ich ja nur die Domain oder die letzten 6 Stellen als Vergleichsfaktor heranziehen.

[vt1816]

Zitat von mgutt

"ol.com"

Mit den/jeden 6 Zeichen am Ende lassen sich bestimmt noch hunderte andere Domains finden (mit unterschiedlichen IP-Adressen)...

[mgutt]

Zitat von vt1816

Mit den/jeden 6 Zeichen am Ende lassen sich bestimmt noch hunderte andere Domains finden (mit unterschiedlichen IP-Adressen)...

Gut, dann werde ich wie gesagt die komplette Domain extrahieren. Dann sollte das denke ich passen. Noch irgendwelche Einwände?

[mgutt]

Jetzt fällt mir gerade spontan ein, dass das nichts wird, weil man Domains einfach nicht zuverlässig extrahieren kann.

Da kann ich denke ich nur sowas machen, um noch ein Zeichen mehr zu ziehen:

$host = 'cache-frr-ab06.proxy.aol.com';
$hostlen = strlen($host); // 28
$fldpos = strrpos($host, '.'); // 24
if (($hostlen - $fldpos) == 3) { // .de, .at, usw.
  $provider_name = substr(gethostbyaddr($_SERVER['REMOTE_ADDR']), -6);
}
else { // .com, .net, .info usw.
  $provider_name = substr(gethostbyaddr($_SERVER['REMOTE_ADDR']), -7);
}

Ist aber auch nicht gerade schick. Am besten wäre tatsächlich die komplette Domain.

[cortex]

Zitat von mgutt

Ist aber auch nicht gerade schick. Am besten wäre tatsächlich die komplette Domain.

nein, am besten wäre es, robust und zuverlässig zu programmieren und nicht selbst verursachte (gewollte) löcher mit absurden / zerbrechlichen gefrickel zu füllen.

egal... cx

[mgutt]

Dann schlag mal eine Lösung vor.

Ich denke ich arbeite erstmal mit einem Whitelistfilter für .cnobi und .de und extrahiere dann ".aol.com", ".arcor-ip.net", ".t-ipconnect.de", usw. als Salt. Damit decken wir sicherlich 90% oder mehr der Nutzer ab. Beim Rest kann ich dann ja immer noch statistisch auswerten, in wie weit sie relevant sind.

Ein User in meinem Forum schlug vor, dass ich den Standort des Einwahlknotens noch heranziehen könnte. Aber ich habe die Erfahrung gemacht, dass ein Nutzer auch zwischen mehreren Knoten springen kann, wenn er sich genau in der Mitte befindet. Damit fällt das denke ich wieder flach. Mal abgesehen davon, dass man nur schwer an die Geodaten kommt. Ich kenne da jetzt nur die Google Maps API als mögliche Option.

[Crisps]

Ich verwende Autologins so - Einfach beim Login einen zufälligen Hash generieren und den als permanenten Cookie speichern (Beim gewollten ausloggen kann ja dieser wieder gelöscht werden):

$bla = md5(uniqid(microtime(), true), true);

Beim erneuten Besuch wird dieser dann mit dem Eintrag in der User-Tabelle abgefragt.

So speichert man keinen Usernamen/Passwort auf dem PC des Users ab.

Bin ich faul und ungeduldig jenseits aller Vorstellungskraft? Ja!

Ist das typisch für die Mehrzahl User? Ja!

Wenn ich auf einem Forum oder irgendeiner Online-Zeitung einen Account habe, möchte ich die Möglichkeit haben beim einloggen nicht gleich nach meinem Passwort suchen zu müssen (ja, die meisten meiner Passwörter sind so kompliziert).

Wem Autologins schon zu unsicher sind, sollte am besten überhaupt nicht mehr online gehen.

[cortex]

Zitat von mgutt

Dann schlag mal eine Lösung vor.

die diskussion haben wir doch schon hinter uns...

Zitat von Crisps

Ich verwende Autologins so - Einfach beim Login einen zufälligen Hash generieren und den als permanenten Cookie speichern

das war dem op ja nicht sicher genug; daher sagte ich bereits:

Zitat von cortex

das konzept eines automatischen user-logins läuft jedem bestreben, eine anwendung so sicher wie möglich zu machen, zuwider

Zitat von Crisps

Wenn ich auf einem Forum oder irgendeiner Online-Zeitung einen Account habe, möchte ich die Möglichkeit haben beim einloggen nicht gleich nach meinem Passwort suchen zu müssen

warum auch nicht; ich muss aber auch die kehrseite der medaille / dieses komfort-merkmals in kauf nehmen und keine lösung zaubern, die entweder nur unzuverlässig funktioniert oder nicht für alle user funktioniert.

Zitat von Crisps

Wem Autologins schon zu unsicher sind, sollte am besten überhaupt nicht mehr online gehen.

danke für den tip - da werde ich mein online-verhalten wohl überdenken müssen...

cx

[mgutt]

Bisher habe ich das gleiche gemacht wie Du, nur dass bei jeder Impression der Hash erneuert wurde. Den Hash habe ich dann bei jeder Impression in die Usertabelle gepackt. Damit war das Autologin-Cookie so komfortabel wie bei Dir auch, nur dummerweise gibt es halt immer wieder Probleme. z.B. wenn die Datenbank abschmiert und dieser Hash irgendwie verloren geht (was genau passiert weiß ich gar nicht) oder eben, dass die Browser einfach nicht mehr die Cookies überschreiben lassen.

Welchen Wert man nun heranzieht ist dabei vollkommen Schnuppe, Hauptsache es ist ein zufälliger Salt enthalten.

Das ist aber durchaus ausbaufähig.

Gerade wg. Bugs im Browser bin ich der Ansicht, dass man zumindest eine minimale Verifizierung durchführt. Es reicht ja schon, wenn man das Betriebssystem und den Browser vom Benutzer ausliest. Klar ist der User-Agent ebenfalls leicht zu klauen, aber so hat man zumindest Hacker-Noobs ausgeschlossen, die einfach nur irgendwelche Cookie-Stealer ausprobieren.

Als nächsten Schritt dachte ich eben an den Provider. Setzt man z.B. voraus, dass ein Autologin nur mit unserem "Zufallshash", "Windows XP Internet Explorer 7" und "T-Online" möglich ist, wären das schon zwei Hürden, die nicht sonderlich am Komfort rütteln.

Gegen XSS hilft HTTP_ONLY, aber gegen Bugs in Browsern hilft nunmal keine serverseitige Technik.