Login über zwei Domains hinweg

[Meowsalot]

Hallo,

besteht irgendwie die Möglichkeit ein Login über zwei Domains hinweg zu realisieren? Ich nutze für mein Login eine Session.

Bis bald!
Meowsalot (Bernd)

[Henry]

Hallo Meowsalot,

besteht irgendwie die Möglichkeit ein Login über zwei Domains hinweg zu realisieren? Ich nutze für mein Login eine Session.

Dass dies kein Problem ist, siehst du wenn du vernetzte Seiten, wie Facebook, Google, etc. siehst. Einmal eingeloggt, auf vielen Domains aktiv. Was natürlich für die auch das Tracking noch einfacher und personalisierter macht. Hat daher auch seinen Grund, warum das ausloggen oft umständlicher zu finden ist, als das einloggen.

Aber zurück zu deiner Frage, da bräuchte es schon ein paar Einzelheiten mehr.

Gruss
Henry

[Meowsalot]

Hallo Henry,

ich habe folgende Script um zu prüfen ob ein User eingeloggt ist

function isUserLoggedIn($mysqli) {
        $session = session_id();
        $stmt = $mysqli->prepare("SELECT * FROM zugangsdaten WHERE user_session=?");
		    $stmt->bind_param("s", $session);
        $stmt->execute();
        $stmt->store_result();

        if($stmt->num_rows() === 1) {
            return true;
        } else {
            return false;    
        }
    }

Mit folgendem Script logge ich einen User ein

function login($mysqli, $userMail, $pw) {
        
        $stmt = $mysqli->prepare("
                
                SELECT user_id FROM zugangsdaten 
                WHERE user_nickname=? 
                AND user_passwort=? 
                AND user_aktiv=? 
                AND user_onoff=?");
		    $ak = 1;
        $uk = 0; 
        $stmt->bind_param("ssss", $userMail, $pw, $ak, $uk);
        $stmt->execute();
        $stmt->store_result();

		if($stmt->num_rows() === 1) {
            $stmt = $mysqli->prepare("
                 
                Update zugangsdaten 
                SET user_session=?, user_login=now() 
                WHERE user_nickname=? AND user_passwort=?");
            
            $stmt->bind_param("ssi", session_id(), $userMail, $pw);
            $stmt->execute();
            
            return true;
        } else {
            return false;
        }    
    }

Solange ich auf einer Domain bleibe funktioniert dieses Problemlos. Sobald ich jetzt die zweite Domain aufrufe, die auf die gleiche Datenbank zugreift bekomme ich das Login angezeigt, sprich ich bin auf der anderen Seite nicht eingeloggt.

Bis bald!
Meowsalot (Bernd)

[Regina Schaukrug]

Solange ich auf einer Domain bleibe funktioniert dieses Problemlos. Sobald ich jetzt die zweite Domain aufrufe, die auf die gleiche Datenbank zugreift bekomme ich das Login angezeigt, sprich ich bin auf der anderen Seite nicht eingeloggt.

Ich fand:

$session = session_id();

Das ist also klar. Denn die Session gilt immer nur für eine Domain. Und das ist auch gut so.

Doch dann fand ich noch:

SELECT user_id FROM zugangsdaten 
WHERE user_nickname=? 
AND user_passwort=? 
AND user_aktiv=? 
AND user_onoff=?");

…

$stmt->bind_param("ssss", $userMail, $pw, $ak, $uk);

Du speicherst also das Passwort im Klartext. Das ist gefährlich. Benutze hierfür die Funktion password_hash() und deren Schwestern password_verify(), password_needs_rehash().

Falls Du auf den Gedanke kommst, die MySQL/MariaDB-interne Funktion PASSWPORD() zu benutzen, beachte die Warnung:

The PASSWORD() function is used for hashing passwords for use in authentication by the MariaDB server. It is not intended for use in other applications.

Um die für Dein Vorhaben günstigste Vorgehensweise auswählen zu können brauche ich noch Informationen:

• Liegen beide Domains dauerhaft im Sinne "für immer und ewig" auf dem gleichen Server?
• Hast Du für beide HTTPS?

Eine Lösung wird übrigens nicht trivial sein. Dein Vorhaben wird also einigen Aufwand verursachen. Sind die Domains nicht "für immer und ewig" auf dem gleichen Server ist der halt nur größer.

Die Frage ist: Willst Du das WIRKLICH? oder geht es Dir nur um die Behebung einer eher kleinen Unbequemlichkeit?

Beginne in jedem Fall damit, das ernsthafte Problem mit den Klartextpasswörtern zu beheben.

Hier mal was älteres von mir zu dem Thema (PDF). Das hat aber mit PHP 7.x weiter Gültigkeit.

[Meowsalot]

Hallo Regina,

wie kommst du darauf dass ich meine Passwörter als Klartext in der Datenbank speichere? So schaut es in meiner Tabelle aus

Das Login erledige ich so

if(isUserLoggedIn($mysqli) === TRUE) {
    header('Location: index.php');

} else {
        
        if(isset($_POST['einloggen'])) {
        
            $user_nickname      = $_POST['user_nickname'];
            $passwort           =  hash('sha256',$_POST["passwort"].$salt);
            
            if (login($mysqli, $user_nickname, $passwort) === true) {
            $page = 'index.php'; 
            if (
                isset($_SESSION['page_after_login'])
                and strlen((string)$_SESSION['page_after_login'])
            ) {
                $page = (string)$_SESSION['page_after_login'];
            }
            header('Location: ' . $page);

        } else {
            $fehler = "Login fehlgeschlagen!";
        }
    }

Um die für Dein Vorhaben günstigste Vorgehensweise auswählen zu können brauche ich noch Informationen:

quote hereLiegen beide Domains dauerhaft im Sinne "für immer und ewig" auf dem gleichen Server? quote hereHast Du für beide HTTPS?

Beide Domains laufen selbstverständlich über HTTPS. Ich bin bei All-Inkl und habe einen Webhosting Vertrag. Der Support meinte, es kann sein dass Domain A auf Server B und Domain B auf Server X liegt obwohl ich nur einen Account habe.

Bis bald!
Meowsalot (Bernd)

[Regina Schaukrug]

Hallo Regina,

wie kommst du darauf dass ich meine Passwörter als Klartext in der Datenbank speichere? So schaut es in meiner Tabelle aus

Weil ich in Deinem Quelltext nichts von der Bildung eines (salted) Hashes gesehen habe.

Oh Gott!

Was auch immer das für Hashes sind (ich sehe die Länge nicht) und ich hoffe nicht, dass gar etwas umkehrbar verschlüsseltes ist. (mit auf dem Server gespeicherten Schlüssel, was so sicher ist, wie den Schlüssel für einen Safe im Schreibtisch einzuschließen) Auch wenn es Hasches sind dann sind die, die ich da sehe, genau so gefährlich wie Klartextpasswörter, denn wenn es Hashes sind, dann sind diese ungesalzen. Auf jeden Fall hast Du nicht die password_hash()-Funktion oder deren Schwestern benutzt.

Und ja: Du musst das ändern. Sowas (unsalted hashes oder - DAS GENAU hast Du: Hashes mit einem nicht-individuellem salt) - hat man vor langer, langer Zeit so gemacht und DAMALS für "sicher genug" gehalten. Inzwischen kann man derlei sehr schnell knacken. Teraybyte-große SSDs für Rainbow-Tables sind im Konsumer-Segment angekommen, damit geht das richtig schnell.

Mit sowas landet man in der Zeitung.

[m.]

Mahlzeit,

Weil ich in Deinem Quelltext nichts von der Bildung eines (salted) Hashes gesehen habe.

hash('sha256',$_POST["passwort"].$salt);

Da es eine Variable gibt, wird er wohl irgendwo irgendwas salzen, vermute ich mal

Was auch immer das für Hashes sind (ich sehe die Länge nicht) und ich hoffe nicht, dass gar etwas umkehrbar verschlüsseltes ist),

hash('sha256',$_POST["passwort"].$salt);

da steht doch sha256, daher ist doch eindeutig, was das für Hashes sind

das ist fast genau so gefährlich wie Klartextpasswörter,

Jetzt übertreib mal nicht. Du sagst ja quasi dass Rainbow-Tables und BruteForce keinen Aufwand bedeuten.

Teraybyte-große SSDs für Rainbow-Tables sind im Konsumer-Segment angekommen, damit geht das richtig schnell.

Aha, die wissen dann also was in $salt steht? Selbst wenn da nur ein "fqawsed54t5ftgqa4" drin steht als String, kannst du jeden Rainbow-Table knicken.

Natürlich ist es besser, gleich die richtigen Funktionen und Strukturen zu nutzen aber unnötige Panikmache halte ich da für Kontraproduktiv. Fakt ist, in den seltensten Fällen ist bei einen Hackangriff die Passwortspeicherung das Problem sondern es sind entweder völlig unsichere Passwörter oder Lücken im System, die ein Eindringen ohne Login erlauben.

[Regina Schaukrug]

Aha, die wissen dann also was in $salt steht? Selbst wenn da nur ein "fqawsed54t5ftgqa4" drin steht als String, kannst du jeden Rainbow-Table knicken.

In seinem Fall steht der Salt offensichtlich als fixer oder berechenbarer, nicht-individueller String irgendwo im Programm oder in einer Datei.

Das Problem ist nicht der bekannte Salt, es ist, dass es für jedes Passwort wahrscheinlich der selbe ist.

Das nächste Problem ist: Moderne Funktionen wie password_hash() machen das nicht einmal sondern salzen und hashen das Passwort mehrere tausend Mal. Aus dem einen Grund: Damit der Vorgang mehr Zeit braucht.

unnötige Panikmache halte ich da für Kontraproduktiv

Das ist es nicht. Der TO hat die Idee irgendwo her und dann implementiert. Es ist zu befürchten, dass irgendwer daherkommt und diese im Zeitablauf unsicher gewordene und deswegen zu verwerfende Idee auch abschreibt und für sicher hält.

es sind entweder völlig unsichere Passwörter oder Lücken im System, die ein Eindringen ohne Login erlauben.

Ja. Wie eben Wordpress-Plugis, welche Angreifern statt dem Upload einer Grafik die Installation einer PHP-Shell und das Abgreifen der ganzen Passwort-Datenbank erlauben.

[m.]

Mahlzeit,

In seinem Fall steht der Salt offensichtlich als fixer oder berechenbarer, nicht-individueller String irgendwo im Programm oder in einer Datei.

Wieso? Kann genau so gut sein, dass da eine komplexe Funktion mit einer aufwändigen Berechnung ist. Abgesehen davon hebelt auch ein statischer "salt", wie gesagt, jeden Rainbow-Table aus denn wenn ein Angreifer an den Salt kommt, ist er eh so weit auf dem Server dass er an die Zugangsdaten der Datenbank kommt und auch auf den restlichen Webspace zugreifen kann. In dem Fall hat der Betreiber ganz andere Probleme als die, dass jemand extra dafür einen Rainbow-Table erzeugt um genau für diesen Salt einen zu haben.

Im Übrigen, wenn der Hacker an einen statischen Salt kommt, kommt er auch an die Funktion wenn einer berechnet wird und wir haben den exakt gleichen Effekt.

Wie gesagt, man sollte die vorgesehenen Funktionen nutzen, trotzdem sind andere Umsetzungen nicht pauschal unsicher.

[Regina Schaukrug]

Wie gesagt, man sollte die vorgesehenen Funktionen nutzen, trotzdem sind andere Umsetzungen nicht pauschal unsicher.

Doch. Weil diese die Sicherheit womöglich auch anderer Dienste beschädigen.

Grund:

Kommt eine hinreichend kriminelle Person in den Besitz der Datenbank und des Salts (oder dessen Berechnung...), dann kann und wird diese diese Datenbank und den Salt verkaufen. Die Datenbank enthält einen Nickname.

Diese Datenbank gerät nun in die Hände von weiteren, spezialiserten Kriminellen mit den technischen Möglichkeiten (oder sogar eines Geheimdienstes). Ein paar SSDs, ein paar Recheneinheiten wie sie auf Grafikkarten sind oder gar für SHA-X spezialisierte ASICs genügen um in vertretbarer Zeit die Passwörter zu den Nicknamen zu berechnen.

Diese Daten geraten an Dritte, welche diese Kombinationen nutzen um sich bei anderen Diensten mit diesem Nickname und dem Passwort (Erzähl mir nicht, es sei der Job des Nutzers für jeden Dienst ein eigenes Passwort zu verwenden - die machen das nicht!) anzumelden oder z.B. via Google die zugehörige Mailadresse herauszufinden und dann auch Mailadresse + Passort zu versuchen.

Und wenn das an der oder den richtigen Stelle(n) passt, dann hat die hier vorliegende, unsichere Implementation womöglich ganz wesentlich dazu beigetragen, die Existenz eines der Nutzer, vielleicht sogar des Betreibers zu vernichten.

Willst Du daran teilnehmen, in dem Du das beschönigst?

Die Umstellung auf die derzeit nicht als unsicher verpönten Methoden ist zumutbar.

[m.]

Mahlzeit,

**Willst Du daran teilnehmen, in dem Du das beschönigst?*×

Ich beschönige nichts, ich nehme die Paranoia raus. Du redest hier von Projekten die so gross sind, dass sie für eine kriminelle Gruppierung (da schliesse ich NSA und Co. mit ein) interessant sind. Wer ein solches Projekt betreibt, fragt nicht hier im Forum wie ein Login geht.

Und genau darum geht es, um einen User, der hier nachfragt weil er ein kleines Projekt programmiert dessen Datenbank keine Sau interessiert weil der Aufwand in keiner Relation zum Nutzen steht. Dazu müssten erstmal mehrere 100.000 Datensätze erbeutet werden.

Die Umstellung auf die derzeit nicht als unsicher verpönten Methoden ist zumutbar.

Das stimmt und ich habe dazu auch konkrete Vorschläge gemacht, nicht nur Paranoia verbreitet 😉

[Regina Schaukrug]

Du redest hier von Projekten die so gross sind, dass sie für eine kriminelle Gruppierung (da schliesse ich NSA und Co. mit ein) interessant sind.

Die NSA setzt ganze Rechenzentren in die Wüste und ist an jedem Datenfitzelchen interessiert. Guggst Du "Fluggastdaten".

Wer ein solches Projekt betreibt, fragt nicht hier im Forum wie ein Login geht.

Du. Lies mal bei heise & co. nach, von wem so alles in den letzten paar Monaten Datenbanken mit Zugangsdaten, bei denen die Passwörter mit sha1 oder gar md5 gehasht wurden, in die "Wildbahn" gerieten.

Das sind richtige große Firmen bei, bei denen man eigentlich Intelligenz vermuten würde - und die hatten es eigentlich alle nötig, mal einen Typ wie mich oder hier im Forum zu fragen.

[m.]

Mahlzeit,

Das sind richtige große Firmen bei, bei denen man eigentlich Intelligenz vermuten würde - und die hatten es eigentlich alle nötig, mal einen Typ wie mich oder hier im Forum zu fragen.

Und die wurden gehackt, weil die Passwörter nicht richtig gehashed waren? Hast du dazu ne Quelle?

[Regina Schaukrug]

Das sind richtige große Firmen bei, bei denen man eigentlich Intelligenz vermuten würde - und die hatten es eigentlich alle nötig, mal einen Typ wie mich oder hier im Forum zu fragen.

Und die wurden gehackt, weil die Passwörter nicht richtig gehashed waren? Hast du dazu ne Quelle?

DAS habe ich nicht behauptet. Das allerdings die Passwörter nicht sicher gehasht wurden lässt vermuten, dass auch in anderer Hinsicht gewaltig geschlampert wurde und Typen am Werk waren, die eher auf Budgettreue, hohe Boni und fette Dividenden gesetzt haben als auf Sicherheit.

Zudem könnten die Passwörter der Admins aus anderen Datenbanken stammen, wo diese ebenfalls im Klartext oder als schwache Hashes gespeichert waren. Das ist also wie mit den Dominosteinen.

[m.]

Mahlzeit,

DAS habe ich nicht behauptet. Das allerdings die Passwörter nicht sicher gehasht wurden lässt vermuten, dass auch in anderer Hinsicht gewaltig geschlampert wurde und Typen am Werk waren, die eher auf Budgettreue, hohe Boni und fette Dividenden gesetzt haben als auf Sicherheit.

Also nimmst du irgendeine Schlagzeile als Argument obwohl das absolut am Thema vorbei geht? Dann gehst du diese Firmen persönlich an weil echte Argumente fehlen?

Sorry, das ist Kindergarten. Wenn du ein Argument bringen willst, dann eins, dass deine Paranoia-Aussagen zum Thema erklärt.

Als nächstes kommt dann "Alle Seile müssen verboten werden denn viele Leute erschiessen sich. Wenn aber Seile verboten werden, können sich schon mal einige nicht mehr aufhängen"

[Regina Schaukrug]

DAS habe ich nicht behauptet. Das allerdings die Passwörter nicht sicher gehasht wurden lässt vermuten, dass auch in anderer Hinsicht gewaltig geschlampert wurde und Typen am Werk waren, die eher auf Budgettreue, hohe Boni und fette Dividenden gesetzt haben als auf Sicherheit.

Also nimmst du irgendeine Schlagzeile als Argument obwohl das absolut am Thema vorbei geht?

Ich? Nein. Du solltest erst mal ALLES lesen. Denn ich habe weiter geschrieben:

Zudem könnten die Passwörter der Admins aus anderen Datenbanken stammen, wo diese ebenfalls im Klartext oder als schwache Hashes gespeichert waren. Das ist also wie mit den Dominosteinen.

Fällt der Erste kippen dann der Reihe nach die anderen. Mit sicheren Hashes (das ist das, was ich fordere) kann man diese Kippfolge unterbrechen.

[m.]

Mahlzeit,

Fällt der Erste kippen dann der Reihe nach die anderen. Mit sicheren Hashes (das ist das, was ich fordere) kann man diese Kippfolge unterbrechen.

Es kann aber auch sein, dass ein Whistleblower die Datenbank direkt vom Server gezogen hat und dann verkauft. Willst du jetzt verbieten, dass ein Mensch Zugriff auf den Server hat?

Mit irgendwelchen Vermutungen Paranoia zu begründen halte ich mindestens für fragwürdig.

[Regina Schaukrug]

Fällt der Erste kippen dann der Reihe nach die anderen. Mit sicheren Hashes (das ist das, was ich fordere) kann man diese Kippfolge unterbrechen.

Es kann aber auch sein, dass ein Whistleblower die Datenbank direkt vom Server gezogen hat und dann verkauft.

Das hat aber zwei Ursachen:

1. Sicher gehasht hätte die Datenbank keinen Wert, der Antrieb würde entfallen. Sowas kauft doch keiner. Es sei denn jemand denkt sehr langfristig (z.B. Geheimdienste)
2. Whistleblower sind was ganz anderes. Solche Datenbanken verticken Mitarbeiter, die regelmäßig sehr unzufrieden über den Umgang des Unternehmens mit sich und oder anderen Mitarbeitern sind. Den fairen und angemessenen Umgang mit Mitarbeitern haben die für die IT Verantwortlichen merkwürdigerweise oft nicht auf dem Schirm. Dafür ist Taylorismus stark verbreitet, was freilich kein Geschäftsführer oder Aussichtsrat je durch seinen Pressesprecher zugeben wird.

[m.]

Mahlzeit,

1. Sicher gehasht hätte die Datenbank keinen Wert, der Antrieb würde entfallen. Sowas kauft doch keiner. Es sei denn jemand denkt sehr langfristig (z.B. Geheimdienste)

Kundendaten haben keinen Wert? In welcher Welt lebst du eigentlich? Eine Datenbank mit Namen, Telefonnummern, Adresse, Kaufverhalten … die kann Millionen wert sein. Langsam solltest du aufhören denn offensichtlich fehlt dir hier einiges an Wissen zum Thema

was Punkt 2. soll, verstehe ich nicht denn auch wenn du jetzt die Schuld am "blowen" irgendjemand zuschiebst, wird es deshalb auch nicht besser also wieso versuchst du so ein Verhalten zu rechtfertigen?

[Regina Schaukrug]

Kundendaten haben keinen Wert?

Hier geht's erstmal nur um Passwörter. Die Kundendaten auch bei Dritten zu klauen wird durch die unsicher gehashten Passwörter erst möglich:

Für Dich jetzt mal GANZ deutlich:

1. Nehmen wir mal an, ich und andere würden sich hier im Forum mit Mailadresse und Passwort anmelden.
2. Nehmen wir an, die Tabelle mit Mailadresse und Passwort gerät in die "Wildbahn".
3. Nehmen wir jetzt an, das Passwort wäre unsicher gehasht.
4. Dann kann jemand das Passwort errechnen.
5. Er kann versuchen das bei Amazon und meinem Mailaccount zu benutzen.
6. Jetzt nehmen wir an, ich sei ein Trottel und würde das machen, was viele machen: "Ein Passwort für alles."
7. Er bestellt auf meine Rechnung bei Amazon einen Haufen Zeug und lässt sich das an eine Postbox schicken. Die Benachrichtigungen von Amazon bekommt nur er selbst, weil er das Passwort meines Mailkontos geändert hat und ich deshalb nicht mitbekomme, dass überhaupt Mails ankommen.
8. Dann ich ich arm und er reicher.
9. Und jetzt nehmen wir mal an, ich wäre ein so doofer Admin, dass das Passwort auch noch bei AWS-Konto passt.
10. Dann hat er gleich die nächste Datenbank mit benutzernamen und Passwörtern. Und alles könnte bei 3 wieder losgehen, wenn ich die Passwörter so unsicher gehasht hätte.

Kannst Du mir folgen oder sind das ein paar Schritte zu viel?

[m.]

Mahlzeit,

lassen wir es gut sein. Du willst nicht wissen was ich dir sage, Argumente ignorierst du und jetzt wirst du auch noch pampig. Sorry, aber wer nichts lernen will, soll es bleiben lassen.

BTW: Du bist mehrfach massiv vom Thema abgewichen, willst mich aber mit Fettschrift dafür rügen, dass ich das Thema ausgeweitet hab, obwohl diese Ausweitung zum grundthema "Sicherheit" gehört. Deine Abweichungen vom Thema hatten nur den Sinn, deine "Argumente" zu konstruieren damit du nicht zugeben musst, dass auch andere recht haben könnten.

Den Thread an sich finde ich aber sehr interessant, hoffe der landet im Archiv.

[m.]

Mahlzeit,

Fällt der Erste kippen dann der Reihe nach die anderen. Mit sicheren Hashes (das ist das, was ich fordere) kann man diese Kippfolge unterbrechen.

Verdammt, dann wäre das mit NAG Datacenter AG bestimmt nicht passiert, wenn sie alle ihre Passwörter richtig gehashed hätten.

Ich hatte einen Server bei 1st-housing. Diese Firma wurde von der NAG Datacenter AG übernommen. In einer Nacht- und Nebelaktion wurden alle Server auf Lastwagen verladen, also das komplette Rechenzentrum ausgeräumt. Dürften mehrere Milliarden Kunden-Datensätze aus zig tausenden Projekten gewesen sein.

Naja, hätten die alle ihre PHP-Passwörter richtig gehashed, wären die Server sicher alle noch da und nicht bis heute unauffindbar.

Ok, wenn ich das lese, muss ich dir recht geben, dass das richtige Hashen von Passwörtern in einer PHP-Anwendung alles hätte verhindern können 😱

[Regina Schaukrug]

Welche Reaktion erwartest Du?

Warum versuchst Du das gesehene Problem mit unsicheren Hashing der Passwörter trotz meiner sachlichen und logischen Argumente zu verniedlichen und durch fachlich und sachlich völlig neben der Spur liegende Aussagen ins Lächerliche zu tun?

Übrigens: Gerade der von Dir behauptete Umstand, dass da in einer Nacht- und Nebelaktion Server verschwunden seien, zeigt doch überdeutlich, dass das sichere Hashen wichtig ist. Denn wenn die nicht sicher gehasht waren, besteht die Möglichkeit, das Dritte jetzt Benutzernamen und Mailadresse haben und die Klartextpasswörter ermitteln konnten und das dadurch jetzt andere Dienste gefährdet sind.

[m.]

Mahlzeit,

Welche Reaktion erwartest Du?

Dass du endlich schnallst, dass bei Kundendaten bzw. deren unerlaubten Veräusserung, das Passwort scheiss egal ist.

Warum versuchst Du das gesehene Problem mit unsicheren Hashing der Passwörter trotz meiner sachlichen und logischen Argumente zu verniedlichen und durch fachlich und sachlich völlig neben der Spur solche Aussagen ins Lächerliche zu tun?

Wow, du scheinst wirklich in einer anderen Sphäre zu schweben. Ich versuche dir klarzumachen, dass du Paranoia schiebst zu einem Thema das nur in ausnahmefällen relevant ist. Glaubst du wirklich, NSA & Co. haben es nötig, Passwörter von Usern zu sammeln? Die holen sich die Daten direkt aus der entsprechenden Datenbank und versuchen nicht ein bisschen mit Rumspielen zufällig nen Dienst zu erwischen bei dem das Passwort passen könnte. Die Zielgruppe für solche Daten ist extrem gering und daher sind nur Daten relevant die sich effektiv rentieren. Weiterhin sind deine Argumente in den wenigsten Fällen logisch und ich habe auch das Problem nie verniedlicht.

Du behauptest aber dass das Hashen von Passwörtern alle Sicherheitsprobleme löst und die restlichen Kundendaten keinen Wert haben und das ist, mit Verlaub, Schwachsinn

Übrigens: Gerade der von Dir behauptete Umstand, dass da in einer Nacht- und Nebelaktion Server verschwunden seien, zeigt doch überdeutlich, dass das sichere Hashen wichtig ist. Denn wenn die nicht sicher gehasht waren, besteht die Möglichkeit, das Dritte jetzt Benutzernamen und Mailadresse haben und die Klartextpasswörter ermitteln konnten und das dadurch jetzt andere Dienste gefährdet sind.

Ja, wie gesagt, die Passwörter sind sicher das Wichtige, nicht die personenbezogenen Daten die immer(!) im Klartext vorhanden sind. So ein Rechenzetrum kann zig Millionen bis Milliarden wert sein. Wenn da nur ein gut laufender Onlineshop dabei ist, geht es um nen zweistellingen Millionenbetrag und denen gehen die Passwörter soweit am Arsch vorbei, so gross ist das Universum nicht.

Also komm in die Realität und hör auch dich irgendwo fest zu fahren und andere Gefahren, die mindestens genau so problematisch sind, zu ignorieren.

[Regina Schaukrug]

Wow, du scheinst wirklich in einer anderen Sphäre zu schweben. Ich versuche dir klarzumachen, dass du Paranoia schiebst zu einem Thema das nur in ausnahmefällen relevant ist.

Um zu vermeiden, dass wir uns morgen früh auf einer heimeligen Lichtung im zarten Frühnebel mit scharfen Säbeln in den Händen gegenüber stehen, beende ich die von Dir nicht erst jetzt unsachlich geführte Diskussion.

[m.]

Mahlzeit,

die von Dir nicht erst jetzt unsachlich geführte Diskussion.

Den Abschluss finde ich geil von dir nachdem du gefühlt 25x das Thema gewechselt hast und ich dich wieder zurück zum Thema gezwungen hab 😂

[Meowsalot]

Hallo Regina,

jetzt bleib mal bitte ganz locker. Viel schlimmer finde ich Weibseite wo ich mir mein Passwort erneut zuschicken lassen kann, die speichern die Kennwörter als Klartext in ihrer Datenbank wie es etwa lastPass macht. Bei diesem bin ich bis letzte Woche davon ausgegangen dass dieser gut ist.

Aber jetzt zu meinem Thema, ich ändere dieses gerne wenn es der Sicherheit dient, gar keine Frage. Nur das würde bedeuten jeder User muss sich ein neues Kennwort vergeben? Oder wie würdest du dieses machen? Und kann ich meine Login Funktion weiterhin nutzen oder muss auch dieses komplett umgestellt werden?

Bis bald!
Meowsalot (Bernd)

[m.]

Mahlzeit,

Aber jetzt zu meinem Thema, ich ändere dieses gerne wenn es der Sicherheit dient, gar keine Frage. Nur das würde bedeuten jeder User muss sich ein neues Kennwort vergeben?

Nein, du kannst ja den Hash nochmal neu hashen, packst einen Flag in die Datenbank der dir dann sagt ob das Passwort neu ist und nur mit der neuen Funktion gehasht wird oder mit beiden weil das Passwort noch nicht geändert wurde. Nach angemessener Zeit verschickst du dann Mails an die, die ihr Passwort nicht selbst geändert haben, sie sollten das, aus Sicherheitsgründen, mal wieder machen und wenn dann alle Passwörter geflagt sind (oder inaktive User ignorierbar sind), nimmst du nur noch den neuen Hash.

Oder wie würdest du dieses machen? Und kann ich meine Login Funktion weiterhin nutzen oder muss auch dieses komplett umgestellt werden?

Ich würde auf vorhandene Libs aufsetzen und nix eigenes schreiben. Entweder ein Framework, das diese Funktionalität bietet oder eben was einbinden. Symfony und Laravel können das z.B. vermutlich cakePHP o.ä. auch. Libs weiss ich grad keine, da kann evtl. jemand anderer helfen.

Der Vorteil: Eine Community löst Sicherheitsprobleme und du hast eine Sorge weniger.

[Regina Schaukrug]

Ich würde auf vorhandene Libs aufsetzen und nix eigenes schreiben. Entweder ein Framework, das diese Funktionalität bietet oder eben was einbinden. Symfony und Laravel können das z.B. vermutlich cakePHP o.ä. auch.

Au ja. Diese beliebten Verweise "gut getesteten Frameworks mit großer Community".

Wordpress ist auch "gut getestet" und hat eine wahrhaft riesige Community.

• Und ist zugleich das wohl meistgeknackte "CMS".

Ich vertraue in wichtigen Sicherheitsfragen solchen Frameworks genau soweit, wie ich deren Quelltext vollständig gelesen und komplett verstanden(¹) habe. Hintergrund ist, dass eben diese Frameworks auch von Webseiten benutzt wurden, deren Benutzerdatenbanken geleakt wurden.

Das kann am Framework selbst liegen und an der fehlerhaften Implementation. Lag es an der Implementation, dann an der Dokumentation, also letztendlich doch am Framework bzw. dass es jemand verwendet hat, der es NICHT vollständig gelesen und komplett verstanden(¹) hat.

---

¹) Was es jedenfalls für mich regelmäßig einfacher macht, darauf zu verzichten und hundert Zeilen Vanilla-PHP zu schreiben.

[m.]

Mahlzeit,

Au ja. Diese beliebten Verweise "gut getesteten Frameworks mit großer Community".

Sorry, hab vergessen, dass es ja zig Millionen blöde Leute gibt, die diese Frameworks einsetzen und zig tausende, die Sicherheitslücken beheben. Da ist etwas, das du alleine entwickelst und nur alleine testest, viel vertrauenserweckender, da du sicher mehr Fheler findest als tausend Programmierer zusammen

Wordpress ist auch "gut getestet" und hat eine wahrhaft riesige Community.

• Und ist zugleich das wohl meistgeknackte "CMS".

Wordpress ist veralteter, unbrauchbarer Codemüll. Dein Vergleich heisst für mich, dass su die Arbeit anderer generell ablehnst, aber die Systeme selbst nicht kennst.

Ich vertraue in wichtigen Sicherheitsfragen solchen Frameworks genau soweit, wie ich deren Quelltext vollständig gelesen und komplett verstanden(¹) habe. Hintergrund ist, dass eben diese Frameworks auch von Webseiten benutzt wurden, deren Benutzerdatenbanken geleakt wurden.

Ja, bestimmt bist du der grösste Spezialist in diesen Dingen und die Formen mit zig Programmierern, die mit genau diesen Dingen Geld verdienen, sind alles stümperhafte Idioten die besser Bäcker oder Strassenkehrer werden …

Das kann am Framework selbst liegen und an der fehlerhaften Implementation. Lag es an der Implementation, dann an der Dokumentation, also letztendlich doch am Framework bzw. dass es jemand verwendet hat, der es NICHT vollständig gelesen und komplett verstanden(¹) hat.

Na dann haben wir ja Glück, dass du so gut bist und nur fehlerfreien und absolut sicheren Code schreibst.

Da du die Funktionen password_* empfiehlst, hast du dann also auch den Quellcode von PHP zumindest bei diesen Funktionen vollständig gelesen und verstanden (und dazu natürlich auch die Libs dahinter und alles für jedes Betriebssystem bis hinunter zum Kernel) denn da könnte ja überall eine Implementierung fehlerhaft sein und du kannst dem ja sonst nicht vertrauen.

¹) Was es jedenfalls für mich regelmäßig einfacher macht, darauf zu verzichten und hundert Zeilen Vanilla-PHP zu schreiben.

Wer die Eingeweide von PHP so gut kennt, dass er genau weiss wie vorgegebene Funktionen arbeiten, hat meinen Respekt.

Wenn du natürlich diese Funktionen blind benutzt weil du ihnen vertraust, ist das ein typisches mit zweierlei Mass messen. Einer Firma mit Community vertraust du, einer anderen nicht.

Achja, sind ja sogar viele Communities denen du vertrauen musst um PHP, Apache, mysql/MariaDB, Linux (hier Liste unendlich weiterführen) zu nutzen aber einem PHP-Framework vertraust du nicht. Schon extrem paradox wie ich meine.

[Regina Schaukrug]

Nur das würde bedeuten jeder User muss sich ein neues Kennwort vergeben? Oder wie würdest du dieses machen?

Das ist jetzt ein Trick.

Es wird versucht das Loin mit der neuen Methode durchzuführen.
   Fehlschlag: 
      Es wird versucht das Login mit der alten Methode durchzuführen.
         Erfolg:
            Das eingegebene Passwort wird mit der neuen Methode gehasht
            oder (besser) aber der Benutzer wird zur Eingabe eines neuen Passworts gezwungen
            Ab dann klappt die Neue Methode.

Auch bei der Methode mit password_verify() ist nach dem erfolgreichen(!) Login mit password_needs_rehash() zu prüfen ob der bestehende Hash dem Stand der Technik entspricht. (Seite 4: "Ein stilles Update können Sie auch durchführen") Zu diesem Zweck ist die Methode im ersten Abschnitt des Hashes durch einen Code notiert. Liefert password_needs_rehash() true, wird das Passwort (das eben eingegebene oder ein Neues) ebenfalls mit password_hash() neu gehascht und eingetragen.

Dann geht's weiter wie bisher.

Vorteil: Man muss in PHP nichts mehr umschreiben, weil die Verwendung der der "Methode auf dem Stand der Technik" im Hintergrund stattfindet. Man muss nur dafür sorgen, dass PHP seine Updates erhält.

Das ist die Wurst, die man sich braten will.

[m.]

Mahlzeit,

Vorteil: Man muss in PHP nichts mehr umschreiben, weil die Verwendung der der "Methode auf dem Stand der Technik" im Hintergrund stattfindet. Man muss nur dafür sorgen, dass PHP seine Updates erhält.

Nachteil, inaktive Userpasswörter werden nie rehashed und dadurch bleibt das Login bei deinem Ansatz auf Dauer unsicher.

[Regina Schaukrug]

Nachteil, inaktive Userpasswörter werden nie rehashed und dadurch bleibt das Login bei deinem Ansatz auf Dauer unsicher.

Dieser Umstand ist auch mit jedem anderen Ansatz nicht vollautomatisch zu beheben. Lösung ist, alle oder inaktive User mit Fristsetzung zu benachrichtigen, dass wegen modernerer Sicherheitsvorkehrungen ein Login und ggf. die Änderung des Passworts nötig ist.

Wenn das nicht erfolgt muss man halt nach Fristablauf im Interesse der inaktiven Benutzer selbst deren Einträge "brutal" löschen. Das entspricht übrigens auch der DSGVO. Stichworte "Notwendigkeit, Zweckbestimmung".

Die können sich ja neu anmelden.

[m.]

Mahlzeit,

Dieser Umstand ist auch mit jedem anderen Ansatz nicht vollautomatisch zu beheben.

Dann hast du meinen Post zum Thema nicht gelesen.

[Regina Schaukrug]

Ich hab Dir auf einen bestimmten Post vollständig und mit technisch korrekten Aussagen geantwortet und diesen eingehend zitiert, damit klar ist worauf ich antworte. Aus Deinem geheimnisvollen "Dann hast du meinen Post zum Thema nicht gelesen." kann ich nichts entnehmen.

[m.]

Mahlzeit,

Ich hab Dir auf einen bestimmten Post vollständig und mit technisch korrekten Aussagen geantwortet und diesen eingehend zitiert, damit klar ist worauf ich antworte. Aus Deinem geheimnisvollen "Dann hast du meinen Post zum Thema nicht gelesen." kann ich nichts entnehmen.

Sorry, ich dacte das "zum Thema" wäre ausreichen damit du weisst, ich meine meinen Post in gleicher Ebene in dem ich erklärt habe wie ich das lösen würde. Mein Fehler.

[Meowsalot]

Hallo Regina,

und wie sieht es hier mit der DSGVO aus? Ich darf einem User nicht ungefragt eine eMail mit einer bitte um Passwortänderung zukommen lassen?

Könnte teuer für mich werden, denn der User hat nie eingewilligt dass ich ihm irgendwelche Mails zuschicken darf.

Bis bald!
Meowsalot (Bernd)

[Regina Schaukrug]

Könnte teuer für mich werden, denn der User hat nie eingewilligt dass ich ihm irgendwelche Mails zuschicken darf.

Das könnte es auch so. Denn es fehlt dann an einem Zweck der Speicherung seiner Mailadresse sowie der Beschränkung auf das für die Zwecke der Verarbeitung notwendige Maß - und Du musst die Daten ohnehin löschen.

Art. 5 Absatz 1 Buchstabe c DSGVO

Im Übrigen wäre der Mailversand in diesem Fall "die erforderliche Verarbeitung zur Erfüllung einer rechtlichen Verpflichtung, der der Verantwortliche unterliegt;"

Art. 6 Absatz 1 Buchstabe c DSGVO

Du hast nämlich alles zumutbare zu tun um die Daten zu schützen. Dazu kannst Du auch die Mitwirkung einverlangen.

[Meowsalot]

Hallo Regina,

wenn ich die Mail Adresse lösche, dann ist auch der Benutzer weg, was ja nicht sinn der Sache sein kann. Außerdem steht in den AGB dass die Mail Adresse = der Benutzername ist, also hat der User eingewilligt dass ich seine Mail Adresse speichern darf?

Bis bald!
Meowsalot (Bernd)

[Regina Schaukrug]

wenn ich die Mail Adresse lösche, dann ist auch der Benutzer weg, was ja nicht sinn der Sache sein kann.

Bei einem "inaktiven Benutzer" schon. Denn was soll denn der Zweck für die Speicherung der Daten inaktiver User sein?

Außerdem steht in den AGB dass die Mail Adresse = der Benutzername ist, also hat der User eingewilligt dass ich seine Mail Adresse speichern darf

Pauschal erscheint das wahrscheinlich. Aber so lange ich das gesamte Vertragswerk nicht kenne und wegen der Rechtsdienstleistungsverordnung werde ich mich hüten, den Einzelfall umfassend zu beurteilen.

[m.]

Mahlzeit,

und wie sieht es hier mit der DSGVO aus? Ich darf einem User nicht ungefragt eine eMail mit einer bitte um Passwortänderung zukommen lassen?

Ich weiss nicht konkret, wie das geregelt ist mir Mails, die die Account-Sicherheit betreffen. Es ist ja im Interesse des Users, dass er eine solche Mail bekommt, sie darf natürlich nicht als Werbemail ausfallen wie "Du warst so lange nicht mehr da, melde dich doch mal wieder an und kauf was". Generell hast du ja, wenn du so ein Onlineangebot betreibst, passende AGB und eine Datenschutzerklärung. Da steht dann auch entsprechend drin, ob du es darfst oder nicht.

Wenn am Ende raus kommt, dass du keine Mail verschicken darfst, bleibt nur die Sperrung oder Löschung des Accounts, evtl. mit der Möglichkeit, dass der User ein neues Passwort anfordern kann.

Du wirst aber nur Sicherheit haben, wenn du dazu einen Fachanwalt befragst und dir eine verbindliche, schriftliche Auskunft geben lässt.

[Meowsalot]

Hallo m.,

nach Rücksprache mit meinem Anwalt soll ich wie folgt vorgesehene wenn es wirklich ein Sicherheitsrisiko darstellt:

• Passwörter in der Datenbank komplett löschen
• User gibt sein Passwort ein, es schlägt fehl, die Datenbank erkennt dass das Feld leer war
• Meldung ausgeben warum der Login nicht möglich war
• Link anbieten um Passwort neu zu vergeben
• Passwort "richtig" speichern
• Fertig

Er meinte auch, in so einem Fall auch wenn der User keine Einwilligung gegeben hat, dürfte man ihm eine Mail schicken, da es hier um Sicherheit geht und diesem dem User nur zu gute kommt.

Bis bald!
Meowsalot (Bernd)

[Regina Schaukrug]

wenn es wirklich ein Sicherheitsrisiko darstellt:

Erst mal sind wir, so lange keine Anzeichen dafür vorliegen, dass die Datenbank illegal kopiert wurde, bei einem "potentiellen Risiko". Es geht also mit dem von mir vorgeschlagenen stillen Update nach dem Login. Muss aber zeitnah sein.

• Link anbieten um Passwort neu zu vergeben

Dann musst Du aber der Gefahr entgegen wirken, dass diese Funktion durch einen Dritten missbraucht wird. "Anderer Faktor", z.B. Identifizierung per Token (gemeinsames, individuelles, nicht erratbares Geheimnis) in einem Email an seine bekannte Adresse, welches er dann wieder eingeben muss. Das wäre jedenfalls der Standardweg.

Er meinte auch, in so einem Fall auch wenn der User keine Einwilligung gegeben hat, dürfte man ihm eine Mail schicken, da es hier um Sicherheit geht und diesem dem User nur zu gute kommt.

Sowas sagte ich doch schon in Bezug auf Art. 6 Absatz 1 Buchstabe c DSGVO. Es gibt im deutschen Recht auch das "Handeln ohne Auftrag" mit dem ein Schaden für den "Nichtauftraggeber" vermieden werden soll.

[m.]

Mahlzeit,

• Passwörter in der Datenbank komplett löschen

Dann stell aber auch sicher, dass sich niemand mit nem leeren Passwort anmelden kann. Ich würde dann gleich Passwörter per Zufall erzeugen und entsprechend Hashen. Die Hashfunktion brauchst du eh, eine kleine Methode um nen Zufallsstring zu erzeugen ist kein Aufwand und brauchst du eh wenn du ein Passwort erzeugen willst, wenn ein User ein neues anfordert.

Ist nur ein Bauchgefühl, dass ich ein Passwortfeld nicht leer lassen würde.

• User gibt sein Passwort ein, es schlägt fehl, die Datenbank erkennt dass das Feld leer war

Würde trotzdem nen Flag setzen, damit du nachvollziehen kannst, wer sich ein neues Passwort schicken hat lassen. Aufgrund dieses Flags kannst du dann eine Meldung ausgeben wie "bitte neues Passwort anfordern" o.ä.

• Meldung ausgeben warum der Login nicht möglich war
• Link anbieten um Passwort neu zu vergeben

genau dieses. Deshalb der Flag, damit die Meldung nur Leute kriegen, die kein neues Passwort vergeben.

• Passwort "richtig" speichern
• Fertig

Er meinte auch, in so einem Fall auch wenn der User keine Einwilligung gegeben hat, dürfte man ihm eine Mail schicken, da es hier um Sicherheit geht und diesem dem User nur zu gute kommt.

So würde ich das auch sehen aber ich bin kein Jurist 😉

[MudGuard]

Hi,

Nachteil, inaktive Userpasswörter werden nie rehashed und dadurch bleibt das Login bei deinem Ansatz auf Dauer unsicher.

Dieser Umstand ist auch mit jedem anderen Ansatz nicht vollautomatisch zu beheben. Lösung ist, alle oder inaktive User mit Fristsetzung zu benachrichtigen, dass wegen modernerer Sicherheitsvorkehrungen ein Login und ggf. die Änderung des Passworts nötig ist.

Wenn das nicht erfolgt muss man halt nach Fristablauf im Interesse der inaktiven Benutzer selbst deren Einträge "brutal" löschen. Das entspricht übrigens auch der DSGVO. Stichworte "Notwendigkeit, Zweckbestimmung".

Daß bei nicht-Aktivwerden des Users dessen User-Eintrag gelöscht (bzw. gesperrt - wenn gesetzliche Regelungen die Löschung verhindern) wird, sollte in der Mail mit drinstehen.

Und es sollte in der Mail auch die Möglichkeit geben, seinen User-Eintrag sofort löschen bzw. sperren zu lassen.

cu,
Andreas a/k/a MudGuard

[Regina Schaukrug]

Daß bei nicht-Aktivwerden des Users dessen User-Eintrag gelöscht (bzw. gesperrt - wenn gesetzliche Regelungen die Löschung verhindern) wird, sollte in der Mail mit drinstehen.

Klare Sache.

Und es sollte in der Mail auch die Möglichkeit geben, seinen User-Eintrag sofort löschen bzw. sperren zu lassen.

Das auch. Ob Löschen oder Sperren will übrigens - von vorn herein - gut überlegt sein.

[pl]

hi

ich habe folgende Script um zu prüfen ob ein User eingeloggt ist

function isUserLoggedIn($mysqli) {
        $session = session_id();
        $stmt = $mysqli->prepare("SELECT * FROM zugangsdaten WHERE user_session=?");

Was haben bei Dir die Zugangsdaten mit einer solchen Prüfung zu tun? Das ist doch nicht etwa alles in einer Tabelle bei Dir?

MfG

[Meowsalot]

Hallo pl,

Was haben bei Dir die Zugangsdaten mit einer solchen Prüfung zu tun? Das ist doch nicht etwa alles in einer Tabelle bei Dir?

doch, diese Daten stehen alle in einer Tabelle.

Und jetzt bitte nicht mit PERL kommen 😉

Bis bald!
Meowsalot (Bernd)

[pl]

hi,

Was haben bei Dir die Zugangsdaten mit einer solchen Prüfung zu tun? Das ist doch nicht etwa alles in einer Tabelle bei Dir?

doch, diese Daten stehen alle in einer Tabelle.

Es ist besser das zu trennen. 2 Tabellen: Zugangsdaten, Login. In die Logintablle gehört die SID, der Benutzername und der Zeitpunkt der Anmeldung. Falls ein Logout erfolgte, der Zeitpunkt dazu. Ansonsten hat jedes Login ein Expires.

Und jetzt bitte nicht mit PERL kommen 😉

Erstens heißt das nicht PERL sondern Perl und zweitens hat das damit nichts zu tun.

MfG

[m.]

Mahlzeit,

doch, diese Daten stehen alle in einer Tabelle.

Halte ich für ungünstig. Besser ist, du hast eine Tabelle für Userdaten und eine zusätzliche für das Sessionhandling. Das hat zum einen den Vorteil der höheren Geschwindigkeit bei richtiger, programmiertechnischer, Umsetzung zum anderen bekommt ein Angreifer weniger Daten wenn eine Tabelle kompromittiert wird.

Früher wurde da immer von "Normalisierung" gesprochen, ob das noch stand der Technik ist und noch so genannt wird, weiss ich nicht.

[Rolf B]

Hallo Meowsalot,

das ist nicht nur ungünstig, sonder leider falsch modelliert.

User und Session sind unterschiedliche und unabhängige Entitäten, die nur bei Bestehen einer festen 1:1 Beziehung in einer Tabelle gemeinsam gespeichert werden dürften. Das ist aber nicht so.

Eine Session kann sich auf einen angemeldeten User beziehen, MUSS ABER NICHT. Es gibt genug Webseiten (z.B. bahn.de), bei denen ich anonym eine Menge tun kann und erst dann, wenn es ans Bezahlen geht, ein Login nötig wird. Ein User dagegen muss keine Session haben (wenn er abgemeldet ist), kann aber eine haben. Und er kann auch mehrere haben, wenn er auf mehreren Geräten (oder auch nur in unabhängigen Browserfenstern) unterwegs ist.

Die Beziehung zwischen User und Session ist also 1:n. Die Trennung ist deshalb unbedingt erforderlich, und die Implementierung der Relation muss so erfolgen, dass die User-Id als Fremdschlüssel in der Session-Tabelle gespeichert wird. In dieser Session-Tabelle müsste dann auch noch der Verfalls-Timestamp stehen (user_login greift nicht, wenn es parallele Sessions gibt).

Rolf

[pl]

Moin,

ein Login muss nicht unbedingt ins relationale DBMS. Es genügt, den Login (Benutzername, Gruppe, Anmeldezeitpunkt) in der Sessiondatei zu speichern. So hat diese Datei auch selbst ein Verfallsdatum und ein Logout beschränkt sich darauf, den Eintrag zu löschen.

Eine DB ist nur dann erforderlich, wenn über die Logins ein Protokoll zu führen ist. Und auch dann gibt es keinerlei Beziehung zwischen den Tabellen Zugangsadten und Login, der Begriff der Normalisierung ist da völlig fehl am Platze.

MfG

[Rolf B]

Hallo pl,

ok, da hast Du recht.

Meine (Uralt-)PHP Anwendung, die ich betreuen „darf“, hat eine Session-Table und einen SQL Session Handler, da war ich wohl zu sehr drauf fixiert.

Rolf

[pl]

hi @Rolf B

die Sessions organisieren ist freilich eine interessante Geschichte um nicht zu sagen eine Herausforderung. Also ich mache das so:

    if($sid){
        tie %SESSION, 'SessionFile', file => $sid or die $@;
    }

und später wird %SESSION zu einer Eigenschaft der FWinstanz. So landet der Adminlogin, sofern erfolgreich in %SESSSION

        # Credentials OK ab hier
        $self->{SESSION}{LOGINTAB} = {
            group => 'admin',
            user  => $user,
            ts    => time(),
        };

Und da %SESSION an eine Klasse gebunden ist, können Methoden aufgerufen werden wie z.B. das Speichern:

tied(%{$self->{SESSION}})->write();

womit der Login persistiert wird. Und jetzt kommt der eigentliche Hack: die Klasse SessionFile ist austauschbar. Und damit auch der Speicherort.

MfG

[Mitleser]

ein Login muss nicht unbedingt ins relationale DBMS.

Muss nicht, kann aber vorteilhaft sein.

Eine DB ist nur dann erforderlich, wenn über die Logins ein Protokoll zu führen ist.

z.B. bei einer Serverfarm im Load-Balancing kann das ebenfalls nützlich sein. Wobei man dann vermutlich so etwas wie memcached vorziehen wird.

[dedlfix]

Tach!

besteht irgendwie die Möglichkeit ein Login über zwei Domains hinweg zu realisieren? Ich nutze für mein Login eine Session.

Kommt drauf an, ob du eine Lösung à la OpenID oder OAuth haben möchtest, oder ob du was eigenes basteln kannst.

Das Problem ist, dass du die Logged-In-Information (üblicherweise eine Session-ID) auf dem Client von Domain A zu Domain B bekommen musst. Wenn du aber Seiten von A aufrufst, kannst du nicht auf Cookies oder localStorage von B zugreifen. (Begrenzt sind Cookies möglich, bei Subdomains.)

Eine Lösung wäre, eine Domain C verwaltet die Anmeldungen. Beim Besuch von A oder B wird C kontaktiert und um eine Session-ID (oder eine andere Art der Logged-In-Information) gefragt. Die überträgst du dann in Requests zu A und B. Du müsstest aber über CORS-Header freigeben, dass der Browser die fremde Domain C besuchen darf, wenn du auf A oder B bist. Alternativ gehts auch ohne C, dann jeweils den anderen (A<->B) befragen.

dedlfix.

[Meowsalot]

Hallo dedlfix,

danke für deine Erklärung.

Eine Lösung wäre, eine Domain C verwaltet die Anmeldungen. Beim Besuch von A oder B wird C kontaktiert und um eine Session-ID (oder eine andere Art der Logged-In-Information) gefragt. Die überträgst du dann in Requests zu A und B. Du müsstest aber über CORS-Header freigeben, dass der Browser die fremde Domain C besuchen darf, wenn du auf A oder B bist. Alternativ gehts auch ohne C, dann jeweils den anderen (A<->B) befragen.

Eine weitere Domain nur für den Login würde ich ungern nutzen wollen. Da ist mir das A<->B lieber. Wie mein Login und die Prüfung derzeit ausschaut siehst du hier:

https://forum.selfhtml.org/self/2018/aug/27/login-ueber-zwei-domains-hinweg/1730213#m1730213

was müsste ich jetzt machen um das A<->B umzusetzten?

Bis bald!
Meowsalot (Bernd)

[Henry]

Hallo Meowsalot,

Hallo dedlfix,

Eine weitere Domain nur für den Login würde ich ungern nutzen wollen. Da ist mir das A<->B lieber.

wie @dedlfix schon schrieb, ist C nicht zwingend notwendig.

Alternativ gehts auch ohne C, dann jeweils den anderen (A<->B) befragen.

Also eine Mutterdomain, welche die Kinder steuert.

was müsste ich jetzt machen um das A<->B umzusetzten?

Die Anmeldeprozedur automatisiert bei den vernetzten Domains ausführen lassen oder alternativ, so würde ich es machen, beim Besuch von B, C, D, etc. ein Script laufen lassen, dass prüft ob ich bereits bei A eingeloggt bin und dann die Loginfreigabe (Session erstellen) auf der jeweiligen Seite. Falls nicht bei A eingeloggt, dann bei XY einloggen und simultan bei A einloggen (bzw. je nach Prüfroutine den Status dort deklarieren).

Gruss
Henry

[dedlfix]

Tach!

Eine weitere Domain nur für den Login würde ich ungern nutzen wollen. Da ist mir das A<->B lieber. Wie mein Login und die Prüfung derzeit ausschaut siehst du hier:

Die Serverseite ist das kleinere der beiden Teilprobleme. Zuerst solltest du clientseitig herausfinden, wie man den Browser dazu bringen kann, eine Information, die er von Domain A bekommen hat, zu Domain B zu senden. Lass dein Projekt erstmal beiseite und versuch diesen Schritt prinzipiell hinzubekommen. Dann kannst du schauen, ob/wie das auch mit Cookies geht.

Der nächste Schritt ist zu erkunden, wie die Serverseite dazu aussehen kann. Wie kommt eine Information vom VHost der Domain A so zu liegen, dass der VHost der Domain B diese lesen kann, und im speziellen wie das mit Session-Daten vonstatten gehen kann.

dedlfix.

[m.]

Mahlzeit,

besteht irgendwie die Möglichkeit ein Login über zwei Domains hinweg zu realisieren? Ich nutze für mein Login eine Session.

Generell ja. Der Aufwand hängt dann u.a. davon ab ob sich beide Domains auf dem gleichen Server befinden und ob sie sich den Userspace teilen.

Aktuell realisiere ich ein Kundenprojekt mit mehreren Domains auf Basis von OctoberCMS. Die Domains zeigen alle auf das gleiche Verzeichnis und das CMS übernimmt das Routing bis hin zur Auswahl des Templates, Sprache, Inhalte pro Domain und alles ist in einer Oberfläche bearbeit- und wartbar. Login gibt es dadurch für alle Domains auch nur eins.

[Meowsalot]

Hallo m.,

ob die Domains immer auf dem gleichen Server liegen kann ich nicht sagen und würde mich darauf auch nicht verlassen. Ich bin zwar mit beiden Domains beim gleichen Hoster aber dieser meinte es kann innerhalb von einem Account auch sein, dass eine Domain auf Server A und die zweite auf Server X liegt.

Bis bald!
Meowsalot (Bernd)

[m.]

Mahlzeit,

ob die Domains immer auf dem gleichen Server liegen kann ich nicht sagen und würde mich darauf auch nicht verlassen. Ich bin zwar mit beiden Domains beim gleichen Hoster aber dieser meinte es kann innerhalb von einem Account auch sein, dass eine Domain auf Server A und die zweite auf Server X liegt.

Das würde dann aber bedeuten, dass du für jede Domain ein eigenes Login hast. Eine Domain ist nur eine Art Zeiger auf eine IP. Der Server (Apache, nginx o.ä.) sagt dann "die Domain kenn ich und ich weiss, wo die zugehörigen Inhalte liegen".

Vielleicht verstehe ich das ja falsch aber ein Account heisst für mich, ich habe Webspace und ich habe Domains. Über eine Weboberfläche kann ich dann sagen, welche Domain auf welche Ordner im Dateisystem zeigen soll. Obige Aussage ist für mich daher unverständlich, wenn dein Account nicht Serverübergreifend auf Dateisysteme zugreifen kann.

[Regina Schaukrug]

Ich bin zwar mit beiden Domains beim gleichen Hoster aber dieser meinte es kann innerhalb von einem Account auch sein, dass eine Domain auf Server A und die zweite auf Server X liegt.

Das innerhalb eines Accounts zwei Domains auf zwei verschiedenen Servern liegen dürfte hinsichtlich der Account- und Domainverwaltung aus technischen Gründen technisch ziemlich schwierig zu händeln sein. Das geht schon bei disk-quotas (die ja für den vertrag und also den Account gelten) los. Ansonsten müsste man sich darüber unterhalten, was mit "Server" gemeint ist, und da würde ich von der Kiste ausgehen, die den eigentlichen Webserver (häufig: Apache) beherbergt.

Was gibt denn

<pre><?php
echo $_SERVER['DOCUMENT_ROOT']
     . "\n"
     . $_SERVER['SERVER_ADDR'];
?>

auf den jeweiligen Domains aus?

Die IP Adresse von einem Client aus via DNS aufzulösen bringt nichts, weil da Proxys dazwischen sein können. Sowohl auf der Clientseite als auch auf der Serverseite kann das "transparent" geschehen, also so dass im öffentlichen DNS der Domainname auf die IP des Proxys zeigt. So kann z.B. ein "halbes Rechenzentrum" nach außen die öffentliche IP eines Proxys haben, der dann die Requests nur an die eigentlichen Server - mit vielleicht sogar privaten IPs (z.B. aus dem Adressbereich 10.x.x.x/8) verteilt. Insofern kann die Auflösung also die Täuschung erwecken, dass die Webseiten zweier oder mehr Domains auf dem gleichen Server liegen.

• $_SERVER['SERVER_ADDR'] zeigt Dir also die "endgültige" IP aus Serversicht. Die wäre hier womöglich aussagekräftiger.

Kommen wir zur eigentlichen Session und zum Experiment

Ich hab damit ein wenig rumgespielt, das Folgende hat nur Testcharakter, es soll Dich zum Weiterdenken animieren, es ist kein fertiger Code!

Der Krempel wird dann funktionieren,

• wenn beide Domains auf dem gleichen Server liegen
• und das Verzeichnis für die Session-Dateien identisch ist
• und Du musst Dich ggf. noch um CORS-Einträge kümmern.

Liegen die Session-dateien nicht auf den gleichen Server muss beim Session-Transfer dafür gesorgt werden, dass die Session-Datei vom Server A zum Server B kopiert wird. Das geht mit PHP eigentlich ganz einfach.

$sessTransferKey hat (noch) keine Bedeutung.

A) Erzeugung der Session auf Domain A:

<?php
#https://home.fastix.org/Tests/session_start.php
$serverA='https://home.fastix.org';
$serverB='https://home.fastix.org';

if (! session_id() ) { 
	session_start();
}

if ( ! isset( $_SESSION['foo'] ) ) {
	$_SESSION['foo'] = 'bar';
}

if ( ! isset( $_SESSION['TransferKey'] ) ) {
	$_SESSION['TransferKey'] = generateTransferKey();
}

$sessionFileName = ini_get('session.save_path') . '/sess_' . session_id() ;

echo '<p>Session-ID: ' . session_id() . '</p>';
echo '<p>Session-File: ' . $sessionFileName . '</p>';

echo '<hr><pre>' . htmlspecialchars( file_get_contents ( $sessionFileName )  ) . '</pre></hr>';
echo '<p>Gehe zu <a href="' . $serverB . '/Tests/session_use.php">' . $serverB . '/Tests/session_use.php</a></p>';

function generateTransferKey() {
	$blob = '';
	for ( $i=0; $i<160; $i++ ) {
		$blob .= chr( random_int( 1,126 ) );
	}
	return base64_encode( $blob );
}

b) "Antelefonieren" der Session von einer Seite von Domain B aus mit Javascript

<html>
<!-- https://home.fastix.org/Tests/session_use.php /-->
<head></head>
<body>
<p>Session ID: <span id="sessID"></span></p>
<p>Session TransferKey: <span id="sessTransferKey"></span></p>
<p>Session Transfer ausgeführt: <span id="TranferOK"></span></p>
</body>
<script>
var xhttp = new XMLHttpRequest();
xhttp.onreadystatechange = function() {
    if ( this.readyState == 4 && this.status == 200 ) {
	   vars = JSON.parse( this.responseText );
       document.getElementById('sessID').innerHTML = vars['sessID'];
       document.getElementById('sessTransferKey').innerHTML = vars['sessTransferKey'];
       
       var xhttp2 = new XMLHttpRequest();
	     xhttp2.onreadystatechange = function() {
			 if (this.readyState == 4 && this.status == 200) {
			   document.getElementById('TranferOK').innerHTML = this.responseText;
			 }
		};
		xhttp2.open( "POST", "https://home.fastix.org/Tests/sessiontransfer.php", true );
    xhttp2.setRequestHeader( "Content-type", "application/x-www-form-urlencoded" );		
		data = 'sessID='           + encodeURIComponent( vars['sessID'] ) 
		     + '&TransferKey=' + encodeURIComponent( vars['sessTransferKey'] );
		xhttp2.send( data );        
    }
};
xhttp.open( "GET", "https://home.fastix.org/Tests/sessionGetIDandTransferKey.php", true );
xhttp.send(); 
</script>
</html>

C) Und zu guter Letzt die "sessiontransfer.php", für die eigentlich nur mit session_id() die frühere id zu setzen ist, der Rest geht automatisch mit session_start() - Aber nur wenn die Session-Datei vorhanden ist!

<pre>
Postdata: 
<?php
print_r( $_POST );
?>
SESSION:
<?php
# Hier eventuell das Kopieren der Session-Datei von Server A nach Server B
session_id( $_POST['sessID'] );
session_start();
print_r( $_SESSION );
?>
</pre>

wenn Du die Session-Datei kopierst, dann musst Du ferner Sorge dafür tragen, dass im Falle einer Abmeldung das Original und alle Kopien zuverlässig zerstört (gelöscht) werden.

[Regina Schaukrug]

Achso.

Rufe danach auf Server B die sessionTest.php auf:

<pre><?php
# sessionTest.php
echo 'ID:' . $session_id() . "\n";
session_start();
print_r( $_SESSION );

Die sollte die gleiche ID, den TransferKey und foo (beide mit Wert) beinhalten. Dann hat das geklappt.

[Regina Schaukrug]

@Meowsalot

Melde Dich mal, ich würde schon gern wissen, ob Du den Sessiontransfer implementieren konntest. (Oder was nicht geklappt hat.) Der dient nämlich genau Deinem genannten Ziel des Logins auf einer der Domains.

[Meowsalot]

Hallo Regina,

ich würde mich am Wochenende damit beschäftigen. Muss meine Internetseite mit dem neuen Design fertig bekommen. Hoffen dieses ist OK für dich.

Bis bald!
Meowsalot (Bernd)