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