Das klingt sehr nach Fencepost Security. Stellen Sie sich vor, Sie betreiben eine Einrichtung mit einem Maschendrahtzaun, der 500 Fuß hoch ist. Um wie viel würde sich die Sicherheit verbessern, wenn dieser Zaun 3.000 Fuß hoch wäre? Keine - weil jeder, der versucht einzusteigen, die 500 Fuß nicht erklimmen wird; Sie werden darunter graben, ein Loch schneiden usw.

Ebenso haben Sie ein Passwort, das beispielsweise 20 zufällige alphanumerische Zeichen enthält. Das sind 62 ^ 20 Möglichkeiten. Sie erwägen, es in 20 zufällige Unicode-Zeichen zu ändern. Dies erhöht den Wahrscheinlichkeitsbereich erheblich, außer dass das brutale Erzwingen eines zufälligen Kennworts mit 20 Zeichen nicht dazu führt, dass die Dinge kompromittiert werden.

Dies ist aus Sicherheitsgründen eine gute Idee. Ein Passwort mit Unicode-Zeichen ist schwerer zu erzwingen als ein Passwort mit ASCII-Zeichen gleicher Länge. Dies gilt auch dann, wenn Sie die Bytelänge anstelle der Zeichenlänge vergleichen, da Unicode das höchstwertige Bit verwendet, während ASCII dies nicht tut.

Ich denke jedoch, dass dies nicht praktikabel wäre, da Unicode-Fehler so häufig sind . Ich denke, wenn Sie überall Unicode-Passwörter verwenden, werden Sie auf mehr als ein paar Websites stoßen, auf denen Sie Probleme beim Anmelden haben würden, da die Entwickler die Unicode-Unterstützung für Passwörter nicht korrekt implementiert haben.

Das Argument Security by Obscurity zu ignorieren, ist eine grundlegende Frage der Entropie. Ein 8-stelliges Unicode-Passwort ist sicherer als ein 8-stelliges ASCII-Passwort, aber weniger sicher als ein 64-stelliges ASCII-Passwort.

Im Allgemeinen stimme ich Sjoerd zu - dies verursacht wahrscheinlich mehr Unannehmlichkeiten als Vorteile. Darüber hinaus wird Unicode Ihr Leben wahrscheinlich unglücklich machen, wenn Sie jemals ein zufälliges Passwort manuell eingeben müssen.

Für den Randfall, in dem Sie einen Dienst verwenden müssen, der Unicode aktiv unterstützt, während Sie a Das maximale Limit für die Kennwortlänge (das wiederum ignoriert normalerweise andere Sicherheitslücken) gibt es dafür.

Der einzig gültige Grund für die Verwendung von Unicode-Zeichen in Kennwörtern ist, dass die Anzahl der Zeichen (nicht Bytes) in einem Kennwort für eine bestimmte Site begrenzt ist (wie bei dieser dummen Bank, die zuvor a hatte) > maximal 10 Zeichen), so dass es in ein oder zwei Tagen leicht zu erraten ist. In diesem Fall können Sie Unicode verwenden (sofern die Websitebesitzer dies zulassen), um in der Zwischenzeit mehr Entropie in Ihr Kennwort einzugeben, während Sie die Websitebesitzer auffordern, NIST 800-63-3 und einzuhalten Längenbeschränkungen entfernen (und Hash ordnungsgemäß, damit das Speichern von Passwörtern kein Problem darstellt).

Ich wollte auch hier ein Missverständnis korrigieren:

Unicode verwendet das höchstwertige Bit, während ASCII nicht.

Während dies für normales ASCII zutrifft, verwendet das erweiterte ASCII, das einige Passwortmanager (z. B. KeePass) bei der Passwortgenerierung verwenden können, jedes einzelne Bit jedes Bytes und weist somit eine höhere Entropie auf Dichte als sogar Unicode, das immer noch eine Struktur aufweist, die angibt, wie viele der folgenden Bytes Teil desselben Zeichens sind (Beachten Sie, dass in eine ungültige Bytesequenz in Unicode ).

Da eine Site, die Sie auf kurze Passwörter beschränkt, ihre Passwörter wahrscheinlich nicht richtig hasht (was dazu führt, dass Unicode-Passwörter fehlschlagen oder mit th gespeichert werden) Bei falscher Codierung sollten Sie fast nie die Zeit damit verschwenden, sich mit Unicode-Passwörtern zu beschäftigen, denn während Sie von Ihren lustigen Zeichen so abgelenkt sind (und die Tatsache, dass Sie Ihr Passwort zurücksetzen müssen, weil es seltsam gespeichert wurde), könnte ein Angreifer raten Ihre (in) Sicherheitsfragen oder die Verwendung von Schokoladenkryptografie, um Zugriff auf Ihr Konto zu erhalten.

Dieser Ansatz kann Ihre Gesamtsicherheit in bestimmten Fällen verringern nicht verbessern.

Informationssicherheit besteht aus drei Attributen: Vertraulichkeit, Integrität und Verfügbarkeit () CIA-Triade). Wenn Sie sich ausschließlich auf eines konzentrieren, können Sie leicht die Bedeutung der anderen übersehen.

Die Vertraulichkeit von Passwörtern wird durch die Entropieprinzipien erreicht: Wie „nicht erratbar“ ist Ihr Passwort? Dies wird üblicherweise durch die Größe des Brute-Force-Schätzraums gemessen, ausgedrückt als Potenzen von 2 oder Bit. Ein Brute-Force-Angreifer kann nur so viel raten. Durch Auswahl eines längeren Passworts zur Erhöhung dieser Entropie können Sie alle bekannten oder vorhergesagten Vermutungsmöglichkeiten überschreiten. Wenn Sie die Entropie auf über 80 Bit bringen (oder Ihren Wert auswählen), ist das Passwort selbst für nationalstaatliche Akteure unerreichbar. Unabhängig von der oben stark vereinfachten Beschreibung ist der Punkt, dass das Überschreiten von "außerhalb der Reichweite" Ihre Sicherheit nicht wesentlich erhöht. Und es ist für die Sicherheit nicht relevant, wenn Sie die gewünschte Entropie mit 10 Unicode-Zeichen oder 17 ASCII-Zeichen erreichen.

Verfügbarkeit bedeutet "Kann ich bei Bedarf auf meine Daten zugreifen?" Wenn Sie vollständige Unicode-Zeichensätze verwenden, besteht die Gefahr, dass verschiedene Websites, die Unicode nicht unterstützen, oder Browser oder Betriebssysteme, die Unicode falsch implementieren, oder Websites, die Unicode unsichtbar in ASCII übersetzen, unter dem Deckmantel in Konflikt geraten. Die daraus resultierende Verwirrung erhöht das Risiko, Ihren zukünftigen Zugriff auf die Daten einzuschränken. Dies stellt eine potenzielle Verringerung der zukünftigen Verfügbarkeit dar.

Im Allgemeinen ist die Wahrscheinlichkeit, dass ein Angreifer Ihr 80-Bit-Kennwort brutal erzwingt, nicht annähernd so hoch wie die Wahrscheinlichkeit, auf eine schlecht codierte Site zu stoßen, die nicht mit Unicode umgehen kann richtig. Daher kann Ihre Gesamtsicherheit verringert anstatt erhöht werden.

Natürlich haben viele Websites eine Kennwortlänge und andere Einschränkungen, die auch die Entropie Ihrer Kennwörter drastisch einschränken. In diesen Fällen kann die Verwendung des vollständigen Unicode-Satzes die Entropie Ihrer Kennwörter erhöhen, vorausgesetzt, sie weisen keine anderen versteckten Fehler auf. Auf diesen Websites verbessern Sie möglicherweise Ihre Sicherheit. Es ist jedoch praktisch unmöglich, von außen zu erkennen, ob eine Site Ihre Passwortdaten ordnungsgemäß verarbeitet.

Dies ist möglicherweise keine direkte Antwort. Wenn das Kennwort jedoch nur digital gespeichert wird, sollten Sie sich fragen, warum Sie überhaupt ein Kennwort anstelle eines Byte-Arrays generieren. Sobald Sie das Ganze als einfache Bytes betrachten, gilt die Frage nicht mehr.

Auch die Länge> Komplexität in allen Dingen, die mit Passwörtern zusammenhängen.

Es gibt einen RFC zu Ihrem Problem: Vorbereitung, Durchsetzung und Vergleich von internationalisierten Zeichenfolgen, die Benutzernamen und Kennwörter darstellen, deren Zusammenfassung lautet:

In diesem Dokument werden aktualisierte Methoden beschrieben zur Behandlung von Unicode-Zeichenfolgen, die Benutzernamen und Kennwörter darstellen. Der vorherige Ansatz war als SASLprep (RFC 4013) bekannt und basierte auf Stringprep (RFC 3454). Die in diesem Dokument angegebenen Methoden bieten einen nachhaltigeren Ansatz für den Umgang mit internationalisierten Benutzernamen und Kennwörtern.

Wenn Sie Französisch lesen, finden Sie hier auch eine gute Erklärung: http : //www.bortzmeyer.org/8265.html.

Abschnitt 8 des RFC befasst sich speziell mit der Sicherheit von Passwörtern unter Verwendung eines "beliebigen" Unicode-Zeichens mit den folgenden Abschnitten:

• 8.1. Passwort- / Passphrasenstärke
• 8.2. Vergleich von Passwort / Passphrase
• 8.3. Identifikatorvergleich
• 8.4. Wiederverwendung von PRECIS
• 8.5. Wiederverwendung von Unicode

Zusätzlich zu den anderen guten Antworten möchte ich nur darauf hinweisen, was bei der Verwendung des vollständigen Unicode-Satzes für Kennwörter entlang der Pipe schief gehen kann.

Angenommen, Sie verwenden zufällig a mehr oder weniger gültige UTF-8-Zeichenfolge,

• Es gibt Zeichen, die in der Mitte der mehrsprachigen Grundebene als Zeilenumbruch interpretiert werden, wie U + 2029 Paragraph Separator. Möglicherweise können sie nicht in ein einfaches Feld <input> eingegeben werden.
• Es gibt beide Leerzeichen, die möglicherweise von einer Sprache entfernt werden oder nicht trim () -Methode
• Wenn Sie Ersatzzeichen (U + D800-U + DFFF) verwenden, Nichtzeichen wie U. + FDD0, Zeichen für den privaten Gebrauch oder nicht zugewiesene Zeichen (obwohl gültige UTF-8-Sequenzen). Das Verhalten eines bestimmten Werkzeugsatzes ist grundsätzlich undefiniert (Entfernen, Ersetzen, Ablehnen, Nichtstun oder eine beliebige Kombination von Zeichen) diese)
• Wenn Sie diakritische Zeichen hinzufügen, kann jedes laufende Tool dies in eine NFC- oder NKD -Darstellung ändern und die Bytes im Kennwort ändern.
• und Das kommt nur von oben. Ich bin sicher, ich habe viele andere mögliche Probleme vergessen, wenn Passwörter aus dem gesamten Unicode-Bereich ausgewählt werden.

Ähnlich wie bei @JohnDeters vorgeschlagen, könnte dies eine schlechte Idee sein, da Der Vorteil eines größeren Quellraums wird durch die beweglichen Teile der Textverarbeitung auf dem Weg übergewichtet.

Was für die Sicherheit zählt, ist die Entropie des Passworts - wie viele Bits tatsächlicher Informationen enthält das Passwort.

Die andere Seite des Problems ist, wie schwierig es ist, sich das Passwort zu merken und das Passwort einzugeben. Stellen Sie sich vor, Sie versuchen, Ihr Passwort auf einem iPhone einzugeben, und Sie stellen fest, dass dies nicht möglich ist (ich habe nicht überprüft, wie schwierig es ist, beliebige Unicode-Zeichen einzugeben). Oder Sie erkennen, dass es sehr, sehr schwierig ist, es zu 100% richtig einzugeben. Oder es dauert nur ewig - ich habe möglicherweise ein Passwort mit der gleichen Entropie und mehr Zeichen, aber doppelt so schnell zu tippen. Und du brauchst vier Versuche, um es richtig zu machen, während meins beim ersten Mal richtig ist.

Andere haben ausführlich auf das Risiko hingewiesen, dass die Dienste, für die Sie diese Kennwörter verwenden, Unicode nicht korrekt implementieren. Ich werde die Dienste hinzufügen, die heute möglicherweise morgen ausführen, aber ansonsten überspringe ich dieses Thema.

Ein Element, das ich Hier muss man sich fragen: Wie lange muss ein Passwort dauern, um eine bestimmte Sicherheitsstufe zu erreichen? Nehmen wir an, wir möchten, dass unsere Passwörter so stark sind wie ein 128-Bit-Kryptografieschlüssel (was für die meisten Website-Passwörter wahrscheinlich übertrieben ist; ich empfehle 80 Bit). Wenn Sie sich an zufällige ASCII-Kennwörter halten, erreicht ein 19-stelliges Kennwort, das aus den ~ 95 druckbaren ASCII-Zeichen gezogen wird, diese Stufe. (Die Mathematik: Eine Menge von ungefähr 100 Elementen ist ungefähr 6,6 Bit / Element (da log2 (10) ≈ 3,3 und log2 (100) doppelt so groß ist) und 128 ÷ 6,6 ≈ 19,4. 19 ASCII-Zeichen sind also tatsächlich ungefähr 126 Bits, nicht 128, sondern meh.)

In Unicode sind derzeit ungefähr 130.000 Codepunkte definiert, eine Zahl, die wir nur als 2 ^ 17 schätzen werden. Dies bedeutet, dass Sie zum Erreichen der 128-Bit-Ebene 7 Unicode-Codepunkte benötigen (128 ÷ 17 ≈ 7,5, also 7 Codepunkte nur etwa 119 Bit, aber wiederum meh.)

Für 80-Bit-Sicherheit Level, das meiner Meinung nach für die meisten Websites sinnvoller ist, besteht aus 12 ASCII-Zeichen im Vergleich zu 5 Unicode-Codepunkten.

Sind Sie bereit, einen massiven Usability-Treffer zu erzielen und Website-Fehler zu riskieren, nur damit Sie 5 oder mehr haben können? 7-stellige Passwörter statt 12 oder 19 Zeichen? Ich glaube einfach nicht, dass es sich lohnt.

Nun, Unicode ist 'nur' eine Liste von etwas über 130000 Zeichen. UTF-8 ist die gebräuchlichste Codierung, die diese eine große Zahl verwendet und sie gemäß einer Reihe von Regeln in eine Basis-256-Zahl (genauer gesagt, die Regeln sind in binären Oktetten sinnvoller) "konvertiert". Wenn Sie also eine utf-8-Codierung verwenden möchten, sind Sie an viele Regeln gebunden, die die gewünschte Zufälligkeit effektiv verringern. Und ich weiß nicht, wie Sie die gesamte Unicode-Interpretation verwenden sollen.

Wenn Sie sich keine Gedanken über druckbare Zeichen machen, können Sie das gesamte ASCII (oder vorzugsweise eine 8-Bit-Erweiterung) in Betracht ziehen, aber bei Warum sollte man sich überhaupt mit dem Standard der Charakterinterpretation beschäftigen? Könnten Sie dann nicht einfach eine einfache formlose zufällige Binärstruktur verwenden?

Selbst wenn Sie nur digitalen Speicher verwenden, würde ich es hassen, der Benutzer zu sein, der etwas eingeben musste und den Unterschied zwischen （und (. (Hinweis: Sie sind doppelt und einfach) nicht erkannt hat. beabstandet)

Wenn Sie dieses Beispiel für die Breite verwenden, wie in anderen Antworten angegeben, erwarten Sie, dass die Unterstützung dieser Beispiele funktioniert - abhängig von der hier festgelegten SQL-Sortierung würde ein falsches Kennwort korrekt sein!

Nein. Sie möchten die Basis einer Exponentialfunktion erhöhen und gleichzeitig riskieren, dass viele Dinge kaputt gehen (z. B. Geräte, die Ihre Sonderzeichen nicht eingeben können usw.). Berechnen Sie die Entropie Ihres Unicode-Passworts und verlängern Sie Ihr ASCII-Passwort, bis es mehr Entropie aufweist.

az allein beträgt 26 ^ (Länge). Nehmen wir an, Sie erhalten 256 ^ (Länge) und möglicherweise 2 Bytes pro Zeichen mit Unicode. Dann finden Sie irgendwo die Gewinnschwelle 26 ^ (ascii_length) > 256 ^ (2 * Unicodelength) . Wählen Sie diese Länge als ascii_length und Sie können trotzdem Ihr Passwort aufschreiben und haben die gleiche Sicherheit.

Wenn die Site keine langen Passwörter unterstützt (Schande über sie), würde ich vermuten Sie können auch keine gute Unicode-Unterstützung garantieren. Vielleicht werden Sie beim nächsten Upgrade einer internen Bibliothek gesperrt. Warum also dort ein Problem riskieren? Und ein Problem, das der Benutzerunterstützung schwer zu erklären ist und kaum weiß, was Unicode bedeutet.

Es ist keine gute Idee, zufällige Unicode-Kennwörter zu generieren, da das generierte Kennwort für den Benutzer möglicherweise nicht lesbar ist. Der Text der Frage befasst sich jedoch mit der Verwendung von Unicode-Passwörtern. Dies ist eine gute Idee und wird von NIST 800-63-3, Abschnitt 5.1.1.2 Memorized Secret Verifiers empfohlen, in dem es heißt:

Verifizierer MÜSSEN vom Abonnenten ausgewählte gespeicherte Geheimnisse mindestens 8 Zeichen lang sein. Verifizierer MÜSSEN vom Abonnenten ausgewählte gespeicherte Geheimnisse mit einer Länge von mindestens 64 Zeichen zulassen. Alle druckenden ASCII [RFC 20] -Zeichen sowie das Leerzeichen MÜSSEN in gespeicherten Geheimnissen akzeptiert werden. Unicode-Zeichen [ISO / ISC 10646] MÜSSEN ebenfalls akzeptiert werden.

Für die oben genannten Längenanforderungen muss jeder Unicode-Codepunkt als einzelnes Zeichen gezählt werden.

Es wird fortgesetzt:

Wenn Unicode-Zeichen in gespeicherten Geheimnissen akzeptiert werden, sollte der Prüfer den Normalisierungsprozess für stabilisierte Zeichenfolgen unter Verwendung der in Abschnitt 12.1 des Unicode-Standardanhangs 15 definierten NFKC- oder NFKD-Normalisierung anwenden .

Zusammenfassend: Die Verwendung von Unicode erhöht die Entropie und erleichtert Benutzern, die kein Englisch beherrschen, das Leben.