Otázka:
Generovat uživateli místo požadavku heslo?
AndrewX192
2012-12-26 10:44:31 UTC
view on stackexchange narkive permalink

Pokouším se zvážit výhody nepovolení vytváření vlastních hesel uživateli, ale musím si vybrat z vygenerovaného výběru. Existují nějaké příklady webů, které používají tento přístup?

Úpravy pracovního postupu pro takový web by byly v souladu s:

Registrace: uživatel je vyzván k výběru vygenerovaných hesel pro jejich účet. Obnovení hesla: uživatel je vyzván k výběru hesla ze seznamu vygenerovaných hesel po kliknutí na odkaz pro obnovení hesla v jeho e-mailu nebo SMS.

Za předpokladu, že tento systém byl spojen s pokyny, jak používat správce hesel nebo jiný systém pro zapamatování hesla, stálo by to za implementaci na nový web?

O jaký typ systému jde? Zásady hesel nejsou univerzální. To, co je dobré pro pracovní počítač, nemusí být nutně dobré pro heslo fóra atd.
Osm odpovědi:
Thomas Pornin
2012-12-28 00:48:07 UTC
view on stackexchange narkive permalink

Generování hesel pro uživatele znamená, že získáte dobrá hesla. Zabezpečení je však všeobjímající věc; také potřebujete, aby si uživatelé hesla pamatovali a neuchovávali je nejistě (tradiční poznámka pod klávesnicí), a obecně řečeno, potřebujete, aby uživatel spolupracoval . Je jen málo horšího, co můžete udělat, než přeměnit uživatele na nepřátele.

Dobrou věcí tedy je poskytnout volitelné heslo. generátor: tlačítko, na které může uživatel kliknout, aby získal silné, náhodně generované heslo, které může použít. Ale nevynucujte to: v opačném případě se uživatelé stanou nepřátelskými a nepřátelští uživatelé jsou velmi kreativní, pokud jde o práci s bezpečnostními funkcemi.

Je třeba mít na paměti několik zásad při generování uživatelských hesel:

  • Nepřehánějte to. Víme, že váš generátor hesel může vytvářet hesla s 37 náhodnými znaky. Ale opravdu opravdu potřebujete, aby uživatelé hesla přijali.

  • Nechte uživatele zadat heslo. Hesla si pamatujete prsty. Pokud může uživatel heslo jednoduše vybrat pomocí tlačítka nebo jej zkopírovat a vložit, zadá jej v době registrace bez zadávání a o 90 sekund později jej úplně zapomene. Zapomenutá hesla jsou čas navíc na helpdesku. Zabránění kopírování a vložení znamená, že heslo bude muset být na obrazovce zobrazeno jako soubor obrázků, nikoli jako volitelný text.

  • Dejte si pozor na procházení přes rameno. Pokud uživatel vygenerované heslo uvidí, zobrazí se na obrazovce heslo. V mnoha situacích (zejména v pracovním prostředí) nemůže uživatel prakticky zabránit kolegům se záludnými očima v příležitostném prohlížení. Z tohoto důvodu jsou pole pro zadávání hesel zakryta a stejný důvod platí i zde.

Ali Ahmad
2012-12-26 11:50:26 UTC
view on stackexchange narkive permalink

Myslím, že testování vaší strategie hesel pomocí testovacího prostředí zahrnujícího alespoň 50–100 účastníků může poskytnout nějaké odpovědi. Vždy nejde o bezpečnost, ale o chování lidí, jak reagují na změny. Následuje průzkum o tom, jak lidé uvažují o nezabezpečených heslech

  • je snazší si je zapamatovat
  • Máme příliš mnoho účtů
  • Stejné heslo pro stejnou kategorii / třídu webů
  • je to nedůležitý web
  • jinak příliš obtížné
  • používat jedno heslo pro všechny weby
DCG
2012-12-27 03:17:08 UTC
view on stackexchange narkive permalink

Myslím, že je důležité zvážit, kdo bude tento web používat. Děti a senioři pravděpodobně nemohli tento typ bezpečnostního opatření využít. Zatímco web zaměřený na IT profesionály by mohl být dokonalým místem pro změnu (ne) bezpečnostního paradigmatu souvisejícího s hesly.

Matt
2012-12-28 00:04:29 UTC
view on stackexchange narkive permalink

Pokud uživatel nemá silnou touhu komunikovat s vaším systémem, očekávám, že by v případě nové služby šel ke konkurenci nebo by se bez ní obešel. Možná budete schopni získat trakci, pokud je účet mimořádně cenný (příklady: banka nebo obchodní hostingová služba).

Přechod na správce hesel pouze pro váš systém by pravděpodobně nestačil; uživatel pravděpodobně zapomene, jak získat své heslo (nebo jakýkoli proces), pokud jej často nepoužívá. Co byste potřebovali, je, aby uživatelé přešli na používání správce hesel pro všechny.

Uživatelé by také potřebovali přístup k tomuto správci hesel všude, protože všechna jejich hesla jsou nyní náhodné řetězce, v které nemají žádnou naději. pamatovat. U počítačů, které nevlastní (práce / klient nebo přátelé / rodina), potřebují získat heslo bez nainstalovaného obsahu, takže potřebujete telefonní aplikaci (a předpokládáme, že uživatel má chytrý telefon).

Bylo by skvělé, kdyby každý používal náhodná a jedinečná hesla pro každý systém, ke kterému se přihlašuje. Očekávám také, že je to ve většině případů nepraktické.

Keverw
2012-12-26 10:52:06 UTC
view on stackexchange narkive permalink

Myslím, že by to mohlo stát za to pro některé kritické obchodní aplikace, bankovní aplikace, možná i pro hostování ovládacích panelů. Ale myslím, že někteří spotřebitelé a ostatní se tím naštvou a možná nebudou chtít registraci. Možná byste měli udělat uživatelské rozhraní, kde máte automaticky generovaná dobrá hesla a poznámky o nich vlevo, ne vpravo nebo mít malý odkaz pro ruční zadání hesla. Možná zkontrolujete, zda je to silné heslo, například některé požadavky a některé krátké snadno srozumitelné vzdělávací informace v okolí. Jako by hybridní přístup fungoval lépe. Ještě jsem nic takového neviděl, takže to vypadá jako nový a jedinečný nápad.

Použitelnost a bezpečnost mají vždy kompromis. Nemůžeme navrhnout bezpečný systém bez kompromitovatelnosti použitelnosti a je to pěkný článek o tom Bruce Schneier http://www.schneier.com/blog/archives/2009/08/security_vs_usa.html.
Nechci, aby tento systém byl efektivní, pokud jej bude možné obejít (stejně jako všechny ostatní bezpečnostní systémy). Zdá se, že by bylo zapotřebí mít úplné řešení „problému s heslem“, jak jsem uvedl v dalších komentářích k této otázce.
Deer Hunter
2012-12-26 18:41:23 UTC
view on stackexchange narkive permalink

Mám několik pochybností:

  • Je schéma generování hesel, které používáte, skutečně náhodné a nerozbitné?
  • Lze vygenerovaná hesla obnovit z pomocných informací, jako je čas registrace atd. ? To, co ve skutečnosti děláte, je snižování entropie pro útočníka, který by musel namísto plnohodnotného slovníkového útoku vyzkoušet tři možnosti.
  • Odcizíte určitý podíl uživatelů, kterým se nelíbí lžíce - řešení kritická z hlediska bezpečnosti.
  • Mohou vám vzniknout právní rizika (nejsem právník), pokud dojde k narušení přístupu a klienti vy obviní, že jste nedbalou stranou.

Vzhledem k výše uvedeným čtyřem položkám by se obecně nedoporučovalo nabízet uživatelům generovaná hesla.

V současné době nic neimplementuji (jedná se spíše o výzkumné téma) a # 1 a # 2 se zdají implementační specifické. Více se obávám posledních dvou bodů. # 3 závisí na situaci, myslím, že by to mohlo mít lepší výsledky v podnikovém IT prostředí. Nejsem ani právník, ale rád bych se dozvěděl více o # 4.
@AndrewX192 Z pohledu výzkumu si přečtěte několik článků ze IEEE Symposium o použitelném soukromí a zabezpečení (SOUPS). Ve výzkumu existuje mnohem více než pouze textové heslo, tj. Heslo založené na obrázku, heslo založené na automatu, tj. A mnoho dalšího
user10211
2012-12-26 19:17:26 UTC
view on stackexchange narkive permalink

Toto je spolehlivý způsob, jak zaplavit požadavek na resetování hesla. NIKDY TO NEDĚLEJTE.

Viděl jsem, že správce hesel používá celkem nula průměrných uživatelů. Ti, kdo používají správce hesel, již vědí, že mohou náhodně generovat hesla.

Myslím, že je třeba více přemýšlet. Zajímalo by mě, jestli by kombinace webů a programů, které přepnou na toto schéma, mohla pomoci vyřešit „problém s heslem“. Pokud by uživatelé nikdy nedostali příležitost vytvořit si vlastní heslo, nemohli by si je pamatovat. To by mohlo vést k tomu, že by si uživatelé hesla ukládali na papír, což je bolest, ale mohlo by jim to pomoci při jejich ukládání do klíčenky. Jedná se spíše o výzkumnou otázku než o otázku implementaci.
@AndrewX192 A když to děláme, proč nemít kombinaci webů a programů vyžadujících k ověření uživatelů tokeny hardwarového ověřování? To prostě není praktické. Výzkumné otázky jsou dobré a dobré, ale nakonec záleží na praktičnosti.
Tinned_Tuna
2013-06-24 16:42:56 UTC
view on stackexchange narkive permalink

Domnívám se, že postup přiřazování hesel shora dolů je (nebo byl) běžný ve vojenských nasazeních.

Obvykle byste odhadovali průměrnou dobu ztráty hesla, i když jakýkoli počet prostředků , z nichž některé mohou zahrnovat:

  • Sociální inženýrství
  • Brute Force
  • neopatrní uživatelé, kteří je prosakují

Poté byste tento odhad využili a vynutili opětovné vygenerování hesel v „bezpečném“ časovém okně. Vaši koncoví uživatelé vás za to mohou nenávidět. Má však mnoho výhod:

  • Heslo můžete snadněji propojit s koncovým uživatelem - vygenerovali jste je pro všechny, tak proč Bob používal Alicino heslo, když mu bylo heslo uděleno .
  • Organizace může explicitně vyvážit riziko svých hesel proti pohodlí koncového uživatele, konkrétně tím, že odpovídajícím způsobem změní délku a životnost hesla.
  • Různé systémy mohou vyžadovat různá hesla pro stejné uživatele, což vede ke snadněji implementovatelným kontrolám přístupu a lepšímu oddělení obav. Pro stejné výhody však můžete delegovat ověřování & na konkrétního poskytovatele identity.

Musíte však také být schopni bezpečně doručit hesla uživatelům. To je překvapivě obtížné; určitě jim nemůžete poslat e-mail přes otevřený internet, může být podplacen kurýr (a může provést DoS pomalou cestou nebo „ztrátou“ klíčů k místní řece) atd.

Toto režim pravděpodobně také povede, jak poznamenal The Bear k extrémně nepřátelským uživatelům. Nepřátelští uživatelé představují vážné bezpečnostní riziko. Mohou přestat používat systém k vykonávání své práce tím, že z aplikace (zabezpečené) aplikace vyjmou data, aby s ní mohli pracovat, což zcela poruší smysl systému.

Celkově vzato u většiny aplikací nehlídáte dostatečně citlivá data, která by zaručovala tuto úroveň paranoie. Nemůžete zaručit bezpečné doručení hesel, nemůžete trénovat své uživatele a pravděpodobně je nemůžete donutit, aby používali váš systém. Toto je téměř jistě hrozné schéma pro 99,9999% aplikací.



Tyto otázky a odpovědi byly automaticky přeloženy z anglického jazyka.Původní obsah je k dispozici na webu stackexchange, za který děkujeme za licenci cc by-sa 3.0, pod kterou je distribuován.
Loading...