Tak treba softwaru na mem pocitaci muzu zakazat pristup na internet. Napr. inkscape si mozna precte SSH klice, ale uz je neposle dal. Kdezto ta "appka" na https://dicekeys.app/ je primo webova stranka mimo jakoukoliv moji kontrolu.
Ta appka na https://dicekeys.app/ běží zjevně v prohlížeči a můžete zkontrolovat její zdrojový kód. A vždy je možné ji navíc zakázat přístup do internetu nebo zkusit co to kam posílá.
Je skutečně náhodné a jeho tvorba není závislá na prakticky neověřitelném slibu třetí strany, že je jejich generátor náhodných čísel skutečně náhodný. Systém kostek vyhazuje z problému několik potenciálních problémů a zbývá jen důvěra v kvalitu kostek, která může reálně ubrat několik bitů entropie, pokud budou nekvalitní.
To jo, ale kostky nejsou taková neznámá černá skříňka jako generátory skutečných náhodných čásel, které tak i často vypadají. Některé takové externí generátory jsou taky prokazatelně náhodnější než jiné, ikdyž všechny tvrdí dokonalou náhodnost. Kostky jsou pochopitelnější a ověřitelnější. Při vytváření klíče kostkami bez appky odpadá dlouhý řetěz slepé důvěry od ovladače, přes OS, procesor, absenci spywaru až po samotný generátor hesel. Zbyde jen důvera v kostky, algoritmus tvorby klíče a mé schopnosti to správně spočítat, což je v podstatě nejideálnější stav, ke kterému se lze reálně dopracovat.
Kombinaci více generátorů náhodných čísel bych nedělal, je to docela hazard a výsledky jsou neprůkazné. Některé postupy mohou chyby i násobit.
Dobře. Takže máte plus mínus ověřené kostky, ze kterých dostanete 196 bitů entropie. A vedle toho máte hardwarový generátor, který by měl dávat 196 bitů entropie, ale podle vás je cinknutý a dává výrazně méně bitů entropie. Navíc je to jeho obecná vlastnost – můžete takových generátorů koupit několik (stejně jako kostek) a nechat je běžet paralelně vedle sebe. Nějak mne nenapadá, co by ten generátor musel dělat, aby výrazně snížil množství bitů entropie a zároveň jste to při testu nepoznal.
Myslím, že stejně kvalitní heslo, jako tím hodem kostek, získám tak, že prostě do Googlu zadám „random password generator“ a „náhodně“ si vyberu nějaký odkaz, kde si to heslo nechám vygenerovat. Předem na to zaútočit prakticky nejde, a i kdyby byl ten generátor cinknutý, nebude provozovatel stejně vědět, kdo a kde to heslo použil.
Uplne jednoduse. Ten generator bude generovat 196b, kde bude trebas 80b entropie a statistickymi testy to sotva bez extra namahy poznas.
(Jednoducha konstrukce je - vezmi funkcni generator, vygeneruj 196b, z nich 196-80 nahrad pevnym patternem a prozen kryptografickou hash funkci, co ti da novych 196b. Statistickymi metodami to nad blackboxem nepoznas, dokud neudelas _hodne_ testu. Kdybys chtel mit ten generator OSS, tak to samozrejme bude tezsi, ale porad mas prostor pro subtilni chyby, ktere dosahnou podobneho efektu a bude to chtit hodne hodne draheho casu je najit pri auditu.)
A jeste trochu "hloubeji" - rozdil je v tom, ze monoliticka kostka ma daleko mene "zajimavych" vnitrnich stavu proti takovemu generatoru.
(A ne, nerikam poridit si tyhle kostky. Jen rikam, ze nemas pravdu v tom, ze u kostek je podobne riziko skryteho chovani jako u SW nebo elektronickeho generatoru.)
Pořád se ovšem bavíme o případu, že nejde o cílený útok. Tj. cinknutý by nebyl ten jeden můj generátor, ale všechny. Tj. ty testy bych neprováděl jen já, ale všichni uživatelé. Navíc výrobce takového generátoru by nevěděl, k čemu jsem ho použil, takže by stejně nevěděl, na co má útočit.
A jak už jsem psal – kdybych se bál, že jsou všechny generátory kolem mne cinknuté, tak prostě s jejich výstupy udělám XOR. Opravdu se nebojím toho, že když si vygeneruju náhodná data na mobilu, na procesoru stolního počítače, generátorem pseudonáhodných čísel a na internetovém generátoru, že to všechno bude cinknuté a všechny nitky povedou do jednoho místa. (A i kdyby to tak bylo, ty kostky to stejně nezachrání.)
Pořád se tu totiž bavíme o 196 bitech entropie získaných hodem kostkami, k jejichž uchování potřebuju nezanedbatelný prostor a pro jejich dekódování nezanedbatelnou energii (nebo důvěru v aplikaci třetí strany). Takže řešit vedle toho statistickou analýzu elektronického generátoru je jako kdyby děti na pískovišti při dělání báboviček řešily, jestli má písek optimální vlhkost a strukturu zrn.
Nebo-li když si teď na tomhle počítači nechám ve správci hesel vygenerovat 30znakové heslo, které si pak napíšu na papírek, bude to heslo reálně stejně bezpečné, jako to získané z těch kostek. A to předpokládá, že se se s tím správce hesel nijak nemaže a pro generování hesel používá to, co je nejsnáz dostupné v systému, tj. klidně nějaký pseudonáhodný generátor.
Provádět testy můžete jak chcete, jsou věci, které testy neodhalí:
https://en.m.wikipedia.org/wiki/Dual_EC_DRBG
Představte si čip, jehož výrobce jej vydává za HW RNG. Přepočítat po něm výsledky moc dobře nejde. Uvnitř ale bude ve skutečnosti schováno něco jako zmíněné Dual_EC_DRBG. Statistické testy projdou...
Vy ale pořád řešíte případ, kdy mi nějaký útočník podstrčí falešný generátor a bude vědět, na co ho použiju. Jenže takhle to master heslo napsané na papírku nevznikne.
Porovnáváme tu dva případy. V jednom případu si zakoupím tuhle sadu kostek, hodem získám nějaké náhodné heslo a to použiju jako hlavní heslo pro správce hesel. Ty kostky samozřejmě nijak zkoumat nebudu – ony asi nebudou úplně ideální, generovaná entropie bude asi mírně nižší, ale pro daný způsob použití se to nevyplatí řešit.
V druhém případě to samé heslo vytvářím tak, že třeba do Googlu zadám „random password generator“, vyberu si nějaký odkaz a použiju ho pro vygenerování hesla. Použitý generátor bude mít nejspíš hodně daleko k pořádnému hardwarovému generátoru, je vysoce pravděpodobné, že to bude jen nějaký softwarový generátor pseudonáhodných čísel. Jenže to vám je stejně k ničemu, protože nevíte, co jsem použil.
Pokud naopak budu potřebovat použít hardwarový generátor, asi to nebude kvůli jednomu hlavnímu heslu k soukromé klíčence. Spíš to bude kvůli šifrované komunikaci, a tam mi zase nijak nepomůže házení kostkami. Navíc by byl problematický i ten hloupý (neúmyslný) výrobní nedostatek, že ty kostky nebudou úplně dobře vyvážené (což je dost pravděpodobné). A nijak nepomůže, že ten nedostatek umím zjistit.
Jenže on to není žádný nesmysl. user_userovic_login vyjmenovává útoky na elektronické generátory, a tváří se, že na fyzické generátory náhody nelze zaútočit. Když mu dám něco do ruky a budu o tom tvrdit, že jsou to hrací kostky, bude to považovat za generátor skutečně náhodných čísel, bez jakéhokoli ověření.
Přitom nesmysl je už to považovat kostku za generátor náhodných čísel. To, co generuje náhodu, není kostka, ale hod kostkou. Když budete chtít a kostku si v ruce správně připravíte, klidně můžete třeba v 90 % případů hodit číslo, které si vyberete.
Možná jsem to napsal trochu nešikovně, bylo možné to pochopit i tak, že mi jde jen o ověřování samotných kostek. Myslel jsem samozřejmě celý proces generování entropie. Úskalí elektronických generátorů jsou jiná, než úskalí fyzických generátorů, ale jak je známo třeba z různých útoků na kasina, fyzické objekty nejsou žádnou zárukou nenapadnutelnosti generování náhody.
Mohou. Dále mohu třeba kostku položit na plastovou misku ve vodě a zkoušet, jestli se z toho nestane kompas. Ano, lze namítat, že zde může působit ještě nějaká další síla, kterou třeba ani neznám. Pořád v tom ale vidím větší jistotu než v kontrole elektronických náhodných generátorů. A stačí na to znalosti ze základní skoky.
> Ve skutečnosti, kdybyste chtěl ty kostky ověřit, budete tápat úplně stejně, jako u těch generátorů.
Tak to bych se hádal. Do kostek se poměrně špatně přidává komunikace s C&C servery, chování závislé na datu a podobné vychytávky. U kostek stačí "chvíli" házet a ověřit distribuci. To u nějaké chytré krabičky nestačí ani ve snu.
I z těch kostek byste mohl data odesílat. Generátor náhodných čísel také do sítě vůbec nemusíte mít připojený, takže schopnost komunikovat s C&C servery může být stejná, jako u těch kostek. Když dostanete výsledky „házení“, ověříte distribuci, a pak si jeden z výsledků vyberete (třeba upustíte tužku na seznam) – bude záležet na tom, zda ty výsledky „házení“ vznikly na kostce nebo na nějakém generátoru?
Ještě jsem zapomněl dodat, že ty kostky jsou dostupný generátor skutečných náhodných čísel, ne nějaká pseudonáhodná náhražka. Oproti virtuálnímu světu jsou kostky taky odolné proti téměř všem útokům na generátory [pseudo]náhodných čísel.
Například Debian OpenSSL měl v roce 2006 problém poté, co někdo na výzvu kompilátoru kvůli nadbytečnému kódu odstranil velkou část "nadbytečné" entropie. 2 roky se generovaly slabé klíče. Generátor WinXP byl k ničemu od samotného počátku. V roce 2013 byla objevena chyba v Javě, která ohrozila peněženky s bitcoiny (byly zaznamenány i náhodné kolize). A co takhle CVE-2014-3100, buffer overflow v KeyStore Androidu 4.3? atd,...
26. 8. 2020, 08:47 editováno autorem komentáře
A k čemu je mi takové "skutečně náhodné" (ať už to má znamenat cokoliv) heslo, když se ho může snadno zmocnit každý kdo zjistí, kam jsem si strčil tu krabičku? A ještě hůře - když mi může ty kostky přeházet a tím znemožnit přihlášení?
Nejde mi o postup vygenerování, ale o způsob uchování. To si můžu vycvakat klávesy z klávesnice a losovat je z pytlíku a vzniklé heslo si napsat na papírek, který strčím do peněženky...
Stejný pocit jako u Cryptosteel - člověk bude potřebovat obnovit a zjistí „děti si s tím hrály a pomíchaly to“ :-)
Dohromady dostanete entropii více jak 196 bitů.
No on ve videu píše 128b-196b. A to je málo. Díky narozeninovému paradoxu se to dá s padesátiprocentní úspěšností lousknout už po 64b-98b pokusech. Minimální síla se dnes uvádí 112b (224b) a standardem je 128b (256b). Proto máme AES256, SHA3-256 atd.
Určitě je to lepší řešení než jiné generátory hesel (ve skutečnosti je to velmi pěkný nápad), ale asi bych tomu neříkal jedno heslo na celý život nebo na dekádu. To by muselo být větší (což ale není takový problém).
Heslo na úrovni dnešní krypto by mělo mít alespoň 18 znaků (malá velká abeceda + číslice). 258b (ln(18^(26*2+10))/ln(2)). Přidáním jednoho písmenka navíc je to 62x silnější. Chce to ale dobrý generátor (a paměť).
24. 8. 2020, 12:22 editováno autorem komentáře
Máte pravdu, tak dlouho jsem bojoval s bc a neexistencí factorialu, že jsem to otočil. Je to 43 znaků (l((26*2+10)^43)/l(2)). Mě se to zdálo divné, ale kontroloval jsem to s projektem s jinou abecedou. I mistr tesař se utne.
Jak přišel na 128 netuším. Co mě ale dráždí víc, je fakt, proč je to 196b a ne 256+. Kdyby to měl jako 6x6 (36 kostek) tak mu vychází luxusních 301b entropie (l(fac(36)*24^36/4)/l(2)).
No to záleží na tom, na co chcete útočit (nebo před jakým typem útoku se chránit). Pokud budete útočit na jeden konkrétní účet, tak ano, musíte projít všechny kombinace (tj 50% je (2^n)/2). (Kolize druhého řádu.)
Pokud ale máte zašifrovaná data z nějaké služby a máte tam všechny účty světa, a chcete z toho dostat alespoň něco, tak se to mění na 2^(n/2). (Kolize prvního řádu.)
Ale jako uživatel bych si moc nevybíral. Není důvod nepoužít kryptograficky silné heslo.
A v čem mi (s alepoň trochu realistickým šifrovacím schématem) pomůže že vím, že Alice a Bob mohou mít stejné heslo, když neznám ani jedno z nich?
Bojím se že vzoreček máte dobře, ale v dané situaci nelze použít - těch 2^(n/2) je šance že je tam _jakákoli_ kolize. Ale Vás zajímají jen kolize mezi m uživateli a n pokusy na lousknutí, nikoli všechny kolize v n. A protože m~2^20, n~2^6x, pak je zřejmé že ta šance bude proti birthday paradoxu mizivá.
Tak to je asi o definicích. Protože obvykle se šifrovací schema považuje za prolomené ve chvíli, kdy je nalezena libovolná kolize prvního řádu. Tj to heslo Alice nebo Boba ani nemusíte znát, ale víte že je stejné (nebo vede na stejný otisk). Třeba to víte díky slabému klíči (nebo v tomto případě heslu).
A z toho se odvozuje kryptografická síla. Pokud vím, tak brute force metodou se už hodně dávno (v devadesátkách) podařilo cracknout 96b. V roce 2013 byla minimální krypto síla nastavena na 112b. Co se podařilo brute force od té doby nevím, ale dneska je standardní krypto síla 128b. Tj 256b.
Tj v zásadě cokoliv pod 128b (256b) můžete v klidu odmítnout. A já nevím co se louská dneska (jestli je to 105b nebo tak něco) a celkem mě to nezajímá.
A já chápu, že intuitivně požadujeme nejlépe kolizi druhého řádu a to ještě navíc na konkrétní klíč. Ale takto se krypto nestaví (nebo takto mě to nikdo neučil). Krypto se staví na zabránění i hypotetickým kolizí prvního řádu a to nejen na základně oslabení funkce (tam je to končená), ale i díky slabé síle.
Proto mě to tak dráždí. Jasně, tohle kostičkové řešení je nesrovnatelně lepší než jakékoliv lidské heslo, o tom žádná, ale mohli to posunout do oblasti nad 256b (což by šlo velmi snadno).
Ale no tak... v tom prvním příspěvku jste napsal jasně: "Díky narozeninovému paradoxu se to dá s padesátiprocentní úspěšností lousknout už po 64b-98b pokusech." a to prostě není pravda. Stane se, tak to holt přiznejte, nevymýšlejte krkolomné výmluvy a můžeme jít dál. Jak říká staré úsloví: čím víc se v tom budete šťourat, tím víc to bude smrdět.
Ještě doplním - ony ty bity jsou opravdu docela ošemetné. Někdy v době ne zase tak nedávné kdy se vedly boje kolem legality silných šifer, tak si pamatuji (bohužel se mi tu publikaci nedaří teď dohledat) že nějaký kryptolog přišel s nápadem "secure 40bit cipher". - celé to bylo založené na tom, že v prepare fázi se z klíče velmi pomalu, ale pořád na PC dosažitelně odvozoval řádově gigabajt dat způsobem co nešel rozumně paralelizovat, které následně používala samotná bloková šifra - a ta byla opět navržena tak, aby z nich většinu potřebovala (takže byste potřeboval předpočítat a uchovávat 2^40 GB dat abyste mohl efektivně šmírovat).
Sice to bylo na naše poměry neskutečně pomalé, ale zadání (efektivně zabezpečit občanovi třeba email před vládou tak, aby bylo ekonomicky nereálné ho dešifrovat bez porušení navrhovanáho zákona) to splňovalo.
Jasně že to nebylo optimální řešení a pokud by se historie obrátila tímto směrem, nejspíš by se prosadilo něco jiného (steganografie tehdy už byla dobře známá), ale jako argument do diskuse na téma že bity bez kontextu nejsou všechno to myslím postačí.
Moment, uvědomujete si, že se nebavíme o hashi
Uvědomuju, ale nepřijde mi na tom nic špatného. Ten secret se stejně v následujícím kroku zahashuje, nebo se použije pro nějakou key derivation fci. V nejhorším případě ten secret bude jen "zbytečně" dlouhej, což ničemu nevadí.
Jako já nehledám nějakou minimální bezpečnou délku, ta mě prostě nezajímá. Já si věci zjednodušují tím, že 256+ je vyhovující a to že to někde bude "zbytečně" velké je celkem jedno.
secure 40bit cipher
Zkuste ten paper najít, protože 40b nemůže být secure, když se vám libovolný vstup zašifruje do jednoho z 2^40 výstupů.
Jinak popisem to trochu připomíná PBKDF2. Tam se taky doufá, že mnohonásobnou iterací se to dostatečně zpomalí.
ad 256bit entropie = OK. Jakmile narazíte na praktické otázky (jako potřeba aby to uživatel vyťukal bez překlepů, aniž by měl tendence to copypastovat z texťáku na ploše, nebo po síti jak se vejít do jednoho paketu na ethernetu), tak to tak úplně jednoznačné není.
ad.40bit - to je ale délka klíče, ne délka bloku dat. 2^40 je pouze možých zobrazení nějakého nespecifikovaného bloku na sebe, ale ten může být klidně 512bytes sektor a pak good luck.
Zkusím to ještě najít někde v bordelu na disku.
Sakra nenechá mě to edit, tak znova :(
ad kolize - základní protiargumenty.
- Pokud to použijete na online službě, proč by hledali kolize když si to heslo v cleartextu vytáhnou přímo z formuláře?
- Pokud službě věříte, a akorát jí uteče databáze, tak to bude nějak osolené -> zase kolizi nenajdete.
A když to použijete lokálně jako master password ke klíčence, tak tam se to stejně nějak používá k rozšifrování hlavního klíče té klíčenky, kolize s jiným heslem někde ve světe opravdu není relevantní. Jediné na čem záleží je odolnost proti BF.
A ve chvíli, kdy cena za brute force je vyšší než cena za 0day exploit na zařízení co používáte, tak opravdu netřeba řešit jestli tam máte entropii 80 nebo 280 bitů. Nebo k Vám namontovat kamerku. A nebo další side channel https://xkcd.com/538/
- Pokud to použijete na online službě, proč by hledali kolize když si to heslo v cleartextu vytáhnou přímo z formuláře?
- Pokud službě věříte, a akorát jí uteče databáze, tak to bude nějak osolené -> zase kolizi nenajdete.
Závidím vám váš optimismus :-) I ve druhém případě, pokud to má služba v salted hash, tak jí (nebo nějakému útočníkovi) to vůbec nebrání mít ještě někde vedle plain text.
Používání hesel pro přihlašování je vůbec peklo. Lze používat klíče. Podpora pro to je (ve webserverech i browserech). Lze dosáhnout PFS. Přihlášení se na stránku by bylo stejné jako přihlášení se k ssh. Klíčů můžete mít hromadu a velikost klíče předčí jakékoliv heslo. Ne, místo toho se používají hesla jak za krále klacka. Nebo ještě hůře, aktuálním morem je nasazení "SSO" s loginem na FB nebo na Google. Máme tady standard OpenID, lze provozovat vlastní server, ale nemáte ho kde použít, protože všude je klasický password login nebo FB / Google.
to je ale délka klíče
Jasný, to ale znamená jen 2^40 pokusů o dešifrování (a rozpoznání otevřeného textu). Což je trivka. Chápu, že to obalil "strašně časově náročnou fcí" (což je přístup stejnej jako u PBKDF2), ale na velikosti klíče to nic nemění.
Kolik je to kombinací?
6 stěn
každou stěnu mohui otočit 4x - kdyby na každé steně byly 4 písmena, každé orientované jinak, podle otočení, budu mít 6*4 písmen = 24
Počet kostiček je 25. Tedy 24^25 = 3,200965864×10³⁴
Převedeno na počet bitů = log(3,200965864×10³⁴)÷log(2) = 114,624062518
Jak tam docílí ty další bity?
Ten výpočet tam je blbě.
Já nevím, tak to srovnejte třeba s bitcoin trezorem. Ten má 24 slov a každé slovo je z množiny 2048 (11bitů). Dohromady mám 264 bitů
Tady mám 25 slov z množiny 24 (min 4.5849bit). Protože mám 6 stěn a každou stěnu mohu otočit 4x
Pokud přidám otočení krabice, mám další dva bity
24. 8. 2020, 15:29 editováno autorem komentáře
ne, výpočet tam je dobře, vy to nějak motáte
každá kostka skutečně může ukazovat číslo 1-6 a jednu ze 4 orientací, to je těch vašich 24^25
otočení krabice se ubírá, protože chtějí, aby bylo jedno, jak je natočená - to je to dělení 4
ale každá kostka má také navíc jedno písmeno, každé jiné (ze všech stran ovšem stejné), podle vás na pořadí nezáleží, teda jako by ty kostky byly bez písmen, jen s čísly a různě otočené
jestli přidám písmena, tak kombinací je tolik, kolik máte vy, krát 25!, protože tolik různých permutací 25 písmen za sebou dokážu vytvořit a přitom čísla a orientace nechám stejné
závěr - vysledek je dobře
Dotaz laika, naprostého diletanta: Mohla by jako heslo sloužit třeba fotka nebo třeba písnička? Myslím to tak, že by datový popis , datová struktura nějaké fotografie nebo nějaké zvukové nahrávky (ne nutně nějaké velké) mohly být použity jako heslo? Asi nesmyslný dotaz, že? A už jen doplňovací- jsem na Linuxu-existuje nějaký password manažér normálně uživatelný jak v Linuxu, tak ve windech? Díky a omlouvám se :-) !
Na ten dotaz doplňovací :) - je jich vícero. Za sebe můžu doporučit třeba https://keepassxc.org/
Na jednom moc zajímavém semináři o bezpečnosti se jeden docela známý hacker rozzesmál nad složitostí vytváření hesel, protože se stále bojuje mezi "jednoduché na zapamatování, aby si to člověk nemusel psát" X "těžké na prolomení".
On dal návod, který mne povbavil:
délka hesla je vlastně hlavním bezpečnostním opatřením. Když ho postavíme na nějaké známé frázi (např. z písničky) , ale tu frázi pozměníme, dostaneme velmi bezpečné heslo. Např.
"kockalezediroupesstrechounebudeliprsetumoknem"
- neobsahuje kapitálky
-neobsahuje zvláštní znaky
- neobsahuje čísla
ale
- je zapamatovatelné
- je tak dlouhé, že je téměř neprolomitelné
- není sociálním inženýringem zjistitelné (není to písnička od mé oblíbené skupiny apod)
- není prorazitelné slovníkovým útokem
Tohle se sice celkem často tvrdí, ale neřekl bych, že je to tak úplně pravda. Pokud to budu lámat po písmenech, tak opravdu není šance. Ale co když zkusím vzít jako základní kameny běžná slova ze slovníku? Pak už těch možností k vyzkoušení nebude až tak astronomicky moc. Můžete to sice opepřit "překlepy", ale ty zase může testovat i útočník (jako to dělá třeba John the Ripper). Tady navíc vycházíte ze známé dlouhé fráze, kterou pouze mírně obměníte.
A v neposlední řadě je tu i otázka praktičnosti takové fráze. Pokud je to fráze, kterou budete používat jen ve výjimečných situacích, tak to není problém, ale pokud by to měla být třeba fráze k něčemu jako password store, budete ji muset psát denně nebo dokonce několikrát denně a to nebude nic příjemného.
- _urcite_ nebrat existujici pisnicku
- cela slova jsou IMO plytvani
Radeji nejakou dementni frazi, co si snadno zapamatuju. A treba prvni pismena.
"Nejhorsi na slabych heslech je to, ze jsou slaba. Entropie, entropie; pokazde si f*ndu myje." -> Nnshjt,zjs.E,e;psf*m.
Porad nic moc (zrovna to rozlozeni prvnich pismen neni zadny zazrak, mozna to bude lepsi trebas u tretich?).
Jen poznámka z praxe. Rozmyslete si, odkud budete na daný systém přistupovat. Dávat do hesla speciální znaky se může vymstít, pokud se potřebujete přihlásit na nějakém nestandardním terminálu (konkrétně třeba vmware). Plete se CZ / ENG klávesnice apod. Úplné žůžo je přistupovat na vmware terminál ze vzdálené plochy z českých widlí z rdesktopu z linuxu s EN klávesnicí.
Takže nakonec je lepší zvolit abecedu jen malá písmena a projistotu se vyhnout i z/y, protože kde kdo rád nastavuje qwertz českou klávesnici.
A udělat to heslo prostě delší. Delší heslo se opisuje překvapivě snadněji, než řešit vše uvedené výše (v některých kombinacích terminálů hvězdičku prostě nenapíšete).
To je v zásadě přístup podle xkcd 936. Lepší než používat nějakou známou písničku s drobnou obměnou je provést náhodný výběr slovníkových slov, třeba 4096 nejpoužívanějších slov. Každé slovo tak dá dvanáct bitů entropie, tedy zhruba jako ve dvou zcela náhodných alfanumerických znacích (6 bitů na znak při 64 možných znacích). Pokud těch slov vylosujete pět za sebe, může vám vyjít naprosto nesmyslná věta typu Correct horse battery staple, kterou si ale snadno zapamatujete a bude mít sílu srovnatelnou s desetiznakovým silným heslem.
Problém je, že to je dlouhé heslo, které rozhodně není dobré například na odemykání obrazovky počítače. Ale třeba na odemykání správce hesel vhodné je.
Problém tohohle přístupu je, že to řeší čistě jen útok hrubou silou. Ale třeba proti nedokonalému odpozorování hesla už to odolné není – útočník bude pravděpodobně schopen chybějící/nejasné části doplnit.
Na druhou stranu, nějaké master heslo ke správci hesel obvykle pořád ještě potřebujeme, a pořád lepší takovéhle heslo, než slovníkové heslo.
Pár takových hesel jsem si vygeneroval už kdysi na základce.
Sestavil jsem relativně náhodná slova do vět tak, že se to nějak rýmovalo, a zároveň se to dalo přečíst, i když to nedávalo žádný smysl.
Přesně jak je v XKCD, udělal jsem si tehdy 4, a dodnes si je pamatuji. Jsou dlouhá, takže se hodí právě jako heslo ke keepassu, a víceméně nezapomenutelná.
Má to ale háček. Takováhle říkanka se tak dobře vyslovuje, jak prochází přes řečová centra v mozku, že má člověk tendenci jej vyslovit. A to stačí udělat jednou. Navíc jak je snadno zapamatovatelné a nesmyslné, zaujme to případného posluchače, ale to je stejně irelevantní - jakmile je takové heslo vysloveno nahlas, je po něm.
Navíc si myslím, že tím, že se nad heslem zamyslím a tím ho v duchu vyslovím, bude relativně snadno zjistitelné nějakým skenováním chodu mozku. Pokud ze mě tedy někdo bude chtít heslo dostat, stačí mě narvat pod nějaký šikovný přístroj a o tom hesle se mimochodem zmínit nebo ho jinak připomenout. Mně se pak v duchu automaticky prožene "Nepleť mouchy s hermelínem, přejedeš katedrálu s mlýnem", přičemž si myslím, že se to jako lehké nervové vzruchy dostane až ke svalům (mám ten pocit), a je vymalováno. Nebo stačí nějaký pozměněný stav mysli, třeba drogy, aby to člověk i zamumlal. To se u nevyslovitelného hesla nestane.
> Navíc si myslím, že tím, že se nad heslem zamyslím a tím ho v duchu vyslovím, bude relativně snadno zjistitelné nějakým skenováním chodu mozku...
A není klasická pendreková kryptoanalýza trochu reálnější? :D I od agentury, co má přístup k mimozemským technologiím, hrozí spíš waterboarding někde ve sklepě.
To samozřejmě je, ale po waterboardingu člověk alespoň ví, že to heslo už sdělil, takže jej nebude dále používat. Předpokládám, že pendreková kryptoanalýza prolomí každé zapamatovatelné heslo.
Takhle se to ale s trochou fantazie dá udělat skrytě, i když je to pořád technicky daleko složitější než keyloger.
Otázka není, jestli se něco dá s trochou fantasie udělat skrytě. Otázka je, kdo a proč by něco takového dělal. Jaký druh útočníka se dá předpokládat? A co získá tím či oním druhem útoku? K čemu chce to heslo použít? Nejde místo nějakého extra sofistikovaného útoku ta data získat nějakým jiným kanálem se zlomkem námahy?
Vaše hypotetické čtení myšlenek nebo drogy jsou extrémně komplikované útoky. To nebude dělat jen tak někdo pro pár peněz. Jak máte pojištěné, aby se útočníkovi vyplatilo nechat vás dýchat?
Pokud je to master heslo pro uchovávání ostatních hesel, a ta ostatní hesla mají nějaký význam, což si lze vcelku snadno představit (můžu takhle mít třeba zašifrovanou utajovanou dokumentaci), tak to znamená, že útočník se k datům nejen dostane, ale ještě k tomu nepozorovaně a případně je může i sledovat v čase, než se rozhodne například k útoku.
Pokud mě zabije, zbytečně tím vyvolá pozornost.
Jasně, jsou to všechno hypotetické a dost extrémní představy.
Jenom bych připomněl, že „sestavil jsme relativně náhodná slova“ dost snižuje entropii, protože lidský mozek ta slova ani náhodou neumí vybrat náhodně. „Rýmuje se“ také snižuje entropii, „dalo se to přečíst“ rovněž. Takže entropie takového hesla je mnohem nižší, než by odpovídalo „počtu slov ve slovníku na počet slov v hesle“.
Ne že by takové heslo bylo vyloženě slabé, dneska nejspíš pořád ještě útoku hrubou silou odolá, ale k síle hesla z opravdu náhodně vybraných slov má dost daleko.