Názory k článku Neuniklo vám heslo nebo privátní klíč? Zjistíte to v databázích úniků
Článek je starý, nové názory již nelze přidávat.
-
Big G (neregistrovaný) 77.78.90.---
Přesně tak. Navíc vůbec nemusí dojít k úniku hesla. Stačí když se někde vyskytne daná emailová adresa.
Např v úniku QIP: In mid-2011, to že QIP heslo vaší emailové schránky nikdy nevěděl, a že jste si ho od roku 2011 již pravděpodobně několikrát změnil je jedno, prostě jste Pwned a hotovo! -
deer (neregistrovaný) 151.237.229.---
Neviete, ci je nejaka moznost v haweIbeenPwned vymazat zaznam, ked ma to uz nezaujima? Napr. na moj email najde 10 sluzieb, z ktorych bol zaznamenany unik. U vsetkych som uz zmenil heslo alebo vymazal ucet. A tak by som rad tie sluzby v haweIbeenPwned znova rad "resetol" do stavu, ze som OK.
-
mngnt (neregistrovaný) 195.80.183.---
1. Ak unikla Tvoja kombinacia mail/heslo z nejakej sluzby, nejde len o to, zmenit to na tej sluzbe, ale HLAVNE o to, zmenit to vsade inde kde tu kombinaciu pouzivas.
2. k samotnej otazke: Predpokladam, ze by to bolo sialene narocne z technickeho hladiska. Uz takto, udrzovat DB s niekolkymi stovkami milionov zaznamov bude strasne narocne, aj ked je iba v RO.
3. ak uz raz bola mailovka leaknuta, je najvyssi cas dat jej zbohom. Bude tam zbytocne chodit spam. Na registracie na sluzby idealne pouzivam jednorazove mailovky https://www.sharklasers.com/, pripadne nejake adresy, za ktorymi mi nebude smutno.
3. Priklad: idem utocit na nejaky zoznam znamych adries, podari sa mi dostat k Tvojmu mailboxu, na haweIbeenPwned mailovku zmenim na neleaknutu (ak mam pristup do mailboxu, mozem to este aj " dokazat") a nadalej si tuto Tvoju mailovku pouzivam, ako sa mi zapaci. Obet (Ty) si to skontroluje, vidi, ze je v bezpeci, nadalej pouziva maily hesla. -
Všechny tyhle služby se mi strašně líbí :-) a také jak se ty důvěřivý lidičkové nebojí je používat :-D
"Jojo, tady nám napište svoje heslo a my zjistíme, jestli je v databázi uniklých hesel. A pokud tam není, tak jej tam přidáme za Vás. A rovnou dyžtak přidejte i e-mail, abychom to měli jednodušší." -
B2 (neregistrovaný) ---.net.upcbroadband.cz
To není o tom jestli je známý nebo ne, ale o tom, že se ví se přesně a adresně, kdo službu provozuje, takže v případě že by zaškodil, policie ví u koho zaklepat. Není to schránka na Bahamách s velkolepým marketingovým názvem. Podle toho můžete upravit míru nedůvěry.
-
knezi (neregistrovaný) ---.koleje.cuni.cz
Spíš bych to ovšem viděl na to API. Protože server mi posílá to (javascriptový kód), co se mu zrovna líbí. Ne že bych chtěl tuhle službu kritizovat, ale prostě obecně nemůžeme věřit, že když ten JavaScript to neposílá, tak to při příštím načtení u někoho jiného nepošle. Jeden z důvodů, proč nextcloud nebude implementovat šifrování úložiště ve webovém prohlížeči.
-
lolo (neregistrovaný) 84.245.121.---
"Stejně tak je možné hlídat celou doménu, na které přijímáte třeba firemní poštu. Správce se tak může dozvědět, že některý z jeho uživatelů má kompromitované heslo"... Píšete blbosti. Služba akurát tak zobrazuje servery, ktorým unikli databázy a vy ste na nich boli prihlásený. To ale neznamená že niekto získal prístup do vášho emailu. Maximálne tak môže vyčítať z uniknutej databázy váš email a heslo ktorým ste sa prihlasovali na "napadnutú" stránku. Ale URČITE NIE heslo do samotného emailu. Samozrejme za predpokladu ak ste neboli blbec a nepoužili ste rovnaké heslo na stránku aké máte do emailu :)... A na druhej strane, HIBP stránka je pekných kolektor emailových adries.
-
Možná by stačilo podívat se jak ten web funguje a zjistíte, že sdílí jen prvních 5 znaků z SHA1 hashe hesla, které použije na hledání leaknutých hashů které začínají na stejné znaky. Výsledné porovnání pak už dělá čistě frontend, který heslo nikdy neopustí. A pro větší paranoiky je pořád ještě možnost použít API a krok po kroku udělat kontrolovaně to samé co dělá web.
heslo: heslo
SHA1 hash: 6e017b5464f820a6c1bb5e9f6d711a667a80d8ea
Prvních 5 znaků: 6e017
Api: https://api.pwnedpasswords.com/range/6e017
Shodný řádek: B5464F820A6C1BB5E9F6D711A667A80D8EA:18782Těch 18782 je počet výskytů v leaknutých datech. Wow.
-
Práce bezpečnostního konzultanta nebude potřeba ve chvíli, kdy NIKDO ani do tak "perfektního webu" nepošle ani nudli. Nebo tady všichni na 100% víte, že to právě teď i včera a zítra funguje přesně tak? Vy kontrolujete JavaScript, který vám zrovna přišel? Přečtěte si alespoň něco o Kevina Mitnicka. Autor webu ví a jistě i zmíní na své přednášce, že lidi jsou prostě trdla, zejména když jeho web použijí (používá důkaz bezpečnostní naivity pomocí reálného příkladu, to se na přednáškách o bezpečnosti dělá vždycky). Upozorňuji, že článek o stejném tématu zde na root.cz není poprvé a já vždycky jen zírám, jak se tady všichni zaklínají, že "tohle přeci můžu/musím vyzkoušet". Kriste pane!
-
Dobře, předpokládejme, že mi přišel zlý JavaScript, který odešle celé heslo v otevřeném tvaru. To samé přece dělá prakticky každý web, ke kterému se přihlašuju, který s tím ovšem posílá ještě přihlašovací jméno. V čem přesně je tedy problém, kdyby se Troy Hunt dozvěděl, že někdo někde na webu nejspíš používá heslo „Gf9VrTd6Dm“?
-
Jenže heslo správně patří jenom do prohlížeče, prohlížeč by nikdy neměl samotné heslo prozradit, vždy jen jeho hash. Realita je ovšem jiná, zdaleka nejběžnější způsob přihlášení je formulář, odkud se heslo posílá v otevřeném tvaru. Jaký je rozdíl v tom, zda heslo zadám na do formuláře Have I Been Pwned nebo třeba tady na Root.cz? Jak můžu vědět, že Root.cz obratem to heslo nepošle třeba právě do Have I Been Pwned? U Troye Hunta si můžu zkontrolovat ten JavaScript, ale na Root.cz si můžu zkontrolovat akorát to, že se heslo opravdu v otevřeném tvaru odesílá na server, a co se s ním děje tam, nad tím už žádnou kontrolu nemám.
Párování hesla s již známým (tím samým) heslem nedává žádný smysl, nedozvím se nic nového. Na potvrzení hesla v takovéhle databázi nevidím nic nebezpečného – pokud to bylo unikátní heslo, nejpozději v okamžiku, kdy ho zadám do HIBP a dozvím se, že uniklo, ho na původním webu změním. Jako korpus pro slovníkový útok je myslím mnohem užitečnější celá databáze HIBP než hesla sbíraná po jednom přes webový formulář.
-
@Filip Jirsák
Super, takže tobě vadí že browser tvé heslo pošle plaintext (ale skrze https) a tak své plaintext heslo vrazíš klidně do cizího webu ... ale co, vzhledem k tomu že provozovatel služby stejně s heslem může udělat cokoliv, tak ho klidně zadám kamkoliv zrovna ... vtiipné.
Kažpodádně i kdyby bylo heslo hashované už v browseru, tak by po tobě tady výzkumník chtěl akorát ty hashe a stejně bys nevěděl co s takovým hashem udělá ten tvůj provozovatel webu, jestli ho taky nepošle kamkoliv ... jediný rozdíl je že nezná původní heslo, ale stejně zná to co stačí k autentizaci vůči serveru. -
Pokud jej budeme považovat za útočníka:
* má další položku do slovníku
* má k ní IP adresu a podobné údaje
* může provozovat i jinou službu, kterou budu používat ze stejné IP (stejného profilu prohlížeče / whatever), která k tomu bude znát moji e-mailovou adresu, username a možná i bude něco tušit o mých zájmech. -
Záleží, o jakém scénáři hovoříme.
a. Pokud všude používám unikátní heslo, pak to určitě je riziko. Na druhou stranu je otázkou, jak moc to má zde smysl – snad pokud by někde leaknulo heslo bez e-mailové adresy.
b. Pokud používám všude stejné heslo, pak je tu „jen“ o jednu službu víc, která ho může znát. Je samozřejmě potenciálně další riziko. Že mohou výhody převážit je věc druhá. Víceméně to je asi scénář, který uvažujete.
c. Nová hesla vytvářím unikátní, ale je tu spousta legacy věcí. To je na zvážení.
d. Věřím, že někdo najde ještě nějaký další scénář mezi A a B, kde v případě nedůvěry v HIBP stojí za zvážení, zda a která hesla tam pouštět přes webinterface. -
V úvahu bychom přece měli brát všechny scénáře. Každopádně provozovateli webu, ke kterému patří to heslo, to heslo předávám. Drtivé většině provozovatelů webů přitom věřím méně, než Troy Huntovi. Pokud používám na více místech stejné heslo, to heslo už stejně nejspíš dávno uniklo a v HIBP dávno je, takže když by se ho Hunt dozvěděl přes web, nedozví se nic nového. Pokud je moje heslo unikátní a já si ho přes web HIBP ověřím (a ten web by si heslo ukládal), dozví se jenom to heslo a nic jiného (ano, IP adresu, UA atd.). V čem vidíte to riziko?
Pokud někdo nevěří tomu webu, může použít REST API.
-
Psal jsem, že předpokládám z nějakého důvodu nedůvěru – reagoval jsem na Vaše tvrzení ve stylu „a i kdyby to posílal v plaintextu“, což je scénář, ve kterém mu moc důvěry nepřisuzujete.
> Pokud používám na více místech stejné heslo, to heslo už stejně nejspíš dávno uniklo a v HIBP dávno je, takže když by se ho Hunt dozvěděl přes web,
Dost možná jen hash. A taky je to otázka množství, pravděpodobnosti atd.
> Pokud je moje heslo unikátní a já si ho přes web HIBP ověřím (a ten web by si heslo ukládal), dozví se jenom to heslo a nic jiného (ano, IP adresu, UA atd.). V čem vidíte to riziko?
Je to další heslo do slovníku. Podle dalšího profilování je určitá šance to spojit s konkrétním uživatelem. V nejjjednodušším případě TH (nebo někdo s ním spolčený) bude provozovat další službu, kde se registrujete, zadáte e-mail nebo něco podobného. To se mimochodem může stát i přímo v rámci HIBP, když tam zadáte e-mail a kontrolujete, jestli náhodou k němu není nějaký kopmpromitovaný účet. Separátní služba je ale méně nápadná.
P.S.: Nemělo to znít, že bych TH vyloženě nevěřil. Jen jsem se zamyslel, co by znamenalo, kdyby…
-
Vít Šesták: K tomu „co by znamenalo, kdyby“ je ale podle mne potřeba dodat, že to se děje dnes a denně na každém webu, kam se přihlašujete heslem.
V HIBP nejsou žádné hashe z úniků, jsou tam hesla v otevřeném tvaru. Taková, která už v otevřeném tvaru unikla, nebo byla tak slabá, že se podařilo hash „rozlousknout“.
Že je to další heslo do slovníku opět platí u každého webu, kam se nějakým heslem přihlašuju.
Pokud někdo nevěří tomu webu, může použít RESTové API. Nebo si může otevřít vývojářskou konzolu a tam si zkontrolovat, že jediný požadavek, který odešel, bylo opravdu prvních pět písmen hashe hesla. Takže i kdyby tam byl kód, který někdy umí poslat heslo v otevřeném tvaru, zjistil bych, že se odeslalo něco víc, a to jedno heslo bych si změnil.
Podstatné je ale to, že HIBP se nedozví víc, než majitel každého webu, kam se přihlašuju heslem – ve skutečnosti se dozví méně, a je snadné ověřit, že se dozví výrazně méně. Takže stejné námitky, které má někdo vůči HIBP, by měl mít vůči každému webu, kam se přihlašuje jménem a heslem.
-
Sdělovat/posílal komukoliv hesla/hashe z důvodu sebevětší "důvěryhodnosti" je hovadina.
Notabene - autor toho webu píše takové logické nesmysly, že se nám vysmívá (vlastně vám, kteří mu heslo dáte, resp. věříte že mu ho možná nedáte). Např. že máte ověřovat/posílat korporátní hesla - to vážně chcete začít sbírat ve své síti plain hesla, abyste je mohli hashovat a cosi kamsi posílat? To jako FAKT? Jen kvůli tomu že má COOL REST API? A že se dozvíte nějaké MAGICKÉ číslo, kolikrát je prý kdesi uvedeno? K ČEMU JE TO DOBRÉ?
BTW: Jasně, Office 365 od MS má teď takovou cool funkci, že když řeknete heslo, občas vám řekne: Takové heslo jsme už párkrát viděli, zadejte jiné. Možná takhle by se nasbíraná data dala zpeněžit nebo využít. Ale je to stejně pytlovina (entropii hesla můžete odhadnout bez posílání hashe kamsi sám).
-
Ono jde o jakýsi kousek hashe, ze kterého nelze určit, co přesně to bylo za heslo, protože na tak malém kousku je dost prostoru pro kolize. Je to jen takový kompromis mezi posláním celého hashe (případně hesla v plaintextu) a stahováním celé databáze, která je mimochodem také k dispozici.
K entropii: Ano, dá se různě odhadovat, ale není to až tak triviální problém. Je heslo 47ET6GECDFKWHT47AYIJQWKWKI====== bezpečné? Teď už ne, protože jsem jej postnul veřejně. Jakou má entropii:
* Před publikováním mělo entropii 128 bitů, protože jsem jej vytvořil pomocí head -c16 /dev/random | base32.
* Pro toho, kdo nevěděl, jak jsem to heslo využil, mělo ještě větší entropii.
* Pro mě a pro ty, kdo četli tento příspěvek, má to heslo nízkou entropii.Prakticky jsem už četl o případu, kdy bylo cracknuté „podobné“ heslo, protože jej někdo využil z nějaké přednášky. Taky různý 1337 $p3€ch se může někdy na malém vzorku jevit jako heslo s vyšší entropií než má ve skutečnosti. A sebelepší heslo má malou entropii, pokud unikne z jiné služby.
Přijde mi to tedy jako pěkný doplněk dalších mechanismů kontroly síly hesla.
-
Milan Keršláger: Hovadina je komukoli posílat/sdělovat hesla. Bohužel na téhle hovadině je založený dnešní web. Mně se to nelíbí, kritizuju to, ale to je asi tak všechno, co s tím můžu dělat. Sám sebe chráním alespoň tím, že různým webům posílám unikátní hesla.
Korporátní hesla nemusíte začít sbírat – to, že klient odešle heslo na server, a tam se zkoumá, jestli splňuje bezpečnostní politiky, se s korporátními hesly dělá naprosto běžně. Kdyby se server nedozvěděl heslo v otevřeném tvaru, nemůže kontrolovat, zda neobsahuje uživatelské jméno, jméno, příjmení, známá slova nebo zda není příliš podobné předchozím padesáti heslům.
Jediný bezpečný způsob zacházení s hesly je takový, že heslo zná jen uživatel a software, kterému uživatel může důvěřovat. Jakmile heslo zná víc než jeden subjekt, je to špatně. Bohužel tenhle špatný způsob se dnes používá v drtivé většině případů. V takové situaci je nejnebezpečnější to, když uživatel používá stejné heslo na více místech. A na to se právě zaměřuje Have I Been Pwned, protože pokud heslo bylo součástí nějakého úniku, určitě není použité poprvé. Když použijete dobré heslo, nemůže se vám stát, že už existuje v databázi uniklých hesel – ta pravděpodobnost, že se dobrým heslem trefíte do hesla někoho jiného je příliš nízká. Přičemž tuhle entropii nijak odhadnout nedokážete, jediná možnost je prohledat ten seznam známých hesel.
Pláčete na špatném hrobě. To, že je naprosto běžné, že heslo nezná jen uživatel, ale předává ho provozovateli nějaké služby, není výmysl Troye Hunta. On na ten problém jenom upozorňuje. Kdyby měly servery uložené jen ServerKey a StoredKey, nebo jen veřejné klíče, žádná databáze uniklých hesel by nemohla vzniknout a Have I Been Pwned by neexistovalo.
-
Tady nejde o entropii ve smyslu náhodnosti, ale jestli to heslo není zkonstruováno na základě běžného slova (slovo heslo, 1234568, jméno/příjmení uživatele atp).
Vstupovat do autentizačního mechanismu v korporátu (abyste mohl cosi kdesi ověřit) je ještě větší pytlovina. Jen vložením nutného kódu snížíte bezpečnost systému řádově (je pak jednodušší ty hesla doopravdy sbírat). Běžný programátor neví, jak ochránit paměť proti leaknutí původního obsahu, běžně se vyrábí logy (ve kterých budou citlivé informace) atd.
-
Milan Keršláger: Jenže u hesel jde o entropii ve smyslu náhodnosti. Při louskání hesel hrubou silou jde o to vyzkoušet co nejrychleji co nejvíc nejpravděpodobnějších hesel. Pokud uživatelé vytváří hesla na základě běžných slov, bude útočník zkoušet hesla vytvořená na základě běžných slov. Pokud budou uživatelé vytvářet hesla podle XKCD 936, budou útočníci hesla k vyzkoušení vytvářet stejným způsobem. Obecně jakékoli známé pravidlo pro tvorbu hesel obrovsky snižuje entropii hesla, protože útočník samozřejmě nebude zkoušet všechna možná hesla, ale právě hesla odpovídající těm známým pravidlům. Proto je mimochodem tak nebezpečná povinná změna hesla po určitém čase, protože to u většiny uživatelů znamená, že si vytvoří velmi jednoduché pravidlo po to heslo. Takže jediná entropie, která se u hesel počítá, je skutečná entropie, náhodnost.
Mechanismy změny hesla v korporátu většinou mají možnost nastavit politiku hesel. Součástí toho bývá i možnost ověřit heslo nějakým externím nástrojem. Např. pro Windows Server jsou to Password Filters, pro OpenLDAP je ppolicy overlay atd. Únik hesla z paměti není potřeba řešit, bavíme se tu o autentizačním serveru – pokud může útočník číst jeho RAM, máte úplně jiný problém, než únik jednoho hesla.
-
Útočník neútočí na nejsilněji chráněné, nýbrž na nejslaběji chráněné místo. To znamená že buďto máte uhodnutelné heslo (Filip123) nebo je to fuk, jaké si dáte (OsBrnoTrava). Entropie je vám úplně k ničemu, protože když budete mít heslo Kr2!V5PHc$xUd%3, musí si ho uživatel někam napsat (nebo to mít v SuperHyperPasswordManageru) a tím pádem je absolutní entropie k prdu, protože nepřežije útok Mitnicka (tj. sociální inženýrství) nebo si útočník si přečte logy z pohozené zálohy, kde vy budete mít záznam z komunikace s tím super mega API.
Nechápete totiž, že při plané honbě za SuperHeslem vytvoříte desítky dalších slabých míst.
-
1. Password manager naopak Mittnicka částečně zalepí – heslo se mi u rhybářů samo nevyplní.
2. Špatné logování a špatně zabezpečené logy nevzniknou použitím silného hesla anu použitím password manageru. Naopak, vhodné použití password manageru omezí dopad na ten jeden web, protože najednou není problém mít unikátní a kvalitní hesla. -
OsBrnoTrava je ale také uhodnutelné heslo. Zvlášť pokud útočník ví, že heslo tvoříte vložením názvu města do jiného názvu města. Vzhledem k tomu, že hesla dnes znají minimálně dva subjekty, musí těch silných hesel mít uživatel desítky, takže jediná bezpečná možnost je používat správce hesel. Sice je to drbání se levou rukou za pravým uchem, ale dnes je to nejbezpečnější řešení. Sociální inženýrství s tím nijak nesouvisí, pokud z vás někdo dokáže heslo vylákat, je jedno, zda je to slabé heslo nebo zda mu ho dáte ze správce hesel.
Vaše poznámka o logách komunikace s API Have I Been Pwned je už čirá demagogie. Do toho API se posílá prvních pět znaků hexadecimální reprezentace SHA-1 hashe hesla. Víte, k čemu to útočníkovi bude?
Já nepíšu o žádné honbě za SuperHeslem. Zato vy jste nepopsal ani jedno reálné slabé místo. Zmínil jste akorát sociální inženýrství, které s HIBP nijak nesouvisí, a pak jste si vymyslel nesmysl s logy.
Mimochodem, pořád se bojíte úniku hesla z autentizačního serveru. Což je ale přesně ten problém, o kterém jsem psal – že se autentizační server heslo vůbec dozví. A přesně na tohle je také důvod, proč vůbec může existovat HIBP, a proč upozorňuje právě na to, že vaše heslo zná i provozovatel webu nebo jiné služby, a to heslo tudíž může uniknout. Neustále přehlížíte, že HIBP není příčina, ale následek.
-
> Že je to další heslo do slovníku opět platí u každého webu, kam se nějakým heslem přihlašuju.
To mi přijde trochu mimo to, co jsem říkal. Pokud heslo používám na jediném webu, pak provozovatel si může heslo uložit do slovníku, ale nebude mu až tak moc platné. Může se s ním maximálně přihlásit na tentýž web a dělat něco, co by nejspíš mohl tak jako tak. Když ho ale sdělím TH, mohl by teoreticky se ho snažit někde zneužít, případně dohledat, ke kterému webu patří. Jenže TH bez toho hesla na ten server přístup nejspíš nemá (i když i to se teoreticky může stát), takže to není totéž.
-
Psal jsem různé scénáře, protože se to různě opatrní lidné mohou snažit použít. Ironicky, opatrnější lidé s unikátními hesly o HIBP budou spíše vědět než neopatrní. (Jak moc bude kdo ochoten tam zadat svoje heslo – to už je druhá věc.) Otázka je, komu je vlastně vyhledání uniklého hesla určeno:
* Lidé s unikátními silnými hesly nic takového nepotřebují. No, ledaže by uniklo plain heslo bez e-mailové adresy, ale kontrolovat tam pravidelně všechna hesla by taky byl porod.
* Lidé opakovaně používající stejné nebo dost slabé heslo se o to až tak nezajímají a hlavně: těžko jim to radit jako systematické řešení.
* Kromě těchto krajních případů tu mohou být různé „něco mezi“, možná tam to najde větší využití.
* Třeba to má trochu jiný účel – demo nebo šlo o hračku autora. Případně to někoho může přesvědčit, jak velký problém je znovupoužití hesla.Těžko se mi z toho usuzuje, kdo to vlastně bude používat a čím to bude krmit. Váš předpoklad mi tedy nepřijde až tak samozřejmý.
-
Záleží, o jakém scénáři hovoříme.
a. Pokud všude používám unikátní heslo, pak to určitě je riziko. Na druhou stranu je otázkou, jak moc to má zde smysl – snad pokud by někde leaknulo heslo bez e-mailové adresy.
b. Pokud používám všude stejné heslo, pak je tu „jen“ o jednu službu víc, která ho může znát. Je samozřejmě potenciálně další riziko. Že mohou výhody převážit je věc druhá. Víceméně to je asi scénář, který uvažujete.
c. Nová hesla vytvářím unikátní, ale je tu spousta legacy věcí. To je na zvážení.
d. Věřím, že někdo najde ještě nějaký další scénář někde mezi A a B, kde v případě nedůvěry v HIBP stojí za zvážení, zda a která hesla tam pouštět přes webinterface. -
@Milan Keršláger
Proto uvádím tu variantu s API, používám to přes něj. Napsat si třeba v Pythonu vlastní bezpečné ověřovadlo hesel je na pár minut. A proti odeslání prvních 5 znaků SHA1 snad nemáte nic, ne? :)
To API je mimochodem hrozně fajn i pro password managery, je díky tomu možné jednoduše pro uživatele kontrolovat úniky jeho hesel.
-
Přezdívka: * (neregistrovaný) 185.82.239.---
Bohuzel, nekterym lidem to muzete dat cerne na bilem, kopat je u toho tam kam slunce nestviti a stejne budou u REST API mlet neco o Javascriptu. Jiz chvili zvazuji zabudovani tohoto endpointu do naseho systemu. Sice mam implementovany fail2ban a 2FA, ale radsi k tomu pridam i hesla, ktere nejsou ve slovnicich.
-
NN (neregistrovaný) ---.87-197-140.telecom.sk
Testol som pre zaujímavosť jedno staré heslo a podľa webu je pawned. Stiahol som preto konkrétny súbor s uniknutými heslami a pri hľadaní konkrétneho NTML hashu som zistil, že ide o false positive. Z dôvodu, že web databázu dotazuje len na prvých niekoľko znakov hashu, je to naozaj dosť nespoľahlivé.
-
Z dôvodu, že web databázu dotazuje len na prvých niekoľko znakov hashu, je to naozaj dosť nespoľahlivé.
Proč si vymýšlíte vlastní teorii, když je to v článku napsané? Web se sice serveru dotáže na prvních pět znaků hashe, ale server vrátí všechny hashe takto začínající, a JavaScript mezi nimi pak hledá už ten jeden konkrétní SHA-1 hash. Pokud jste skutečně narazil na SHA-1 kolizi, pak gratuluju, budete slavný – pokud vím, byla by to druhá známá kolize SHA-1 a určitě první nalezená náhodou. -
Ano, byli to lidé z Google. Ten můj komentář byl psán trochu v nadsázce – náhodnou kolizi kryptografických hashů samozřejmě nikdy neuvidíte, pravděpodobnost vzniku takové kolize je extrémně nízká, a na tom je celý princip kryptografických hashů založen. Kdyby někdo narazil i na náhodně vzniklou kolizi, byl by to pro danou hashovací funkci problém a znamenalo by to její postupný konec – bez ohledu na to, že nevznikla záměrně a neuměli bychom jí zopakovat.
-
- Odborný operátor helpdesku
- PROGRAMÁTOR
- Vývojář/konzultant Dynamics CRM
- DevOps/CI developer
- Programátor webových aplikací
- Tester
-
- Jak šetřit čas při práci s e-maily
- Zkušenosti generála tajné služby: Práce s lidmi
- Paměťový palác - tajemství všech mistrů paměťových soutěží
- Co se v mládí naučíš, v byznysu zapomeň
- Start Speaking Czech Now! - The Essentials
- Osobní styl muže jako brána k úspěchu
-
- Odborný operátor helpdesku
- PROGRAMÁTOR
- Vývojář/konzultant Dynamics CRM
- IT Projektový manažer - junior (SW&APP)
- Programátor JAVA
- Programátor webových aplikací
-
- Vizuálním myšlením k úspěšnému byznysu
- Paměťový palác - tajemství všech mistrů paměťových soutěží
- Talent management generace Y
- Co se v mládí naučíš, v byznysu zapomeň
- Funkce datum a čas v Excel
- Osobní styl muže jako brána k úspěchu
