php sicherer Login

[mixmastertobsi]

Hallo,

kann mir jemand einen Tipp geben, wie ich am besten einen sicheren Login mit PHP programmiere.

Momentan nutze ich sha1 und erstelle hier eine Kombination von dem User-Password und einem Default-Password, welches ich generiert hatte. Diesen Hash speicher ich dann bei Login als Cookie und bei jedem Seitenaufruf wird geprüft, ob der Hash-Wert, der das Cookie gespeichert ist, passt. Ist das sicher, oder was würdet Ihr empfehlen?

[dedlfix]

Tach!

kann mir jemand einen Tipp geben, wie ich am besten einen sicheren Login mit PHP programmiere.

Es gibt keine absolute Sicherheit. Der erste Punkt bei Sicherheitsmaßnahmen ist, sich zu überlegen, was genau man haben möchte. Wogegen soll es abgesichert sein.

Ist das sicher, oder was würdet Ihr empfehlen?

Was möchtest du erreichen? Ist es für etwas nicht besonders Wichtiges und es kommt nicht darauf an, das die für dieses und kein anderes Projekt verwendeten Passwörter wegkommen? Oder hast du Verantwortung, dass Passwörter fremder Leute für Dritte, die überall dasselbe Passwort verwenden, möglichst unbenutzbar abgelegt werden müssen? Anders gefragt: Reicht ein Lattenzaun mit Vorhängeschloss oder muss es ein Tresor sein?

Eigenbau-Lösungen sollten im Zweifelsfall jedenfalls vermieden werden. Neuere Versionen von PHP haben Passwortfunktionen an Bord und auch eine Dokumentation nebst FAQ zum Umgang mit Passwörtern im Manual. Mit "php password" findet man diese recht einfach.

dedlfix.

[mixmastertobsi]

Ich habe es mal mit password_hash probiert. Das komische ist, dass aber immer ein anderer Hash-Wert berechnet wird, obwohl das Passwort gleich ist.

Ob es ein Tresor sein muss, weiß ich nicht, aber etwas sicher sollte es schon sein.

Also Beispiel senden wir unseren Kunden eMails einen Link mit einem SHA1 Hash - wenn dieser passt, kann der User zum Beispiel eine Bewertung abgeben, für seinen Auftrag.

[dedlfix]

Tach!

Ich habe es mal mit password_hash probiert. Das komische ist, dass aber immer ein anderer Hash-Wert berechnet wird, obwohl das Passwort gleich ist.

Nicht komisch, works as designed and documented. Da ist ein jedes Mal zufällig generierter Salt-Wert dabei. Der führt dann logischerweise dazu, dass da immer ein anderer Wert entsteht. Sollte sich legen, wenn du (nur zum Testen!) mal einen definierten Salt übergibst.

dedlfix.

[mixmastertobsi]

Hallo,

ich habe es nun wie folgt gelöst. Gut so?

Den Password-Hash speicher ich nach erfolgreichen Login in die Session. Bei jedem Seitenaufruf wird das Passwort im Klartext von der DB gelesen und mit dem Hash-Wert geprüft. Welche Parameter sollte ich noch bei password_hash verwenden?

[dedlfix]

Tach!

ich habe es nun wie folgt gelöst. Gut so?

Nein.

Den Password-Hash speicher ich nach erfolgreichen Login in die Session. Bei jedem Seitenaufruf wird das Passwort im Klartext von der DB gelesen und mit dem Hash-Wert geprüft.

In die Datenbank kommt der Hash, der bei der User-Registrierung erzeugt wurde. Vergleichen kannst du das beim nächsten Login eingegebene Passwort mit dem Hash mit der Funktion password_verify(). Anderenfalls kannst du ja gleich Klartext mit Klartext vergleichen, wenn du Klartext speicherst.

dedlfix.

[mixmastertobsi]

Hallo,

aber Klartext speicher ich ja nur in der DB. Wenn der User zum Beispiel sein Kennwort vergessen hatte, kann ich ihm das Kennwort erneut zusenden, ohne dass ein neues erstellt werden muss. Wenn das Kennwort in der Session gespeichert wird, kann es nicht per hack ausgelesen werden? Bei Cookie könnte es ja auch ausgelesen werden...

[dedlfix]

Tach!

aber Klartext speicher ich ja nur in der DB. Wenn der User zum Beispiel sein Kennwort vergessen hatte, kann ich ihm das Kennwort erneut zusenden, ohne dass ein neues erstellt werden muss.

Wenn man das Zusenden möchte, muss man es im Klartext speichern. Aber die Datenbank ist nicht unhackbar. Und es ist besser, eins vom System generieren zu lassen, das man an die hinterlegte Email-Adresse sendet, als Klartext zu verwalten.

dedlfix.

[Gunnar Bittersmann]

@@dedlfix

aber Klartext speicher ich ja nur in der DB. Wenn der User zum Beispiel sein Kennwort vergessen hatte, kann ich ihm das Kennwort erneut zusenden, ohne dass ein neues erstellt werden muss.

Wenn man das Zusenden möchte, muss man es im Klartext speichern. Aber die Datenbank ist nicht unhackbar.

Und selbst wenn die Datenbank nicht das potentielle Risiko wäre, dann ist es die E-Mail. E-Mail ist wie eine Postkarte, nicht wie ein Briefeinschreiben.

LLAP 🖖

[TS]

Hallo und guten Tag,

Wenn man das Zusenden möchte, muss man es im Klartext speichern. Aber die Datenbank ist nicht unhackbar.

Man kann es ja erst im Klartext zusenden lassen und dann trotzdem nur den Prüfstring dafür speichern.

Und selbst wenn die Datenbank nicht das potentielle Risiko wäre, dann ist es die E-Mail. E-Mail ist wie eine Postkarte, nicht wie ein Briefeinschreiben.

Und das sollte dann möglichst auch verschlüsselt, also nicht (nur) über eine verschlüssete Übertragung, geschehen. Das ist leider noch nicht bei jedem Normaluser möglich.

Die Methode des Zusendens an eMailkonten ist auch deshalb umstritten, weil man nicht sicherstellen kann, dass nur der berechtigte Nutzer die Mail lesen kann. Die Provider halten sich nicht alle daran, dass einmal vergebene eMail-Namen nicht wiedervergeben werden dürfen, wenn die Anbieter-Kundenbeziehung beendet wurde. Hier sind alse massenhaft feindliche Übernahmen möglich, auch wenn diese oft nur dem Zufall unterliegen.

Ich hinterlasse deshalb hier nochmal die Frage:
Wie sollte man ein (neues) Zugangspasswort übermitteln?

Grüße
TS

[Auge]

Hallo

Ich hinterlasse deshalb hier nochmal die Frage:
Wie sollte man ein (neues) Zugangspasswort übermitteln?

Garnicht. Wenn ein Benutzer ein neues Passwort anfordert, soll ihm per Email ein Link mit einem Zufallsstring in der URL zugesandt werden, mit dem eine Seite aufgerufen wird, auf der er selbst ein neues Passwort festlegen kann. Dieser Link hat zeitlich begrenzt (z.B. 15 Minuten) gültig zu sein.

Tschö, Auge

[TS]

Hallo und guten Tag,

Ich hinterlasse deshalb hier nochmal die Frage:
Wie sollte man ein (neues) Zugangspasswort übermitteln?

Garnicht. Wenn ein Benutzer ein neues Passwort anfordert, soll ihm per Email ein Link mit einem Zufallsstring in der URL zugesandt werden, mit dem eine Seite aufgerufen wird, auf der er selbst ein neues Passwort festlegen kann. Dieser Link hat zeitlich begrenzt (z.B. 15 Minuten) gültig zu sein.

Das fängt aber nicht den Fall ab, dass das Mailkonto gekapert wurde oder die Mailübertragung mitgelesen wird. Ich komme da einfach zu keiner sinnvollen Lösung. Es fehlt einfach ein Authentifizierungsschritt, also ein "Secret" dafür.

Grüße
TS

[Auge]

Hallo

Ich hinterlasse deshalb hier nochmal die Frage:
Wie sollte man ein (neues) Zugangspasswort übermitteln?

Garnicht. Wenn ein Benutzer ein neues Passwort anfordert, soll ihm per Email ein Link mit einem Zufallsstring in der URL zugesandt werden, mit dem eine Seite aufgerufen wird, auf der er selbst ein neues Passwort festlegen kann. Dieser Link hat zeitlich begrenzt (z.B. 15 Minuten) gültig zu sein.

Das fängt aber nicht den Fall ab, dass das Mailkonto gekapert wurde oder die Mailübertragung mitgelesen wird.

Den Fall kannst du als Seitenanbieter nicht abfangen. Du hast den Übertragungsweg nicht unter Kontrolle. Allerdings war das auch nicht Gegenstand deiner oben stehenden Frage.

Tschö, Auge

[TS]

Hallo und guten Tag,

Garnicht. Wenn ein Benutzer ein neues Passwort anfordert, soll ihm per Email ein Link mit einem Zufallsstring in der URL zugesandt werden, mit dem eine Seite aufgerufen wird, auf der er selbst ein neues Passwort festlegen kann. Dieser Link hat zeitlich begrenzt (z.B. 15 Minuten) gültig zu sein.

Das fängt aber nicht den Fall ab, dass das Mailkonto gekapert wurde oder die Mailübertragung mitgelesen wird.

Den Fall kannst du als Seitenanbieter nicht abfangen. Du hast den Übertragungsweg nicht unter Kontrolle. Allerdings war das auch nicht Gegenstand deiner oben stehenden Frage.

Eine Idee hätte ich noch.
Wenn der eMail-Name für das Passwort nirgends in der Publikation offengelegt wird (und dies der User selber auch nicht tut), und der Username (Anmeldename) in der eMail mit dem Link nirgendwo auftaucht, dann könnte dieser anschließend ein Secret darstellen, also den Gegenschlüssel zum übersandten Token (wenn auch nur ein sehr schwaches). Mit Klick auf den Token-Link käme man dann zu einer https-Webseite, die den Besucher nach seinem Anmeldenamen fragt. Ein Versuch frei, bei Fehler Mülltonne und Warnung ins Log, sonst Abfrge nach neuem gewünschten Passwort.

Und dann kann man immer noch entscheiden, ob der neue Hash derselbe sein darf, wie der alte in der DB, nur um diese andere Idee dazu nicht zu vergessen.

Grüße
TS

[Matthias Apsel]

Hallo Auge,

Erstmal 👍 von mir.

Garnicht.

Gar nicht wird gar nicht zusammengeschrieben. Im Gegensatz zu „zusammengeschrieben“. 😈

Bis demnächst
Matthias

[MudGuard]

Hi,

Gar nicht wird gar nicht zusammengeschrieben. Im Gegensatz zu „zusammengeschrieben“. 😈

wobei es bei letzterem von der Bedeutung abhängt:

"Zwei Autoren haben ein Buch zusammen geschrieben".

cu,
Andreas a/k/a MudGuard

[dedlfix]

Tach!

Gar nicht wird gar nicht zusammengeschrieben. Im Gegensatz zu „zusammengeschrieben“. 😈

wobei es bei letzterem von der Bedeutung abhängt:

"Zwei Autoren haben ein Buch zusammen geschrieben".

Da passt das „zusammen“ sprachlich aber besser hinter die Autoren.

"Zwei Autoren haben zusammen ein Buch geschrieben".

Vielleicht war es aber auch so:

"Zwei Autoren haben zusammen ein Buch zusammengeschrieben".

dedlfix.

[Der Martin]

Moin,

Gar nicht wird gar nicht zusammengeschrieben. Im Gegensatz zu „zusammengeschrieben“. 😈

wobei es bei letzterem von der Bedeutung abhängt:

"Zwei Autoren haben ein Buch zusammen geschrieben".

ja, und mir fällt noch ein bekanntes Beispiel ein, das die Bedeutungsunterschiede zwischen Getrennt- und Zusammenschreibung aufzeigt:

Wir können weinend zusammenbrechen, wir können aber auch weinend zusammen brechen.

Fragt sich nur, was unangenehmer ist ...

So long,
 Martin

[Gunnar Bittersmann]

@@Matthias Apsel

Gar nicht wird gar nicht zusammengeschrieben.

Sondern aus ein an der.

LLAP 🖖

[Kay nicht angemeldet]

Ich hinterlasse deshalb hier nochmal die Frage:
Wie sollte man ein (neues) Zugangspasswort übermitteln?

Gar nicht!

Der Benutzer soll das Passwort selber erzeugen.

Gängige Praxis, der User bekommt einen temporären Link als Einmal-Token, der ihn über eine verschlüsselte Verbindung auf ein Formular führt, wo er ein neues Passwort vergeben kann. Welche weiteren Eingaben hier noch notwendig sind, entscheidet jeder Betreiber selber. Gebräuchlich sind altes Passwort, Kunden-Pin, Anwort auf geheime Frage oder Ähnliches. Auch die zusätzliche Verwendung von PIN, TAN oder Token per SMS sind gebräuchlich. Aber wenn der Keylogger beim User nach Hause telefoniert nützt auch eine sichere Schlüsselerzeugung nichts. Das Fliegendepersonal der Lusthansa hat einen Transponder, um sich einen Einmal-Token zu generieren (Ich glaube der war 5 Minuten gültig), wenn die sich ins System per Internet einloggen wollten.

[Matthias Apsel]

Hallo Kay nicht angemeldet,

Das fliegende Personal der Lusthansa hat einen Transponder,

heißen die immer noch „Tamagotchi“?

Bis demnächst
Matthias

[Kay nicht angemeldet]

Hallo Kay nicht angemeldet,

Das fliegende Personal der Lusthansa hat einen Transponder,

heißen die immer noch „Tamagotchi“?

Das Teil das mein Ex-Nachbar hatte, sah aus wie ein USB-Stick mit Display. Ich kannn nicht sagen wie die Dinger heute intern genannt werden.

[Felix Riesterer]

Lieber mixmastertobsi,

aber Klartext speicher ich ja nur in der DB.

sehr schlecht!

kann ich ihm das Kennwort erneut zusenden, ohne dass ein neues erstellt werden muss.

Sehr schlecht!

Wenn das Kennwort in der Session gespeichert wird, kann es nicht per hack ausgelesen werden?

Wenn Du Dir dabei unsicher bist (siehe Dein Fragezeichen), dann solltest Du das unbedingt(!!) unterlassen!

Bei Cookie könnte es ja auch ausgelesen werden...

Deshalb lässt Du Deine Finger vom Cookie! Wenn Du hier kompetenten Rat haben willst, solltest Du auch beherzigen, was man Dir rät (wie z.B. PHPs eigenen Session-Mechanismus zu verwenden, denn die sind mit ihren Erfahrungen schon sehr viel weiter als Du!).

So. Und warum kein PW im Klartext in der DB? Weil in Systeme immer wieder einmal eingebrochen wird. Dabei gehen dann sensible Daten mit. Besonders schlimm, wenn die Passwörter dann auch zu allem Unsinn noch im Klartext stehen...

Bei der Sachkenntnis, die sich aus Deinen Beschreibungen und Fragen vermuten lässt, darfst Du Dir nicht sicher sein, dass Du in Deiner Software nicht noch andere Schwachstellen wie XSS- oder SQL-Injection-Schwächen hast! Gerade deshalb sind Klartext-Daten wie Passwörter oder Kreditkartennummern in der DB eine sehr gefährliche Sache!

Liebe Grüße,

Felix Riesterer.

[TS]

Hallo und guten Tag,

Deshalb lässt Du Deine Finger vom Cookie! Wenn Du hier kompetenten Rat haben willst, solltest Du auch beherzigen, was man Dir rät (wie z.B. PHPs eigenen Session-Mechanismus zu verwenden, denn die sind mit ihren Erfahrungen schon sehr viel weiter als Du!).

Der benutzt auch ein Cookie, nur eben keines, das nach dem Instanztod des Browserfensters noch beim Client gespeichert bleiben sollte!

Und damit das Cookie oder auch Sessiontoken auf der Reise von und zum Server nicht gelesen werden kann, sollte die Übertragung ja auch vershlüsselt stattfinden.

Die Kenntnis eines Sessiontokens einer "angemeldeten" Session sollte ausßerdem nicht ausreichen, das Passwort eines Users zu ändern. Dazu sollte immer noch das alte Passwort zusätzlich notwenig sein. Während dieses Requestpaket übers Netz läuft, besteht dann selbstverständlich wieder Unsicherheit. Wer dann in einer unverschlüsselten Verbindung an dieser Stelle abfangen, umleiten, verändern und weiterleiten kann, hat gewonnen.

Grüße
TS

[Christian Kruse]

Hallo TS,

Deshalb lässt Du Deine Finger vom Cookie! Wenn Du hier kompetenten Rat haben willst, solltest Du auch beherzigen, was man Dir rät (wie z.B. PHPs eigenen Session-Mechanismus zu verwenden, denn die sind mit ihren Erfahrungen schon sehr viel weiter als Du!).

Der benutzt auch ein Cookie,

Das ist zwar richtig, aber der Cookie enthält nur die Session-ID.

nur eben keines, das nach dem Instanztod des Browserfensters noch beim Client gespeichert bleiben sollte!

Das kannst du nicht beeinflussen. Du kannst nur eine Empfehlung abgeben und ansonsten davon ausgehen, dass derjenige, der den Cookie hat, tatsächlich der ist, für den er sich ausgibt.

LG,
CK

[TS]

Hallo und guten Morgen,

Der benutzt auch ein Cookie,

Das ist zwar richtig, aber der Cookie enthält nur die Session-ID.

Ja und? Damit kann jeder, der sich mit Sessionsystemen auskennt auch in fremde Daten Einblick nehmen oder diese sogar verändern. Alles das, wad ein Berechtigter mit dem System machen dürfte, kann ein Unberechtigter dann auch.

War immer ein nettes Spiel bei einer Single-Seite, bei ein Teilnehmer mittels Javascript und CSS in def Lage war, die Cookies seiner Profilbesucher abzufischen...

Das kannst du nicht beeinflussen. Du kannst nur eine Empfehlung abgeben und ansonsten davon ausgehen, dass derjenige, der den Cookie hat, tatsächlich der ist, für den er sich ausgibt.

Darum steht da auch "sollte".

Grüße
TS

[Christian Kruse]

Hallo TS,

Der benutzt auch ein Cookie,

Das ist zwar richtig, aber der Cookie enthält nur die Session-ID.

Ja und? Damit kann jeder, der sich mit Sessionsystemen auskennt auch in fremde Daten Einblick nehmen oder diese sogar verändern.

Ja, aber keine Daten in der Session manipulieren. Und darum ging es mir.

LG,
CK

[Christian Kruse]

Hallo Felix,

Bei der Sachkenntnis, die sich aus Deinen Beschreibungen und Fragen vermuten lässt, darfst Du Dir nicht sicher sein, dass Du in Deiner Software nicht noch andere Schwachstellen wie XSS- oder SQL-Injection-Schwächen hast!

äh, was hat das mit Sachkenntnis zu tun? In dieser Sicherheit sollte man sich nie wiegen, denn das kann schneller passieren als man denkt.

LG,
CK

[TS]

Hallo und guten Tag,

aber Klartext speicher ich ja nur in der DB. Wenn der User zum Beispiel sein Kennwort vergessen hatte, kann ich ihm das Kennwort erneut zusenden, ohne dass ein neues erstellt werden muss.

So ähnlich hatte sich das Yahoo wohl 2014 auch gedacht :-(

Wenn das Kennwort in der Session gespeichert wird, kann es nicht per hack ausgelesen werden? Bei Cookie könnte es ja auch ausgelesen werden...

Wenn die Sessiondatei nicht in einem shared Memorybereich liegt, wird es schwer, das Passwort aus der Session zu holen. Die Sessiondatei sollte außerdem nur persistent, aber nicht permanent (also nur "temprorärpermanent") sein. Da wäre es für einen Angreifer zu teuer, alle Sessiondateien zu lesen, um an Passworte zu gelangen. Aber um auch diese Möglichkeit noch zu verhindern, gehört das Passwort auch nicht in die Sessiondatei! Du benötigst es nur einmal, um es mit dem gehashten Wert des Passwortes aus der Datenbank zu vergleichen und dann ein Session-Token zu erzeugen.

Grüße
TS

[mixmastertobsi]

OK, also verstanden.

Aber wenn ich das Passwort weiter in der DB lassen möchte, macht es doch Sinn, wenigstens in Session nicht das Passwort in Klartext stehen zu haben, weil wenn ich Klartext mit Klartext vergleichen würde, geht es zwar schneller, aber ich hätte zwei Schwachstellen - oder?

[TS]

Hallo und guten Tag,

OK, also verstanden.

Aber wenn ich das Passwort weiter in der DB lassen möchte, macht es doch Sinn, wenigstens in Session nicht das Passwort in Klartext stehen zu haben, weil wenn ich Klartext mit Klartext vergleichen würde, geht es zwar schneller, aber ich hätte zwei Schwachstellen - oder?

Jein gequält klingend

Die schlimmere Schwachstelle ist die Datenbank. Dort könnte ja im Schadensfall nicht ein einziges Passwort, sondern 500 Millionen (-> Yahoo) abgegriffen werden.

Um von der Paranoia zu einer soliden Lösung zurückzufinden, mach Dir einfach mal Gedanken darüber, wer auf dem Host (also nicht nur dem http-Server) an Dateien herankommen könnte und wie. In Shared-Hosting-Umgebungen hat(te) man häufig alle Sessiondateien in einem einzigen Verzeichnis liegen (vorzugsweise /tmp oder einem Unterverzeichnis davon), in dem jeder Hosting-Teilnehmer mit seinen Skripten lesen konnte. Da konnte man dann leicht Sessions entführen. Hoster, die das auch heute noch so machen, sollten geächtet werden :-O

Grüße
TS

[Sandra U.]

Aber wenn ich das Passwort weiter in der DB lassen möchte

Warum um alles in der Welt ist es so wichtig, das Passwort im Klartext zu speichern? Niemand, wirklich niemand braucht sowas. Hat jemand sein Passwort vergessen, dann ist es vollkommen egal, ob du ihm das alte schickst oder ein neues. Vergessen hat er das alte sowieso und falls es ihm später wieder einfällt und er so verliebt ist, kann er mit dem neuen sein altes wunderbar wiederherstellen.

Überhaupt: Passwörter verschickt man generell nicht. Niemals. Falls etwas vergessen wurde, dann einen einmaligen, fünf Minuten gültigen Zugangscode an die hinterlegte E-Mail-Adresse, mit dem der Benutzer ein neues Passwort eingeben kann (bzw. muss).

Genau genommen gehen dich die Passwörter der Benutzer gar nichts an und entsprechend solltest du sie behandeln.

Ich bin etwas irritiert, dass du die Frage mit "Sicherheit" eröffnest, aber die grundlegendsten, in langen (leidvollen) Jahren erlernte, bewährte Regeln ignorierst.

Die schlimmere Schwachstelle ist die Datenbank. Dort könnte ja im Schadensfall nicht ein einziges Passwort, sondern 500 Millionen (-> Yahoo) abgegriffen werden.

Bevor jetzt der Hinweis "Sind ja nur meine drei Kunden" kommt: Ein Großteil benutzt überwiegend dasselbe Passwort für viele Dienste. Das Problem auch bei der Yahoo-Nummer ist gar nicht einmal der Umfang, sondern dass mit diesen Daten etliche andere Dienste angegriffen werden können.

[Matthias Apsel]

Hallo Sandra U.,

Hat jemand sein Passwort vergessen, dann ist es vollkommen egal, ob du ihm das alte schickst oder ein neues. Vergessen hat er das alte sowieso und falls es ihm später wieder einfällt und er so verliebt ist, kann er mit dem neuen sein altes wunderbar wiederherstellen.

Es gibt Dienste, die untersagen, bereits verwendete Passwörter erneut zu benutzen.

Bis demnächst
Matthias

[Der Martin]

Hallo,

[...] kann er mit dem neuen sein altes wunderbar wiederherstellen.

Es gibt Dienste, die untersagen, bereits verwendete Passwörter erneut zu benutzen.

ja, aber zumindest soweit ich das bisher kennengelernt habe, wird nur mit dem unmittelbar davor gültigen Passwort verglichen, so dass die Folge A, B, A, B zwar nicht möglich ist, wohl aber A, B, C, A, B, ...

Das ist natürlich keine allgemeingültige Aussage, sondern nur ein Erfahrungswert.

Manche Dienste verlangen auch, dass man das Passwort regelmäßig (z.B. alle drei Monate) ändert; in solchen Fällen verwende ich normalerweise ein gleichbleibendes Basis-Passwort und hänge ein monats- oder quartalsweise hochzählendes Suffix an.

So long,
 Martin

[TS]

Hallo und guten Morgen,

Manche Dienste verlangen auch, dass man das Passwort regelmäßig (z.B. alle drei Monate) ändert; in solchen Fällen verwende ich normalerweise ein gleichbleibendes Basis-Passwort und hänge ein monats- oder quartalsweise hochzählendes Suffix an.

Gut, dass wir das jetzt wissen ;-)

Grüße
TS

[Christian Kruse]

Hallo Matthias,

Es gibt Dienste, die untersagen, bereits verwendete Passwörter erneut zu benutzen.

Genau so bescheuert.

Einerseits musst du dafür eine Passwort-Historie speichern (sehr schlecht), und andererseits geht dich das nichts an.

LG,
CK

[dedlfix]

Tach!

Es gibt Dienste, die untersagen, bereits verwendete Passwörter erneut zu benutzen.

Ist in der Aussage das "untersagen" als AGB-Klausel "nimm keine Passwörter, die du woanders nimmst" gemeint oder als "unterbinden innerhalb des Systems"?

Einerseits musst du dafür eine Passwort-Historie speichern (sehr schlecht), und andererseits geht dich das nichts an.

Ist eine Historie der gehashten und gesalzten Passwörter immer noch "sehr schlecht"?

dedlfix.

[Christian Kruse]

Hallo dedlfix,

Einerseits musst du dafür eine Passwort-Historie speichern (sehr schlecht), und andererseits geht dich das nichts an.

Ist eine Historie der gehashten und gesalzten Passwörter immer noch "sehr schlecht"?

Klar, unnötiger Angriffsvektor und es widerspricht der Datensparsamkeit.

LG,
CK

[Christian Kruse]

Hallo Christian,

Einerseits musst du dafür eine Passwort-Historie speichern (sehr schlecht), und andererseits geht dich das nichts an.

Ist eine Historie der gehashten und gesalzten Passwörter immer noch "sehr schlecht"?

Klar, unnötiger Angriffsvektor und es widerspricht der Datensparsamkeit.

Um das auszuführen: wenn ich eine Passwort-Historie speichere, dann hat der potentielle Angreifer gleich n Passwörter, die er an anderen Accounts ausprobieren kann, statt nur einem. Oder er sieht sogar ein Muster, wie ich meine Passwörter generiere.

Auch wenn ich die Passwörter nicht im Klartext ablege, muss ich bei meinen Überlegungen davon ausgehen, dass der Angreifer in der Lage sein könnte, das Klartext-Passwort irgendwie doch wiederherzustellen. Sicherheitsbewusstes Denken ist oft äuquivalent mit paranoidem Denken.

LG,
CK

[Matthias Apsel]

Hallo dedlfix,

Ist in der Aussage das "untersagen" als AGB-Klausel "nimm keine Passwörter, die du woanders nimmst" gemeint oder als "unterbinden innerhalb des Systems"?

Konkret: Ebay und das System lässt es nicht zu.

Ich habe allerdings nicht getestet, ob nur das letzte PW gespeichert wird, @Der Martin. Die Fehlermeldung las sich nicht so.

Einerseits musst du dafür eine Passwort-Historie speichern (sehr schlecht), und andererseits geht dich das nichts an.

Ist eine Historie der gehashten und gesalzten Passwörter immer noch "sehr schlecht"?

Und es könnte sogar sein, dass verschiedene Passwörter denselben Hash haben. Das wird umso wahrscheinlicher je mehr die Passwörter zufällig sind.

Bis demnächst
Matthias

[TS]

Hallo und guten Morgen,

Ich habe allerdings nicht getestet, ob nur das letzte PW gespeichert wird, @Der Martin. Die Fehlermeldung las sich nicht so.

Der Prüfcode des letzten sollte bereits gespeichert sein. Da greift das Scheinargument "Datensparsamkeit" nicht.

Und es könnte sogar sein, dass verschiedene Passwörter denselben Hash haben. Das wird umso wahrscheinlicher je mehr die Passwörter zufällig sind.

Könntest Du bitte die Wahrscheinlichkeit angeben, die für den Fall gilt:

• Hash mit 32 Digits à 62 Zeichen
• Passwort 8 bis 16 Digits à 72 Zeichen oder mehr

?

Grüße
TS

[Christian Kruse]

Hallo TS,

Ich habe allerdings nicht getestet, ob nur das letzte PW gespeichert wird, @Der Martin. Die Fehlermeldung las sich nicht so.

Der Prüfcode des letzten sollte bereits gespeichert sein. Da greift das Scheinargument "Datensparsamkeit" nicht.

Datensparsamkeit ein Scheinargument zu nennen ist schon eine ziemliche Beleidigung. Wenn du nicht mit mir übereinstimmst, bist du herzlich eingeladen mich von deiner Ansicht zu überzeugen, aber bitte bleibe dabei sachlich.

Warum Datensparsamkeit hier ein Sicherheitsfeature ist, habe ich ausgeführt.

LG,
CK

[TS]

Hallo und guten Morgen,

Datensparsamkeit ein Scheinargument zu nennen ist schon eine ziemliche Beleidigung. Wenn du nicht mit mir übereinstimmst, bist du herzlich eingeladen mich von deiner Ansicht zu überzeugen, aber bitte bleibe dabei sachlich.

Warum Datensparsamkeit hier ein Sicherheitsfeature ist, habe ich ausgeführt.

Ok anders herum erklärt: Datensparsamkeit ist hier nur ein Scheinargument, da die benötigten Daten bereis gespeichert sind.

Beruhige dich also bitte!

Grüße
TS

[Christian Kruse]

Hallo TS,

Datensparsamkeit ein Scheinargument zu nennen ist schon eine ziemliche Beleidigung. Wenn du nicht mit mir übereinstimmst, bist du herzlich eingeladen mich von deiner Ansicht zu überzeugen, aber bitte bleibe dabei sachlich.

Warum Datensparsamkeit hier ein Sicherheitsfeature ist, habe ich ausgeführt.

Ok anders herum erklärt: Datensparsamkeit ist hier nur ein Scheinargument, da die benötigten Daten bereis gespeichert sind.

Es ging in der Nachfrage ganz explizit um das anlegen einer Passwort-Historie. Wo sind die benötigten Daten denn bitte bereits vorhanden?

Beruhige dich also bitte!

Ich bin durchaus ruhig, ich habe dich nur darauf aufmerksam gemacht, dass dein Stil beleidigend für mich war. Das heisst nicht, dass ich wütend bin oder aus der Haut fahre – wäre ich das gewesen, hätte ich nichts mehr dazu gesagt und den Beitrag ignoriert. Tatsächlich habe ich eher gedacht, dass du das anders gemeint hast als es hier angekommen ist.

LG,
CK

[TS]

Hallo und guten Morgen,

Datensparsamkeit ein Scheinargument zu nennen ist schon eine ziemliche Beleidigung. Wenn du nicht mit mir übereinstimmst, bist du herzlich eingeladen mich von deiner Ansicht zu überzeugen, aber bitte bleibe dabei sachlich.

Es ging in der Nachfrage ganz explizit um das anlegen einer Passwort-Historie. Wo sind die benötigten Daten denn bitte bereits vorhanden?

Bei meiner Aussage ging es eindeutig um das letzte gespeicherte Passwort bzw. dessen Hashcode!

Anderes Thema:Mich wundert ein wenig, woraus Du in Diskussionen immer persönliche Beleidigungen konstruierst. Lass das bitte mal sein!

Grüße
TS

[Christian Kruse]

Hallo TS,

Datensparsamkeit ein Scheinargument zu nennen ist schon eine ziemliche Beleidigung. Wenn du nicht mit mir übereinstimmst, bist du herzlich eingeladen mich von deiner Ansicht zu überzeugen, aber bitte bleibe dabei sachlich.

Es ging in der Nachfrage ganz explizit um das anlegen einer Passwort-Historie. Wo sind die benötigten Daten denn bitte bereits vorhanden?

Bei meiner Aussage ging es eindeutig um dad letzte gespeicherte Passwort bzw. den Hashcode davon!

Du hast dich offensichtlich auf mein Posting bezogen, in dem ich Datensparsamkeit als Argument gebracht habe.

LG,
CK

[Der Martin]

Moin,

Warum Datensparsamkeit hier ein Sicherheitsfeature ist, habe ich ausgeführt.

davon abgesehen ist Datensparsamkeit auch eine der Grundforderungen des Datenschutzgesetzes. Sie lautet sinngemäß, dass keine Daten erfasst und gespeichert werden sollten, die für die Erfüllung der vorgesehenen Aufgabe nicht notwendig sind.

Was dabei notwendig ist, muss man im jeweiligen Anwendungsfall abwägen, das Gesetz ist an der Stelle (bewusst?) schwammig.

So long,
 Martin

[Christian Kruse]

Hallo Matthias,

Einerseits musst du dafür eine Passwort-Historie speichern (sehr schlecht), und andererseits geht dich das nichts an.

Ist eine Historie der gehashten und gesalzten Passwörter immer noch "sehr schlecht"?

Und es könnte sogar sein, dass verschiedene Passwörter denselben Hash haben. Das wird umso wahrscheinlicher je mehr die Passwörter zufällig sind.

Nein, das ist aufgrund der modernen Hashing-Algorithmen de facto ausgeschlossen.

LG,
CK

[Christian Kruse]

Hallo Christian,

Einerseits musst du dafür eine Passwort-Historie speichern (sehr schlecht), und andererseits geht dich das nichts an.

Ist eine Historie der gehashten und gesalzten Passwörter immer noch "sehr schlecht"?

Und es könnte sogar sein, dass verschiedene Passwörter denselben Hash haben. Das wird umso wahrscheinlicher je mehr die Passwörter zufällig sind.

Nein, das ist aufgrund der modernen Hashing-Algorithmen de facto ausgeschlossen.

Mir ist nicht klar, warum man das anders sehen sollte. Bei bcrypt (Default-Verfahren für password_hash) wird ein 192-bit-Hash erzeugt, dessen Key abgeleitet wird von dem Passwort. Das ist kein traditionelles Salting/Hashing mehr. Der Key (man könnte ihn auch Salt nennen) ist 128 bit lang. Die Wahrscheinlichkeit, eine Kollision zu erzeugen, also τ1,τ2=bcrypt(pw,cost), Pr[τ1=τ2] liegt also bei $$2^{64}$$ - eine Kollision innerhalb der Passwort-Historie ist de facto ausgeschlossen.

Edit: nicht die Wahrscheinlichkeit ist bei $$2^{64}$$, sondern man erhält durchschnittlich bei $$2^{64}$$ Hashing-Vorgängen eine Kollision.

Edit 2: Der cost-Parameter kommt aus dem bcrypt-Algorithmus, der vorsieht, dass ein Passwort nicht nur einmal diesen Algorithmus durchläuft, sondern n mal, um Sidechannel-Attacken vorzubeugen.

LG,
CK

[Google weiß alles]

Bei bcrypt (Default-Verfahren für password_hash)

DERZEIT das Default-Verfahren. Empfehlenswert ist es, nach dem Feststellen, dass ein korrektes Passwort übergeben wurde

password_verify ( $password , $hash )

mit

password_needs_rehash ( $hash , PASSWORD_DEFAULT )

zu prüfen, ob der der AKTUELLE Algorithmus benutzt wurde und, wenn nicht, mit

password_hash ( $password )

das übergebene Passwort neu gehascht zu speichern. Grund dafür: Der Algorithmus könnte ja mal verbessert werden. Dafür muss man aber auch sein PHP einem Update unterziehen...

Im Härtesten aller Fälle MÜSSEN die User sogar angeschrieben und zu einem Login aufgefordert werden und nach einer Wartefrist alle Accounts, bei denen das (und damit das Update) nicht erfolgte, zu LÖSCHEN.

@TS

Speichere unter keinen Umständen die Passwörter im Klartext. Nicht in der Session, nicht in der Datenbank, nirgendwo. Nur im Arbeitsspeicher (beim Login) ist das unumgänglich. Bau eine Passwort-Vergessen-Funktion ein. Es ist überhaupt kein Problem, erst eine Zufallszahl aus 6-16 Zeichen zu ermitteln, dann aus einem Wertebereich s mal zufällig ein Zeichen auszuwählen und daraus also einen String von 6 bis 16 Zeichen zu bauen, diesen mitsamt Verfallszeitunkt gehascht in der DB als temporären Passwort-Hash abzulegen und dem Benutzer einen Link zu senden, wo er sich einloggen und sein Passwort selbst neu setzen kann.

Eine Passwort-Ändern Funktion muss sowieso vorhanden sein...

Im Falle des Erinnerns (also bei einem erfolgreichen Login mit dem alten Passwort) KANN man dann das temporäre Passwort auch vernichten. Muss man aber nicht, man kann ja auch das "vergessene" Passwort löschen und den Benutzer bei Übermittlung des temporären Passwortes klar sagen, dass das alte Login nicht mehr funktioniert.

Wenn das Passort freilich an einem Counter (Schalter vor dem Admin-Stübchen) vergeben wird kann das Verfahren abgewandelt werden.

[TS]

Hallo und guten Tag,

[...]

@TS

[...]

Danke für Eure Anregungen. Ich sammele die alle mal und versuche daraus einen Artikel fürs Wiki zu machen. Damit ist mein "Zettel" jetzt aber erstmal voll genug ;-)

Grüße
TS

[Der Martin]

Hallo,

Konkret: Ebay und das System lässt es nicht zu.

Ich habe allerdings nicht getestet, ob nur das letzte PW gespeichert wird, @Der Martin. Die Fehlermeldung las sich nicht so.

über ebay kann ich in dem Zusammenhang nichts sagen. Ich weiß aber aus eigener Erfahrung, dass GMX ein rotierendes System mit drei unterschiedlichen Passwörtern akzeptiert, und ein Windows-Server bei der Anmeldung an der Domäne ebenfalls (wobei das im letzteren Fall vermutlich vom Admin nahezu beliebig konfigurierbar ist).

Und es könnte sogar sein, dass verschiedene Passwörter denselben Hash haben. Das wird umso wahrscheinlicher je mehr die Passwörter zufällig sind.

Von Christians Einwand abgesehen: Warum sollte die Wahrscheinlichkeit gleicher Hashes bei zufälligen Passwörtern größer sein als bei systematischen?

Ciao,
 Martin

[Matthias Apsel]

Hallo Der Martin,

Und es könnte sogar sein, dass verschiedene Passwörter denselben Hash haben. Das wird umso wahrscheinlicher je mehr die Passwörter zufällig sind.

Warum sollte die Wahrscheinlichkeit gleicher Hashes bei zufälligen Passwörtern größer sein als bei systematischen?

Wir reden dann jetzt offensichtlich von früher.

Weil die Hashfunktionen so gebaut sind, dass sie bei ähnlichen Passwörtern garantiert unterschiedliche Hashes erzeugen. Nimm als einfachstes Beispiel das Modulo-11 Verfahren. Kommt es zu genau einem Zahlendreher sind die Prüfziffern garantiert verschieden.

Bis demnächst
Matthias

[Christian Kruse]

Hallo mixmastertobsi,

Aber wenn ich das Passwort weiter in der DB lassen möchte, macht es doch Sinn, wenigstens in Session nicht das Passwort in Klartext stehen zu haben, weil wenn ich Klartext mit Klartext vergleichen würde, geht es zwar schneller, aber ich hätte zwei Schwachstellen - oder?

Pack das Passwort gar nicht in die Session. Gar nicht. Du brauchst es nicht.

PHP-Sessions sind serverseitig, wenn jemand dir eine Session unterschiebt, dann ist der Server kompromittiert und er könnte genau so gut direkt an deine Datenbank. Wenn jemand eine Session klaut (Sessios Hijacking, google ruhig mal danach), dann hilft dir das Passwort in der Session auch nichts, weil er ja die Session geklaut hat.

Der Sicherheitsgewinn ist also gleich null. Pack die User-ID in die Session und das wars.

Und hashe die Passwörter in der Datenbank, for fucks sake. Dass man das im Jahre 2016 immer noch sagen muss ist traurig.

LG,
CK

[andaris]

Hallo!

Fürs Hashen von Passwörtern ist SHA1 nicht gut geeignet da es zu schnell berechenbar und somit anfällig für Brute-Force ist. Verwende am besten die PHP 5.5+ Password Hash API: http://de.php.net/password_hash bzw http://de2.php.net/manual/de/function.password-verify.php.

Passworthashes sollten nur auf dem Server liegen und nicht über Cookies oder anderweitig durch die Gegend geschickt werden - verwende lieber das reguläre Session-System von PHP (http://de2.php.net/manual/en/book.session.php). Damit wird nach erfolgreichem Login auf dem Client ein Cookie mit einem zufälligen Sessiontoken abgelegt, dieses dient anschließend zur Authentifizierung.

[Sandra U.]

kann mir jemand einen Tipp geben, wie ich am besten einen sicheren Login mit PHP programmiere.

Eine Session-Funktion wird bei PHP schon mitgeliefert. Warum willst du das Rad neu erfinden?

Momentan nutze ich sha1 und erstelle hier eine Kombination von dem User-Password und einem Default-Password, welches ich generiert hatte. Diesen Hash speicher ich dann bei Login als Cookie und bei jedem Seitenaufruf wird geprüft, ob der Hash-Wert, der das Cookie gespeichert ist, passt. Ist das sicher, oder was würdet Ihr empfehlen?

Üblicherweise besteht die Sitzungskennung aus einer langen Kette zufälliger Zeichen, und zwar mit Grund:

Zum einen ist das theoretisch (!) sicherer als dein Weg, weil aus so einer Zufallskennung keine Rückschlüsse mehr auf andere Daten gezogen werden können – es existieren ja schlichtweg keine anderen Daten.

Vor allem aber kann, zweitens, jeder, der an der Verbindung mitlauscht, deine Bastelkennung abfangen und sich fürdahin bis zur Änderung des Passworts (das bedeutet in aller Regel: bis in alle Ewigkeit) nach Belieben anmelden. Insofern wäre es beinahe wurscht, ob du das Passwort selbst überträgst oder, wie jetzt, eine Prüfsumme desselben. Habe ich eines von beiden, bin ich drin, heute, morgen, in zwei Jahren.

Jede Session, zu der man sich anmelden muss, muss auch geschlossen werden können. Bei dir geht das nicht, weil die Kennung statisch ist.

Also Beispiel senden wir unseren Kunden eMails einen Link mit einem SHA1-Hash - wenn dieser passt, kann der User zum Beispiel eine Bewertung abgeben, für seinen Auftrag.

Die Hascherei scheint es dir angetan zu haben. Drogen haben aber noch jeden betrogen, und du bekommst keine Sicherheit, nur, weil du irgendwo "SHA1" (oder dergleichen) draufschreibst.

Verwendest du für diese Bewertungsfunktion womöglich auch noch das eingangs beschriebene Passwort seines Kundenkontos? Toll. Dann brauche ich nicht einmal an der HTTP-Leitung lauschen, ich kann auch sein E-Mail-Postfach durchschauen, um in seinem Konto rumzufuhrwerken

Soll der Kunde ohne Anmeldung einen Auftrag bewerten können, dann schicke ihm einen Zufallswert, der entsprechend mit Auftragsnummer verknüpft in deiner Datenbank gespeichert und mit einem Verfallsdatum versehen ist. Mit diesem Wert kann er dann ohne weiteren Umstand seine Meinung abgeben, und zwar nur seine Meinung abgeben, nichts anderes, und dies auch nicht bis zum Sankt Nimmerleinstag, sondern bis in drei Monaten (zum Beispiel, je nachdem, was das für Aufträge sind) und gegebenenfalls vielleicht auch nur einmal bzw. nur hinzufügend zu vorigen Bewertungen des Auftrags.

[TS]

Hallo und guten Tag,

[...]

Sehr schöne Antwort. Muss ich mal meinen "Daumen hoch" für geben ;-) [1]

Fehlt jetzt nur noch, dass die Datenübermittlung ohnehin verschlüsselt stattfinden sollte! Dann lässt sich auch das Token nicht mehr einfach entführen.

Die Verschlüsselung reduziert die Eindringlingsmöglichkeiten auf wirklich professionelle Lauscher (Schwerkriminelle, Regierungen und deren Beauftragte ...), die beim Zertifikatsvergleich schnell genug ein falsches liefern können und wirklich den gesamten Datenverkehr mitlesen können (-> Routing-Kontrolle).

Grüße
TS

[1] Da "Daumen hoch" in unterschiedlichen Kulturkreisen auch andere Bedeutungen haben kann, sollten wir uns für SelfHTML mal ein eigenes Symbol für das Flag "gefällt mir" ausdenken.

[Matthias Scharwies]

Servus!

Hallo und guten Tag,

[...]

Sehr schöne Antwort. Muss ich mal meinen "Daumen hoch" für geben ;-) [1]

[1] Da "Daumen hoch" in unterschiedlichen Kulturkreisen auch andere Bedeutungen haben kann, sollten wir uns für SelfHTML mal ein eigenes Symbol für das Flag "gefällt mir" ausdenken.

evtl +1 ?

Herzliche Grüße

Matthias Scharwies

[TS]

Hallo und guten Tag,

[1] Da "Daumen hoch" in unterschiedlichen Kulturkreisen auch andere Bedeutungen haben kann, sollten wir uns für SelfHTML mal ein eigenes Symbol für das Flag "gefällt mir" ausdenken.

evtl +1 ?

Witzbold :-)

Grüße
TS

[Christian Kruse]

Hallo TS,

[1] Da "Daumen hoch" in unterschiedlichen Kulturkreisen auch andere Bedeutungen haben kann, sollten wir uns für SelfHTML mal ein eigenes Symbol für das Flag "gefällt mir" ausdenken.

Du meinst das grosse Plus, das an jedem Beitrag gleich zwei mal hängt?

LG,
CK

[Auge]

Hallo

[1] Da "Daumen hoch" in unterschiedlichen Kulturkreisen auch andere Bedeutungen haben kann, sollten wir uns für SelfHTML mal ein eigenes Symbol für das Flag "gefällt mir" ausdenken.

Du meinst das grosse Plus, das an jedem Beitrag gleich zwei mal hängt?

Das ist aber kaputt. Ich wollte diesen Beitrag schon allein wegen des letzen Absatzes (mindestens) zweimal plussen, schließlich gibt es ja, wie du selbst sagst, zwei Plusse. Das funktioniert aber leider nicht. Bugreport? ;-)

Tschö, Auge

[Christian Kruse]

Hallo Auge,

[1] Da "Daumen hoch" in unterschiedlichen Kulturkreisen auch andere Bedeutungen haben kann, sollten wir uns für SelfHTML mal ein eigenes Symbol für das Flag "gefällt mir" ausdenken.

Du meinst das grosse Plus, das an jedem Beitrag gleich zwei mal hängt?

Das ist aber kaputt. Ich wollte diesen Beitrag schon allein wegen des letzen Absatzes (mindestens) zweimal plussen, schließlich gibt es ja, wie du selbst sagst, zwei Plusse. Das funktioniert aber leider nicht. Bugreport? ;-)

Works as designed, zwei Stimmen haben nur Pro-Mitglieder aus dem Inner Circle ;-)

LG,
CK

[Auge]

Hallo

Das ist aber kaputt.

Works as designed, zwei Stimmen haben nur Pro-Mitglieder aus dem Inner Circle ;-)

Da isser wieder! Ich wusste, da war noch 'was.

Tschö, Auge

[Gunnar Bittersmann]

@@Christian Kruse

[1] Da "Daumen hoch" in unterschiedlichen Kulturkreisen auch andere Bedeutungen haben kann, sollten wir uns für SelfHTML mal ein eigenes Symbol für das Flag "gefällt mir" ausdenken.

Du meinst das grosse Plus, das an jedem Beitrag gleich zwei mal hängt?

Das ist aber kaputt. Ich wollte diesen Beitrag schon allein wegen des letzen Absatzes (mindestens) zweimal plussen, schließlich gibt es ja, wie du selbst sagst, zwei Plusse. Das funktioniert aber leider nicht. Bugreport? ;-)

Works as designed, zwei Stimmen haben nur Pro-Mitglieder aus dem Inner Circle ;-)

Dann sollten aber nur die Pro-Mitglieder aus dem Inner Circle die zwei Plusse zu sehen bekommen. Nicht das UI mit Dingern überladen, die keine Funktion haben. Bugreport? ;-)

LLAP 🖖

[Auge]

Hallo

@Christian Kruse

Ich wollte diesen Beitrag … zweimal plussen …

Nur damit klar ist, um welchen Beitrag es geht – ich hatte den Link vergessen und mein Beitrag („dieser Beitrag“) ist es nicht –, es geht speziell um den letzten Absatz dieses Beitrags.

Tschö, Auge