it-swarm-eu.dev

Proč zakázat speciální znaky v hesle?

Viníkem je v tomto případě konkrétní (a zvláště velká) banka, která ve svých heslech nepovoluje speciální znaky (jakéhokoli druhu): Just [a-Z 1-9]. Je pro to nějaký platný důvod? Zdá se být kontraproduktivní zakládat takovou sílu hesla, zejména pro systém chránící takové cenné informace.

Jediná věc, se kterou jsem byl schopen přijít, je slabý pokus o zmaření SQL injekcí, ale to by předpokládalo, že hesla nejsou hashována (což, jak doufám, není pravda).

68
Gary

Jedno vysvětlení, které jsem zde neviděl, je, že mnoho finančních institucí je pevně integrováno se staršími systémy a je vázáno na omezení těchto systémů.

Ironií tohoto je, že jsem viděl systémy, které byly vytvořeny tak, aby byly kompatibilní se staršími systémy, ale nyní jsou starší systémy pryč a politika musí stále existovat pro kompatibilitu s novějším systémem, který byl postaven tak, aby byl kompatibilní se starším systémem.

(lekce je, že pokud musíte být kompatibilní se starým systémem, umožněte některá budoucí omezení těchto omezení).

65
Mark Burnett

A co náklady na podporu? Řekněme, že jsme každému povolili vytvořit heslo, které se skládá z chars. Hurá, v našich heslech jsme schopni použít speciální znaky. Ale počkejte - jak na zemi můžeme toto heslo zadat, pokud chceme získat přístup do naší banky z mobilního telefonu? Je jednodušší napsat z naší klávesnice než z mobilního telefonu.

A co prázdniny? Jsme ve Velké Británii, která má přístup pouze k britské klávesnici. Namísto můžeme snadno napsat £. Slovo easily je zde velmi důležité. Pro některé průměrné uživatele může být zadávání znaků pro „novou“ klávesnici problém. Jak se to bude snažit vyřešit? Pravděpodobně zavolá bankovní podporu a požádá je o změnu hesla nebo požádá why the € character dissapeared from his keyboard.

13
p____h

To může být (slabě) odůvodněno jako opatření do hloubky ochrany - pokud dojde k chybě injekce nebo jiné interpretace dat, může být omezením sady znaků a délky hesla možné zabránit zneužití. Také to trochu zjednodušuje implementaci, protože pokud se zabývají pouze 7bitovými ASCII znaky), zpracování Unicode a vícebytových řetězců znaků je irelevantní a jednodušší implementace jsou zpravidla méně pravděpodobné, že obsahují chyby.

Posouzení tohoto sníženého rizika vzhledem ke zvýšenému riziku v důsledku nižší kvality hesla však není jednoduché - očekával bych, že se zvyšujícím se počtem uživatelů systému narůstá také počet hesel, která by mohla být ohrožena, čímž dojde k investici do zrušení takových hesel. omezení stojí za to. Vše, co bylo řečeno, hesla většiny uživatelů budou hrozná, i když je pole zcela neomezené.

12
D Coetzee

Můj odhad je, že pro všechna pole zadaná uživatelem existuje zásada a stejná zásada zadávání uživatele (bez zvláštních znaků) byla použita pro pole včetně hesel pro jednoduchost. Nebo v nějakém okamžiku některá banka neměla hashovací hesla a měla útok SQLi skrz jejich pole pro heslo a bylo rozhodnuto o tom, že hesla nemohou mít speciální znaky (a důvod této politiky byl zapomenut, jakmile bylo zavedeno hašování).

Určitě je výhodou zabezpečení nepovolení zvláštních znaků v jiných uživatelsky zadaných polích, které nejsou hashed a mohly by být použity pro různé útoky, jako je SQLi nebo XSS (na správce banky při pohledu na účet). Tyto hrozby jsou však obecně řešeny vždy pomocí vázaných parametrů v SQL a vždy dezinfikováním vstupu uživatele před zobrazením/uložením do db.

Můj další odhad je, že chtějí mít vlastní pravidla, která se mohou lišit od jiných míst, takže nemůžete snadno znovu použít standardní silné heslo (které se může ztratit), a musí přijít s něčím jedinečným pro své stránky.


ÚPRAVA: Na základě dalšího myšlení si v závislosti na jazyce dokážu představit alespoň tři speciální ASCII znaky, které by měly být všeobecně zakázány/odizolovány, protože jim umožňují pouze pokušení osudu. Konkrétně: \0 (null - ascii 0), protože se obvykle používá k označení konce řetězce v jazycích ve stylu C (možná uživatelé změní paměť po konci řetězce). Také návraty vozíku a řádkové zdroje \r (ascii 13) a \n (ascii 10), protože jsou často závislé na systému, zda jsou konce řádků \r\n nebo \n a to vyvolává nevyhnutelné, mohu se přihlásit pouze z oken, ne z mého počítače Mac/linux. Ve skutečnosti se zdá docela rozumné povolit pouze tisknutelný ASCII (32-126) a zakázat netisknutelný ASCII 0-31 a 127.

Pokud však speciální znaky znamenají unicode ne ASCII znaky (jako ,./<>?;':"[]{}\|[email protected]#$%^&*(-=_+ Zdá se rozumné, aby jednoduchost implementace z více operačních systémů/klávesnic/prohlížečů neumožňovala speciální znaky. Představte si, že vaše heslo obsahuje malé pí. Bylo to, že řecký pi (π), který je kódovým bodem 0x3c0, nebo koptské malé písmeno pi (ⲡ), který je kódovým bodem 0x2ca1 - bude fungovat pouze jeden a tento typ problému podobných znaků s různými kódovými body bude existovat v unicode. Váš hash, který pracuje na bitech, nebude schopen vyrovnat dva π, takže pokud se pokusíte přihlásit na různých místech, můžete zadat různé znaky.

Podobně, i když je tento problém jedním problémem, může programátor do značné míry ovládat a pokusit se o opravu, umožnění znaků unicode vytváří problémy s kódováním. To je pro vaše základní ASCII znaky vše reprezentované jedním bajtovým číslem. Existuje však spousta různých schémat, jak kódovat unicode. Je to UTF-7, UTF-8, UTF-16, UTF-32, Latin-1 (iso-8859-1), kódování Latin-N a (pro některá kódování) jaký je pořadí bytů (malý nebo velký endian) ? Kódový bod unicode pro pi (0x3c0) by byl reprezentován jako bajty 2b 41 38 41 2d v UTF-7, CF 80 v UTF-8, FF FE c0 03 v UTF-16 a FF FE 00 00 c0 03 00 00 v UTF-32. Nebyli byste schopni reprezentovat pí v latině-1 (má pouze 95 dalších tisknutelných znaků), ale pokud jste měli A1 ve vašem hesle a byly v různých kódováních, budete ho muset reprezentovat z některého z následujících znaků ¡ĄĦЁ‘ก”Ḃ (které v některých latinsko-N může A1).

Ano, webová stránka může mít definovanou znakovou sadu, ale uživatelé ji mohou přepsat na stránce v prohlížeči nebo zkopírovat a vložit data z jiného místa do jiného kódování. Na konci dne může být jednodušší tyto postavy jen zakázat.

9
dr jimbob

Jako zobecnění zde uvádíme nejčastější důvody, proč finanční instituce omezují délku a složitost znakové sady.

(1) Webové služby jsou systémy front-end ke starým aplikacím sálových počítačů, které mají často osmimístné omezení tvořené pouze malými písmeny alfa a čísly. Žádné „speciální znaky“. Zvláště to je nejčastější omezení. +1 na Mark Burnett výše.

(2) Nejsou hashovací hesla, takže nemohou jednoduše uložit číselný řetězec pevné délky (tj. Hashový výstup - 32 bajtů SHA256 (heslo)). Proto se musí obávat omezení velikosti vstupu.

(3) Vektor hrozby injekce SQL je problém s heslem, pouze pokud jsou hesla uložena jako prostý text. Mnoho organizací a dalších ztrácí čas starostí s únikem znaků hesla, když je problém okamžitě vyřešen uložením hashovaného hesla (ideálně solené a natažené pomocí něco jako PBKDF2).

Kromě upřednostnění jednoduchého resetování hesla pro zákaznickou podporu PŘI BEZPEČNÉMU NABÍDKU NEJSOU přijatelný důvod, o kterém jsem si vědom, že by bylo možné zaslat uživatelské heslo ve formě prostého textu z uživatelského zařízení. Nechcete odpovědnost, takže nikdy nepřijímejte. To jsou kryptografické hashe.

Zde je skvělý blogový příspěvek, který shrnuje některé doporučené postupy a obsahuje ukázky kódu. http://crackstation.net/hashing-security.htm

4
OnTheShelf

Vlastně jsem se zeptal na velký webový obchod, který (bol.com, nejsem si jistý, zda jsou mezinárodní).

Jejich rada je používat silné heslo, měnit jej často, používat písmena a čísla, že by měla být dlouhá a možná nějaké další věci, na které jsem zapomněla. Každopádně následuje obvyklá rada, která nikdo. Zdá se však, že jim záleží na zásadách týkajících se hesla.

Přesto neumožňují většinu speciálních znaků a maximální délka hesla je 12 znaků. Na požádání mi řekli, že jinak by příliš mnoho lidí kontaktovalo podporu.

Když jsem je poslal zpět, abych se zeptal, co je „Zapomněli jste heslo?“ funkce byla pro, nemám žádnou odpověď ...

Takže pro banky, kde je jednoduché resetování hesla e-mailem vyloučeno, myslím, že náklady na podporu jsou opravdu důvodem (jak zde navrhují ostatní). Pro jakékoli jiné webové stránky, jako je tento bol.com, bych velmi nedůvěřoval, zda mají hash svá hesla. Měli byste použít jedinečnější heslo, pokud databáze uniká, vaše heslo bude známo.

2
Luc

Omezení znakové sady na alfanumeriku omezuje pravděpodobnost skriptu nebo zneužívá možnost překonat fázi ověření vstupu.

Uživatel může vždy zlepšit své zabezpečení pomocí delších hesel, ale aplikace musí mít specifický whitelist, který pomůže předcházet útokům.

1
Rory Alsop

Mohu se pokusit podat svůj názor na výše uvedený problém jako návrháře rozhraní uživatelského rozhraní a ne jako programátora: klíčovým bodem je, že požadavek na přihlášení je částečně problémem návrhu rozhraní uživatelského rozhraní, nikoli problém pouze s programováním.

K dispozici je vynikající kniha „Apress - Návrh uživatelského rozhraní pro programátory“, která ukazuje analogický problém související s velikostmi oken, který zveřejním níže:

Zde je obvyklý vzorec programátorského myšlení: existují pouze tři čísla: 0, 1 a n. Pokud je n povoleno, všechny n jsou stejně pravděpodobné. Tento myšlenkový vzor vychází ze staré konvence kódování (pravděpodobně inteligentní), že byste neměli mít v kódu žádné číselné konstanty, kromě 0 a 1.

Nyní je výše uvedené myšlení správné pouze v problémech s programováním, ale protože se týká uživatelských rozhraní a zejména oken, není

Ale není to pravda. Jak se ukazuje, není stejně pravděpodobné. Existuje mnoho dobrých důvodů, proč byste mohli chtít okno přesně v horní části obrazovky (maximalizuje se tak realita obrazovky), ale ve skutečnosti neexistují žádné důvody, proč ponechat dva pixely mezi horní částí obrazovky a horní částí okna. . Ve skutečnosti je tedy 0 mnohem pravděpodobnější než 2.

Nyní, když se dostáváme k našemu problému, by teoreticky měly být všechny znaky stejně pravděpodobné a stejně přípustné z programovacího i formálního hlediska, ale jsme zde také v instanci problému rozhraní UI a musíme si toho být vědomi a dát jí správnou váhu .

Takže parafrázuji odpověď z vlákna, nad kterým je podle mého názoru správná:

Řekněme, že jsme každému umožnili vytvořit hesla, která obsahují znak €. Hurá, v našich heslech jsme schopni použít speciální znaky. Ale počkejte - jak na zemi můžeme toto heslo zadat, pokud chceme získat přístup do naší banky z mobilního telefonu? Je snazší psát € z naší klávesnice než z mobilního telefonu.

To je hlavní bod z hlediska použitelnosti a neměli bychom za to vinu uživateli, pokud si o několik let později uvědomí chytrý telefon, když roky předtím, než vůbec neexistovaly, použil postavu, které by se měl vyhnout.

Je naší povinností myslet na tento typ problémů a nechat uživatele, aby se mu vyhnul!

0
dendini

Trochu pozdě na párty - nedávno jsem četl, že důvodem je to, že pro mnoho bank je hodnota zvýšené bezpečnosti umožňující těmto znakům vyvážena náklady na implementaci a náklady na podporu jednání se zákazníky, kteří si nemohou pamatovat jejich hesla .

Neříkám, že je to dobrý důvod, ale tak jsem interpretoval to, co jsem četl.

http://www.theglobeandmail.com/technology/digital-culture/why-canadas-banks-have-weaker-passwords-than-Twitter-or-google/article18325257/

0
Steve Campbell