it-swarm.com.de

Ist es eine gute Idee, den gesamten Unicode-Bereich zu verwenden, um ein zufälliges Passwort zu generieren, anstatt begrenzte Bereiche?

Ich weiß, dass einige Websites/Apps mit geringer Sicherheit Kennwörter nur auf alphanumerische Zeichen beschränken und andere einen etwas breiteren Bereich ASCII) zulassen. Einige Websites/Apps unterstützen auch Unicode.

Kennwörter können normalerweise auf jeder allgemeinen Tastatur eingegeben werden. Sie werden daher normalerweise mit den allgemein verfügbaren Zeichen generiert. Wäre es jedoch für Passwörter, die nur digital gespeichert werden, eine gute Idee, die Schätzzeit durch Verwendung des gesamten Unicode-Zeichenbereichs zu maximieren? Oder gibt es Gründe zu der Annahme, dass einige oder die meisten Unicode-unterstützenden Websites/Apps ihren zulässigen Zeichenbereich noch einschränken könnten?

55

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

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.

78
Sjoerd

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.

116
Kevin

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

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

Für den Edge-Fall, in dem Sie einen Dienst verwenden müssen, der Unicode aktiv unterstützt und gleichzeitig eine maximale Kennwortlängenbeschränkung erzwingt (dies wiederum zu ignorieren, weist normalerweise auf andere Sicherheitslücken hin), gibt es ein Argument dafür.

21
Hector

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 max von 10 Zeichen), so dass es in ein oder zwei Tagen leicht zu erraten wäre. 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- und einzuhalten Längenbeschränkungen entfernen (und Hash ordnungsgemäß, damit das Speichern von Passwörtern kein Problem darstellt).

Ich wollte hier auch 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 hat somit eine höhere entropische Dichte als sogar Unicode, das immer noch eine Struktur aufweist, die angibt, wie viele der folgenden Bytes sind Teil desselben Zeichens (Beachten Sie, dass es so etwas wie eine ngültige Bytesequenz in Unicode gibt ).

Da eine Site, die Sie auf kurze Kennwörter beschränkt, ihre Kennwörter wahrscheinlich nicht richtig hasht (was dazu führt, dass Unicode-Kennwörter fehlschlagen oder mit der falschen Codierung gespeichert werden), sollten Sie fast nie die Zeit damit verschwenden, sich mit Unicode-Kennwörtern zu beschäftigen, weil Sie dies tun Abgelenkt von Ihren lustigen Charakteren (und der Tatsache, dass Sie Ihr Passwort zurücksetzen müssen, weil es seltsam gespeichert wurde), könnte ein Angreifer Ihre (in) Sicherheitsfragen erraten oder Schokoladenkryptographie) verwenden um Zugriff auf Ihr Konto zu erhalten.

14
NH.

Dieser Ansatz könnte Ihre Gesamtsicherheit in bestimmten Fällen verringern und nicht verbessern.

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

Die Vertraulichkeit von Passwörtern wird durch die Prinzipien der Entropie erreicht: Wie "nicht zu erraten" 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 meine Daten bei Bedarf abrufen?" 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 unter) übersetzen Die daraus resultierende Verwirrung erhöht das Risiko, Ihren zukünftigen Zugriff auf die Daten einzuschränken. Dies bedeutet eine potenzielle Verringerung der zukünftigen Verfügbarkeit.

Im Allgemeinen ist die Wahrscheinlichkeit, dass ein Angreifer Ihr 80-Bit-Passwort erzwingt, nicht annähernd so hoch wie die Wahrscheinlichkeit, auf eine schlecht codierte Site zu stoßen, die Unicode nicht richtig verarbeitet. 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.

10
John Deters

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

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

3
Tom

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 zum Umgang mit Unicode-Zeichenfolgen beschrieben, 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 Passwö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. Stärke des Passworts/der Passphrase
  • 8.2. Passwort/Passphrase-Vergleich
  • 8.3. Identifikatorvergleich
  • 8.4. Wiederverwendung von PRECIS
  • 8.5. Wiederverwendung von Unicode
3
Patrick Mevzek

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

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

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

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

2
Boldewyn

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 nicht mehr tun, aber ansonsten überspringe ich dieses Thema.

Ein Element, das meiner Meinung nach hier berücksichtigt werden muss, ist die Frage: 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 Passwörter) halten, erreicht ein 19-stelliges Passwort, das aus den ~ 95 druckbaren ASCII Zeichen) gezogen wird, diese Ebene. (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. Also 19 ASCII Zeichen ist eigentlich ungefähr 126 Bit, nicht 128, aber 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 sind 7 Codepunkte nur etwa 119 Bit, aber wiederum meh.)

Für die 80-Bit-Sicherheitsstufe, die meiner Meinung nach für die meisten Websites sinnvoller ist, sind es 12 ASCII Zeichen vs. 5 Unicode-Codepunkte).

Sind Sie bereit, einen massiven Usability-Hit zu erleiden und Website-Fehler zu riskieren, nur damit Sie Passwörter mit 5 oder 7 Zeichen anstelle von 12 oder 19 Zeichen haben können? Ich denke einfach nicht, dass es das wert ist.

1
Luis Casillas

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 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.

1
gnasher729

Es ist keine gute Idee, zufällige Unicode-Passwörter zu generieren, da das generierte Passwort für den Benutzer möglicherweise nicht lesbar ist. Im Text der Frage geht es jedoch um die Verwendung von Unicode-Passwörtern. Dies ist eine gute Idee und wird im Abschnitt 5.1.1.2 Memorized Secret Verifiers NIST 800-63-3 empfohlen.

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 Druckzeichen ASCII [RFC 20]) sowie das Leerzeichen MÜSSEN in gespeicherten Geheimnissen akzeptiert werden. Unicode-Zeichen [ISO/ISC 10646] MÜSSEN ebenfalls akzeptiert werden.

Für die Zwecke der obigen Längenanforderungen MUSS jeder Unicode-Codepunkt als ein einzelnes Zeichen gezählt werden.

Es geht weiter:

Wenn Unicode-Zeichen in gespeicherten Geheimnissen akzeptiert werden, MUSS 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.

0

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 warum sollten Sie sich an diesem Punkt überhaupt mit dem Standard für die Zeicheninterpretation beschäftigen? Verwenden Sie dann nicht einfach eine einfache formlose zufällige Binärstruktur?

0
JonnyRobbie

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 voneinander getrennt) nicht erkannt hat.)

Wenn Sie dieses Beispiel für die Breite verwenden, wie in anderen Antworten angegeben, wird erwartet, dass die Unterstützung dieser Beispiele funktioniert. Abhängig von der hier festgelegten SQL-Sortierung ist ein falsches Kennwort korrekt!

0
David M

Nein. Sie möchten die Basis einer Exponentialfunktion erhöhen und gleichzeitig riskieren, dass viele Dinge kaputt gehen (d. H. 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.

a-z Allein ist 26 ^ (Länge). Nehmen wir an, Sie erhalten 256^(length) 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 notieren und haben die gleiche Sicherheit.

Wenn die Site keine langen Passwörter unterstützt (schade), würde ich vermuten, dass sie auch keine gute Unicode-Unterstützung garantieren können. 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, die kaum weiß, was Unicode bedeutet.

0
allo