nicht angemeldet
automatisches Login - best practice
suitHallo,
ich überlege gerade, wie ich am besten eine Funktion zum automatischen Einloggen umsetze. Man soll also beim Einloggen auf einer Website die Möglichkeit haben, sich zukünftig an diesem Computer automatisch einloggen zu lassen.
Gegeben ist, dass nur Prüfsummen der Passwörter gespeichert werden und dass die Seite für das Login Session-Cookies verwendet und die Session-Daten auf dem Server automatisch aufgeräumt werden (es werden PHP-Sessions verwendet). Damit scheidet aus, einfach die Session-Dauer zu verlängern. Es muss also für den automatischen Login ein zusätzliches Cookie gesetzt werden. Nur wie macht man das am besten?
1. Variante: im Cookie wird das Passwort unverschlüsselt (oder in irgend einer umkehrbaren Verschlüsselung) gespeichert. Das ist natürlich ungünstig, da jeder, der Zugang zum Computer hat, das Passwort herausfinden kann.
2. Variante: für den automatischen Login wird ein Zufalls-String generiert. Im Cookie wird dieser selbst und auf dem Server seine Prüfsumme gespeichert. Eigentlich ist das nur eine Variation von Variante 1 und hat den Nachteil, dass der automatische Login nur an ein- und demselben Computer funktioniert.
3. Variante: Im Cookie wird die Prüfsumme (oder eine Prüfsumme der Prüfsumme) des Passwortes gespeichert (so wie auf dem Server gespeichert). Nachteil: wer an die Prüfsummen auf dem Server kommt, kann sich mit einem "selbst gebastelten" Cookie einloggen.
Das hat also alles einen Haken. Gibt es noch prinzipiell andere Möglichkeiten?
Ale×
-
你好 Ale×,
automatischer Login (auch Scheunentor genannt) ist eh völlig unsicher, jeder, der Zugriff auf das Gast-System hat, hat damit auch Zugriff auf das Nutzer-Profil. Also wozu so kompliziert denken: ein Cookie, in dem der Benutzername mit dem (gehashten) Passwort steht und fertig.
再见,
克里斯蒂安--
http://wwwtech.de/
IRC-Clients und Irssi-Scripting | Flyspray
Mit einem Windhauch kannst du das Feuer loeschen. Mit einem Windhauch kannst du das Feuer entfachen.
-
Also wozu so kompliziert denken: ein Cookie, in dem der Benutzername mit dem (gehashten) Passwort steht und fertig.
Ein Cookie mit einer SEHR langen Session ist weitaus sicherer als das Passwort in gehashte Form ins Cookie zu legen. So kann man sich "nur" einloggen, aber nicht aus einem Hash auf das Password schließen.
-
你好 suit,
Also wozu so kompliziert denken: ein Cookie, in dem der Benutzername mit dem (gehashten) Passwort steht und fertig.
Ein Cookie mit einer SEHR langen Session ist weitaus sicherer als das Passwort in gehashte Form ins Cookie zu legen. So kann man sich "nur" einloggen, aber nicht aus einem Hash auf das Password schließen.
Dafür kann ich das Passwort (üblicherweise) neu setzen. Ist also gehopst wie gesprungen.
再见,
克里斯蒂安--
http://wwwtech.de/
IRC-Clients und Irssi-Scripting | Flyspray
If God had a beard, he'd be a UNIX programmer.
-
Dafür kann ich das Passwort (üblicherweise) neu setzen. Ist also gehopst wie gesprungen.
Natürlich - aber du weißt dann nicht automatisch das Passwort des Benutzers (welches der normale Mensch bei 297 anderen Seiten auch noch verwendet).
-
你好 suit,
Dafür kann ich das Passwort (üblicherweise) neu setzen. Ist also gehopst wie gesprungen.
Natürlich - aber du weißt dann nicht automatisch das Passwort des Benutzers (welches der normale Mensch bei 297 anderen Seiten auch noch verwendet).
Das weiß ich bei der Speicherung als Hash auch nicht. Den müsste ich erst knacken, und wenn der Hashing-Algorithmus nicht fehlerhaft ist (MD5 vs. SHA-2 anyone?), geht das auch nur mit Brute Force, sprich auf die gleiche Methode wie man es über den „normalen“ Login angehen würde/müsste.
再见,
克里斯蒂安--
http://wwwtech.de/
IRC-Clients und Irssi-Scripting | Flyspray
Nichts zu begehren, das ist der Weg.
-
Das weiß ich bei der Speicherung als Hash auch nicht. Den müsste ich erst knacken, und wenn der Hashing-Algorithmus nicht fehlerhaft ist (MD5 vs. SHA-2 anyone?), geht das auch nur mit Brute Force, sprich auf die gleiche Methode wie man es über den „normalen“ Login angehen würde/müsste.
Nein, dazu brauch ich keine rohe Gewalt sondern lediglich eine Regenbogen-Tabelle die mich im besten fall in Sekunden zum Erfolg führt. Das hat aber nichts mit einem fehlerhaften Hash-Algorithmus zu tun
md5 hat bekanntermaßen ein Problem mit Kollision - dieses bezieht sich aber darauf, dass sich realtiv schnell 2 beliebige Klartexte finden lassen, die den selben Hash produzieren, nicht aber dass man zu einem bekannten Hash schnell einen Text finden kann, der den selben Hash produziert (Preimage). Siehe Cryptographic Hashes: 1.4. Collisions and preimages. Die "Brute-Force-Methode" mittels Rainbow-Tables ist in diesem Fall einfach die schnellere und erfolgversprechendere - und da hilft auch kein SHA-256, es vergrößert einfach nur die Tabelle.
Wenn der Hash nicht versalzen und das Passwort potentiell unsicher (<= 8 Stellen Buchstaben/Zahlen) ist, hilft der besste Hash nix.
-
你好 suit,
Das weiß ich bei der Speicherung als Hash auch nicht. Den müsste ich erst knacken, und wenn der Hashing-Algorithmus nicht fehlerhaft ist (MD5 vs. SHA-2 anyone?), geht das auch nur mit Brute Force, sprich auf die gleiche Methode wie man es über den „normalen“ Login angehen würde/müsste.
Nein, dazu brauch ich keine rohe Gewalt sondern lediglich eine Regenbogen-Tabelle die mich im besten fall in Sekunden zum Erfolg führt.
Regenbogen-Tabellen funktionieren doch nur bei Hashing ohne Salt. Zumindest wenn ich es richtig im Kopf habe, die Zeit, dass ich mich damit beschäftigt habe, ist schon etwas her.
md5 hat bekanntermaßen ein Problem mit Kollision - dieses bezieht sich aber darauf, dass sich realtiv schnell 2 beliebige Klartexte finden lassen, die den selben Hash produzieren, nicht aber dass man zu einem bekannten Hash schnell einen Text finden kann, der den selben Hash produziert (Preimage).
Das habe ich auch nicht behauptet :) MD5 war nur der einzige Hashing-Algorithmus, der mir auf die Schnelle eingefallen ist, der erst kürzlich als problematisch eingestuft wurde.
再见,
克里斯蒂安--
http://wwwtech.de/
IRC-Clients und Irssi-Scripting | Flyspray
Der Geist ist alles. Du wirst, was du denkst.
-
Regenbogen-Tabellen funktionieren doch nur bei Hashing ohne Salt. Zumindest wenn ich es richtig im Kopf habe, die Zeit, dass ich mich damit beschäftigt habe, ist schon etwas her.
Nein, sie funktionieren auch wunderbar bei Hashes mit Salt - wenn nun jedes Passwort gleich versalzen ist (und nicht durch ein anderes Merkmal), ist dies sogar problematisch. Die Tabelle muss natürlich entsprechend größer sein.
Angenommen die vorangestellte Salt-Komponente ist "12" und das Klartextpassword ist "3456", so wäre der Hash für 123456 vermutlich einfach in einer Rainbow-Table zu finden.
Das Klartextpasswort ist dann offensichtlich nicht 123456 und es ist ohne Brute Force oder Trial & Error nicht herrauszufinden, was die Salt-Komponente ist.
Hat man nun ein weiteres Password - z.B. 7890 lässt sich aus dieser Information die Salt Komponente ermitteln und noch wesentlich effizenter eine Rainbow-Table erstellen. - Aus dem Grund ist es praktikabel, einen Salt so zu erstellen, dass er bei jedem Datensatz verschieden ist, um diesen Angriffspunkt von vorne herrein auszuschließen - aber mit einer entsprechend großen Rainbow-Table wird man auch diese Passwörter irgendwann knacken.
Das hilft allerdings alles nix, wenn jemand die Datenbank klaut - es ist halt nur aufwändiger, weil für jeden Hash dann eine eigene Tabelle erstellt werden muss.
Das habe ich auch nicht behauptet :) MD5 war nur der einzige Hashing-Algorithmus, der mir auf die Schnelle eingefallen ist, der erst kürzlich als problematisch eingestuft wurde.
Das Problem ist aber auf dem Papier und praktisch nicht einsetzbar - problematisch wirds erst, wenn Kollisionsangriffe möglich sind (wie das etwa bei SHA-1 der Fall ist).
-
你好 suit,
für diese Diskussion bin ich aktuell zu wenig in dem Thema drin, tut mir Leid. Ich glaube dir das einfach mal und komme, wenn ich mich mehr damit beschäftigt habe (aktuell habe ich dafür leider zu viel zu tun, sonst hätte ich zuerst nachgelesen und dir dann geantwortet ;), ggf. darauf zurück, wenn es dir recht ist.
再见,
克里斯蒂安--
http://wwwtech.de/
IRC-Clients und Irssi-Scripting | Flyspray
Q: God, root, what's the difference?
A: God is merciful.
-
-
-
Hallo suit,
Nein, dazu brauch ich keine rohe Gewalt sondern lediglich eine Regenbogen-Tabelle die mich im besten fall in Sekunden zum Erfolg führt.
Ich verwende "gesalzene" Hashs, da bringen die Regenbogen-Tabellen nichts.
Ale×
-
Ich verwende "gesalzene" Hashs, da bringen die Regenbogen-Tabellen nichts.
Unsinn - es kommt nur auf die Dimension der Tabelle an und diese sind mit heutigen Rechnern extrem schnell generiert.
Es ist zwar dann nicht mehr so leicht, das Klartextpasswort zu ermitteln, aber dennoch nicht unmöglich. Wenn jemand das Passwort "gewinner" hat und das Passwort mit Salt 7xyd8e8ece39cAgL9y4gewinner" ist - was wird dann wohl das Klartext-Passwort sein?
Wie im anderen Post erwähnt kann ein gleichbleibender Salt sogar einen bessere Angriffspunkt bieten als ein Hash ohne Salt.
-
Hallo suit,
das man immer einen anderen/zufälligen Salt nehmen sollte ist klar. Und natürlich ist und bleibt das Ganze ein Katz- und Mausspiel mit der immer weiter zunehmenden Rechenleistung.
Ale×
-
das man immer einen anderen/zufälligen Salt nehmen sollte ist klar. Und natürlich ist und bleibt das Ganze ein Katz- und Mausspiel mit der immer weiter zunehmenden Rechenleistung.
Ja, aber ein vermeidbares Katz-und-Maus-Spiel, wenn man den Hash des Passworts (mit Salt oder nicht) nur in der Datenbank speichert und ihn nicht aller welt als Cookie zur Verfügung stellt.
-
-
-
-
-
-
-
-
-
Hallo Christian,
automatischer Login (auch Scheunentor genannt) ist eh völlig unsicher, ...
OK, gut zu wissen. Dann muss ich mir schon nicht weiter den Kopf darüber zerbrechen.
克里斯蒂安
Ich wusste gar nicht, dass sich Namen so gut übersetzen lassen. Hat das im chinesischen auch eine Bedeutung oder ist das nur die Aussprache?
Ale×
-
你好 Ale×,
克里斯蒂安
Ich wusste gar nicht, dass sich Namen so gut übersetzen lassen. Hat das im chinesischen auch eine Bedeutung oder ist das nur die Aussprache?
Das ist nur die Aussprache. Um eine echte™ Übersetzung zu erstellen, müsste man ja die Bedeutung übersetzen, und das hätte dann nicht mehr viel mit dem Klang des Namens zu tun. :)
再见,
克里斯蒂安--
http://wwwtech.de/
IRC-Clients und Irssi-Scripting | Flyspray
Auf der ganzen Welt gibt es nichts Weicheres und Schwaecheres als Wasser. Doch in der Art, wie es dem Harten zusetzt, kommt nichts ihm gleich.
-
Hallo Christian,
Das ist nur die Aussprache.
Immerhin gibt es einen Wikipedia-Eintrag (na gut, scheint nur eine Begriffserklärung zu sein).
Ale×
-
你好 Ale×,
Das ist nur die Aussprache.
Immerhin gibt es einen Wikipedia-Eintrag (na gut, scheint nur eine Begriffserklärung zu sein).
Ja, das ist die übliche Art und Weise, Namen zu „übersetzen“ (in Wirklichkeit ist das ja nur eine Transliteration).
再见,
克里斯蒂安--
http://wwwtech.de/
IRC-Clients und Irssi-Scripting | Flyspray
Auf der ganzen Welt gibt es nichts Weicheres und Schwaecheres als Wasser. Doch in der Art, wie es dem Harten zusetzt, kommt nichts ihm gleich.
-
-
-
-
Hallo,
jetzt muss ich doch noch mal nachaken:
jeder, der Zugriff auf das Gast-System hat, hat damit auch Zugriff auf das Nutzer-Profil.
Aus Sicht des Seitenbetreibers ist das doch erst mal zweitrangig. Der Nutzer muss selbst wissen, ob er diese Option wählen kann. Problematisch finde ich vielmehr, dass das Speichern der Passwort-Prüfsummen auf dem Server nutzlos wird, wenn ich im Cookie ebenfalls die Prüfsumme speichere. Dann könnte ich doch gleich die Passwörter im Klartext speichern (OK, mit dem Unterschied, dass ich das eigentliche Passwort, das vom Benutzer vielleicht auch woanders verwendet wird, nicht kenne).
Wird das Passwort dagegen als Klartext im Cookie gespeichert, habe ich als Seitenbetreiber keine Sicherheitslücke in meinem Verantwortungsbereich (auch wenn mir diese Variante trotzdem nicht so richtig gefällt).Ale×
-
你好 Ale×,
jeder, der Zugriff auf das Gast-System hat, hat damit auch Zugriff auf das Nutzer-Profil.
Aus Sicht des Seitenbetreibers ist das doch erst mal zweitrangig. Der Nutzer muss selbst wissen, ob er diese Option wählen kann.
Der Nutzer ist in der überwiegenden Anzahl der Fälle dumm und bequem und wird sich entweder nicht durchlesen, was du dazu schreibst, oder es ist ihm egal oder beides. Und du darfst dich dann mit den Leuten herum ärgern, wenn das Kind in den Brunnen gefallen ist.
Problematisch finde ich vielmehr, dass das Speichern der Passwort-Prüfsummen auf dem Server nutzlos wird, wenn ich im Cookie ebenfalls die Prüfsumme speichere. Dann könnte ich doch gleich die Passwörter im Klartext speichern (OK, mit dem Unterschied, dass ich das eigentliche Passwort, das vom Benutzer vielleicht auch woanders verwendet wird, nicht kenne).
Wird das Passwort dagegen als Klartext im Cookie gespeichert, habe ich als Seitenbetreiber keine Sicherheitslücke in meinem Verantwortungsbereich (auch wenn mir diese Variante trotzdem nicht so richtig gefällt).Im Klartext würde ich das Passwort nicht speichern, auch wenn es bequemer für dich wäre. Wer weiß, wie oft der Nutzer das noch einsetzt. Und es ist richtig, dass der potentielle Angreifer das Passwort im Klartext gar nicht mehr braucht, um an den Account zu kommen, aber mal ehrlich: macht das einen Unterschied? Du hast doch schon wissentlich eine massive Lücke ins System gerissen, indem du das Autologin erlaubst, bzw. du reduzierst den Login doch eh schon auf Maschinen-Ebene.
Aber wenn ich weiter darüber nachdenke, würde ich so was vermutlich über eine dritte Möglichkeit machen, ich würde für jede Maschine, auf der Autologin aktiviert wird, eine ID erstellen und die in einer weiteren Tabelle speichern, mit der Nutzer-ID als Schlüssel. So musst du das Passwort gar nicht übertragen und hast eine echte Maschinen-Identifikation, und nicht mehr eine verkappte Nutzer-Identifikation.
Raten würde ich zu der Methode allerdings immer noch nicht!
再见,
克里斯蒂安-
Hallo Christian,
Im Klartext würde ich das Passwort nicht speichern, auch wenn es bequemer für dich wäre.
Es geht nicht mal um Bequemlichkeit. Ob ich im Cookie Klartext oder eine Prüfsumme speichere, spielt keine Rolle. Allerdings reiße ich bei mir eine Lücke auf, wenn ich die Prüfsumme herausgebe. Die ist dann nämlich plötzlich keine Prüfsumme mehr sondern selbst ein Kennwort (ich prüfe dann ja, ob die Prüfsumme des Cookies == Prüfsumme auf dem Server ist).
Aber Du hast wohl recht: wahrscheinlich ist die Gefahr größer, dass das Passwort auf Benutzer-Seite in falsche Hände kommt, als dass jemand an die Datenbank auf dem Server kommt.
Aber wenn ich weiter darüber nachdenke, würde ich so was vermutlich über eine dritte Möglichkeit machen, ich würde für jede Maschine, auf der Autologin aktiviert wird, eine ID erstellen und die in einer weiteren Tabelle speichern, mit der Nutzer-ID als Schlüssel.
An so etwas habe ich auch schon gedacht (ist ja im Prinzip eine Variation der im Ausgangsposting beschriebenen Variante 2), bisher aber den Aufwand gescheut.
Raten würde ich zu der Methode allerdings immer noch nicht!
Ich brauche so eine Funktion auch nicht, aber sie wird nun mal eingefordert.
Ale×
-
-
-
-
Mir fällt dazu noch folgende Cookie Problematik ein:
Automatisches Einloggen via Cookie kann einen Konflikt mit der dem User eigenen Cookie Management darstellen. Wenn nicht klar wird, dass das automatische Login verlangt, dass Cookies dauerhaft gespeichert werden, ist das eher kontraproduktiv.
Meine Einstellung zu Passworten ist, dass sie nur ausserhalb des Computers sicher verwahrt werden. Permanentes Eintippen durch den User fördert das Training, das sich bei der nächsten Vollinstallation des Systems auszahlt.mfg Beat
--
><o(((°> ><o(((°>
<°)))o>< ><o(((°>o
Der Valigator leibt diese Fische-
Hallo Beat,
bin mir jetzt nicht ganz sicher, ob ich Dich richtig verstanden habe...
Wenn nicht klar wird, dass das automatische Login verlangt, dass Cookies dauerhaft gespeichert werden, ist das eher kontraproduktiv.
Meinst Du, wenn der Benutzer seine Cookies löscht und sich dann wundert, warum er nicht mehr automatisch eingeloggt wird?
Meine Einstellung zu Passworten ist, dass sie nur ausserhalb des Computers sicher verwahrt werden.
Klar, am besten nur im Kopf. Aber selbst dann muss man noch aufpassen, dass man sie nicht im Schlaf ausplaudert. ;-)
Permanentes Eintippen durch den User fördert das Training, das sich bei der nächsten Vollinstallation des Systems auszahlt.
Wenn man die Browser-Profile sichert und nach einer Neuinstallation wieder einspielt, ist eigentlich alles inklusive Cookies und gespeicherter Passwörter noch da.
Ale×
-
Wenn man die Browser-Profile sichert und nach einer Neuinstallation wieder einspielt, ist eigentlich alles inklusive Cookies und gespeicherter Passwörter noch da.
Theoretisch ja, praktisch nein:
- Du sicherst nicht jedes mal, wenn du einen neuen Account irgendwo einrichtest, dein Browser-Profile.
- Jene die am meisten Bequemlichkeit wollen, und also Passworte durch den Browser speichern, tun es höchstwahrscheinlich nie.
In BdE-Online verwende ich SIDs in URLs was zur Folgr hat, dass der Browser-Mechanismus nicht greift. Es ist immer wieder fun zu sehen, wieviele einen Account öffnen, und beim zweiten mal dann versuchen, ihren Account zu hacken. So viel zum Thema Mentalitätsveränderung durch falschen Luxus.
mfg Beat
--
><o(((°> ><o(((°>
<°)))o>< ><o(((°>o
Der Valigator leibt diese Fische
-
-
Hi,
Permanentes Eintippen [des Passworts] durch den User fördert das Training, das sich bei der nächsten Vollinstallation des Systems auszahlt.
Das foerdert vielleicht eher die ein-Passwort-fuer-alles-Mentalitaet, oder sogar die Cleverness, Liebchen's Geburtdatum, Hundis Namen oder "passwort" als Passwort zu verwenden ...
MfG ChrisB
--
„This is the author's opinion, not necessarily that of Starbucks.“
-