Ich denke, der Grund ist der gleiche wie bei jeder anderen Eingabevalidierung. um sicherzustellen, dass es während der Verarbeitung und Lagerung keine Probleme verursacht. Für Passwörter ist dies natürlich völlig falsch, da sie gehasht und daher im Klartext weder gespeichert noch wirklich verarbeitet werden sollten.

Ich würde solche Einschränkungen als Hinweis darauf nehmen, dass die Entwickler nicht wissen, was sie aus Sicherheitsgründen tun, und das Kennwort wahrscheinlich im Klartext speichern werden. Bleib weg.

Ich werde gehen mit: den gleichen alten Gründen, warum Menschen seltsame Dinge tun.

• Weil es zu dieser Zeit eine gute Idee zu sein schien. Entwickler sind möglicherweise gut gemeint, aber schlecht informiert. Die Kennwortlänge muss nicht begrenzt werden, aber Entwickler sind sich dessen möglicherweise nicht bewusst. Vielleicht haben Entwickler nicht einmal darüber nachgedacht.

• Weil es einfacher war als die Alternativen. Vielleicht verwenden sie eine API, die nicht funktioniert Passwörter beliebiger Länge; Dies könnte es einfacher machen, die Kennwortlänge zu begrenzen, als eine bessere API zu verwenden. Möglicherweise haben sie SQL-Injection-Fehler in ihrer Datenbank, und anstatt die Dinge richtig zu codieren, um den SQL-Injection-Fehler zu vermeiden, ist es einfacher, nur einige Zeichen auf die schwarze Liste zu setzen (z. B. Benutzern zu verbieten, einfache Anführungszeichen in ihre Passwörter aufzunehmen). Vielleicht war es aus irgendeinem Grund einfacher, ein Array mit fester Länge als eine Zeichenfolge mit variabler Länge zu verwenden. Wer weiß.

Fazit: Es gibt keine wirklich gute Rechtfertigung für solche Grenzen. Ich bin sicher, wir sind daran gewöhnt, dass im Handel erhältliche Software oft alle möglichen seltsamen Designfehler enthält. Es passiert. Es ist eine Tatsache des Lebens. Dies ist eine Folge der Tatsache, dass "gut genug" viel billiger ist als "perfekt".

Ein vernünftiger Grund für die Begrenzung der Kennwortlänge und des möglichen Zeichensatzes besteht darin, den Benutzer zur Anwendung geeigneter Kennwortverwaltungstechniken aufzufordern. In einfachen Worten, wenn ein Passwort riesig oder voller seltsamer Zeichen ist, erhöht dies die Wahrscheinlichkeit, dass der Benutzer das Passwort auf ein Blatt Papier (traditionell unter die Tastatur geklebt) aufschreibt und / oder dasselbe Passwort in mehreren Systemen wiederverwendet

Konzeptionell liegt es in seiner Verantwortung, wie der Benutzer seine eigenen Passwörter verwaltet, und es geht ihn nichts an. In der Praxis sind Benutzer jedoch in Bezug auf die Sicherheit ahnungslos und können sich nicht mit etwas langweilen, das keine sofortige Vergeltung bietet (insbesondere wenn Benutzer potenzielle Kunden sind). Es liegt also an der Website, zu versuchen, das zu tun, was sie kann, um den Benutzer zu schützen.

Beachten Sie, dass ich nicht behaupte, dass der Versuch, eine gute Passwortverwaltung durchzusetzen, der ist Grund, warum eine bestimmte Site die Passwortlänge begrenzt; Dies ist nur ein Grund, warum I eine Beschränkung der Kennwortlänge auf meiner eigenen Website vorsieht (wenn ich eine Website mit Benutzerkennwörtern verwalten würde).

Eine weitere Begründung für einen begrenzten zulässigen Zeichensatz soll die Interoperabilität fördern: Vorzugsweise sollte der Benutzer in der Lage sein, sein Passwort auf einer Vielzahl von Eingabegeräten einzugeben. Nicht-ASCII-Zeichen eignen sich nicht für alles, was wie eine US-Tastatur aussieht (es ist möglich, Nicht-ASCII-Buchstaben auf einer US-Tastatur einzugeben, ich mache das ständig, aber die Methoden variieren je nach Betriebssystem und Konfiguration und tun dies auch funktioniert nicht gut mit blindem Tippen, wie es bei der Passworteingabe üblich ist). Smartphones unterliegen noch größeren Einschränkungen. Auch hier ist die Interoperabilität (meiner Ansicht nach) ein guter Grund, einen begrenzten Zeichensatz durchzusetzen, aber viele Websites unterliegen aus schlechten Gründen einer solchen Einschränkung (z. B. damit das Kennwort unachtsam in SQL gespeichert werden kann) Anfrage ohne ordnungsgemäße Escape-Zeichenfolge, was nur als schlampiges Engineering bezeichnet werden kann.

Ich dachte, wir hätten eine Frage wie diese, aber entweder ist mein Such-Fu heute Abend schwach oder es war auf einer anderen Site.

Grundsätzlich ist es in den meisten Anwendungen oder Datenbanken sinnvoll, nützliche Grenzen für die Eingabe zu definieren Saiten. Auf diese Weise können Sie die Eingabe stoppen, sobald das Limit erreicht ist (wodurch Überläufe usw. vermieden werden können), und Sie können auch die Codeleistung vorhersagen.

Außerdem benötigen Sie möglicherweise temporären Speicher, während Sie Kennwörter überprüfen, bevor sie gehasht werden Eine beliebig lange Eingabe kann Probleme verursachen.

Warum 32? Eine vernünftige Zahl für die meisten Zwecke - die Entropie in 32 Zeichen ist riesig. In einigen Umgebungen reicht dies natürlich nicht aus, aber für viele von ihnen ist ein Zertifikat oder ein zweiter Faktor (z. B. ein Token) möglicherweise ohnehin besser geeignet.

Da meine erste Frage die Marke verfehlt hat, gebe ich eine separate Antwort. Der Hauptgrund ist, dass Grenzwerte erforderlich sind. Obwohl die Bedenken hinsichtlich des Speicherplatzes und des Datenblocks zutreffend sind, gibt es einige Probleme.

Wenn Sie zuerst meine ursprüngliche Antwort unten lesen, werden Sie feststellen, dass eine der Empfehlungen iteratives Hashing ist (dh pbkdf). . Dies erfordert eine große Anzahl von Iterationen, um wirklich effektiv zu sein. Wenn ein Benutzer eine große Zeichenfolge senden kann, werden die Kosten für die Berechnung dieses iterativen Hashwerts für eine einfache Authentifizierungsfunktion schnell teurer als erwartet.

Jede einzelne rechenintensive Aufgabe auf einem Server, insbesondere eine Dies ist explizit für einen nicht authentifizierten Benutzer verfügbar und wird von einem böswilligen Benutzer missbraucht, um einen Denial-of-Service-Angriff durchzuführen.

Zweitens bietet die Implementierung eines Kennworts mit fester Länge die Möglichkeit, vorzeitig zu beenden, wenn dies extrem ist lange Anfrage wird eingereicht. Wenn die Parameter in der Anforderung außerhalb der erwarteten Länge liegen, können Sie einfach eine Fehlermeldung ausgeben und die Verbindung schließen.

Der Grund dafür, dass die Anforderungen an die Kennwortkomplexität auf vielen Websites durchgesetzt werden, besteht darin, zu verhindern, dass Benutzer ein schwaches Kennwort auswählen. Es gibt zahlreiche Beispiele in der jüngeren Geschichte, die zeigen, dass die meisten Benutzer schwache, leicht einzugebende und leicht zu merkende Passwörter anstelle komplexer Passwörter auswählen. In diesem Fall setzt sich der Eigentümer der Website selbst einem Risiko aus, da Benutzer die Website ausnahmslos beschuldigen, wenn ein Kennwort gestohlen oder geknackt wird und welche Ergebnisse dies sowohl für die Website als auch für den betroffenen Benutzer haben kann.

Durch die Implementierung strenger Kennwortanforderungen wird die Wahrscheinlichkeit verringert, dass ein Angreifer das Kennwort leicht erraten kann. Passwörter müssen außerdem vor zwei verschiedenen Angriffspfaden geschützt werden. Der erste, Online-Angriffe, setzt voraus, dass ein Website-Entwickler über eine Richtlinie verfügt, die den Erfolg von Brute-Force-Angriffen verhindert. Dies wird erreicht, indem ein Benutzer ein entsprechend langes, komplexes Kennwort auswählen und die Anzahl der fehlgeschlagenen Anmeldeversuche einschränken muss, bevor er verlangsamt (dh vorübergehende Sperren, Captchas usw.) oder Anmeldeversuche stoppt (permanente Sperren, obligatorisches Zurücksetzen des Kennworts, Kontobestätigungen) usw.)

Der zweite Angriff ist ein Offline-Angriff, bei dem ein Angreifer eine Kopie einer Kennwortdatenbank abruft und versucht, mithilfe einer Regenbogentabelle oder eines Offline-Kennwortcrackers mehrere Konten zu knacken. Diese Art von Angriff wird verhindert, indem ein starker Hashing-Algorithmus in Verbindung mit einem Salt pro Benutzer und vorzugsweise ein erneutes Aufwärmen im pbkdf2- oder bcrypt / scrypt-Stil verwendet wird, um die Rechenkosten für das Offline-Cracken zu erhöhen.

Letztendlich beides Diese Techniken schlagen fehl, wenn Websites Benutzer nicht dazu ermutigen, ein eindeutiges Kennwort für ihre verschiedenen Konten auszuwählen. Viele Benutzer wählen dieselben Kennwörter für mehrere Konten aus. Wenn dieses Kennwort verfügbar ist, insbesondere für ihr E-Mail-Konto, kann ein Angreifer diese Anmeldeinformationen für einen anderen Dienst verwenden. Aus diesem Grund ist es am besten, eindeutige, sichere Kennwörter für jede Site oder zumindest verschiedene Gruppen von Sites zu generieren und einen sicheren Passwort-Manager zum Speichern aller verschiedenen Passwörter zu verwenden.