To je odpověď na jinou otázku. Jak už bylo v tomhle kontextu mnohokrát zmíněno, je rozdíl, jestli nastavím slabé heslo k emailu, a jestli to samé heslo použiji i k registraci na pochybném webu, nebo jestli mám slabé heslo někde, kde na tom nezáleží.
Nemám problém si někde nastavit heslo abc123.
- Pokud za mě někdo hodlá odevzdat domácí úkol z programování, tak ať si to užije...
- Pokud mi někdo ukradne účet na místě, kam jsem se musel zaregistrovat jen abych mohl odeslat jeden, dva komentáře, nebo si mohl přečíst aresu odkud lze stáhnout nějaký film, tak to opět nepovažuji za problém.
Zajímavé by bylo, kdyby někdy leaknula hesla k internetovému bankovnictví a emailovým schránkám.
Pak by bylo potřeba vybrat z toho emailové schránky, které někdo používá k serióznějším aktivitám, a teprve nad tím by mělo smysl dělat tenhle typ analýz..
..jenže na takovéhle seriózní výzkumy nejsou data... ;-)
Pepane, ono staci, kdyz nekdo z toho tveho e-mailu posle nejaky vulgarni e-mail tvemu dekanovi a kdyz to udela chytre (ve smyslu ze to bude vypadat jakoby to nemelo byt urcene pro tveho ucitele), tak se z toho nevykecas a daji ti to sezrat. Dalsi vec je ze ti tam nekdo treba do odeslane posty ulozi nejake detske porno (patrne jako 99% populace nekontrolujes slozku odeslane) a uda te... Tech moznosti jak zneuzit tvuj ucet je milion, pokud si myslis ze ne, klidne mi dej svuj e-mail, heslo... ;)
Jo jasně. To víš že jo. A co když s těmi hesly skutečně je otrava?
Do školního systému se přihlašuju tak ze tří různých počítačů. Synchronizovat hesla online je blbost, protože to pak nemá s bezpečností nic společného, a pamatovat si nplusprvní heslo odmítám. Buďto projde dát tam stejné heslo, jako používám na podobně nedůležitá místa, nebo tam dám svoje oblíbené protetní Abcd!234 (nastavuješ debilní kritéria na výběr hesel? Tak to máš blbý, žádná bezpečnost navíc se nekoná.)
Na aplikaci, kterou jsem nedávno vyvíjel, jsem hesla před uložením do databáze na serveru nechal každé jinak náhodně upravit a postup jak je upravit se ukládá vedle hesla v databázi.. Takže i kdyby bylo heslo 'password', tak hash slovníkem nikdo jen tak nerozlouskne.. Samozřejmě se ale nedovím, kolik uživatelů má stejné heslo apod., jako to udělali tito koumáci.
Co píšu je, že v případě, že by člověk měl heslo 'password', tak se před zahashováním upraví na delší směs náhodných znaků. Takže kdyby někdo získal hash, tak stejně potřebuje znát postup jak jej upravit, který je v databázi a ve zdrojáku je, jakým způsobem se s tím postupem pracuje. Nepíšu, že lidé mají mít osmimístné hesla a skutečné slova. Jen že při osmimístném heslu se zahashovává mnohem delší směs různých znaků, takže obyčejnou slovníkovou metodou to člověk nerozlouskne.
Ono to není uložené v plain textu. Normálně se ten plain text upraví tou metodou a hned poté ještě zahashuje. Aplikaci jsem nepustil do světa, jen jsem se zatím učil vyvíjet aplikace na android a server mi běží doma na RPi, kde jsme zatím jediní, kdo tento můj výtvor používá. Bohužel. :D
Tomu se říká security through obscurity a co se bezpečnosti týče, spoléhat se na to je hrdelní zločin.
Tomu se říká „solení“ hesla (přidá se sůl, salt) a považuje se to za základní ochranu hashovaných hesel. Taky je možné hesla „opepřit“ – ke všem heslům se přidá stejný text, který ale není uložený v databázi, ale někde jinde. Pokud pak unikne databáze, útočník nezná pepř a tím pádem nemůže na hashe útočit hrubou silou (pepř samozřejmě musí být dostatečně velký a náhodný, aby ho útočník nemohl uhodnout, pokud by znal nějaké heslo, třeba své, v otevřeném tvaru).
V kryptografii je dost podstatné nevymýšlet vlastní vynálezy a použít něco hotového a ověřeného. Ty vlastní vynálezy mívají dost často ten problém, že mají nějakou triviální díru, které si autor není vědom.
"Pokud pak unikne databáze, útočník nezná pepř a tím pádem nemůže na hashe útočit hrubou silou ..." Hrubou silou útočit může podle libosti, ale nemůže použít předem vytvořenou databázi heslo-hash, a ani pouhý seznam hesel k vyzkoušení mu moc nepomůže. Musí mechanicky vyzkoušet všechny kombinace "pepř"+"heslo", nebo si musí najít jiným cíl, který nepoužívá sůl ani pepř. (Například Windows XP, ten má směšně slabý hash, který ještě před zahešováním heslo rozdělí na dvě sedmimístná hesla a konvertuje do uppercase. Tabulka pro všechna hesla složená z písmen, čísel a 32 dalších znaků má jen 7,5 GB).
Já svého času upravil zdrojaky loginu pro roota tak, že když se někdo napoprvé správně přihlásil tak to bylo podezřelé :-) Prostě napoprvé bylo třeba zadat nesprávné heslo až na druhý pokus správně. Pak jsem ten server přestal spravovat a na tuhle drobnost nového admina zapomněl upozornit. Chudák hned druhý den volal, že nemúže nic dělat ani jako root :-D
Já bych spíš odhadl, že chytří lidé budou umět zvážit, kde dobré heslo potřebuji.
Já osobně používám řekl bych rozumná a celkem i silná hesla tam, kde by mě prolomení mohlo více mrzet (aktivní mail, paypal, banka, facebook, studijní systém naší školy...).
Ale na spoustu stránek (kde je často naprosto nesmyslně vyžadována registrace a přihlašování, často různé eshopy...) používám zpravidla kombinaci dvou, tří mých dost neobvyklých slov (ve slovníku spisovné češtiny možná nějaké z nich najdete jako archaismus nebo obrozenecký neologismus, který se neuchytil), popř. číslo, popř. velká písmena (podle toho, jaké zrovna podmínky to po mě chce).
Výhodu to má v tom, že pokud se tam náhou potřebuji někdy znovu přihlásit, tak většinou do pěti pokusů dovedu to heslo uhodnout.
Nezlobte se na mě, ale fakt nejsem s to si zapamatovat nad deset bezpečných hesel, která nepoužívám aspoň jednou do měsíce.
To je mi jasné. Proto je volím jen tam, kde by mě případné prolomení nemrzlo. Jinde mám, jsi jsem psal, samozřejmě hesla silná.
Jinak po password manageru se dívám pořád a zatím vybírám. Sám nejsem bezpečnostní expert a moc takoveto věci neprogramuji. Proto si nejsem schopný ověřit, kde skutečně různé managery nasazují dost silnou šifru a jestli jim někde hesla neunikají. A bez synchronizace a (v případě nouze) přístupu k heslům z cizího počítače to také není ono. Pokud máte tip na nějaký, tak si rád nechám poradit.
No já na to jdu jinak:
1) Banka, maily,... - KeePass2, není co řešit.
2) E-shopy, kde nakupuju pravidelně - viz 1.
3) E-shopy, kde nakupuju občas - nákup bez registrace, jenom na dodací adresu.
4) E-shopy, kde hodlám nakoupit a chtějí registraci - jdu jinam. Nejde o heslo, ale o osobní údaje a nehodlám je dávat zadarmo každýmu pšoukovi výměnou za 0,5% slevy.
5) Admin hesla - RSA klíče + kombinace dvou hesel, který si pamatuju.
> Standard říká, že by weby měly při vytváření nového hesla kontrolovat, zda toto heslo není součástí databází dříve uniklých hesel.
Zajímavé, člověk by čekal, že 40 let po vynálezu asymetrické kryptografie se nějaké weby k heslu vůbec nedostanou a tak by to měl kontrolovat prohlížeč/správce klíčů.
Doufám, že to pravidlo bude vztaženo i na piny u kreditních karet.
A.L.L C.R.E.D.I.T C.A.R.D P.I.N C.O.D.E.S I.N T.H.E W.O.R.L.D L.E.A.K.E.D
https://pastebin.com/2qbRKh3R
Já doufám, že jsem to jen špatně pochopil, protože jestli ne, tak celá tahle zpráva je jeden velký argumentační faul.
Ve zkratce, zkoumalo se porovnávání hashe nových uživatelských jmén a hesel s databází těch, které unikly někdy dříve, je to tak?
1) Ty dříve uniklé údaje ale nevypovídají zcela přesně o kvalitě hesel, protože získání dat mohlo proběhnout mnoha různými způsoby od nabourání bezpečnosti na straně poskytovatele služby, přes nějaké pasti typu man in the middle po chybu na straně uživatele a jeho nedbalost. To, že nějaké heslo se dostalo do databáze uniklých údajů neznamená automatický špatnou kvalitu hesla, protože to heslo mohlo uniknout z mnoha různých důvodů a ne všechny ty důvody znamenají, že heslo bylo špatné/slabé.
2) Lepší studijní výsledky neznamenají nutně chytřejší lidi.
3) Předchozí dva logické fauly jsou zkombinovány do třetího "prstovýcucu", že chytřejší lidé nemají lepší hesla, protože jejich hashe se procentuálně stejně často shodují s databází uniklých hesel jako je tomu u obecné populace.
Teď si trošku zaspekuluji já.
- Co kdyby hypoteticky třeba byly hesla chytřejších lidí (pro jednoduchost nebudu nyní uvažovat způsob zjišťováni "chytrosti") kompromitovaná kvůli nedostatečné bezpečnosti na straně poskytovatele služby, ale hesla samotná by přitom splňovala všechny znaky pro dobré/silné heslo.
- Co kdyby byly hesla obecné populace kompromitovaná proto, že byla příliš jednoduchá/slabá a byla například uhodnuta slovníkovým útokem.
- Dejme tomu, že hesla obou skupin by se proto ocitla ve zmíněné databázi, ale obě skupiny by tam byly z různých důvodů. Pokud se pak hashe obou typů hesel při porovnávání opakují se stejnou pravděpodobností, znamená to spíše, že obě skupiny používají kompromitovaná hesla s podobnou pravděpodobností, ale rozhodně to nevypovídá o používání stejně špatných hesel oběma skupinami, protože ta hesla byla kompromitovaná z jiných důvodů. V tomto příkladu jsem se úmyslně omezil jen na jednoduché modelové případy a rozhodně jsem nevyčerpal všechny modelové možnosti, pouze jsem chtěl načrtnout nelogičnost odvozování závěrů, které jsou ve zprávě prezentované.
Studie jako je tahle jsou silně manipulativní, zaměňují závislosti a korelace a ještě k tomu nesprávně identifikují skupiny populace. Výsledkem je pak uměle vytvořený konstrukt, který tvrdí výsledky v závislosti na tom, jak šikovně to dokáže pojmout ten který řečník. Neboli, jako v tom vtipu, účetní se zeptá, jak to má vyjít a toho výsledku pak dosáhne.
Na 1) nezáleží, protože password reuse. Prostě použili stejné heslo na školní účet jako někde jinde, kde to heslo uniklo. A podle nových standardů NIST jsou všechna uniklá hesla (i pokud to bude 50 znaků dlouhý výstup z /dev/random) automaticky slabá, protože je někdo mohl přidat do slovníku pro slovníkový útok.
Ta studia hodnotila kvalitu hesel podle aktuálního standardu NIST, nijak to nezapírá a neschovává a správička to jasně zmiňuje. Nemusíte souhlasit s tím, jak ten standard vypadá, ale to nic nemění na výsledku studie a její (ne)kvalitě.
Ad 1) Jak už bylo napsáno, každé heslo použité více než jednou je slabé, protože to heslo může znát minimálně provozovatel dané služby. A když to heslo bylo v nějakém úniku, evidentně už někde použité bylo, evidentně ho někdo mohl znát, a evidentně ho někdo zná, když je v té databázi hesel. Pokud byste chtěl argumentovat tím, co když se náhodou silným heslem trefím do uniklého hesla – to je extrémně málo pravděpodobné.
Řekněme, že máme konečný počet hesel m^(2*n)/2. Máme p uživatelů a q služeb, co používají. Tj. v jednom okamžiku p*q hesel. Jaká je pravděpodobnost kolize?
Pokud navíc máme DB úniků hesel, která se plní rychlostí r(t), dostaneme pro počet použitelných hesel m^(2*n)/2-r(t). Jak se změní situace za 20 let, pokud teď je v databázi úniků 5% možných hesel a plní se rychlostí x hesel týdně?
Princip hesel spočívá v tom, že se dají rychle ověřit, ale nedají se uhodnout zkoušením možných variant. Se zvyšujícím se výpočetním výkonem tedy musí růst množina možných hesel – neplatí tedy, že by počet hesel byl konečný. Že musí růst množina možných hesel, nebo-li že se musí hesla prodlužovat, je nepříjemné, ale plyne to z toho požadavku, že hesla musí být odolná proti útoku hrubou silou. Proto taky hesla nebude možné používat věčně, a už dnes přecházíme od hesel, která si uživatel pamatuje, k heslům, která má uložená ve správci hesel. Mimochodem, velikost databáze použitých hesel nemá smysl řešit – z množiny použitelných hesel odebírá směšně málo případů oproti tomu, co z ní odebírá hrubý výkon počítačů. Za použitelnou entropii hesla můžeme považovat třeba 50 bitů, to byste v té databázi použitých hesel musel mít 140 tisíc hesel na každého člověka na planetě.
Bavíme se samozřejmě o heslech, u kterých má útočník možnost zkoušet varianty dle libosti. Hesla, jejichž ověřování je možné nějak omezovat (např. PIN platební karty) jsou jiný případ.
K cemu silna hesla kdyz stale vice sluzeb zavadi pro "vyssi bezpecnost" 5 otazek pro odemceni uctu pri zapomenuti hesla. Nektere weby jsou dokonce tak agresivni, ze tento "backdoor" je povinny... To jsou ty otazky jako "jmeno matky za svobodna", "znacka vaseho prvni automobilu", "jmeno vaseho nejrychlejsiho kone", atd... A pak je tady problem MFA, to je stale casteji vnucovano, pritom je to takovy opruz; ano, MFA je bezpecne, ale je to opruz, ktery v mnoha pripadech nema hodnotu chranenych dat...
Tak to je jednoduchý, vygeneruju náhodný stringy v KeePassu, pastnu je tam a hotovo. Ono důvodem není ani tak odemčení při zapomenutým hesle, ale chytře vytáhnout nějaký cislivý data (na které škole jsi studoval?)
V tom případě je jméno matky "sdafkxnkla56fxsa4" asi moc neuspokojí, ale nenadělají nic.
Proč by člověk měl mít bezpečné heslo? Když nějaká stránka vynucuje vytvoření hesla pro přidání příspěvku do fóra nebo třeba pro stažení souboru, není důvod, aby uživatel to heslo nějak zabezpečoval. Ať si je ukradne kdo chce, stejně se s ním k ničemu nedostane.
Pokud student ten školní email nepoužívá pro soukromé účely, tak tam není důvod mít tam bezpečné heslo. Správce školní sítě se v tom stejně může hrabat bez znalosti hesla - toho bych se asi bál víc, než, že to heslo někdo uhodne.
Bezpečné heslo mám na domácí síti a na internetovém bankovnictví, jinak to neřeším. Třeba u bugzilly k nějakému opensource projektu není třeba heslo nijak zabezpečovat, útočník nemůže napáchat větší škodu, než že tam bude pod mým účtem psát blbosti.
přesně k tomuhle se používávala sdílená hesla -- možná to ještě existuje. web X vyžaduje registraci ke zpřístupnění nějaké banální funkce: zaregistruješ se a heslo pastneš na speciální web. další návštěvníci se nemusí obtěžovat registrací.
podobně single-purpose maily. web chce email, na kterej ti nikdy nic soukromýho ani důležitýho nepošle. založíš schránku na serveru bez hesla, do níž se dostane kdokoliv pouhým zadáním jména schránky.
Výzkumníci tedy vzali uživatelská jména a hesla všech studentů a porovnali jejich heše s databází 320 milionů osobních údajů pocházejících z velkých úniků Have I Been Pwned.
Rozumim tomu dobre, ze "vyzkumnici" maj v databazi neosoleny hashe a moralizujou o silnejch/slabejch/uniklejch heslech? Nebo v "Have I Been Pwned" nasli hashe osolenejch hesel?