Este o idee bună să folosiți întreaga gamă Unicode pentru a genera o parolă aleatorie, mai degrabă decât intervale limitate? [duplicat] (Securitatea informațiilor, Parole, Unicode)

Persoana de entropie a intrebat.

Știu sigur că unele site-uri/aplicații cu securitate redusă restricționează parolele doar la caractere alfanumerice, iar unele permit o gamă ASCII ceva mai largă. Unele site-uri/aplicații acceptă și Unicode.

De obicei, parolele sunt menite să poată fi tastate pe orice tastatură generică, așa că sunt generate de obicei folosind caracterele disponibile în mod obișnuit. Dar pentru parolele care vor fi păstrate doar în format digital, ar fi o idee bună să se maximizeze timpul de ghicire prin utilizarea întregii game de caractere Unicode? Sau există motive pentru a crede că unele sau majoritatea site-urilor/aplicațiilor care acceptă Unicode ar putea totuși să limiteze gama de caractere permise?

Comentarii

    32

  • Ori de câte ori păstrați o parolă „numai digital” (ceea ce mie îmi sună a „manager de parole”), nu ați putea crea întotdeauna parole cu entropie ridicată fără Unicode și numai cu caractere alfanumerice? Sau, cu alte cuvinte – corectați-mă dacă greșesc: aș presupune că serviciile care vă permit să folosiți Unicode pentru parole nu au limitări stricte de lungime, prin urmare entropia nu este o problemă atunci când se folosesc caractere alfanumerice. Pe de altă parte, serviciile cu limitări de lungime nejustificate nu permit caractere Unicode. Entropia va fi o problemă în ambele cazuri. –  > Por Tom K..
  • 22

  • Ai putea folosi o parolă ceva mai lungă și să te scutești de bătăi de cap. –  > Por CodesInChaos.
  • Fiți atenți la modul în care diferite sisteme pot interpreta șirurile unicode, nu toate aplicațiile, gazdele, bazele de date etc. vor gestiona neapărat unicode în același mod: security.stackexchange.com/a/85664/36538 –  > Por Eric G.
  • Ar trebui să fiți foarte atent la serviciile pe care utilizați acest lucru. Dacă vă treziți brusc că trebuie să tastați parola pe o mașină necunoscută, s-ar putea să aveți dificultăți considerabile. Exemplul meu cel mai bun în acest sens este o situație cu care m-am confruntat de mai multe ori: a trebuit să mă conectez pentru a imprima bilete electronice la un centru de afaceri al unui hotel (acestea nu au fost puse la dispoziție decât după ce am plecat de acasă; a fost necesară imprimarea deoarece nu pot rupe jumătate de PDF de pe telefon pentru a satisface sistemul lor învechit). Pierderea consecventă poate fi destul de costisitoare –  > Por Chris H.
  • Nu că ar conta cu adevărat, dar cred că majoritatea utilizărilor de „Unicode” în întrebare și răspunsuri ar trebui să fie, din punct de vedere tehnic, „UTF-8”. (Unicode face o hartă între caractere și numere; UTF-8 face o hartă între numere și secvențe de octeți). –  > Por David Z.
14 răspunsuri
Sjoerd

Aceasta este o idee bună din punct de vedere al securității. O parolă care conține caractere unicode ar fi mai greu de forțat decât o parolă care conține caractere ASCII de aceeași lungime. Acest lucru este valabil chiar dacă comparați lungimea octetului în loc de lungimea caracterului, deoarece Unicode utilizează bitul cel mai semnificativ, în timp ce ASCII nu o face.

Cu toate acestea, cred că nu ar fi practic, deoarece bug-urile Unicode sunt atât de frecvente. Cred că, dacă folosiți parole Unicode peste tot, veți întâlni mai mult de câteva site-uri în care veți avea probleme la logare, deoarece dezvoltatorii nu au implementat corect suportul Unicode pentru parole.

Comentarii

  • Comentariile nu sunt pentru discuții extinse; această conversație a fost mutată pe chat. –  > Por Rory Alsop.
  • Ca să nu mai vorbim de faptul că diferite tastaturi din diferite localități vă vor oferi Unicode diferit. Ceea ce funcționează pe un calculator poate să nu funcționeze pe un alt calculator. –  > Por forest.
Kevin

Acest lucru sună foarte asemănător cu Fencepost Security. Imaginează-ți că ai o instalație care are un gard din sârmă de lanț în jurul ei, înalt de 500 de metri. Cât de mult s-ar îmbunătăți securitatea dacă ați face gardul de 3.000 de metri înălțime? Nimic – pentru că oricine încearcă să intre nu va urca pe cei 500 de metri; va săpa pe sub ea, va face o gaură etc.

De asemenea, aveți o parolă care are, să zicem, 20 de caractere alfanumerice aleatorii. Asta înseamnă 62^20 de posibilități. Vă gândiți să o schimbați în 20 de caractere unicode aleatoare. Ceea ce ridică spațiul de posibilități mult mai mult, cu excepția faptului că forțarea brută a unei parole cu 20 de caractere aleatoare nu este modul în care lucrurile vor fi compromise.

Comentarii

  • Îmi place ideea, dar mai multe posibilități per caracter cu aceeași lungime a șirului (în caractere) ar reprezenta probabil un gard mai gros, la fel cum ar face-o mai multe caractere ascii. –  > Por Baldrickk.
  • 15

  • @Baldrickk Majoritatea algoritmilor de hashing utilizați în mod obișnuit nu depășesc oricum 72 de octeți. O parolă de 12k octeți este la fel de sigură ca o parolă de 72 de octeți. –  > Por Ricky Notaro-Garcia.
  • @Baldrickk Cred că ceea ce se înțelege este că ceva de genul ingineriei sociale sau ocolirea schemei de autentificare este mai probabilă decât expunerea parolelor la un atac prin forță brută. –  > Por SBoss.
  • Ar trebui să precizez că prin idee – am vrut să mă refer la metaforă. Ar fi trebuit să fiu mai clar. –  > Por Baldrickk.
  • +1 pentru @RickyNotaro-Garcia Acesta este cel mai credibil și probabil (și înfricoșător) fapt pe care l-am citit de mult timp despre securitatea parolelor. Aceasta înseamnă, de asemenea, că pentru orice altceva decât o căutare prin dicționar, metoda bruteforce poate fi realizată cu orice fel de șiruri și formate de intrare, un simplu șir de cifre hexagonale va funcționa probabil dacă timpul nu are nicio importanță. –  > Por KalleMP.
Hector

Ignorând argumentul securității prin obscuritate, este o chestiune de bază a entropiei. O parolă Unicode de 8 caractere este mai sigură decât o parolă ASCII de 8 caractere, dar mai puțin sigură decât o parolă ASCII de 64 de caractere.

În general, sunt de acord cu Sjoerd – este posibil ca aceste măsuri să cauzeze mai multe inconveniente decât beneficii. În plus, dacă va trebui vreodată să introduceți manual o parolă Unicode aleatorie, este posibil ca Unicode să vă facă viața un calvar.

Cu toate acestea, pentru cazul limită în care trebuie să utilizați un serviciu care acceptă în mod activ Unicode, impunând în același timp o limită maximă a lungimii parolei (din nou, ignorarea acestui lucru indică, de obicei, alte deficiențe de securitate), există un argument în favoarea acestuia.

Comentarii

  • +1 pentru remarca privind suportul activ. Faptul că există caractere „scăpate” sau un suport mai puțin complet poate fi foarte problematic. Dacă nu poate fi utilizat în mod fiabil, atunci nu este „sigur”. –  > Por mckenzm.
  • „O parolă unicode cu 8 caractere este … mai puțin sigură decât o parolă ASCII cu 64 de caractere.” Unele sisteme trunchiază parolele la 8 caractere, caz în care o parolă unicode de 8 caractere este mai sigură decât o parolă ASCII de 64 de caractere. –  > Por Acumularea.
NH.

Singurul motiv valabil la care mă pot gândi pentru utilizarea caracterelor Unicode în parole este dacă numărul de caractere (nu de octeți) dintr-o parolă pentru un anumit site este limitat (cum ar fi această bancă proastă care anterior a avut un maxim de 10 caractere), astfel încât ar fi ușor de ghicit într-o zi sau două. În acest caz, puteți folosi Unicode (dacă proprietarii site-ului vă permit) pentru a obține mai multă entropie în parola dvs. între timp, în timp ce le cereți proprietarilor site-ului să respecte NIST 800-63-3 și să elimine restricțiile de lungime (și să efectueze o hașurare corespunzătoare, astfel încât stocarea parolei să nu fie o problemă).

Am vrut, de asemenea, să corectez o concepție greșită aici:

Unicode folosește bitul cel mai semnificativ, în timp ce ASCII nu.

Deși este adevărat pentru ASCII normal, ASCII extins pe care unii manageri de parole (de exemplu, KeePass) îl pot folosi în generarea parolelor utilizează fiecare bit al fiecărui octet, având astfel o densitate entropică mai mare chiar și decât Unicode, care are totuși o anumită structură pentru a indica câți dintre următorii octeți fac parte din același caracter (Rețineți că există este un astfel de lucru ca un secvență de octeți invalidă în Unicode).

Deoarece un site care vă limitează la parole scurte probabil că nici măcar nu-și face hash-ul corespunzător (ceea ce face ca parolele Unicode să eșueze sau să fie stocate cu o codificare greșită), nu ar trebui aproape niciodată să pierdeți timpul să vă deranjați cu parolele Unicode, deoarece în timp ce sunteți atât de distrat cu caracterele dvs. amuzante (și cu faptul că trebuie să vă resetați parola pentru că a fost stocată în mod ciudat), un atacator ar putea ghici întrebările dvs. de (in)securitate sau ar putea folosi criptografia de ciocolată pentru a obține acces la contul dvs.

Comentarii

  • În timp ce unii recomandă un caz de utilizare suplimentar („Să te dai mare în fața prietenilor tăi”), acest lucru nu este valabil deoarece parolele nu ar trebui să fie arătate prietenilor :). –  > Por NH..
  • KeePass ar putea folosi fiecare bit din fiecare octet numai dacă serverul ar folosi o codificare pe 8 biți, KeePass ar ști care este codificarea respectivă și fiecare etapă a transmisiei ar fi transparentă pe 8 biți. Din codul sursă (PwCharSet.cs) reiese că opțiunea KeePass, denumită greșit „high ANSI”, include doar caracterele U+00A1 până la U+00AC și U+00AE până la U+00FF, adică caracterele latin-1 non-ASCII imprimabile. Dacă parola este codificată ca UTF-8, entropia pe octet va fi de fapt mai mică atunci când „high ANSI” este bifată decât atunci când este debifată. –  > Por benrg.
  • (Nu că entropia pe octet contează oricum, cu excepția cazului în care parolele sunt trunchiate înainte de a fi hașurate). –  > Por benrg.
  • @Sjoerd are dreptate: ASCII este pe 7 biți. O codificare pe 8 biți ar putea include ASCII ca subset, dar nu este ASCII, ci un superset. Și există multe codificări pe 8 biți – chiar și numai în seria ISO/IEC 8859. Problema codificărilor greșite există chiar și în cazul codificărilor pe 8 biți. –  > Por Rosie F.
John Deters

Această abordare ar putea reduce securitatea generală în anumite cazuri, nu să o îmbunătățească.

Securitatea informațiilor constă în trei atribute: Confidențialitate, Integritate și Disponibilitate (atributele triada CIA). Concentrându-vă exclusiv pe unul dintre ele, puteți trece cu ușurință cu vederea importanța celorlalte.

Confidențialitatea parolelor se realizează prin principiile entropiei: cât de „de neidentificabilă” este parola dumneavoastră? Aceasta se măsoară în mod obișnuit prin dimensiunea spațiului de ghicire prin forță brută, exprimată în termeni de puteri de 2 sau de biți. Un atacator prin forță brută are o capacitate de ghicire limitată; prin selectarea unei parole mai lungi pentru a crește entropia, puteți depăși orice capacitate de ghicire cunoscută sau prezisă. Obținerea unei entropii de peste 80 de biți (sau alegeți valoarea dorită) va face ca parola să fie inaccesibilă chiar și pentru actorii de stat național. Indiferent de descrierea prea simplificată de mai sus, ideea este că depășirea a ceea ce înseamnă „la îndemână” nu contribuie semnificativ la securitatea dumneavoastră. Și nu este relevant pentru securitate dacă obțineți entropia dorită utilizând 10 caractere Unicode sau 17 caractere ASCII.

Disponibilitatea înseamnă „pot ajunge la datele mele atunci când am nevoie de ele?”. Dacă utilizați seturi complete de caractere Unicode, riscați să vă confruntați cu diverse site-uri care nu acceptă Unicode, cu browsere sau sisteme de operare care implementează Unicode în mod incorect sau cu site-uri care traduc în mod invizibil Unicode în ASCII sub acoperire. Confuzia rezultată crește riscul de a vă restricționa accesul viitor la date. Acest lucru reprezintă o potențială scădere a disponibilității viitoare.

În general, probabilitatea ca un atacator să vă forțeze în mod brut parola de 80 de biți nu este nici pe departe la fel de mare ca probabilitatea de a întâlni un site codat prost care nu gestionează corect Unicode. Prin urmare, securitatea dvs. generală ar putea fi diminuată în loc să crească.

Desigur, multe site-uri au o lungime a parolei și alte restricții care limitează dramatic entropia parolelor dumneavoastră. În aceste cazuri, utilizarea întregului set Unicode poate crește entropia parolelor, presupunând că acestea nu au alte defecte ascunse. Astfel, pe acele site-uri, s-ar putea să vă îmbunătățiți securitatea; dar este practic imposibil să vă dați seama din exterior dacă un site gestionează în mod corespunzător datele privind parolele dumneavoastră.

Comentarii

  • Având în vedere suportul slab pentru UTF-8 de multe ori, integritatea este, de asemenea, în pericol (cel puțin a parolei, poate nu și a datelor pe care parola le protejează). –  > Por NH..
  • Dacă un site vă limitează la, să zicem, 10 caractere, mă îndoiesc foarte mult că va permite 10 caractere chinezești. Imaginați-vă că site-ul unde introduceți mai întâi parola o convertește în tăcere în UTF-8 și elimină cel mai mare bit. Acum ești blocat. –  > Por gnasher729.
Tom

S-ar putea să nu fie un răspuns direct, dar dacă parola este păstrată doar în format digital, atunci ar trebui să te întrebi de ce generezi un parolă deloc, în loc de o matrice de octeți. Odată ce privești totul ca fiind pur și simplu bytes, întrebarea nu se mai aplică.

De asemenea, lungimea > complexitatea în tot ceea ce ține de parole.

Comentarii

  • Majoritatea aplicațiilor pur și simplu nu acceptă ca parolă un array arbitrar de octeți. De exemplu, încercați să puneți un octet nul în parola de pe site-ul dvs. preferat. –  > Por Dmitri Grigoriev.
  • @DmitryGrigoryev poate că Tom sugera o reprezentare HEX a matricei sale de octeți. Sursa entropiei nu poate fi determinată prin ghicire dacă există mai mult decât poate găsi un atac de dicționar. –  > Por KalleMP.
  • Nu este clar din întrebare dacă OP caută o parolă pe care să o poată introduce oriunde sau o implementare de autentificare pe care să o folosească pentru propriul site. –  > Por Tom.
Patrick Mevzek

Există un RFC referitor la problema dumneavoastră: Pregătirea, punerea în aplicare și compararea șirurilor internaționalizate reprezentând nume de utilizator și parole al cărui rezumat este:

Acest document descrie metodele actualizate de tratare a șirurilor Unicode reprezentând nume de utilizator și parole. Abordarea anterioară era cunoscută sub numele de SASLprep (RFC 4013) și se baza pe Stringprep (RFC 3454). Metodele specificate în acest document oferă o abordare mai sustenabilă pentru gestionarea numelor de utilizator și a parolelor internaționalizate.

Dacă citiți limba franceză, puteți găsi, de asemenea, o explicație bună a acesteia aici: http://www.bortzmeyer.org/8265.html.

Secțiunea 8 din RFC se ocupă în mod special de securitatea parolelor care utilizează „orice” caracter unicode, cu următoarele secțiuni:

  • 8.1. Rezistența parolei/frazei de acces
  • 8.2. Compararea parolei/frazei de acces
  • 8.3. Comparație între identificatori
  • 8.4. Reutilizarea PRECIS
  • 8.5. Reutilizarea Unicode

Comentarii

  • Aceasta. implementare a Unicode este incredibil greu și lucruri precum utilizarea unei normalizări definite sunt esențiale pentru a avea măcar o șansă de a o face să funcționeze. –  > Por Dubu.
Boldewyn

În plus față de celelalte răspunsuri bune, vreau doar să subliniez următoarele ceea ce poate merge prost de-a lungul țevii cu utilizarea întregului set Unicode pentru parole.

Presupunând că folosiți la întâmplare un șir UTF-8 mai mult sau mai puțin valid,

  • există caractere interpretate ca întreruperi de linie în mijlocul planului de bază multilingv precum U+2029 Separator de paragraf. Puteți accesa s-ar putea să nu le puteți introduce într-un câmp simplu <input> câmp simplu.
  • există atât caractere de spațiere care pot fi sau nu eliminate de către o limbă. trim() de o limbă
  • dacă se întâmplă să folosiți caractere surogat (U+D800-U+DFFF), non-caractere cum ar fi U+FDD0, , Caractere de uz privat sau caractere neatribuite (deși sunt secvențe UTF-8 valide), comportamentul oricărui set de instrumente este practic nedefinit (eliminare, înlocuire, respingere, nu face nimic sau orice combinație a acestora).
  • dacă se întâmplă să adăugați diacritice, orice instrument în curs de utilizare ar putea schimba acest lucru în NFC sau NKD modificând octeții din parolă.
  • și asta doar din capul locului. Sunt sigur că am uitat o mulțime de alte probleme posibile, dacă parolele sunt alese din întreaga gamă Unicode.

Deci, similar cu ceea ce a sugerat @JohnDeters, ar putea fi o idee proastă, deoarece avantajul unui spațiu sursă mai mare este contrabalansat de părțile mobile ale prelucrării textului pe parcurs.

gnasher729

Ceea ce contează pentru securitate este entropia parolei – câți biți de informație reală există în parolă.

Cealaltă parte a problemei este cât de dificil este să ții minte parola și să o tastezi. Imaginați-vă că încercați să introduceți parola pe un iPhone și vă dați seama că nu puteți (nu am verificat cât de greu este să introduceți caractere Unicode arbitrare). Sau vă dați seama că este foarte, foarte greu să o introduceți 100% corect. Sau pur și simplu îți ia o veșnicie – s-ar putea să am o parolă cu aceeași entropie și cu mai multe caractere, dar de două ori mai rapid de tastat. Iar tu ai nevoie de patru încercări pentru a o nimeri, în timp ce a mea este corectă din prima.

Luis Casillas

Alții au remarcat pe larg riscul ca serviciile pentru care folosiți aceste parole să nu implementeze corect Unicode. Eu aș adăuga că serviciile care astăzi o fac ar putea mâine să înceteze să mai facă acest lucru, dar în rest voi trece peste acest subiect.

Un element care cred că trebuie luat în considerare aici este să ne întrebăm: cât de lungă trebuie să fie o parolă pentru a atinge un anumit nivel de securitate? Să presupunem că dorim ca parolele noastre să fie la fel de puternice ca o cheie criptografică de 128 de biți (care este probabil exagerată pentru majoritatea parolelor de pe site-uri web; eu recomand 80 de biți). Dacă vă limitați la parole ASCII aleatorii, atunci o parolă de 19 caractere extrasă din cele ~95 de caractere ASCII imprimabile atinge acest nivel. (Matematica: un set de aproximativ 100 de elemente are aproximativ 6,6 biți/element (deoarece log2(10) ≈ 3,3, iar log2(100) este de două ori mai mare), iar 128 ÷ 6,6 ≈ 19,4. Deci 19 caractere ASCII reprezintă de fapt aproximativ 126 de biți, nu 128, dar mă rog).

Unicode are în prezent aproximativ 130 000 de puncte de cod definite, un număr pe care îl vom aproxima ca fiind 2^17. Aceasta înseamnă că pentru a ajunge la nivelul de 128 de biți aveți nevoie de 7 puncte de cod Unicode (128 ÷ 17 ≈ 7,5, deci 7 puncte de cod înseamnă doar aproximativ 119 biți, dar, din nou, meh.).

Pentru nivelul de securitate de 80 de biți, care cred că este mai sensibil pentru majoritatea site-urilor web, este vorba de 12 caractere ASCII față de 5 puncte de cod Unicode.

Sunteți dispus să vă asumați o lovitură masivă în ceea ce privește utilizabilitatea și să riscați să aveți erori pe site doar pentru a avea parole de 5 sau 7 caractere în loc de 12 sau 19 caractere? Pur și simplu nu cred că merită.

JonnyRobbie

Ei bine, Unicode este „doar” o listă de ceva mai mult de 130000 de caractere. UTF-8 este cea mai comună codificare care ia acel număr mare și îl „convertește” într-un număr de bază 256 (sau, mai exact, regulile au mai mult sens în octeți binari) conform unui set de reguli. Astfel, dacă doriți să folosiți o codificare utf-8, veți fi legat de o mulțime de reguli, ceea ce reduce efectiv caracterul aleatoriu pe care l-ați putea dori. Și nu știu cum ai putea să folosești întreaga interpretare Unicode.

Dacă nu sunteți preocupat de caracterele imprimabile, ați putea lua în considerare întregul ASCII (sau, mai degrabă, o extensie pe 8 biți), dar, în acest moment, de ce să vă mai deranjați cu standardul de interpretare a caracterelor? Nu ați putea utiliza o structură binară aleatorie simplă și fără formă?

David M

Chiar dacă folosiți doar stocarea digitală, nu mi-ar plăcea să fiu utilizatorul care trebuie să tasteze ceva și nu recunoaște diferența dintre ( și (. (Indicație: sunt cu spațiere dublă și simplă).

Folosind acest exemplu sensibil la lățime, după cum s-a observat în alte răspunsuri, vă așteptați ca suportul acestora să funcționeze – în funcție de colarea SQL setată aici, ar avea o parolă incorectă fiind corectă!

allo

Nu. Doriți să măriți baza unei funcții exponențiale, riscând în același timp să se spargă o mulțime de lucruri (de exemplu, dispozitive care nu pot tasta caracterele dvs. speciale etc.). calculați entropia parolei unicode și faceți parola ascii mai lungă până când are mai multă entropie.

a-z singur este 26^(lungime). să zicem că obțineți 256^(length) și eventual 2 octeți per caracter cu unicode. Atunci puteți găsi punctul de echilibru 26^(ascii_length) > 256^(2*unicodelength) undeva. Alegeți această lungime ca ascii_length și veți putea în continuare să vă scrieți parola și să aveți aceeași securitate.

Dacă site-ul nu acceptă parole lungi (rușine pentru ei), bănuiesc că nu pot garanta nici un suport bun pentru unicode. Poate că vei fi blocat data viitoare când vor actualiza vreo bibliotecă internă. Deci, de ce să riscați o problemă acolo? Și o problemă, care este greu de explicat suportului pentru utilizatori, care abia știe ce înseamnă unicode.

Jonathan Rosenne

Nu este o idee bună să generați parole Unicode aleatorii, deoarece parola generată poate fi ilizibilă pentru utilizator. Dar textul întrebării vorbește despre utilizarea parolelor Unicode, iar aceasta este o idee bună și este recomandată de NIST 800-63-3 secțiunea 5.1.1.1.2 Verificatori secreți memorizați care spune:

Verificatorii TREBUIE să solicite ca secretele memorate alese de abonat să aibă o lungime de cel puțin 8 caractere. Verificatorii TREBUIE să permită secrete memorizate alese de abonat cu o lungime de cel puțin 64 de caractere. Toate caracterele de tipar ASCII [RFC 20], precum ș i caracterul spațiu TREBUIE să fie acceptate în secretele memorate. Caracterele Unicode [ISO/ISC 10646] TREBUIE să fie, de asemenea, acceptate.

În sensul cerințelor de lungime de mai sus, fiecare punct de cod Unicode TREBUIE să fie considerat ca un singur caracter.

Acesta continuă:

În cazul în care caracterele Unicode sunt acceptate în secretele memorate, verificatorul TREBUIE să aplice procesul de normalizare pentru șiruri stabilizate, utilizând fie normalizarea NFKC, fie NFKD definită în secțiunea 12.1 din anexa 15 la standardul Unicode.

Pentru a rezuma: Utilizarea Unicode sporește entropia și ușurează viața utilizatorilor care nu cunosc bine limba engleză.

Comentarii

  • Ați putea detalia ce adaugă acest lucru la celelalte răspunsuri? –  > Por Tom K..
  • Am subliniat diferența dintre generarea unei parole Unicode și alegerea uneia și faptul că entropia nu este redusă, așa cum susțin alte răspunsuri, ci crescută, deoarece ar trebui să se numere caracterele și nu biții. De asemenea, NIST nu numai că permite Unicode, ci chiar recomandă utilizarea acestuia, ceea ce reprezintă un răspuns direct la întrebare. –  > Por Jonathan Rosenne.