nicht angemeldet
MudGuard
Rolf B
Rolf B
Der Martin
Rolf B
Auge
encoder
Rolf B
Der Martin
Gunnar Bittersmann
Hallo,
ich muss einmal einen token generieren, den ich an eine Email anhänge. Er wird zugleich in einer db gespeichert, und dort dann abgeglichen.
Das mache ich so:
$randomString = bin2hex(random_bytes(16));
$token = password_hash($randomString, PASSWORD_DEFAULT);
Anschließend soll ein temporäres Passwort generiert werden, was ich so mache:
function generateSecurePassword($length = 12) {
// Definiere die möglichen Zeichenkategorien
$lowercase = 'abcdefghijklmnopqrstuvwxyz';
$uppercase = 'ABCDEFGHIJKLMNOPQRSTUVWXYZ';
$numbers = '0123456789';
$special = '!@#$%^&()-_=+[]{}|;:?';
// Sicherstellen, dass die Länge des Passworts mindestens 6 Zeichen beträgt
if ($length < 6) {
throw new Exception('Die Länge des Passworts muss mindestens 6 Zeichen betragen.');
}
// Generiere mindestens 2 Großbuchstaben, 2 Sonderzeichen und 2 Ziffern
$uppercase_part = substr(str_shuffle($uppercase), 0, 2);
$special_part = substr(str_shuffle($special), 0, 2);
$numbers_part = substr(str_shuffle($numbers), 0, 2);
$lowercase_part = substr(str_shuffle($lowercase), 0, $length - 6);
// Kombiniere die Teile und stelle sicher, dass die Sonderzeichen nicht am Anfang oder Ende sind
$password_core = $lowercase_part . $uppercase_part . $numbers_part;
$middle_part = str_shuffle($special_part); // Mische Sonderzeichen für die Mitte
// Erstelle das Passwort ohne Sonderzeichen am Anfang und Ende
$password = str_shuffle($password_core);
$password = substr($password, 0, $length - strlen($middle_part)) . $middle_part;
// Mische das gesamte Passwort
$password = str_shuffle($password);
// Schneide auf die gewünschte Länge
return substr($password, 0, $length);
}
$newPass = generateSecurePassword(15);
Gibt es dabei etwas auszusetzen oder geht es besser oder sinnvoller?
Zumindest, dass kein Sonderzeichen am Anfang und Ende des Passworts stehen soll, klappt so schonmal nicht.
Gruß, Bernd
Hi,
> $middle_part = str_shuffle($special_part); // Mische Sonderzeichen >
> // Erstelle das Passwort ohne Sonderzeichen am Anfang und Ende
> $password = str_shuffle($password_core);
> $password = substr($password, 0, $length - strlen($middle_part)) . $middle_part;
jetzt stehen die "Sonderzeichen" (die sich in $middle_part befinden), am Ende.
// Mische das gesamte Passwort $password = str_shuffle($password);
und jetzt mischst Du das ganze durch. Also zufällige Reihenfolge. Und damit können die "Sonderzeichen" auch am Anfang oder Ende auftauchen.
// Schneide auf die gewünschte Länge return substr($password, 0, $length);
die Länge müßte schon vorher richtig gewesen sein (siehe die Zeile, wo Du den $middle_part anhängst. Das substr müßte also überflüssig sein.
Gibt es dabei etwas auszusetzen oder geht es besser oder sinnvoller?
Warum sollte das Paßwort keines der "Sonderzeichen" am Anfang oder Ende haben?
Du mischst die einzelnen Zeichenkategorien durch, und entnimmst dann einen Teilstring. D.h. es kann kein Zeichen doppelt vorkommen. Das ist eine ziemliche Einschränkung der Zufälligkeit des Gesamtkonstrukts.
Kann sein, daß es noch mehr Probleme gibt, aber mehr Analyse mag ich jetzt nicht machen.
cu,
Andreas a/k/a MudGuard
Hallo MudGuard,
Kann sein, daß es noch mehr Probleme gibt, aber mehr Analyse mag ich jetzt nicht machen.
Danke für Deine Mühe.
Stimmt, da war ein böser Codedreher drin.
Warum Sonderzeichen nicht am Anfang oder Ende?
Um den user nicht zu verwirren. Es gibt User, die ansonsten denken kölnnten, dass dieses zeichen nicht mehr zum Passwort gehört (z.b. bei einem Satzendzeichen)
Bernd
Hallo Bernd,
es ist eine alte Forderung vom BSI, dass ein Passwort aus 4 Kategorien zusammenzusetzen ist: Kleinbuchstaben, Großbuchstaben, Ziffern und Sonderzeichen. Hinzu kommt dann noch, dass es lang sein soll und überall ein anderes zu verwenden ist. Und nach 60 Tagen ein Neues vergeben werden muss.
Was zu den Zetteln unter der Tastatur führt. Und Schreikrämpfen in den Büros.
Mit der Forderung nach all diesen Zeichen gewinnt man gar nicht so viel. Es gibt ja auch noch die Anforderung, dass diese Zeichen auf einer "normalen" Tastatur eingebbar sein müssen, und dabei ist zu beachten, dass nicht jeder Anwender eine deutsche Tastatur hat. Oder nicht weiß, wie man ein { eingibt. Oder – wie auf meinem Samsung Tablet – das ` durch ein typographisches Anführungszeichen ersetzt wird.
Du hast 83 Zeichen vorgegeben. Das wären $$\log_2 83 \approx 6{,}4$$ Entropiebits pro Zeichen, oder 51 Bits Entropie bei 8 Passwortstellen. Dadurch, dass Du die Zeichenvorräte begrenzt, sind es aber nur
In Summe 33,88 Bits Entropie, durch deine Einschränkungen verzichtest Du also auf 18 Bits der möglichen Passwortentropie. Das ist VIEL, jedes Bit verdoppelt den Passwortraum, d.h. Du hast ihn auf 1/262000 reduziert.
Wie kann man es besser machen? Ein Weg ist correct horse battery staple, das setzt aber eine geeignete Wörterliste voraus.
Ein anderer Weg ist dieser: Wenn man einfach beliebige Kleinbuchstaben verwendet, hat man 4,7 Bits Entropie pro Zeichen. Mal 11 ergibt 51,7. Du bist mit 11 zufälligen Kleinbuchstaben also genauso sicher wie mit einem 8-stelligen Kauderwelsch aus Kleinbuchstaben, Großbuchstaben, Ziffern und kryptischen Sonderzeichen. Mit 16 Kleinbuchtaben bist Du bei 75 - also deutlich besser. Mit einer Länge von 16 und einem Zeichenvorrat von Kleinbuchstaben und Ziffern bist Du bei 82,7 Bits Entropie. Das ist schon ziemlich gut.
Du könntest dein Passwort so erzeugen:
Die Verbesserung der Lesbarkeit ist, diejenigem Zeichen wegzulassen oder zu ersetzen, die verwechselbar sind. Das ist vor allem 1 und l - aber auch 0 und o können ein Problem sein. Oder i und j.
Die folgende Funktion erzeugt einen Zufallsstring gegebener Länge aus einem Zeichenvorrat von 32 unverwechselbaren Zeichen. Die 32 macht die Entropieberechnung einfach: 5 Bits pro Zeichen. Bei 4 Gruppen zu 4 Zeichen also 80 Bits. Magische Zahlen im Code gibt's nicht, die Funktion rechnet ihre Parameter aus dem $charset String aus.
Was sie nicht tut, ist das Eliminieren doppelter Zeichen. Warum auch? "aaaa" ist genauso valider Zufall wie "d7qx". Du kannst, wenn Du magst, auch weitere Kleinbuchstaben durch Großbuchstaben ersetzen. Das erweckt die Illusion, dass Du zufällig Klein- und Großbuchstaben benutzt 😉. Achte aber immer auf mögliche Verwechslung von Zeichen.
$charset = "23456789abcdefghikLmnpqrstuvwxyz";
function getGroup($len) {
global $charset;
$result = "";
$chars = strlen($charset);
$r = random_int(0, $chars**$len - 1);
for ($i=0; $i<$len; $i++) {
$result .= $charset[$r % $chars];
$r = intdiv($r, $chars);
}
return $result;
}
Einfach 4x getGroup(4) aufrufen und 80 Bits Entropie genießen 😉
Rolf
Hallo Rolf,
vielen Dank für Deine Erklärung und die Funktion.
Einfach 4x getGroup(4) aufrufen und 80 Bits Entropie genießen 😉
Stimmt das?
Du sprachst doch davon, dass ich sie per Leerzeichen lesefreundlich trennen soll.
Wenn ein Angreifer nicht weiß, dass das Passwort Leerzeichen enthält, muss er alle möglichen Kombinationen aus 19 Zeichen (16 aus dem Zeichenvorrat + 3 Leerzeichen) berücksichtigen.
Somit kämen wir dann doch in den Genuß von mehr als 80 Bits 😉 Die Entropie pro Zeichen wäre log2(33) ≈ 5,04 Bits. Wenn der Angreifer 19 Zeichen aus einem Zeichenvorrat von 33 Zeichen berücksichtigt, ergibt sich die Entropie zu 19 * 5,04 ≈ 95,76 Bits.
Stimmt das so?
Bernd
Hallo Bernd,
95,76 Bits
Wenn Du das Leerzeichen als Teil des Passworts auffassen möchtest, dann jein. Ein Angreifer muss mehr als eine dieser Mails sehen, um ein Muster für den Zeichenvorrat zu erkennen, und sieht dann auch, dass die Leerstellen immer am gleichen Ort sind.
Wenn Du den Mailempfängern schreibst, dass die Leerstellen im Passwort nur der Lesbarkeit dienen und nicht mit einzugeben sind, dann nein.
Berücksichtige bitte auch, dass ein per Mail versendetes Passwort in dem Moment als kompromittiert gelten muss, wo es deinen Server verlassen hat. Wer sich mit einem solchen Passwort anmeldet, muss dazu gezwungen werden, es bei der Anmeldung sofort zu ändern.
Rolf
Hallo Bernd,
95,76 Bits
Wenn Du das Leerzeichen als Teil des Passworts auffassen möchtest, dann jein. Ein Angreifer muss mehr als eine dieser Mails sehen, um ein Muster für den Zeichenvorrat zu erkennen, und sieht dann auch, dass die Leerstellen immer am gleichen Ort sind.
Genau.
Wenn Du den Mailempfängern schreibst, dass die Leerstellen im Passwort nur der Lesbarkeit dienen und nicht mit einzugeben sind, dann nein.
Genau.
Berücksichtige bitte auch, dass ein per Mail versendetes Passwort in dem Moment als kompromittiert gelten muss, wo es deinen Server verlassen hat. Wer sich mit einem solchen Passwort anmeldet, muss dazu gezwungen werden, es bei der Anmeldung sofort zu ändern.
Genau.
Ich würde meine Nutzer am liebsten alle 3 Monate zwingen, ihr Passwort zu ändern. Alleine, den Ärger spare ich mir...
Was den generierten Pass angeht. Ich zwinge sie zwar, gebe aber ein paar Tage Zeit hierzu. Ich kenne das ja selber: Wenn man das ganze nutzt, hat man ausgerechnet so gar keine Zeit. Und ich will keinen User verärgern.
Bernd
Hallo,
Ich würde meine Nutzer am liebsten alle 3 Monate zwingen, ihr Passwort zu ändern. Alleine, den Ärger spare ich mir...
in der DSGVO-Schulung, die ich im Unternehmen jedes Jahr wieder frisch absolvieren muss, heißt es: Das Erzwingen von regelmäßigen Änderungen des Kennworts gilt unter Fachleuten inzwischen nicht mehr als empfehlenswert, weil die Nutzer dann dazu neigen, systematische, leicht erratbare Kennwörter zu verwenden, anstatt eines wirklich ausgefeilten, sicheren Kennworts, das man dann auch über einen langen Zeitraum verwendet.
Einen schönen Tag noch
Martin
Hallo Martin,
tatsächlich haben sie das bei uns jetzt für die Windows-Accounts auch eingesehen. Die PW müssen 12-stellig sein und laufen dafür nicht mehr ab. Nur das PW für den Mainframe ist - weil's halt ein Riesenhobel von IBM ist - max. 8-stellig und verfault regelmäßig.
Rolf
Hallo
Berücksichtige bitte auch, dass ein per Mail versendetes Passwort in dem Moment als kompromittiert gelten muss, wo es deinen Server verlassen hat. Wer sich mit einem solchen Passwort anmeldet, muss dazu gezwungen werden, es bei der Anmeldung sofort zu ändern.
Ich würde meine Nutzer am liebsten alle 3 Monate zwingen, ihr Passwort zu ändern. Alleine, den Ärger spare ich mir...
Daran tust du gut. Einerseits ist das übel nervend und zweitens, un da stimme ich Martins Wiedergabe des Komplexitätsarguments völlig zu, werden die Passwörter prinzipiell schwächer. Denn was macht der genervte Benutzer? Er benutzt als Passwort ein für ihn leicht zu merkendes Wort mit angehängter und hochzuzählender Zahl[1] statt eines Passworts, dass diese Bezeichnung verdient.
Dann lieber länger, auch gerne als Passphrase aus willkürlich ausgewählten Wörtern, die zusammen keinen Sinn ergeben, sich aber in ihrer Kombination merken lassen.
Tschö, Auge
als willkürliches und wohl typisches Beispiel: !!haSi13 ↩︎
Hallo Auge,
Er benutzt als Passwort ein für ihn leicht zu merkendes Wort mit angehängter und hochzuzählender Zahl[1] statt eines Passworts, dass diese Bezeichnung verdient.
Oder einen Passwortmanager, der zufällige, lange Passworte generiert. Und dessen Aufruf entweder durch ein Passwort wie 12345 geschützt ist, oder der eine valide Anmeldung ans Betriebssystem als hinreichenden Schutz akzeptiert (bspw. die im Browser integrierten Passwortmanager). Die Anmeldung am Betriebssystem erfolgt dann wieder mit 999 oder ähnlichem.
Zusammengefasst: Passwörter sind eine Konstruktion aus den 50er Jahren (würde ich schätzen), bei der die Parameter nutzerfreundlich und sicher umgekehrt proportional zueinander sind. Und sicher ist relativ, es gibt genügend Möglichkeiten, einem User das Passwort abzulauschen, wenn man es darauf anlegt und bei Budget und krimineller Energie kein Limit gesetzt ist.
Vermailte Passwörter sind prinzipiell unsicher. Eigentlich müsste jeder Benutzer sein Konto selbst anlegen und das Passwort vergeben. Passwortvergabe und -änderung muss über einen zweiten Faktor abgesichert werden (Bestätigungsmail). Die Verwendung einer Authenticator-App mit TOTP[1] ist ebenfalls nützlich - wenn man serverseitig programmieren kann, ist es überhaupt nicht schwierig, eine solche Authenticator-Absicherung auf der eigenen Website einzubauen. Das hab ich spaßeshalber schonmal zusammengesucht und programmiert und habe einen Wiki-Artikel dazu auf meiner internen Todoliste. Sofern nicht ein Link auf eine Vorlage reicht 😉
Ob die Passkeys, die uns die Browserhersteller andienen wollen, besser sind, weiß ich nicht. Der Browser muss sie speichern und absichern. Google möchte meine Passkeys gerne zentral speichern. Möchte ich das? Eher nicht.
Rolf
time based one time password ↩︎
Hallo
Er benutzt als Passwort ein für ihn leicht zu merkendes Wort mit angehängter und hochzuzählender Zahl[1] statt eines Passworts, dass diese Bezeichnung verdient.
Oder einen Passwortmanager, der zufällige, lange Passworte generiert. Und dessen Aufruf entweder durch ein Passwort wie 12345 geschützt ist, oder der eine valide Anmeldung ans Betriebssystem als hinreichenden Schutz akzeptiert (bspw. die im Browser integrierten Passwortmanager). Die Anmeldung am Betriebssystem erfolgt dann wieder mit 999 oder ähnlichem.
Ja, geht auch; aber eben auch anders.
Mein Passwortmanagerpasswort ist 15 Zeichen lang und es wird zusätzlich noch ein Kryptoschlüssel benötigt.
Zusammengefasst: Passwörter sind eine Konstruktion aus den 50er Jahren (würde ich schätzen), bei der die Parameter
nutzerfreundlichundsicherumgekehrt proportional zueinander sind. Undsicherist relativ, es gibt genügend Möglichkeiten, einem User das Passwort abzulauschen, wenn man es darauf anlegt und bei Budget und krimineller Energie kein Limit gesetzt ist.
Da hast du wohl recht.
Vermailte Passwörter sind prinzipiell unsicher. Eigentlich müsste jeder Benutzer sein Konto selbst anlegen und das Passwort vergeben. Passwortvergabe und -änderung muss über einen zweiten Faktor abgesichert werden (Bestätigungsmail). Die Verwendung einer Authenticator-App mit TOTP[1] ist ebenfalls nützlich - wenn man serverseitig programmieren kann, ist es überhaupt nicht schwierig, eine solche Authenticator-Absicherung auf der eigenen Website einzubauen. Das hab ich spaßeshalber schonmal zusammengesucht und programmiert und habe einen Wiki-Artikel dazu auf meiner internen Todoliste. Sofern nicht ein Link auf eine Vorlage reicht 😉
Das würde mich tatsächlich interessieren. Ich habe zwar vor Jahren mal TOTP über SMS gebaut, aber das gilt ja auch nicht als sicher. Wenn ich im Netz nach soetwas suche, finde ich zwar zuhauf Projekte (zum Beispiel auf Github), aber die Selbstbeschreibungen der Projekte lassen mich regelmäßig zweifeln, ob das nun die Umsetzung der 2FA für den Login auf einer Website ist, oder „nur“ eine webbasierte App, um sich woanders einloggen zu können.
Ob die Passkeys, die uns die Browserhersteller andienen wollen, besser sind, weiß ich nicht. Der Browser muss sie speichern und absichern. Google möchte meine Passkeys gerne zentral speichern. Möchte ich das? Eher nicht.
Spätestens bei dem Punkt, die PassKeys jemand anderem in die Hand drücken zu sollen, springt der Alarm auch bei mir an.
Tschö, Auge
time based one time password ↩︎
Ne andere Sichtweise.
Ein Passwort das der Nutzer direkt verwenden muss, würde ich nicht mit Leerzeichen trennen. Das verhindert das kopieren des Passworts, was sicher einige tun werden.
gebe aber ein paar Tage Zeit hierzu.
Ich würde im Gegenteil festlegen dass das Passwort sofort geändert werden muss bevor der Nutzer irgendwas in seinem Account tun kann.
Normalerweise will man sich sofort einloggen, dann gleich ein neues Passwort setzen dauert doch nicht lange.
In diesem Fall könnte man auch mit einem viel weniger aufwendig generierten Passwort leben. Ein 15-stelliges Passwort mit diesen ganzen Regeln ist doch zu schade, um nach einmaliger Nutzung durch was viel simpleres ersetzt zu werden 😀
Hallo encoder,
Ein Passwort das der Nutzer direkt verwenden muss, würde ich nicht mit Leerzeichen trennen. Das verhindert das kopieren des Passworts, was sicher einige tun werden.
Hm, ja. Alte Programmiererweisheit: Ohne User wäre unser Leben so viel einfacher...
Man könnte auch HTML Mail verwenden und die Teile in spans mit einem Margin setzen. Oder gleich als Flexbox mit Gap (wenn die Mailclients sowas Modernes kennen):
<div style="display:flex;gap:0.5em"><span>seLf</span><span>htmL</span><span>pass</span><span>w0rd</span></div>
mal so ganz zufällig hingeklimpert… Das würde auch einem Mail-Spion das Auslesen ein winzigbisschen erschweren.
Rolf
Man könnte auch HTML Mail verwenden und die Teile in spans mit einem Margin setzen. Oder gleich als Flexbox mit Gap (wenn die Mailclients sowas Modernes kennen):
<div style="display:flex;gap:0.5em"><span>seLf</span><span>htmL</span><span>pass</span><span>w0rd</span></div>mal so ganz zufällig hingeklimpert… Das würde auch einem Mail-Spion das Auslesen ein winzigbisschen erschweren.
Klar, könnte man. Und was ist mit den usern, die keine html-mails empfangen können/wollen?
Bernd
Hallo Bernd,
Man könnte auch HTML Mail verwenden [...]
Klar, könnte man.
Und was ist mit den usern, die keine html-mails empfangen können/wollen?
die müssten dann mit dem Alternativteil in text/plain Vorlieb nehmen, den man bei HTML-Mails immer mit zur Verfügung stellen sollte.
Einen schönen Tag noch
Martin
Hi Martin,
die müssten dann mit dem Alternativteil in text/plain Vorlieb nehmen, den man bei HTML-Mails immer mit zur Verfügung stellen sollte.
Stimmt.
So einfach kanns sein.
Gilt also, dass der Alternativtext einer HTML-mail nicht gelesen werden kann, wenn die mail abgefangen wird?
Weil iuch mir ja sonst der <tag>-Kokollores sparen könnte?
Bernd
Hallo
die müssten dann mit dem Alternativteil in text/plain Vorlieb nehmen, den man bei HTML-Mails immer mit zur Verfügung stellen sollte.
Stimmt.
So einfach kanns sein.
Gilt also, dass der Alternativtext einer HTML-mail nicht gelesen werden kann, wenn die mail abgefangen wird?
Natürlich kann er das. HTML ist Klartext und kann damit gelesen werden, sofern die E-Mail in diesem Moment nicht verschlüsselt vorliegt. In der Hinsicht unterscheidet sich das nicht von einer Plain-Text-E-Mail.
Weil iuch mir ja sonst der <tag>-Kokollores sparen könnte?
Meiner Meinung nach kannst du das. Plain-Text kann jeder lesen und wenn das Passwort in Anführungszeichen gesetzt ist und dieser Umstand vermittelt wird, sollte jedem Leser klar sein, was in der E-Mail das Passwort ist.
Tschö, Auge
@@Auge
Gilt also, dass der Alternativtext einer HTML-mail nicht gelesen werden kann, wenn die mail abgefangen wird?
Natürlich kann er das. HTML ist Klartext und kann damit gelesen werden, sofern die E-Mail in diesem Moment nicht verschlüsselt vorliegt.
Eben.
sollte jedem Leser klar sein, was in der E-Mail das Passwort ist.
Ja: Es ist Unfug.
Wem es gelingt, die Mail abzufangen, hat eh beides, Token und Passwort. Das Passwort beitet also keine zusätzliche Sicherheit, es ist nur unnötiger Aufwand, kann also weg. Üblicherweise bekommt man nur einen Link mit Token ohne Passwort per E-Mail zugesandt; das hat schon seinen Sinn.
Mehr Sicherheit gibt’s mit längerem Token.
Kwakoni Yiquan
Das würde auch einem Mail-Spion das Auslesen ein winzigbisschen erschweren.
# winzigbisschen
$text=html2text($html)
Das gibts für fast alle Programmiersprachen und auch als eigenständiges Programm.
gebe aber ein paar Tage Zeit hierzu. Ich würde im Gegenteil festlegen dass das Passwort sofort geändert werden muss bevor der Nutzer irgendwas in seinem Account tun kann.
Prinzipiell gebe ich Dir Recht.
Würde aber den Schritt des Passwort-Reset von 2 auf 3 (bei mir) erhöhen.
Deshalb lass ichs.
Ich gehe mit Martin konform, dass alles, was der User als Gängelung wahrnimmt, zu unsichereren Passwörtern führt. Da erreiche ich mit einer Bitte viel mehr als mit Zwang.
Bernd
@@Rolf B
Die Verbesserung der Lesbarkeit ist …
… irrelevant!
Ein generiertes Passwort ist dazu gedacht, sofort[1] geändert zu werden oder sofort im Passwortmanager zu verschwinden.
Es ist nicht dazu gedacht, von Nutzern gelesen zu werden. Oder gar abgetippt zu werden. Oder gar im Kopf behalten zu werden. Und wenn doch, dann steckt dort der Fehler.
Kwakoni Yiquan
oder sofort im Passwortmanager zu verschwinden.
Nana, was machen denn solchewelche, die mehrere Geräte benutzen? Ich selbst würde einen Teufel tun und meine Passwörter - verschlüsselt oder nicht - irgendeinem Webdienst überlassen, damit, wenn der mal gehackt wird, meine gesamte Idendität z.B. einem neosowjetisch-nordkoreanischen Hackerkollektiv zur Verfügung steht.