Geheime URL bzw. automatisches Einloggen mit Browser?

[blackdrake]

Hallo.

Ich habe folgendes Problem:

Ein PHP-Interface erlaubt einem Nutzer (sofern aktiviert), das Einloggen in das System mit 1 URL.

Diese URL sei vereinfacht www.example.com/login.php?secretkey=<...>

Der Secretkey enthält den Benutzernamen und das Passwort in einer serverspezifischen Verschlüsselung. Die Daten sind somit nicht ohne Zusatzinformation zu entschlüsseln.

Da aber der Secretkey (sofern Salt nicht geändert wird) aber zum Einloggen ausreicht, ist es als eine geheime Information anzusehen.

Solange ich die geheime URL von meinem (Annahme: nicht gehackten) Heim-PC aufrufe, ist alles OK. Das Problem besteht, wenn ein Nutzer die geheime URL von einem fremden PC aufruft (was man eigentlich nicht tun sollte). Die URL wäre im Verlauf und somit kann der Einloggvorgang selbst von einem unerfahrenen User durchgeführt werden.

Meine Fragen:

1. Gibt es mit einer Delphi-Application eine Möglichkeit, eine geheime URL aufzurufen, die nicht gespeichert wird (Ausnahme: wenn PC mit Keylogger infiziert), aber trotzdem die nachfolgenden Webseiten (die durch ein HTTP-Redirect hergeholt werden) mit dem Standardbrowser behandelt werden können?

Oder bessere Variante:

2. Gibt es mit einer Delphi-Application eine Möglichkeit, ein HTML-Formular (mit Benutzername und Passwort) auszufüllen, ABER die nachfolgenden Webseiten mit dem Standardbrowser zu behandeln? (Man müsste dem Browser irgendwie das Formular-Ausfüllen beibringen --> Problem: Browser soll beliebig sein!)

Hat jemand eine Idee? Ich befürchte aber, dass das nicht so möglich sein wird.

Die Anwendung könnte die Benutzerdaten verschlüsselt im Anhang besitzen und sie mithilfe einer Hardware-ID entschlüsseln; anschließend das HTML-Formular ausfüllen (=einloggen). Damit würde der automatische Einloggvorgang, der PC gebunden wäre, nicht auf fremden PCs durchgeführt werden.

Gruß
blackdrake

[SirThornberry]

ich würde an der URL ansetzen. Mache es doch wie die meisten fertigen Communities etc.
Erstelle beim Login auf der Webseite eine SessionID. Zu dieser SessionID vermerkst du dir auf dem Server welcher Benutzer es ist. Somit gibt es auch nicht das Problem das jemand das Passwort entschlüsseln kann.
Und jedesmal wenn eine URL mit Angabe dieser SessionID aufgerufen wird schaust du in der Datenbank ob es diese gibt und gewährst dann den Zugriff bzw. verweigerst ihn.
Wenn sich jemand abmeldet löschst du die SessionID und schon bringt sie niemandem mehr was weil sie nicht merh gültig ist. Gegebenfalls kannst du es ja auch so machen das man mehrere Sessions erstellen kann so das du dich auf einem anderen Rechner neu anmeldest, eine neue SessionID bekommst aber die alte welche du zu Hause verwendest weiterhin gültig bleibt.

[blackdrake]

Hallo.

SessionID hört sich für mich ziemlich zeitbegrenzt an. Der Sinn ist es ja, dass das Einloggen immer möglich ist, mit 1 Mausklick. Im Moment verwende ich die Technik mit dem Secret-Key. Das funktioniert zwar, kann aber für unwissende User verhängnisvoll werden, wenn sie die geheime URL von einem fremden PC aus verwenden.

Bei der SessionID wäre doch das Problem, dass sie ungültig wird, wenn man sich ausloggt. Und wäre die Session unendlich, dann könnte sie wiederrum von einem fremden PC aufgerufen werden, wenn die (geheime) URL im Verlauf bleibt.

Gruß
blackdrake

[littleDave]

Wie wäre es folgendermaßen: Du sendest einen Request vor dem Aufruf an den Server. Der Server erstellt dann eine Session intialisiert sie mit einem bestimmten Salt. Diesen Salt bekommt die Anwendung dann als Antwort. Die Anwendung berechnet dann mit dem Salt den Secret Key. Dadurch ändert sich dieser bei jedem neuen Einloggen, da der Server immer wieder einen anderen Salt vorraussetzt.
Du kannst ja den Salt dann noch nach einer bestimmten Zeit ablaufen lassen. Ist diese Zeit erreicht, muss zuerst ein neuer Salt vom Server angefragt werden.

[blackdrake]

Hallo littleDave.

Diese Idee ist super. Vielen Dank.

Ich habe jetzt folgendes geplant:

• Es wird zusätzlich zu den (wenn falsch angewandt unsicheren) Secret-FastLogin-URLs ein Account-Manager mit 1-Klick-Einloggfunktion eingeführt. Dieser ist universell. Das heißt, die EXE ist nicht an den jeweiligen Nutzer, dessen Hardware oder das PHP-System (z.B. durch EXE-Append-Data) angepasst.
  
• Der Nutzer gibt die Zugangsdaten in das Programm ein und kann sie dort auch wieder löschen (wenn er auf einem fremden PC war).
  
• Das Programm sendet eine Anfrage an den Server. Dieser erstellt eine SessionID und gibt diese als HTTP-Content an das Programm zurück. Die SessionID ist Zeit-Terminiert und ist 1 Minute gültig (wird dann automatisch durch den abgelaufenen Timestamp gelöscht)
  
• Das Programm verschlüsselt den Benutzername und das Passwort, die mit einem Delimiter voneinander getrennt sind, mit der SessionID. Das Ergebnis ist der neue SecretKey. [Memo an mich: PHP-Encryption-Algorithmus in Delphi übersetzen]
  
• Der entstandene SecretKey, der nur 1 Mal gültig ist, wird per Browser-Aufruf (GET-Request) an das PHP-System gegeben. Der Knackpunkt hier ist, dass die SessionID nicht in der URL (und folglich im Verlauf) vorkommen darf. Ansonsten könnte man mithilfe der im Verlauf gespeicherten Daten den SecretKey anhand der SessionID entschlüsseln und man hätte die Zugangsdaten.
  
• Der Server muss also alle verfügbaren (gültigen) SessionIDs mithilfe der Entschlüsselung des SecretKeys durchprobieren. Ist der Delimiter (der Benutzername und Passwort voneinander trennt) anwesend, war die Entschlüsselung wahrscheinlich erfolgreich. [Problem: Genaue Kontrolle? Datenmüll mit zufällig dem Delimiter führt zu Login-Fehlschlag]
  
• Der Server führt den Loginvorgang durch (Login-Variablen setzen und HTTP-Redirect) und löscht die verwendete SessionID sofort -> SecretKey ist nicht wieder nutzbar.

Die Technik wird von mir zu einem späteren Zeitpunkt umgesetzt. Im Moment war mir die Idee und der daraus resultierende Plan wichtig.

Problematisch wird jedoch, dass ich durch Delphi an Windows gebunden bin, obwohl das PHP-System logischerweise für alle Betriebssysteme ist. C++, das Cross-Platform ist, kann ich leider nicht.

Gruß
blackdrake

[Apollonius]

Darf ich ein paar Verbesserungsvorschläge machen?
Verschlüssele nicht die Daten, sondern hashe sie. Dann macht es auch nichts mehr, wenn SessionID oder SecretKey bekannt werden. Am besten fügst du die SessionID an das Passwort an, wendest darauf dann die Hash-Funktion an und verschickst das ganze zusammen mit dem Benutzernamen an den Server (dann muss der Server nicht alles durchprobieren - das ist ineffektiv). Du kannst sogar soweit gehen, die SessionID im Klartext mitzuschicken - durch den Hash ist das egal, und die Serverlast reduziert sich. Der Server muss nur prüfen, ob die SessionID in seiner Liste steht und selbst den Hash aus SessionID und Passwort berechnen. Der Nachteil an diser Methode (bei deiner allerdings auch), ist, dass der Server die Passwörter im Klartext speichern muss. Wenn ein Angreifer also die Datenbank in Händen hält, hat er auch die Macht über alle Benutzerkonten.

[blackdrake]

Hallo Apollonius.

Zitat von Apollonius:

Darf ich ein paar Verbesserungsvorschläge machen?

Ja, gerne.

Zitat von Apollonius:

Dann macht es auch nichts mehr, wenn SessionID oder SecretKey bekannt werden.

Der "SecretKey" (dieser Begriff wäre dann ja eigentlich durch die neue Technik veraltet) ist ja nichts geheimes mehr. Er darf ja auch im Verlauf des Zielrechners bleiben. Nur in Kombination mit der dazugehörigen SessionID ist er eine Bombe . Die SessionID kommt aber eigentlich nur ans Tageslicht, wenn die Antwort des Initialisierungsrequests mit einem TCP/IP-Sniffer mitgeschnitten wurde. Und im Falle eines Hackangriffs (durch Spionagesoftware auf dem Zielrechner) würde ein Keylogger das Passwort des Account-Managers ja bereits erfassen.

Zitat von Apollonius:

Der Nachteil an diser Methode (bei deiner allerdings auch), ist, dass der Server die Passwörter im Klartext speichern muss.

Falsch. Bei meiner Methode mit dem verschlüsselten SecretKey und der geheimen serverseitigen einmaligen SessionID bekommt das PHP-Script zwar durch das Entschlüsseln kurzzeitig das Klartextpasswort, verfährt dann jedoch weiter wie bei einem HTML-Loginformular. Es wird MD5(Klartextpasswort)=DatenbankMD5Passwort abgeglichen. Mein System speichert die Passwörter in MD5-Form in der Datenbank.

Zitat von Apollonius:

Verschlüssele nicht die Daten, sondern hashe sie.

Leider scheint deine Idee mit dem Hashen nichts für mein System zu sein. Da das Klartext-Passwort nicht bekannt ist, bringt mir die Informationen SecretKey=Hash(SessionID+Klartextpasswort) und SessionID nichts.

Zitat von Apollonius:

(dann muss der Server nicht alles durchprobieren - das ist ineffektiv)

Das mit der Ineffiktivität und der leicht erhöhten Serverlast (jedoch werden ja nur soviele SessionIDs durchprobiert, wie gerade Loginanfragen pro Minute reinkommen sind) sowie die Kollissionen bei dem Entschlüsseln mit dem Delimiter bleiben weiterhin ein Problem.

Gruß
blackdrake

[mkinzler]

MD5 ist ja bereits ein Hash

[blackdrake]

Zitat von mkinzler:

MD5 ist ja bereits ein Hash

Ja, ich verwende den Hash MD5 innerhalb des Serversystems zur Sicherheit.

Apollonius sah ein Sicherheitsrisiko jedoch bei der Datenübergabe bei dem Loginvorgang, da man dort den SecretKey anhand der (eigentlich geheimen) SessionID entschlüsseln könnte. Würde diese Datenübergabe gehashed anstelle von verschlüsselt sein, müsste ich im Gegenzug serverseitig auf Hashs verzichten, was irgendwie sogar schlimmer wäre.

Gruß
blackdrake