.bash_history aneb rok se s rokem schazi

29.12.2020 21:09 | Přečteno: 2985× | Všechno možný |

Tak se nam vazeni blizi konec roku a to je cas poohlednout se po minulosti cili do historie. K tomuto slouzi vsem jiste znamy prikaz:

history

Zadavane prikazy se nam hromadi v:

~/.bash_history

Pokud jako ja chcete aby soubor porad bobtnal a bobtnal, neprisli tak o cenne prikazy sparametry tak je treba nastavit neomezenou velikost a neomezeny pocet radku v:

~/.bashrc

Jedna se o tyto parametry (-1 znamena neomezene):

HISTSIZE=-1
HISTFILESIZE=-1

Netreba se bat a vyhledavani v .bash_history ktery ma i pres 1 MB je okamzite a netreba se obavat jakehokoli cekani.

Jak v historii sjednat poradek? Nejsnaze treba timto prikazem:

sed 's/^[ \t]*//;s/[ \t]*$//' ~/.bash_history | sort | uniq > vystup.txt 

Soubor vystup.txt je procisten od mezer, tabulatoru, duplicitnich radku, V oblibenem textovem editoru jej jeste rucne prohledneme a protoze je vse abecedne serazeno tak snadno odstranime to co nepotrebujeme (nebo je dokonce i nebezpecne) a nahradime jim ~/.bash_history. I soubor ktery ma nekolik stovek kB lze za par minut proletnout a ihned odhalit co smazat.

Aby se nam snadno v terminalu v historii hledalo tak se hodi alias do ~/.bashrc ktery doplnime na konec tohoto souboru:

alias his="history | grep -i"

Nyni jiz staci zadat napriklad cast nazvu programu:

his ffmpe

A terminal nam vypise vsechny prikazy kde se vyskytuje ffmpe tedy ffmpeg a to bez ohledu na velikost znaku. Hledany retezec je barevne (obvykle cervene) zvyraznen. Abychom mohli prikaz vcetne pripadnych casto slozitych parametru spustit tak pouzijeme vsemocny vykricnik + cislo radku ktere nam vypise terminal pred kazdym radkem kde byl pouzit retezec ffmpe. Vypada to treba takhle:

!458

Po tomto zadani je prikaz ihned vykonan coz casto neni zadouci a proto pouzijeme malou upravu a to:

!458:p

Nyni se prikaz z radku 458 objevi v terminalu, sipkou nahoru jej vlozime, lze jej upravit a nasledne teprv spustit.

Casto se hodi i komentare k prikazum ktere funguji tak ze na konec prikazu dame # a za ni nejake poznamky napr:

youtube-dl --extract-audio --audio-format mp3 --audio-quality 0 --prefer-ffmpeg URL # Stahne, ulozi, extrahuje zvukovou stopu 

Prikaz se normalne vykona a ulozi do historie spolu s komentarem. Komentare si samozrejme lze dopisovat v textovem editoru do souboru .bash_history i dodatecne.

Koho by sraly opakujici se jednoduche prikazy v .bash_history napr: sudo cp mv df ... tak lze do ~/.bashrc doplnit:

# Nasledujici prikazy se nebudou ukladat do .bash_history. Hvezdicka znamena neukladat ani prikazy s parametrama:
HISTIGNORE=history*:his*:ps*:free*:df*:ls*:cd*:top:mc:sudo*:su:exit:uptime:clear

Nyni jeste dve drobne modifikace v ~/.bashrc:

# Ulozi prikaz po odentrovani do .bash_history aniz by bylo treba zavrit (opustit) terminal:
PROMPT_COMMAND="history -a; $PROMPT_COMMAND"
# Stejne prikazy jdouci po sobe budou ulozeny jen jednou a prikaz s mezerou na zacatku nebude ulozen do historie:
HISTCONTROL=ignoreboth

Toz toliko malickosti ktera se muze hodit. Pokud sami mate nejake vychytavky ktere pouzivate v souvislosti s historii prikazu v terminalu tak se sam rad poucim. Historie v terminalu je silna vec, dobre vedena, opatrena komentari dle mych dlouhodobych zkusenosti efektne nahrazuje tvorbu vlastni dokumentace prakticky ke vsem konzolovym nastrojum.

Preji vsem mnoho zdravi, radosti, uspechu v nasledujicim roce a hezky zbytek vanocnich svatku.        

Komentáře

[Petr Fiedler]

To je super zápis. Díky

[kol-ouch]

Jen tak mezi řeči - kolikrát tam máš nějaké heslo omylem zadané do řádku místo do dotazů na heslo (nevím jak to lip popsat)? Mě se třeba stává, ze po su nedoklepnu enter a rovnou píšu heslo a to pak odklepnu - tzn to pak vypadá nějak takhle:

su skfjfjdkskjjjdjjsj

[Jendа]

Ani jednou (ale teda asi je to taky tím, že heslo vlastně nikdy nezadávám -- jen při bootu k disku a pak k zamčené obrazovce). Ale občas se mi stávalo, že jsem do terminálu pastnul nějaký mnohořádkový text a bylo to strašné (naštěstí to nebylo nic zákeřného, takže to dělalo pouze bordel). Postupně se ale něco upgradovalo a nejdřív jsem si začal všímat na vzdálených systémech, že když pastnu příkaz s newline, tak se nevykoná (bylo to velmi matoucí, neboť to nemělo žádnou vizuální indikaci, a kdybyste někdo řešil, jak to vypnout, tak printf \"\e[?2004l\" třeba do PROMPT_COMMAND), ale pak se mi lokálně začalo dít, že pastnutý nepotvrzený text je reverzní video a to už je dobré protože to vidím. Lokálně už mě to párkrát stihlo zachránit. Ale na vzdálených serverech to furt vypínám, protože to, že bych něco takhle omylem pastnul do SSH, se mi nestává, a naopak dělám to, že kopíruji z připravené kuchařky příkazy včetně newlines a ony se rovnou vykonávají.

[Petr Fiedler]

Ani jednou (ale teda asi je to taky tím, že heslo vlastně nikdy nezadávám -- jen při bootu k disku a pak k zamčené obrazovce).

Ty máš vypnuté sudo? Respektive jsi stále root? Není to nebezpečné?

[Jendа]

Mám sudo bez hesla. https://xkcd.com/1200/

[Martin Tůma]

Ježiši, to sem nemůžeš psát. Teď sem vlítne "expert Max" a vysvětlí ti, že "se s tím nemůžeš chlubit v diskuzích a snažit se to obhajovat".

[Petr Fiedler]

Kdysi jsem to měl pár dnů taky nějak tak nastaveno. Prostě jsem nemusel zadávat heslo. Většinou ale všichni tvrdí, že je to risk. Kdyby ti třeba někdo naboural stroj, tak by si mohl dělat co chce. Kdysi mi tu někdo vytkl i jen to, že jsem zadal se sudo příkaz, který se sudo není potřeba zadávat. Proto mě dost překvapilo, že jsi napsal, že nezadáváš heslo. Já používám jen pc a když bych někdy výjimečně použil venku nb, tak kdybych se od něj vzdálil, tak bych jej uzamknul. Takže se nebojím toho, co je v tom vtipu, co jsi odkázal. Spíše by se mi někdo mohl dostat do pc. Buď po síti, nebo bych třeba zobrazil nějaký obrázek, nebo tak něco. Jak je podle tebe reálné, že k tomu může dojít?

[xkucf03]

Pokud někdo napadne tvůj účet a tvoje desktopové prostředí, tak už je vše ztraceno. Může ho upravit tak, aby sis při příštím zadávání hesla myslel, že ho zadáváš do legitimního SSH agenta nebo sudo, a ve skutečnosti se heslo odešle útočníkovi nebo někam uloží. To bys musel na roota chodit někudy úplně jinudy, nezávisle na tvém desktopu – Ctrl+Alt+F2 nebo něco podobného, čemu věříš, že z tvého běžného účtu nelze napadnout (ano, někde to takhle mám – na roota chodím třeba jen přes SSH nebo z textového terminálu, ale je to nepohodlné).

Když ale odemykáš sudo nebo SSH klíče ze svého běžného desktopu, tak je to celkem jedno – to heslo už nikoho nezastaví, maximálně nějakého amatéra, škodolibého příbuzného nebo spolubydlícího atd. Ještě tak to může fungovat jako obrana před vlastní blbostí – během zadávání hesla ti může dojít, že děláš něco špatně a opravíš se – ale na to bych moc nesázel.

[Petr Fiedler]

Pokud někdo napadne tvůj účet a tvoje desktopové prostředí, tak už je vše ztraceno. Může ho upravit tak, aby sis při příštím zadávání hesla myslel, že ho zadáváš do legitimního SSH agenta nebo sudo, a ve skutečnosti se heslo odešle útočníkovi nebo někam uloží.

A jak ten účet upraví, když nezná to heslo? Nebude moci instalovat, ani uděla nějaký zásah do systému, protože to po něm bude chtít to heslo, které nezná.

[Bherzet]

Vloží to do konfiguráků prostředí (v i3 třeba ~/.config/i3/config, odkud se taky dají spouštět programy), do .bashrc (spustí se po otevření terminálu) atd. Potom samozřejmě může vytvořit uživatelskou systemd službu. Možností je spoustu.

[Petr Fiedler]

A proč se tedy vývojáři obtěžují s nějakými bezpečnostními politikami? Jak to tady tak čtu, tak je to totální fraška.

Jinak díky za vysvětlení.

[Bherzet]

Jako proč se považuje za problém lokální eskalace práv nebo tak?

No, protože když ti třeba databáze poběží pod nějakým uživatelem a někomu by se podařilo najít v ní chybu umožňující vzdálené spouštění kódu, tak by pořád měl jen práva toho uživatele. Nedostal by se k dalším službám, které by běžely pod jinými uživateli.

Zde v diskuzi argumentují, že na desktopu je situace jiná a pokud se útočník zmocní uživatelského účtu, pod kterým máš veškerá svá data, cookies z prohlížeče a podobně, tak už není asi až tak zásadní rozdíl, jestli se útočníkovi podaří získat i roota. V tom mají pravdu jen částečně. Když už nic jiného, tak bych určitě nechtěl, aby mi nějaký malware přeflashoval EEPROMku a pak dokázal infikovat i nově nainstalovaný systém. O tom mi kdysi říkal kamarád z AVG, že se to prý děje.

[Petr Fiedler]

Takže na desktopu je dobré mít nastavené heslo u sudo, nebo je to zbytečné?

[Bherzet]

Osobně to heslo zatím vypínat nebudu, ale jen proto, že mi vyhovuje ten extra mezikrok, kdybych něco spustil omylem. Jinak je to asi fakt zbytečné a z bezpečnostního hlediska je to úplně jedno.

Spíš jsem si během té diskuze vzpomněl, že jsem si chtěl vždycky pořídit nějaké sandboxování, ale nevypadalo to moc použitelně. Jenda se zmínil o Qubes OS, tak teď zkoumám to. To by byla dobrá prevence toho hlavního průšvihu, tj. kompromitace hlavního uživatelského účtu.

[Petr Fiedler]

Qubes jsem taky zkoušel, ale neměl jsem volné SSD, takže jen na HDD a už u instalace mě to varovalo, že SSD je silně doporučeno. Přesto jsem do doinstaloval, ale používat se to nedalo. Bylo to neuvěřitelně pomalé. Na nové sestavě to bude určitě lepší (NVMe). Chtěl bych to ale mít šifrované, tak snad s tím nebude z hlediska výkonu problém. A ještě taky nevím, jestli to budu moci opticky ohnout tak, jako Mint - lupa, kotrast atd.

[Martin Mareš]

No myslím, že pokud někoho doopravdy zajímá bezpečnost, tak by si především měl dvakrát rozmyslet, jestli si vůbec nějaké sudo chce instalovat. Historie bezpečnostních děr v tomto nevelkém kusu softwaru je dost strašidelná :)

Variantou může být třeba ssh root@localhost příkaz s autentikací klíčem.

[Petr Fiedler]

Díky.

[xkucf03]

+1

Od doby, kdy se do logů ukládá otisk klíče (takže je poznat, který root se kdy přihlásil), nevidím praktický důvod proč nutit správce používat sudo (leda v případě, že by měli povolené jen vybrané příkazy, ale to většinou neplatí).

[Petr Fiedler]

Tak už nemusíš odpovídat.

[k3dAR]

napr. si prida do ~/.bashrc funkci sudo, pak kdyz pustis "sudo program" tak se nepouzije prave sudo, ale tato funkce, ktera to tve heslo nejdriv posle utocnikovi a pak pustit ten tvuj prikaz, takze nic nepoznas

[Bherzet]

Hah, to mě nenapadlo. A nebo vlastně ještě může vytvořit soubor v ~/bin. Nějak dneska nemám kreativitu, mě napadlo jen „v /usr/bin/ to nepřepíše“ a dál jsem pracoval s tím.

[Petr Fiedler]

Takže mít nastaveno heslo u sudo je tedy zbytečné, ano?

[Petr Fiedler]

Už v tom mám jasno.

[Bherzet]

No, nevím. Je přecejen rozdíl, jestli útočník získá roota okamžitě poté, co něco spustíš pod normálním uživatelem, a nebo prvně musí heslo ukrást. To taky není taková legrace. Nainstaluješ keylogger, musíš ho někam schovat a nastavit mu automatické spouštění, čímž vzniká malé riziko, že si toho uživatel všimne (systemd služby si může vylistovat, konfiguráky/skripty mít verzované, …), a největší oříšek potom je poznat, co z těch zadaných znaků vlastně je to heslo. Asi budeš muset detekovat aktivní okna, ale hledat v těch stisknutých klávesách nějaké sekvence typu sudo-něco-enter-heslo taky není bullet proof, protože třeba sudo apt^C a pak jiný příkaz ti to rozhodí. Takže bys buď potřeboval nějaký emulátor Bashe, nebo to někam posílat přes síť k analýze (což může narazit na nějaký firewall), a nebo to brute-forcovat. A tam se zase uživatel může dozvědět, že mu něco generuje neplatné pokusy o přihlášení…

Náročnost takového útoku je výrazně vyšší. V žádném případě neříkám, že je to neproveditelné, protože není. Už to ale musí dělat motivovaný, technicky zdatný jedinec. A ten to pravděpodobně bude dělat masově a pokud nebudeš mezi prvními, máš alespoň malou šanci, že před probíhajícím útokem budeš včas varován.

Pak je tu samozřejmě to spuštění příkazu omylem. Ručně se to asi nestane, ale u spuštění skriptu (i legitimního vlastního) se to může stát celkem snadno. Chtěl jsem spustit něco, spustil jsem něco jiného, najednou to chce roota – proč?

Za bezpečnostní díru bych vypnuté heslo u suda samozřejmě neoznačil, ale jako moc dobrá praxe mi to taky nepřijde. Na serveru, kde většinu příkazů stejně spouštím pod rootem, je to úplně jedno, ale na desktopu by mi to vadilo.

[Bherzet]

Beru zpět, ukrást to heslo je mnohem jednodušší. Máte pravdu, že když někdo získá přístup k hlavnímu uživatelskému účtu na desktopu, je to asi fakt konečná.

[k3dAR]

ten xkcd "vtip" neni ani tak vtip je to spis poukazani na to, ze clovek kterej se snazi "paranoidne" zabezpecit admin ucet, si treba neuvedomuje ze dulezitejsi udaje pro utocnika ma primo dostupne uzivatelem bez potreby znat admin heslo

[Petr Fiedler]

Tak já mám 3 oblasti, které chci mít zabezpečené. První je bankovnictví. Tam mám nastaveno 2 fázové ověřování, takže bez mobilu by to měl útočník opravdu hodně těžké. Druhá oblast jsou hesla. Mám stažený Bitwarden, ale pořád se nemůžu dostat k tomu, abych si o něm něco přečetl a zprovoznil jej. Třetí oblast jsou dokumenty, které obsahují citlivé údaje jako r.č. atp. Ty mám sice na šifrovaném oddílu, ale ten se mi automaticky odemyká a připojuje při bootu. Tady nevím, jak to zabezpečit, protože i kdybych na tom oddílu vytvořil nějaký kontejner a ty dokumenty dal do něj, tak bych jej stejně někdy musel odemknout a byl bych tam, kde teď. Takže tady mě napadá jedině být velmi opatrný a mít zabezpečený co nejlépe systém proti útoku z venčí. Tady ale musím spoléhat na tvůrce Mintu a programů, protože na to moje znalosti v žádném případě nestačí.

Jinak jsem si toho vědom a relativně mě to trápí.

[Otto]

Spíše by se mi někdo mohl dostat do pc. Buď po síti, nebo bych třeba zobrazil nějaký obrázek, nebo tak něco.

Jak je podle tebe reálné, že k tomu může dojít?

Asi jako že až se dnes vyspíš bude už druhého.

[Heron]

%wheel ALL=(ALL) NOPASSWD: ALL

[Petr Fiedler]

Tvojí odpověď nechápu. Mohl bys mi k tomu prosím tě něco napsat?

[Heron]

Ptal ses, jestli má vypnuté sudo nebo je stále root.

Sudo není potřeba mít vypnuté a přesto není potřeba zadávat heslo. V /etc/sudoers (přes visudo), lze nastavit jednotlivých uživatelům nebo skupinám přístup bez hesla. V tomto případě členům skupiny wheel na FreeBSD, nebo podobně skupině sudo na Debianu. Je to zkrátka jeden řádek v souboru sudoers.

Tj ne, uživatel není stále root (pracuje pod svým běžným uživatelem), může používat sudo, ale neptá se to na heslo. Pochopitelně tohle se nastavuje pouze skutečným adminům. Uživatel se přihlašuje pomocí klíčů (hesla nejsou ani povolená), heslo nastaveno mít ani nemusí (tj není co zadat do promptu sudo) a přes to může používat rootovské příkazy.

[Petr Fiedler]

A není to nebezpečné?

[Martin Tůma]

Pokud se víc bojíš toho, že se někdo dostane k nastavení tvé tiskárny než k tvému bankovnímu účtu, mailu, nebo pornu s přítelkyní, tak ano, je to nebezpečné.

[Petr Fiedler]

nebo pornu s přítelkyní

Přijde ti normální tohle napsat člověku, který se na něco slušně zeptá?
Podle sebe nesuď mě.

[Martin Tůma]

Přijde ti normální tohle napsat člověku, který se na něco slušně zeptá?

Nevidím na té odpovědi nic neslušného. Domácí porno je tam jako příklad souboru, u kterého opravdu nechceš, aby se k němu dostal někdo cizí. Jestli tě uráží slovo porno, tak si tam dosaď třeba "daňové přiznání".

Podle sebe nesuď mě.

Programátor, který obvykle nemá sex, natož přítelkyni, tě tady těžko bude soudit podle sebe...

[Heron]

Ne, není to nebezpečné.

Franta už to napsal výše.

Záleží na kontextu, na desktop už bylo odpovězeno, já řeším servery.

SSH je pouze pomocí klíčů a ssh přístup na roota je vypnutý. Jak přesně více ochrání zadání hesla uživatele? Pokud už útočník má dešifrovaný soukromý klíč správce, tak si může upravit prostředí admina a to heslo stejně získá.

Tj povolit sudo skutečným adminům není nebezpečné, protože ti už stejně přístup na roota mají. Navíc, aby to heslo za něco stálo, tak dneska musí mít 24+ znaků a to nikdo vypisovat nebude. Tj ke všemu již uvedenému stejně ještě řešíme uložení hesla.

[Petr Fiedler]

Pokud už útočník má dešifrovaný soukromý klíč správce, tak si může upravit prostředí admina a to heslo stejně získá.

Nevím, co myslíš tím "dešifrovaný", ale já mám u SSH klíčů nastavena 20 místná hesla složená ze všech typů znaků.

Navíc, aby to heslo za něco stálo, tak dneska musí mít 24+ znaků...

Zdroj?

[Heron]

Nevím, co myslíš tím "dešifrovaný", ale já mám u SSH klíčů nastavena 20 místná hesla složená ze všech typů znaků.

Ano, to je passphrase, kterým je zašifrován ten soukromý klíč. Pro použití (tj přihlášení se na server) je potřeba ten klíč dešifrovat. Což se děje buď vložením do agenta (ssh-add), nebo při přihlášení pomocí ssh. Pokud útočník získá (z paměti) tento dešifrovaný klíč, už nepotřebuje jeho passphrase.

Zdroj?

Toto je krajně neslušné.

Zdrojem je tzv šifrovací síla. Ta se udává v bitech entropie. Dneska je minimálně 128b. Při použití abecedy o 37 znacích to vychází na 25 písmen (log(37^25) / log(2) = 130b). Navíc toto heslo není v žádném případě možné používat pro více věcí, protože potom se z toho stává sdílený klíč a tam je nutné uvažovat narozeninový paradox a tedy zdvojnásobit délku).

Jinak já začínám mít docela problém s tím 128b. Protože 96b bylo hrubou silou prolomeno už docela dávno, pokud by platilo, že se výkon každý rok zdvojnásobuje*, tak je to jen 32 let a to už tam skoro budeme. NSA doporučuje zvýšit velikost RSA klíčů na 3072b (já používám 4096b), SHA minimálně 384 (já 512), ale AES stále na 128 (já 256). Tj i pro NSA začíná být 128b síly trochu málo.

*) Moorův zákon sice už moc neplatí, ale na druhou stranu máme GPU a stroje na síti.

[Petr Fiedler]

Díky za vysvětlení.

Toto je krajně neslušné.

Omlouvám se ti. Viděl jsem to psát lidi a tak jsem to použil. Neměl jsem zlý záměr. Psal jsem větu, ve které jsem tě prosíl o nějaký zdroj pro potvrzení té informace, ale přišlo mi to dlouhé, a tak jsem jí smazal a napsal jen "Zdroj?", abych to zkrátil. Už to tak nebudu psát.

Jinak já všude a vždy používám to nejdelší, co jde. Tedy alespoň pokud je mi známo.

[Jendа]

Protože 96b bylo hrubou silou prolomeno už docela dávno

O jaký případ jde? Například celý Bitcoin za dobu své existence spočítal 2^94 hashů. Zlomit běžnými prostředky třeba i 50bit heslo pokud se k odvození klíče používá nějaká funkce typu Argon mi přijde dost obtížné.

[Heron]

O jaký případ jde?

Hele, musím to najít. Viděl jsem (snad na stackoverflow) pěkný přehled všech veřejně známých brute force útoků a končilo to asi rokem 2000 a potom ticho po pěšině. Samozřejmě jsem si jej neuložil. To byla doba, kdy se ještě soutěžilo v brute force prolamování md5 (tj 128b, když máš smůlu, 64b, když máš narozky nebo Silvestra).

Existuje RSA Factoring Challenge, kde se letos podařilo lousknout 829b složené číslo. Ale převod na crypto sílu se dělá dost těžko.

Zlomit běžnými prostředky třeba i 50bit heslo pokud se k odvození klíče používá nějaká funkce typu Argon mi přijde dost obtížné.

No jasně, tak PBKDF2 funkce jsou zde právě od toho, aby posílili i uživatelem zadané slabé heslo. Ale to bych nepovažoval za výhodu, ale jen za berličku.

[Martin Tůma]

Je to možná neslušný, ale taky by mě zajímal zdroj té informace. Navíc jak tady už poznamenal Jenda, ty běžně neútočíš na heslo samotné, ale na jeho hash. A ta hashovací funkce se volí tak, aby byla výpočetně co nejnáročnější. Takže časová náročnost prolomení hesla není pouze funkcí entropie hesla.

Veškeré tabulky které jsem (v roce 2020) viděl udávají pro 26 znakovou abecedu praktickou neprolomitelnost (v tisících let) někde mezi 15 a 16 znaky hesla. (Pokud máš pocit, že zrovna tvé heslo bude někomu stát za to počítat v Oak Ridge, tak si tam přidej 1-2 znaky).

[Heron]

ale taky by mě zajímal zdroj té informace

Kryptografická síla. Určuje se podle potenciálních možností útočníka. Aktuálně se považuje za kryptograficky silné cokoliv 128+. Tedy entropie 128b a více.

A ta hashovací funkce se volí tak, aby byla výpočetně co nejnáročnější.

Která ta? Pokud si uživatel u generování ssh klíče nezadá opravu velký poučet rounds pro KDF, tak je to rychlé.

Takže časová náročnost prolomení hesla není pouze funkcí entropie hesla.

No to není, ale tohle se silné kryptografii nepoužívá jako argument.

Tj, pokud se mě někdo zeptá, jak silné má mít heslo, já mu řeknu 128b+ entropie a je to vyřízené. Nemusím už potom zkoumat nic dalšího.

[Martin Tůma]

No jde mi o to "se považuje". A dovolil bych si tvrdit, že pro určení toho "se považuje" jsou tyhle praktický záležitosti dost podstatný. Protože všechny ty výpočty stojí v zásadě na sadě "magickejch" pararametrů, jako výpočetní výkon útočníka a náročnost jedné iterace. S nekonečným výpočetním výkonem není žádná (konečná) entropie dostatečná...

[Heron]

Hele, to si ale vyřiď s NISTem. Pojem kryptografická síla je snad známý a průběžně se doporučují nějaké algoritmy s nějakou velikostí klíče (nepřekvapivě rostoucí). Případně s NSA, která na to jde jednodušeji.

Symmetric Factoring Elliptic-Curve  Hash
256       3072      384             384

Tj AES-256, RSA-3072, ECC-384, SHA-384

Tohle jsou doporučení NSA od roku 2016. Jestli někdo nevěří NSA a myslí si, že všechno umí cracknout, tak asi nebude volit menší klíče.

Já si dělám život jednodušší a prostě volím maximum (tj 256, 4096, 512).

S nekonečným výpočetním výkonem není žádná (konečná) entropie dostatečná...

To není, ale fyzikální limity stále existují. A dá se k tomu přistupovat různě, třeba vzít elementární náboj jako jednotku energie a spočítat dostupnou energii v celém (pozorovatelném) Vesmíru apod. Ono to po zlogaritmování vychází na celkem malá čísla (už jen odhadovaný počet všech částic ve viditelném vesmíru je 10^80, tedy 2^265). Tady se někdo pokouší dokazovat, že 128b je neprolomitelné dle termodynamiky. I když tohle je teda dost sporné.

[Martin Tůma]

No stačilo napsat jako zdroj NIST. Nevěděl jsem, že běžně udává i "Security Strength", protože většina jiných organizací udává právě jenom doporučované délky symetrických/RSA/ECC klíčů a hashe. A je vidět, že to za dobu co to už moc nesleduju zase o trochu poskočilo, protože těch 80b, kterejch odpovídá +/- těm 16 alfanumerickejm znakům už maj v legacy a aktuální minimum maj 112b. Asi ty ARMy

[Petr Fiedler]

A je tedy dobré mít nastavenou passphrase u klíče, nebo je to taky jedno? Z pc se v LAN přihlašuji přes SSH na server a do routeru. Z nb se přihlašuji z WAN na server a přes něj případně do routeru. Z mobilu se přihlašuji na server.

Jinak ještě k té neslušnosti. Nejsem si jistý, jestli jsem tě správně pochopil. Omluvil jsem se za to, že jsem napsal pouze "Zdroj?". Přijde mi to takové drzé, napsat jen jedno slovo místo věty, ve které bych poprosil. Takže za to jsem se omluvil. Ale pokud si myslel, že je krajně neslušné i to, když člověk slušně poprosí o zdroj tvé jistoty, tak to nepovažuji za neslušné, protože nikdo nejsme neomylný a je lepší si věci ověřovat.

[Heron]

A je tedy dobré mít nastavenou passphrase u klíče, nebo je to taky jedno?

To každopádně. Je to jen soubor na disku a jiné uživatelské programy jej mohou přečíst a třeba někam poslat. (Pokud není nasazen selinux nebo něco podobného.) Takže soubor s klíčem na disku mít vždycky šifrovaný a potom se nic nestane, pokud unikne někam ven, nebo jej někdo objeví třeba v zálohách apod.

Pochopitelně při podezření na únik klíče je potřeba co nejrychleji jej na serverech zablokovat.

Zdroj

No mě to přijde nevhodné vlastně oboje.

Já diskuse tady považuju spíš za hospodský pokec více lidí a není vůbec nutné, aby někdo, kdo něco tvrdí a to ještě v tak všeobecném tématu, jako je kryptografie, něco dokládal zdrojem. Ano, může být o to požádán, ale klidně může zareagovat někdo jiný anebo si to dotyčný nejlépe zjistí sám. Pojmy jako kryptografická síla apod by zase neměly být tak neznámé.

[Petr Fiedler]

Díky za vysvětlení, Herone.

Slušně se zeptat na zdroj mi nevhodné nepřijde. Tak mi to promiň, když to někdy udělám. :)

[Martin Mareš]

Mně to tedy vůbec neslušné nepřijde, protože čísla, která uvádíte, jsou značně podezřelá. A také že ano:

Při použití abecedy o 37 znacích to vychází na 25 písmen

Proč zrovna 37 znaků abecedy? Co to je za Pišvejcovu konstantu? Lidé běžně v heslech používají v podstatě kompletní ASCII, takže máme 95 znaků abecedy, čili cca 6.6 bitu na znak. Takže už 20 znaků dává přes 128 bitů entropie.

Navíc argument narozeninovým paradoxem nedává smysl - to by hrálo roli až při mnohem větším počtu použití. Zkuste si to prosím spočítat.

Naopak u zmíněného AES byste s narozeninovým paradoxem počítat měl, protože spousta jeho použití naráži na blokové kolize, které kvůli narozeninovému paradoxu nastávají v průměru po 2⁶⁴ krocích. 256 bitů klíče Vám moc nepomůže, když velikost bloku zůstává 128 bitů.

[plostenka]

Ty si pamatujes dvacetimistna hesla do ruznych uctu, nebo mas nejakeho spravce hesel a pamatujes si jen to jedno hlavni heslo?

Me prijde, ze je mnohem bezpecnejsi pamatovat si vsechna hesla, byt treba jen osmiznakova, v hlave, nez kdyz utocnik po uhadnuti jednoho hesla najednou ma pristup ke vsemu (vcetne seznamu toho "vseho"!).

Ve vysledku me leakne jeden ucet+heslo a utocnik nevi kam dal, tobe leakne seznam vsech uctu a seznam vsech hesel...

[Martin Tůma]

Osmiznaková hesla jde dneska prakticky instantně lámat na běžném HW, takže máš li pouze osmiznaková hesla, má útočník přístup ke všemu tak jako tak.

[Max]

No, to platí jen pro alfanumeriku, kterou lze na běžným hw v klidu zlomit do 15 znaků. Jakmile přibydou speciální znaky, dostává se člověk do jiné dimenze. S osmi se dá tedy stále vystačit. Já osobně ale nejdu pod 10 a u kritických věcí mám 20 a zatím to mám v hlavě. Každopádně už mi docházejí kapacity a budu to muset řešit nějak jinak :-/.
Zdar Max

[Martin Tůma]

Právě že ne, podle většiny tabulek ti dneska v rámci max. jednotek hodin prolomí běžný HW osmiznaková hesla i s 80 zakovou abecedou.

[Max]

Jakých tabulek? Myslíš rainbow tabulek se seznamy hashů? Ty už nějaký ten pátek přeci nejsou moc dobře použitelný. Doba rainbow tables md5 a sha1 hashy, kterými jsi prolomil pw do Windows jsou dávno tatam. Ale pokud by byl zájem, hodím sem hash hesla o 8 znacích a klidně se může kdokoli ukázat.
Tady tedy řádek z shadow:

franta:$6$h6761JCqLNwoNicM$sGpJbJQ3VxBWzed3Mtpw.GpY4TDo91xboF/PLcsPPRvVcZ65wqrFCedaYzBKij0DQpoD8QSNgg8ugAOL4aB1n0:18627:0:99999:7:::

Zdar Max

[Max]

Jinak dodám, že tady : Enterprise řešení RFID v podání firmy Intelleflex jsem bez znalosti délky a typu hesla a dalších technik lámal heslo "ifx123"na Intel i5-2400 asi 13h. Samo, že při znalosti délky hesla aj. věcí lze bruteforce zrychlit, ale pořád je to bruteforce uniklého hashe přelitýho saltem apod. Tj., ideální stav, kdy člověk není ničím limitován (třeba počty pokusů za nějaký čas apod.).
Uhodnout tedy heslo o 8 znacích je podle mně na většině systému nereálné. Jediné, jak toho docílit je, že ten systém nabourám, seberu hashe a budu se je snažit lusknout.
A i když systém nemá obranné techniky proti bruteforce útoku, tak zdroje (síť, kapacita serveru apod.) nestačí na to, aby takové heslo šlo vytěžit.
Zdar Max

[Martin Tůma]

Na CPU (alespoň pokud se bavíme o "běžném" HW) se dneska už hesla fakt nelámou. A workstation s několika nadupanejma GPU kartama je dneska otázka desítek tisíc Kč.

Jinak samozřejmě, že se tady celou dobu bavíme o útoku na hash hesla.

[Max]

Tak samo, že CPU na to není vhodné. Byl to jen příklad toho, že i triviální heslo s CPU nejde moc dobře bořit. Mít desktop s 4x GPU, každá za 20kkč, tak je to úplně jinde. Nicméně pořád záleží na tom, jaké se používají šifry. Časy máš níže od Herona a Jendy. Jinými slovy, v dnešní době by heslo o 8 znacích mělo stačit, a to i v krajním případě, že unikne hash hesla, tedy pokud má člověk nějaké svoje vlastní zdroje. Pokud má k dispozici nějaký výpočetní cluster, bude to samozřejmě horší, ale i tak bude dost časového prostoru pro refresh hesel. Pokud ale mají admini 15 místné heslo, tak už i ten cluster by mohl mít problém.
Problém je, že hesla se většinou získávají mnohem jednodušeji a rychleji. Buď sociálním inženýrtsvím, nebo využitím bezpečnostních slabin v OS/programu (třeba takový dll hijacking je celkem zrádná věc).
Zdar Max

[Martin Tůma]

Jakých tabulek? Myslíš rainbow tabulek se seznamy hashů?

Ne, myslim tyhle tabulky

[Max]

To jsou obecné početní tabulky, které jen ukazují odhad síly hesla. Tzn. obecně známé věci. Navíc se opírají o právě takovou tu drobnost, že musí uniknout hash a někdo ho musí dát na pár dost výkonných GPU počítat.
Jinými slovy to moc nevypovídá o tvých pár hodinách na běžném hw.
Zdar Max

[Jendа]

Jakmile přibydou speciální znaky, dostává se člověk do jiné dimenze.

Wat. 15znakovému heslu z lowercase (!) alnum (77.5b) odpovídá 8znakové heslo z abecedy 825 symbolů. To dáváš do hesla emoji?

[Jendа]

Jinak si teda myslím, že hesla stejně nebudete mít úplně náhodná pokud to fakt nebylo vygenerované, všechny ty běžné postupy na vymýšlení (correct horse battery staple, věta a vložit symboly, atd.) budou mít bias.

[Martin Tůma]

Přesně tak. Podle mě "bruteforce budoucnosti" budou různé transformační algoritmy nad abecedama ze slov, protože až se dostaneme k nutnosti > 20 znakových hesel, tak to drtivá většina lidí nebude schopná jinak obsáhnout. Ono se stačí podívat jak to vypadá dneska tam, kde rozhodujou lidé s přehledem "korporátního ajťáka" - 15 znaková hesla s obměnou 6 měsíců buď všichni "generujou" inkrementací čísla na konci, nebo je mají rovnou nalepený na monitoru...

[Max]

Také nejsem zastáncem častých změn hesel. Je to podle mně totální hovadina. Jinak cesta k lepší bezpečnosti podle mně směřuje k lepšímu protlačování certifikátů apod. věcí. Každopádně bruteforce lze vesměs uskutečnit jen v případě toho, že nějak ukradneme hash hesla, protože většina rozumně nastavených systémů neumožňuje 20 pokusů za sekundu. A na takové věci spoléhá třeba TPM apod. řešení, kde člověk má nastavený třeba jen PIN z 6 písmen a i tak je docela problém ho získat (pokud teda nenarazíme na security bug od Intelu apod :) ).
Zdar Max

[Martin Tůma]

Asi Číňan. Kdyby se tady s takovejma znalostma nepokoušel ostatní poučovat o bezpečnosti, tak by to snad bylo i vtipný...

[Max]

Ok, výpis z shadow máš nahoře. Pokud tvrdíš, že na běžným hw to v klidu dáš, tak čekám na výsledek.
Zdar Max

[Martin Tůma]

No a jsme zase u podstaty veškeré bezpečnosti - rizika/ztráty/zisk útočníka versus náklady. Nechci úplně tvrdit, že bych neměl žádnou motivaci to heslo prolomit, ale rozhodně není tak veliká, abych si někde na AWS na to pronajímal cluster. (Nejvýkonější stroj, kterým sám disponuju má mobilní i5 580 - ano, 580, ne 5800 - a NVidi M340 a spojovat ho do clusteru s iMacem 2009 s Core2 duo taky nedává moc smysl )

[Max]

Já mám i7 6700 + RX570 a notebook Thinkpad X200.
Každopádně situace je obměně hw nakloněna, paměti levnější nebudou, desky také ne a CPU udělaly takový pokrok, takže se přidávám k některým lidem a postupně nakupuji na upgrade na Ryzen 5600X + s GPU těžko říci, zda upgradnu, nebo zůstanu.
Zdar Max

[Heron]

No především je naprostý nesmysl po někom konkrétním chtít, aby něco prolomil a na základě toho potom cokoliv usuzovat. Tohle se (určitě nejen mě) stává s naprostou pravidelností, pokud někoho upozorním na to, že MD5 / SHA1 / RC4 / SSL2 / cokoliv jsou nebezpečné a prolomené, tak pokaždé přijde někdo, ať mu teda najdu kolizi, jinak že to neplatí. (Prove it or it didn't happen.) Nebo mi ještě ideálně vysvětluje, že zrovna pro jeho použití to nevadí.

To je argument jak z mateřské školy.

To, že někdo konkrétní něco nedokáže (nebo nechce dokázat, nechce ztrácet čas) na dané věci vůbec nic nemění. Pokud se tím původní tazatel navíc bude řídit, tak může velmi rychle narazit.

[Petr Fiedler]

Tohle já taky naprosto nemůžu pochopit. Zdaleka tomu nerozumím tak, jako ty, ale vždy používám to nejnovější/nejlepší. A pokud je více možností, tak se zeptám. Absolutně mi nejde do hlavy, jak může být někdo spokojen s MD5 a proč nepoužívá SHA512. Já tomu sice do hloubky nerozumím, ale je jasné, že druhá varianta je bezpečnější. Tak proč používat něco méně bezpečné?

[JiK]

protoze je to rychlejsi? protoze to zere min energie? protoze tomu staci mene pameti? mene disku? protoze tomu staci mene entropie?

(aspon castecne) Legitimnich duvodu muze existovat cela rada...

[Heron]

Legitimnich duvodu muze existovat cela rada...

To jistě, je to funkce jako kterákoliv jiná a pokud to někdo používá na místě, kde není potřeba kryptograficky silná funkce a kde mu nevadí reálná existence kolizí (třeba gitu, který používá SHA1 kolize nevadí) tak ji použít může. Problém je, že to lidi používají i tam, kde by kryptograficky silná funkce být měla.

[xkucf03]

kde mu nevadí reálná existence kolizí (třeba gitu, který používá SHA1 kolize nevadí) tak ji použít může

V Gitu je SHA-1, pokud vím, opatchovaná tak, aby se ty kolizní hashe generovaly jiným algoritmem, takže tam efektivně ke kolizím nedochází (alespoň do doby, než se najde nový způsob hledání kolizí, na který ten patch neúčinkuje). Ale nebýt toho, tak by to nebezpečné bylo – někdy se totiž spoléhá na to, že někdo řekne: „verze 9f95cfd68f25 je ta správná, oficiálně vydaná a důvěryhodná, tu si stáhněte a používejte“ a ostatní na to spoléhají. Případně v tom můžou být zapojené i digitální podpisy, ale pokud se podepisuje právě ten SHA-1 hash z gitu, tak tě jeho kolize reálně ohrožují. Někteří dokonce dodnes používají protokol git:// (místo ssh:// nebo https://).

Neškodné mi to přijde třeba v případě hash tabulek, kde s kolizemi počítáš a nijak ti nevadí (co největší unikátnost hashů je žádoucí z hlediska výkonu, ale na funkci kolize vliv nemají).

[Heron]

Dík za doplnění, ty mluvíš o hashi stromu, já o souboru. Testoval jsem to hned jak byly zveřejněny kolizní soubory na nějaké staré verzi gitu a skutečně mu to problém nedělá.

S kolizemi u hash table se obecně počítá, protože hash table se obvykle nepočítají kryptografickou fcí, ta je moc pomalá a navíc zbyčená - účelem hash table je O(1) vyhledávání, na to stačí jakýkoliv jen trochu unikátní index. Ostatně, třeba pro javu hashCode() jsou doporučení vzít existující fieldy, vynásobit je (případně jejich vlastní hashCode) nějakým malým prvočíslem a sečíst. Je to rychlé a efektivní.

[Jendа]

Ten problém to nedělá jen proto, protože na začátku git blobu je délka a až pak jsou data toho souboru. Takže ta kolize nefunguje. Ale šlo by úplně stejným způsobem spočítat kolizi, která git rozbije, jenom by se před hlavičku toho PDF na kterém to demonstrovali ještě předřadila délka. (pokud to neopravili)

Problém v gitu je, že podepisování je implementované právě tak, že se podepíše ten hash. Jako zatím se tím moc útoků udělat nedá, protože kolize znamená nějaké dva náhodně se lišící binární bloky, a to při typickém využití (zdrojáky) nemáš jak exploitovat.

[Heron]

Stejně je zvláštní, že si vybrali sha1. Já nevím přesně, co se tam podepisuje, ale jestli se skutečně podepisuje jen sha1 hash něčeho, tak už v té době (2005) muselo být jasné, že to velice rychle přestane stačit a i kdyby se nenalezlo oslabení (což opět sahá do roku 2005), tak kryptograficky by tomu stejně rychle odzvonilo pro nedostatečnou sílu. Což museli vědět.

Ví někdo, proč si to vybrali? Špatná volba? Nebo se to interně používá jen pro hash table blobů a podepisuje se toho víc? Nebo se i velký Linus spletl?

[xkucf03]

Mně hlavně přijde chyba zadrátovat tam jeden konkrétní hashovací algoritmus. Mělo to být napsané obecně a algoritmus měl být parametrem, aby ho šlo v budoucnu snadno změnit. Podobně jako když v databázi uživatelů máš u hashů hesla poznamenanou i sůl+algoritmus a ne jen ten hash.

[Heron]

Viz nálezy níže.

Mně hlavně přijde chyba zadrátovat tam jeden konkrétní hashovací algoritmus.

Tak ono záleží na co, Linus v tom videu z roku 2007 básní o tom, že to nepoužívají jako crypto, ale jen pro distribuci (tj hash table) a ověření konzistence (a to už může být s kolizemi problém).

Mělo to být napsané obecně a algoritmus měl být parametrem, aby ho šlo v budoucnu snadno změnit.

Ano a v některém z těch odkazů je uvedeno, jak strašná práce to bude. Tj změnit on disk formát, doplnit tam další sloty pro hashe, všechno přehashovat s tím, že se stávajícíma podpisama stejně nic neuděláš, ty tam prostě zůstanou. Transition plan.

[xkucf03]

P.S. Je to už dost dávno, ale myslím, že v roce 2005 to byla hodně teoretická možnost a většina lidí stále vesele používala MD5 (někteří ji používají dodnes), takže SHA-1 byla na tu dobu celkem pokroková záležitost.

[Heron]

Hmm, tak tady jsem našel tohle a po těch 13 letech už to působí poněkud rozpačitě.

Navíc teď se zdá, že udělají tutéž chybu znova, protože si zřejmě vybrali SHA2-256 (fakt se mi nechce číst celý ten email thread). Což je blbě. Z SHA2 se dá použít max 512/512 nebo v nejhorším 512/256. Původní SHA2 nebrat.

[Martin Tůma]

Chápal bych to, kdyby sha1 použil opravdu pouze pro konzistenci dat s tím, že kryptografické zabezpečení se očekává na jiné úrovni, jak tvrdí. Ale jestli o pár minut dál prohlásí, že "garantuji vám, že když mám těch 20B, tak ten repozitář nikdo nezměnil", tak už mi to úplně nesedí...

[Heron]

To je úplně jednoduché. Bylo / je to v knížkách ještě 20 let po té, co ta funkce byla nedoporučovaná (1996).

In 1996, Dobbertin announced a collision of the compression function of MD5 (Dobbertin, 1996). While this was not an attack on the full MD5 hash function, it was close enough for cryptographers to recommend switching to a replacement, such as SHA-1 or RIPEMD-160.

Vlastně největší boom přišel s knížkama o PHP někdy kolem roku 2000 a nezměnilo na tom ani její kompletní prolomení v roce 2004.

MD5CRK ended shortly after 17 August 2004, when collisions for the full MD5 were announced by Xiaoyun Wang, Dengguo Feng, Xuejia Lai, and Hongbo Yu.[7][8] Their analytical attack was reported to take only one hour on an IBM p690 cluster.[9]

Zdroj: MD5 na WIKI.

Prostě to byla TA doporučovaná funkce. Další věcí byla obliba md5sum pro kontrolu stahovaných souborů a ta teda vydržela až do teďka. Další roli sehrávají neexistence "peer review" článků. Na rootu klidně vyšla recenze knihy (rozhodně po roce 2010), kde se jak přes kopírák opět vyskytuje MD5 v PHP pro "ověření" hesel. Tj vlastně nikdo se nestará o to, aby to zmizelo.

Jinak lidi mají neskutečnou setrvačnost. Já na tohle mám takové soukromé OCD a sleduju několik už dávno obsolete věcí, které se pořád drží a drží a drží.

[Petr Fiedler]

Já tohle prostě fakt nechápu. Stáhneš si v dnešní době nové distro a vývojáři k němu jako jediné ověření dají md5sum. Fakt nechápu. To nemá cenu řešit.

[Martin Tůma]

Už ti to tady psali jiní - md5sum je nejrozšířenější a je tudíž největší pravděpodobnost, že si to pomocí něj bude moct uživatel ověřit. Že je to kryptograficky dávno prolomená funkce je v tomhle případě úplně jedno, protože ten soubor budeš stahovat přes úplně stejné HTTPS, které "zabezpečuje" ten hash samotný.

[Fluttershy, yay!]

Navíc když jsou i slabší články řetězce, viz např. Linux Mint.

[xkucf03]

md5sum je nejrozšířenější a je tudíž největší pravděpodobnost, že si to pomocí něj bude moct uživatel ověřit

Obávám se, že u většiny uživatelů je hlavní překážkou jejich laxnost a nedbalost, nikoli nedostupnost potřebných nástrojů. Ten, kdo umí ověřit MD5, umí zpravidla ověřit i SHA-256 a jiné hashe a má na to potřebné vybavení. Problém je spíš v tom, že uživatel to nechce dělat, je mu to jedno a vědomě se chová rizikově. Tohle jsem bohužel viděl i u správců a relativně schopných lidí (rozhodně hash ověřit uměli a mohli, klidně i SHA-512). Podobné je to s kontrolou otisků SSH klíče při připojování se k novému serveru – to velká část lidí prostě ignoruje, nezkontrolují si nezávislou cestou, že ten otisk sedí. Sice to pořád nedosahuje takové míry ignorance jako u běžných windowsových uživatelů, kteří odkliknou jakoukoli chybovou hlášku či varování, jen aby se už připojili na vzdálenou plochu, ale nemá to k tomu daleko.

je v tomhle případě úplně jedno, protože ten soubor budeš stahovat přes úplně stejné HTTPS, které "zabezpečuje" ten hash samotný.

Tohle se dost liší. Obrazy Ubuntu se dlouho stahovaly jen přes nešifrované HTTP – a musel ses snažit, abys našel hash někde na HTTPS (kdybys to kontroloval proti hashi ležícím vedle těch ISO obrazů na HTTP, tak by to bylo k ničemu).

Asi nejlíp má tu distribuci řešenou Apache – např. Tomcat:

Release Integrity: You must verify the integrity of the downloaded files. We provide OpenPGP signatures for every release file. This signature should be matched against the KEYS file which contains the OpenPGP keys of Tomcat's Release Managers. We also provide SHA-512 checksums for every release file. After you download the file, you should calculate a checksum for your download, and make sure it is the same as ours.

To se dá považovat za příčetné. Samotné soubory si pak většinou stahuješ z nějakého zrcadla od třetí strany, někdy dokonce po FTP nebo HTTP, ale to tě nemusí trápit, protože ten podpis a hash sis stáhl přímo od autorů přes HTTPS.

[Heron]

recenze knihy (rozhodně po roce 2010)

Tak jsem to náhodou našel v odkaze jiném mém článku.

[Max]

Jinak ještě menší poznámka pod čarou. Jednou jsme se v diskusi neshodli a od té doby budeš vždy oponovat a snažit se mně za jakýchkoli okolností zesměšňovat? Snažím se vést věcnou diskusi. Fakt nevěřím, že někdo dá pomocí bruteforce útoku nějaké heslo ve vzdáleném systému. Z tvých komentářů jsem pochopil, že hned myslíš na uniklý hash. Ok, ale ani v tomto nevidím moc zářný úspěch, protože celé to není jen o jednom hashy a nějakému seznamu předgenerovaných tabulek, ale o dalších technikách, co to znepříjemňují. Jasně, vygeneruji si alfanum heslo o 15 znacích do md5 a pomocí bruteforce či slovníků ho dám během chvilky. Ale zkus to samé s jinou šifrou, přelitou saltem a dalšími věcmi a najednou jsi úplně někde jinde.
Zdar Max

[Martin Tůma]

Jinak ještě menší poznámka pod čarou. Jednou jsme se v diskusi neshodli a od té doby budeš vždy oponovat a snažit se mně za jakýchkoli okolností zesměšňovat?

Ten problém opravdu není o tom, že bysme se "jednou neshodli". Ten problém je v tom, že ač ti v oblasti bezpečnosti místy chybí i úplné základy (je to vidět i tady v této diskuzi) tak se nerozpakuješ se prohlásit za jedinou autoritu, která dokonce může ostatním určovat co můžou a co nemůžou říkat/psát. A to je to, co mě tak vytáčí. Až tady dojde na algebru ECC, tak budu taky tiše mlčet v koutě, protože diskrétní logaritmus jsem naposledy viděl před 15 lety na matematice 5D a ani tenkrát jsem mu úplně nerozuměl... Rozhodně nebudu Jendovi určovat, jestli si ty křivky může dovolit počítat tak či onak.

Fakt nevěřím, že někdo dá pomocí bruteforce útoku nějaké heslo ve vzdáleném systému.

Tohle je přesně ono. V diskuzi je přes 30 příspěvků, kde se řeší různé aspekty bruteforce útoků na hesla, od výpočetní náročnosti hashovací funkce po možnosti dnešního HW a ty přijdeš zase s něčím, co je z podstaty úplně mimo, asi jako když si se v té minulé diskuzi snažil z jednouživatelského desktopu udělat multiuživatelský server. Mimochodem, proč si se tady taky nepustil do všech, kteří tady jako já v té minulé diskuzi poukazují na praktickou ekvivalenci těch účtů v daném usecase?

Ale zkus to samé s jinou šifrou, přelitou saltem a dalšími věcmi

To jsou právě ty základy. Jestli je hash osolený nebo ne nehraje pro náročnost bruteforce útoku (o rainbow tabulkách tady nikdo nediskutuje) žádnou roli. Počet iterací KDF/složitost hashovacích funkcí se tady už taky řešila a mělo by to být obsaženo v těch tabulkách. Samozřejmě, můžeš najít kombinaci velkého počtu iterací a nějaké z nových hashovacích funkcí, které se na GPU (schválně) špatně počítají, kde to úplně nesedí, ale na principu to nic nemění.

[Max]

Já nejsem ten, kdo tu tvrdil, že osmimístný heslo jde zlomit za pár hodin, a proto je slabý a hned jsi mě kvůli tomu snažil dehonestovat. Když se ukáže, že není v rozumném čase prolomitelný, tak zase odvádíš téma někam jinam k osobním útokům. Z této diskuse je to patrné, nijak jsem tě neurazil, nijak jsem na tebe neútočil, snažil jsem se vést věcnou diskusi, ostatní sem přispěli číslama a ve finále jsme se dozvěděli, že sha512crypt je zatím slušně odolné proti bruteforce. Ty jsi vesměs nepředvedl nic, jen si mně urážel a postnul odkaz na google na tabulku pro BFU.

Pokud jde o salt, tak to dělá několik věcí, jednak jak už bylo řečeno, slouží mj. k tomu, aby stejné heslo nemělo stejný hash. Dále ale slouží i jako obrana před bruteforce pomocí rainbow tables, takže je nejde jednoduše použít.
Zdar Max

[Heron]

že osmimístný heslo jde zlomit za pár hodin

Já tohle beru jako autorskou licenci. Není důležité "za pár hodin", ale je důležitá celková maximální entropie toho hesla. Ta je 50b. S tím nic nenaděláš, to je tak rok 1980 (dle tohoto papíru, kde se pokouší odhadovat nutnou kryptografickou sílu).

Jasně, jsou metody, jak (si) to zkomplikovat přes různé KDF s miliony iterací, ale to potom narazí v praxi třeba na to, že disk zašifrovaný veracryptem (true cryptem) tak po zadání hesla čeká 25s, protože procesor je v daném čase bootu v nějakém prehistorickém módu (protože v roce 2021 je extrémně nutné spouštět kód z roku 1979), takže nemůže použít moderní instrukce (možná už to vyřešili, na toto jsem narážel před x lety).

sha512crypt je zatím slušně odolné proti bruteforce

No spíš je to rovnák na ohejbák. Lidi mají slabá hesla, tak tam dáme pomalou fci.

[Martin Tůma]

No spíš je to rovnák na ohejbák. Lidi mají slabá hesla, tak tam dáme pomalou fci.

Ty hesla mají "biologické limity", proto je snaha je "držet" co nejkratší.

[Heron]

Proto by se hesla měla zrušit a přejít na klíče.

[Martin Tůma]

Kde budeš držet ty klíče?

[Heron]

Toť právě otázka.

[Petr Fiedler]

Není to zase taková tragédie. Já mám např. stejné heslo od LUKS na pc, nb a ext. HDD a jedno heslo se může naučit každý. Má 35 míst a při jeho sestavování jsem čerpal z těcho znaků: a-z, A-Z, 0-9, .,?!§+-_()[]{}<>/%=@* . Používám je už roky, takže je mám velmi dobře zafixováno a ani je nikde nemám napsáno. Ani na papíru, ani na žádném úložišti. Pak mám podobné, ale 20 místné heslo od SSH klíčů a to si taky pamatuji. Dá se to naučit. Teď mám nová hesla od mailu a pod, ale kdysi jsem jich pár, těch důležitých, taky uměl. Je to věc priorit, ochoty a snahy. Nic jiného.

[Martin Tůma]

Když se ukáže, že není v rozumném čase prolomitelný

??! Jediný, co se tady ukázalo je, že já nejsem ochotný to heslo lámat a to má k tvrzení, že není v rozumném čase prolomitelný hoooodně daleko...

ostatní sem přispěli číslama a ve finále jsme se dozvěděli, že sha512crypt je zatím slušně odolné proti bruteforce. Ty jsi vesměs nepředvedl nic, jen si mně urážel a postnul odkaz na google na tabulku pro BFU.

??! Všechny ty čísla vypovídají spíš o tom, že těch 8 znaků je opravdu zatraceně málo. Entropie toho hesla je ~50b což je hluboko pod tím, co NIST aktuálně považuje i za pouhou "legacy" úroveň. A ty přepočtový tabulky pro taková hesla uvádí prolomení v řádech minut, max dní. Tím, že je nazveš "tabulkama pro BFU" na tom nic nezměníš, akorát ukazuješ svojí ignoranci.

[Jendа]

Jediný, co se tady ukázalo je, že já nejsem ochotný to heslo lámat

Ne, ukázalo se, že by sis musel pronajmout 1000 nejlepších GPU a počítat na nich měsíc (a celá sranda by stála několik milionů korun), což je řádově jinde než původní tvrzení prakticky instantně lámat na běžném HW.

[Martin Tůma]

To původní tvrzení ale nebylo pro nějakou konkrétní variantu hashe hesla, ale podle obecných tabulek, které předpokládají nějaký běžný stav. Že je to celý postavený na spoustě magickejch konstant, jako co je běžně dostupný HW, nebo běžná hashovací funkce jsem tady psal už v některém z prvních příspěvků, dávno před tím, než došlo na to "tak se ukaž". Mimochodem třeba na svém systému mám uživatelský účet hashovaný sha512 (nedávno jsem ho měnil) ale root má md5, takže mě ty tabulky nepřijdou mimo realitu.

A i když přijmu stav, že to teda konkrétně znamená pár set tisíc Kč na pronájem strojů někde v cloudu a řádově dny, tak furt mi to ještě přijde v mezích "prakticky instantně a na běžném HW". Je to prostě takřka hned běžně dostupný i jednotlivci.

[Petr Fiedler]

A i když přijmu stav, že to teda konkrétně znamená pár set tisíc Kč na pronájem strojů někde v cloudu a řádově dny, tak furt mi to ještě přijde v mezích "prakticky instantně a na běžném HW". Je to prostě takřka hned běžně dostupný i jednotlivci.

To nemyslíš vážně? Komu z běžných lidí je tohle s ohledem na finance běžně dostupné? Pokud si za tím stojíš a je ti to dostupné, tak si to pronajmi a lámej. Pokud ne, tak to asi není běžně dostupné.

[Martin Tůma]

To je cena nového osobního automobilu (Nová Octavia stojí 800kKč). Máš pocit, že by byl pro drtivou většinu lidí nedostupný?! Kdybych měl třeba takhle zaheslovanou bitcoinovou peněženku se 100000 BTC a to heslo neznal, tak rozhodně místo sezení a smutného koukání na ní rozbiju prasátko a ty stroje si pronajmu. Kdyby to mělo běžet 2 roky v Oak Ridge, tak jsem v hajzlu, protože jednak takový prachy na počáteční investici nikdy neseženu a navíc mi ten cluster v Oak Ridge nikdo nepronajme. Ale takhle tady za měsíc bude můj další příspěvek z vlastního ostrova v Karibiku, kde budu čtenáře ABCLinuxu zdravit obleženej 30 modelkama s Cuba Libre ze 30 let starého rumu v ruce. A většinu z toho času mi zabere ten nákup ostrova a modelek, ne to lámání toho hesla...

Kvůli tomu, abych si tady honil ego nad nějakym Maxem do toho ale ty prachy samozřejmě lejt nebudu.

[Petr Fiedler]

Tvůj příklad je úplně mimo realitu. Tvojí, i většiny běžných lidí. Ale přít se s tebou nehodlám. Pokud chceš argumentovat účelově, aby sis obhájil svojí pravdu, tak to nemá smysl.

[Martin Tůma]

Samozřejmě, že je ta historka smyšlená (už jeno proto, že peněženka se 100000 BTC bude někdy ze začátků BTC a bude pravděpodobně zahashovaná něčím slabším, než sha512crypt, takže by s největší pravděpodobností stačilo herní PC). Co ale není smyšlené a co má ukázat je to, že pokud má i pouhý jednotlivec dostatečnou motivaci, je to v jeho dosahu se k takovému heslu takřka hned dostat.

[Fluttershy, yay!]

reality check: na začátku čovidu měla polovina českých domácností úspory na nejvýše dva měsíce

[Martin Tůma]

A? Nikdo netvrdí, že to bude dostupný všem jednotlivcům, i když v tvém vidění světa by asi měl být dostupný cluster na AWS i "skladníkovi ze šroubárny". Ale lidí, co na to dosáhnou jsou mraky, třeba prakticky každý, kdo vlastní byt v nějakém větším městě.

[Fluttershy, yay!]

Máš pocit, že by byl pro drtivou většinu lidí nedostupný?!

A to je jenom Česko. Globálně je mediánový roční příjem domácnosti cca $10k.

[Martin Tůma]

Koukám, že chodíš na školení pro mladé fact-checkery...

[JiK]

reality check: na začátku čovidu měla polovina českých domácností úspory na nejvýše dva měsíce

A presto jim vystacily na mesicu 8, asi zazrak Chanuky, ne?

[k3dAR]

To je cena nového osobního automobilu (Nová Octavia stojí 800kKč). Máš pocit, že by byl pro drtivou většinu lidí nedostupný?! [...]

nejdriv si psal "bezny HW", ten si pak "vysvetlil" ze je (podle tebe) v podstate pronajem v cloudu 1000 GPU, abys ted obhajoval ze je to bezne dostupne pro drtivou vetsinu? nediv se ze si lidi tukaj na celo

1. pod pojmem "bezny HW" si bez daneho contextu kazdy racionalne uvazujici clovek predstavi Desktop s i5 + 8GB RAM + 1x GPU, i pri uvazeni kontextu se da predstavit maximalne desktop s i7 + 16GB RAM + 2x GPU... 2. prodanem hw v cloudu na tejden za cenu nove Octavie v hodnote 800kkc, v zadnem kontextu nelze povazovat za "bezny HW", jedine co "obhajuje" to co pises (misto toho aby to bylo nazvane cirou demagogii) je to, ze mezi radky se to od tebe da chapat jako "HW bezne dostupny tomu kdo ma patricne vysoke financni prostredky a velkou motivaci a muze jit i o jednotlivce"

3. ciste k te Oktavii, nakup noveho auta za 800kkc, opravdu neni dostupny pro drtivou vetsinu lidi, napak je dalece nedostupny, drtiva vetsina lidi (nepocitejme podnikatele s leasingem) si poridi ojete auto kolem 100kkc az si na nej po par letech nasetri...

[Petr Fiedler]

Taky to tak vidím, ale řekl bych, že to neuzná.

[Martin Tůma]

ze mezi radky se to od tebe da chapat jako "HW bezne dostupny tomu kdo ma patricne vysoke financni prostredky a velkou motivaci a muze jit i o jednotlivce"

Proč mezi řádky? Dostupný u mě neznamená zadarmo, nebo prakticky zadarmo. Podívej se, kolik v Praze stojí byty z kategorie "dostupný bydlení"...

[Petr Fiedler]

Tak on je dostupný i Modrý Mauricius. Když nabídneš pořádnou dardu, tak jej jistě získáš. Ale není to pro obyčejné lidi. A obyčejní lidé na ty byty v Praze hotovost taky nemají. Můj bratr je výkonný ředitel Marsh pro ČR. Část týdne pracuje v pražské pobočce, takže tam z Brna každý týden jezdí a situaci tam i vzhledem ke své profesi výborně zná. Říkal mi, že spousta bytů k pronájmu je prázdná. Lidé na to prostě nemají. A není to jen tím, že zde nejsou turisté. Prostě pro spoustu lidí to teď není finančně dostupné, i když k mání to je. Co na tomhle principu nechápeš? Jak psal Radek, napřed si psal o běžném HW.

[k3dAR]

"bezny HW" dostupny pro "drtivou vetsinu" proste NENI neco za 800kkc na tejden
"bezny HW" dostupny pro "drtivou vetsinu" zaroven neni neco "zadarmo nebo prakticky zadarmo" kdyz je to za 15.000-25.000Kc
"drtiva vetsina" si rozdhone v Praze nekupuje byty za hotovost...

proto pouze (nekolikanasobnem)ctenim mezi tvejma radky lze (s velkou snahou)pochopit co si myslel...

[Jendа]

Až tady dojde na algebru ECC, tak budu taky tiše mlčet v koutě, protože diskrétní logaritmus jsem naposledy viděl před 15 lety na matematice 5D a ani tenkrát jsem mu úplně nerozuměl... Rozhodně nebudu Jendovi určovat, jestli si ty křivky může dovolit počítat tak či onak.

Od toho se distancuju, na tohle je tady limit_false, já ECC taky nerozumím.

[Max]

Tak ono snad nejde jen o kombinace čísel, písem a znaků, ne? Ještě v tom hrajou roli použité šifry, salty a jiné věci.
Zdar Max

[Heron]

Tak ono snad nejde jen o kombinace čísel, písem a znaků, ne?

Jde. Protože toto ti určuje, jak obtížná je ta úloha, resp kolik kroků zabere. Ten hypotetický příklad s 8 znaky a 80 znakovou abecedou (tu bych teda chtěl vidět a hlavně psát někam do terminálu) znamená 1677721600000000 operací, resp 50b entropie.

Potom už jen záleží na tom, jak rychlá je jedna operace. Salt ti k tomu nijak nepomůže, ten slouží k tomu, aby hashe pro dvě stejná hesla vyšla (díky různé soli) různé. Ale spočítat hash se solí nebo bez je stejná operace.

V tom tvém příkladu je jako hash použita SHA512. Co jsem se tak díval, tak lze najít metody s rychlostí i 1Ghash/s (jinak stovky milionů jsou obvyklé).

Tj: 1677721600000000 / 10^9 / 3600 / 24 = 19.4 dnů. Pokud někdo frantu opravdu nenávidí, tak si těch GPU koupí víc.

[Jendа]

V tom tvém příkladu je jako hash použita SHA512.

sha512crypt není SHA512.

[Heron]

Hmmm. Na tomhle je krásně vidět, jaké vyfikundace je nutné zavádět proto, aby někdo mohl dál používat krátká hesla. Takže nejdřív se kryptograficky silné hash fce optimalizují pro největší rychlost, aby se potom zpomalovaly a dohnaly tak nedostatečný vstup.

Jinak na sha512crypt jsem našel první odkaz, kde někomu strašně vadí (mimo jiné), že pro krátká hesla to počítá krátce a lze z času odhadnout délku hesla. Nehodnotím, nečetl jsem moc podrobně.

[Martin Tůma]

Ten hypotetický příklad s 8 znaky a 80 znakovou abecedou (tu bych teda chtěl vidět a hlavně psát někam do terminálu)

Počítám 26 znaků a-z, 26 znaků A-Z, 10 číslic a 18 z běžných ASCII symbolů jako +@#$~^&*... To mi nepřijde zas tak nenapsatelný...

[Heron]

No já raději delší hesla s jednoduchými znaky. Už jsem to tady několikrát uváděl, pokud se člověk přihlašuje na server přes x vzdálených ploch, kde ty widle jsou natvrdo přepnuté do češtiny a nemáš jistotu, že se správně přenáší numpad (protože je standardně v loginu vypnutý), tak někdy znak typu $ nebo * fakt nenapíšeš. Viděl jsem to několikrát, jak si někdo vymyslel ultra cool heslo složené z magických znaků a potom to do toho vmware prostě nemohl dostat.

Takže já někdy záměrně jedu jen malou abecedu a dostatečnou délku.

[Martin Tůma]

Je vidět, že neděláš v korporátu Není tak neobvyklé, že pro doménu nějaký windows-admin-lumen zapne politiku, která přesně tyhle 4 skupiny znaků vyžaduje. A nové heslo každé 3 měsíce, samozřejmě...

[Max]

Jo, stejný problémy mívám i já. U vmware je to různé podle toho, co používáš za klienta. Nejlépe přenáší klávesnici VRC (VMware Remote Console).
Pokud jde o vzdálenou plochu pro Windows, tak jedu 2X Clienta. Sice jsou obě app propri, ale bez nich brečím ještě víc :-/.
Osobně tedy jedu i speciální znaky.
Zdar Max

[Heron]

U vmware je to různé podle toho, co používáš za klienta.

No ty oficiální. HTML5 verzi, která někde nefunguje a nemá všechny funkce, nebo Flash verzi, která už nikde nefunguje . Prostě enterprise software no. Jediné, co alespoň trochu funguje je vmware workstation, ale tu zase k té vspheře nedostaneš, takže si ji musíš koupit bokem. Prostě vmware. Money for nothing.

[Max]

Dnes máš dvě možnosti, flash zrušili, takže buď html5 (relativně dobře se chová na Windows, ale na Linuxu mívám problémy s klávesnicí) nebo právě ten VRC, což je desktop app/klient, lepší alternativa pro html5.
Zdar Max

[Heron]

No a nebo je tady třetí možnost. Mě už to více než rok nemusí zajímat. Spíš mě fascinuje, jak na to lidi přistoupili. Bavil jsem se s vmware golden brilliant diamond partners a ptal se, co oni reálně používají na administraci a ti říkali (tehdy, cca 1.5 roky zpět), že prostě flash verzi a ano, mají na to jeden spešl vyhrazený prohlížeč. (Já už měl tehdy workstation.) Cca měsíc zpět, další pokec s vmware ultra blackhole business partners ti to samé. Fakt nevím, co je k tomu vede, ale psychologii ještě vystudovanou nemám.

[Max]

No, hele, mám rozjetý Proxmox u jedné firmy a ta klávesnice tam také není zrovna ideální (pokud bereme v potaz u html5 verzi klienta).
Zdar Max

[Heron]

Nechápu kontext. Já jsem o proxmox nenapsal ani slovo (nezajímá mě). To že je to jinde špatně nijak neomlouvá to, že je to tady špatně.

[Max]

Chtěl jsem tím jen říci, že konkurence na tom není o moc líp. Je ale pravda, že třeba takový oVirt jsem testoval už hodně dávno, takže tam aktuální stav neznám.
Zdar Max

[JiK]

netreba kupovat. V cloudu jde pronajmout masina s P100 GPU, stoji bez nejakych slev cca $25/den, a kdyz se prihlasis do free trial oracle cloudu, dostanes $300 na utraceni. Takze staci spustit to na stroji s 8 GPU a je to hotovo...za free kredity z toho trialu...tady jsou vysledky z nejake 2 roky stare verze hashcatu.

Hashmode: 1700 - SHA-512

Speed.Dev.#1.....:   963.1 MH/s (69.05ms) @ Accel:32 Loops:64 Thr:640 Vec:1
Speed.Dev.#2.....:  1022.5 MH/s (69.08ms) @ Accel:32 Loops:64 Thr:640 Vec:1
Speed.Dev.#3.....:  1030.9 MH/s (69.03ms) @ Accel:32 Loops:64 Thr:640 Vec:1
Speed.Dev.#4.....:   976.1 MH/s (69.06ms) @ Accel:32 Loops:64 Thr:640 Vec:1
Speed.Dev.#*.....:  3992.6 MH/s

Dal jsem na pastebin cely ten soubor s vysledky, kdyby to nekoho zajimalo.

[Max]

U sha512crypt je "619.0 kH/s", takže "hotovo" fakt nehrozí :).
Zdar Max

[Jendа]

Použitý algoritmus a salt snad jsou napsané u toho, ne? Třeba u toho hashe nahoře je algoritmus 6 = sha512crypt a salt h6761JCqLNwoNicM. sha512crypt se prý louská řádově 200 kkey/s, takže to bude mít Martin tak za 100 let hotové. Náhodné osmiznakové heslo je reálné dát jenom pro nejrychlejší algoritmy (MD5 a spol.), které se louskají klidně 100000x rychleji (desítky Gkey/s) - tam by to opravdu bylo za pár hodin.

[Max]

Je to tak. Bohužel je spousta systémů, kde používají md5 hashe, tam je to jasné. Nicméně není to příklad Linuxu ani jiných OS. Stejně tak i komerční sw dospívají a používají bezpečnější šifry.
Zdar Max

[Martin Tůma]

Neznám konkrétní čísla pro konkrétní případy - vycházim jenom z někým jiným publikovaných obecných tabulek, ale pokud to tvoje číslo je pro jedno GPU, tak i pro ten sha512crypt to nákupem výpočetního výkonu na AWS za cenu max. jednoho osobního automobilu srazim na max. hodiny...

[Max]

Pokud je ta tabulka výše od JiKa nějak reálná, tak asi ne. Lámání sha512crypt je 6500000x pomalejší, než lámání sha512. A pak je tu ještě otázka, zda by ti někdo tak velký výkon pronajal (zda to někdo běžný jako ten oracle umí vůbec poskytnout, takové škálování).
Pro smrtelníka to tedy vidím bledě, ale třeba jen neumím počítat :-/.
Zdar Max

[Jendа]

Hele a co vy vlastně máte všichni za use-cases pro offline bruteforcování? Mně přijde, že jediná věc, která by u mě šla bruteforcovat offline, je šifrovaný disk, resp. jeho zálohy. Na všechno další se dá útočit jen po síti, protože když tam útočník získá hash, tak to znamená, že už stejně přístup má.

(ale jinak teda mám samozřejmě password manager, protože si nedokážu doslova ke stovkám služeb pamatovat ani slabá hesla)

[Martin Tůma]

Šifrovaný disk. Pro stát není přístup k němu žádný problém. Otázka je, jestli to stejně není zbytečný, když ti to dětský porno domů policie klidně donese na disketách...

[Max]

Máš nějaký zdroj, kde stát se dokázal dostat k zašifrovanému disku pomocí luks, nebo třeba truecrypt? Můžeme ještě myslet na Bitlocker od MS, ale tam se šifruje certifikátem a buď můžeme nabourat TPM pomocí Intel bugů, nebo bude třeba cert v TPM slabý/generický, nebo se můžeme pokusit najít šifrovací cert a uhodnout k němu heslo (recovery key).
Takže při použití TPM, ač by to mělo být bezpečné, vidím spíše bezpečnostní problémy. Windows ale na něm trochu lpí, takže možná v rámci Windows to asi nebude ideální, nevím. Možná se k tomu někdo vyjádří trochu blíže, já to zas tak moc do hloubky nezkoumal.
Jinak pak je tu ještě možnost šifrovat na úrovni disku (nastavuje se většinou v rámci biosu). V takovém případě je heslo uloženo ve fw disku. Dřív to šlo celkem lehce vydolovat (vlastní kabel, load firmware, extrakce části s heslem atd.), ale opět, aktuální stav neznám.
Zdar Max
PS: být PČR, tak si heslo/klíč zjistím nějakým druhem sledování osoby, než že bych osobu zatknul a pak ext post se snažil zjistit heslo do zašifrovaného disku

[Jendа]

Stát ti vyhackuje počítač a klíč si přečte. Ale není mi jasné, proč by to měl umět pouze stát, tak možná nemyslel toto.

[Max]

Přesně tak. To jsem také psal. Možná opravdu nemyslel, že by něco bylo zranitelné, ale to, že že si to může útočník obstarat jinak a celé to zabepečení obejít sociálním inženýrstvím aj. věcmi.
Zdar Max

[Martin Tůma]

Nevim jaký informace máš k dispozi ty, ale podle těch mejch bych si to tak neidealizoval. Běžnej postup je ten, že se stroje zabaví a pošlou externistům na analýzu, protože Policie ČR na to ani nemá dostatečně kvalifikovaný lidi. Čemuž se nelze moc divi, protože co si myslíš, že za machry tam za tabulkovej plat a nutnost nechat se prolustrovat prověrkama bude?!

Hackování počítače státem - dtto. Pokud zafunguje něco, co se dá koupit na "trhu pro státní organizace", tak možná, ale představa, že Policie ČR provede nějakej sofistikovanej útok na Jendův zcela nestandardní linuxovej hacker-stroj je úplně mimo realitu.

[Martin Tůma]

K zašifrovanému disku se stát dostane vždy triviálně pomocí domovní prohlídky. Jestli se dostane i k datům pak už záleží právě pouze na síle hesla (alespoň v případě LUKSu, o útocích na Bitlocker nemám informace). V mě známých případech se k datům stát nedostal.

Co se týče sledování/vniknutí do bytu, tak to má tu zásadní nevýhodu, že je tady vždy riziko odhalení a celá akce, která sestává i ze spousty jiných činností se tím zhroutí.

[Jendа]

K zašifrovanému disku se stát dostane vždy triviálně pomocí domovní prohlídky. Jestli se dostane i k datům pak už záleží právě pouze na síle hesla

Aha, tak to jsme se nepochopili. Já myslel že tím mluvíš o tom, že se dostane k dešifrovaným datům na něm.

[Petr Fiedler]

ale jinak teda mám samozřejmě password manager, protože si nedokážu doslova ke stovkám služeb pamatovat ani slabá hesla

A co používáš?

Znáš Bitwarden? Co na to říkáš? Na úvodní stránce sice vybízejí k registraci účtu, ale myslím, že to není třeba a lze to řešit přes vlastní server.

[Max]

Já to budu nasazovat. Dlouho jsem bádal nad tím, co vybrat a nakonec Bitwarden asi zvítězil. Důležité je, že umožňují onpremise. Pak je tu ta věc, že existuje alternativní implementace serveru, která nemá moc funkčních omezení a je plně zdarma (tu ale nasazovat nebudu). Pro sebe osobně bych to řešil jinak, ale pokud existuje nějaký team, je třeba něco sdílet, něco ne, vše auditovat atd., tak je to podle mně dost vhodný program.
Zdar Max

[Bystroushaak]

Znáš Bitwarden? Co na to říkáš? Na úvodní stránce sice vybízejí k registraci účtu, ale myslím, že to není třeba a lze to řešit přes vlastní server.

Já používám Bitwarden a zatím si není na co stěžovat. Umí to i dvoufaktorovou autorizaci.

[Petr Fiedler]

Zrovna si na jejich webu čtu FAQ. Nemůžu tam najít, jestli je registrace povinná? Nevíš?

BTW: Četl jsem si teď u tebe na blogu článek o tom, jak se stát hackerem. Až na ta sprostá slova, která tomu ubírají, super článek.

[Petr Fiedler]

Tak není. Stačí si to nainstalovat k sobě na server a vytvořit si účet tam. Myslel jsem si, že bych si to dal na RPI 4B, ale zarazily mě požadavky na systém:

• Processor: x64, 2 GHz dual core
• Memory: 4 GB RAM (system memory)
• Storage: 25 GB
• Docker: Engine 19+ and Compose 1.24+

Takže mám zatím smůlu a budu si muset časem postavit nějaký server.

[panika]

jak uz tady psali ostatni je i alternativni implementace serveru https://github.com/dani-garcia/bitwarden_rs ja ji pouzivam zatim pro sebe v dockeru na vpsfree a rozhodne si neveme pro jednoho cloveka tolik zdroju. tipnul bych si ze rpi4 v poho.

[Petr Fiedler]

Tipnul by sis správně.

Jinak dík.

[Petr Fiedler]

Ještě něco. Já mám v systému klíčenku Seahorse. Dají se do ní dát GPG klíče, SSH klíče, nebo ta hesla. Aby ses k těm heslům dostal, tak tu klíčenku musíš samozřejmě odemknout. Říkám si ale, jaký je rozdíl mezi tím, když budu mít hesla uložené jako plain text v textovém souboru, nebo v odemknuté klíčence. K obojímu má útočník snadný přistup, ne? Takže klíčenka má tu výhodu, že ta hesla vyplňuje automaticky, ale moc bezpečnější to není. Nebo se pletu?

[Jendа]

Plaintextový soubor má nevýhodu, že to z něj typicky kopíruješ tak, že je všechno vidět když ti někdo vidí na monitor. Osobně používám na webové věci výchozí správce hesel ve Firefoxu.

[Petr Fiedler]

No to já taky, ale třeba některá hesla se do něj bojím dát. Je podle tebe OK dát do něj třeba heslo od banky, datových schránek, nebo NextCloudu? Sice mám všude nastaveno dvoufázové ověření, ale i tak. A co třeba od routeru? Tady dvoufázové ověření nemám a přijde mi to jako úplný masakr.

[plostenka]

To plati pouze v pripade, ze utocnik muze zkouset 10**n moznosti za sekundu. Ale vetsina overeni hesel bud trva dlouho (localhost), nebo je omezena firewallem (online 5 pokusu a mas ban na hodinu).

[Petr Fiedler]

%wheel ALL=(ALL) NOPASSWD: ALL

Funguje to jen částečně. V terminálu jsem zatím na problém nenarazil, i když je třeba říci, že jsem to zkoušel jen krátce. Ve správě aktualizací to ale při instalaci nového jádra sudo heslo chtělo. Zkusil jsem i:

user_name ALL=(ALL) NOPASSWD:ALL

ale chovalo se to stejně. V terminálu to heslo nechtělo, ale při instalaci jádra ve správě aktualizací ano. Jde to nějak nastavit, aby se to heslo nemuselo zadávat nikdy?

[k3dAR]

GUI programy NEpouzivaji(az na vyjimky co jeste nepresli na pkexec) sudo, takze je to v poradku, pro GUI je potreba pridat polkit pravidlo, v adresari /etc/polkit-1/localauthority/50-local.d vytvorit soubor nejakejnazec.pkla s obsahem:

[Install package file]
Identity=unix-group:sudo
Action=*
ResultActive=yes

[Petr Fiedler]

Paráda. Dík

[random]

V BASHi: bind 'set enable-bracketed-paste on'.

Funguje to na moderních terminálech (emulátorech), které před a za text vkládaný ze schránky přidávají escape sekvence, které BASH může rozpoznat.

[Heron]

Proč by tam měla být hesla / nebo se měla zadávat do promptu na heslo?

Ale abych odpověděl: nikdy.

[Martin Tůma]

Jako že se nikdy nepřepíšeš? Kdo nikdy nikde nenapsal heslo do loginu, nechť hodí kamenem...

[Heron]

Do jakého loginu? Bavíme se o terminálu, tam hesla fakt nepíšu. Veškeré přihlašování na další služby (ssh) je pomocí klíčů.

[Martin Tůma]

Do libovolného. A i v terminálu někteří lidé hesla zadávat musí, třeba když daný ssh server nepodporuje klíče, nebo když je potřeba zadat heslo k tomu klíči. O příkazech, který to heslo potřebují z podstaty, jako např passwd ani nemluvě...

[Heron]

třeba když daný ssh server nepodporuje klíče

Každý má své peklo, které si hýčká.

nebo když je potřeba zadat heslo k tomu klíči

Jasně, ale to se nutně nemusí dělat v terminálu a navíc to heslo nemusí být vždy nastavené. Lehce OT, v letošní okurkové sezóně jsem narazil na tohle. Widle ukládají soukromý klíč přímo k účtu, zašifrovaně a samostatný soukromý klíč není nikde. Tj stačí mít zabezpečený login a je to. Podobnou fci může mít zašifrovaný home, kde už může být klíč bez vlastní passphrase.

[Martin Tůma]

Já to všechno beru, jenom jsem ti chtěl naznačit, že tyhle obecný kvantifikátory jako "všichni", "vždy", nebo "nikdy" jsou dost ošemetný a často nakonec zjistíš, že ty sám jsi vlastně důkaz sporem...

[Heron]

Pardon? Vlákno vzniklo z dotazu, kdo kolikrát zadal (minulý čas, bavíme se o history) heslo do terminálu. Na to jsem popravdě napsal, že já nikdy. Na tom už není co řešit, je to prostě individuální odpověď. Těžko můžu být důkaz sporem.

A pokud někdo má problém s hesly v terminálu, tak jsem nabídl i několik jednoduchých řešení.

Mimochodem:

cat .bash_history | grep passwd | wc -l
       0

Účty bez hesla, přihlašování klíčem.

[Martin Tůma]

No jo, to je tak, když někdo odpovídá na otázky, který nebyly pro něj Já to četl tak, že podle tebe nikdy nemůžou být hesla v historii.

[Heron]

OK

[jejda]

HISTSIZE=-1 jsem neznal, dík. Jinak používám hstr. Je to takový jakby "history organizer" . Docela si na to člověk zvykne.

[Jendа]

Netreba se bat a vyhledavani v .bash_history ktery ma i pres 1 MB je okamzite a netreba se obavat jakehokoli cekani.

Můj teda má 4 MB za rok hlavní problém je v tom, že po pár letech pak každý bash zabírá třeba 60 MB RAM, a když mám otevřených 10 terminálů, tak už je to 600 MB… Když jsem míval „jenom“ 8 GB RAM, tak už to bylo podstatné.

Jak v historii sjednat poradek? Nejsnaze treba timto prikazem:

sed 's/^[ \t]*//;s/[ \t]*$//' ~/.bash_history | sort | uniq > vystup.txt

Normální lidi mají v historii čas (což se tipuju zaplo tím, že jsem udělal export HISTTIMEFORMAT='%F %T ', když to teda zjevně není default), protože jako chtějí vědět, co kdy zadávali, a pak je v .bash_history vždycky jeden řádek komentář s timestampem a jeden řádek s příkazem. Ten sort samozřejmě všechny tyhle timestampy hodí na začátek. Oh ne díky.

Deduplikaci dělám takhle:

#!/usr/bin/env python3
import sys
import re

if len(sys.argv) < 2:
  print("usage: %s /path/to/.bash_history > output"%sys.argv[0])
  sys.exit(1)

l = open(sys.argv[1], encoding='utf-8', errors='ignore').readlines()
cmds = []
f = set()

i=0
while i<len(l):
  ts=l[i]
  cmd=l[i+1]
  if not re.match("^#[0-9]{10}$", ts):
    i +=1
    continue

  hs = ts+cmd
  if (not hs in f) and len(hs) < 400:
    cmds.append([ts,cmd])
  f.add(hs)
  i+=2

for cmd in cmds:
  print("%s%s"%tuple(cmd), end="")

Hledany retezec je barevne (obvykle cervene) zvyraznen.

To teda není (teda alespoň na Debianu) default, musí se udělat grep --color=auto (nastavte si alias).

Nyni jeste dve drobne modifikace v ~/.bashrc:

# Ulozi prikaz po odentrovani do .bash_history aniz by bylo treba zavrit (opustit) terminal:
PROMPT_COMMAND="history -a; $PROMPT_COMMAND"

K tomuto je hlavně potřeba dodat, že pomocí history -n (opět doporučuji alias, já mám hn) se ta historie zase kdekoli jinde načte. Aby člověk mohl jít do vedlejšího terminálu a tam ji měl. Zkoušel jsem to i načítat automaticky, tj. mít úplně globální historii přes všechny terminály, ale bylo to nepoužitelné, protože pak šipka nahoru samozřejmě spouštěla nějaký jiný příkaz než který jsem v tom daném terminálu spouštěl.

Mrzuté je, že tahle synchronizace se mi zhruba jednou za měsíc rozbije (typicky tak, že se příkazy přidávají do .bash_history, ale history -n je v existujících terminálech přestane načítat) a musím ukončit všechny shelly a znovu je spustit. Netuším, čím to je.

Pak se ještě hodí ukládat, kromě již zmíněného času (což je myslím čas spuštění) ještě čas doběhnutí, adresář ve kterém bylo spuštěno, návratovou hodnotu a PID shellu ze kterého bylo spuštěno (takže když pracujete ve více terminálech současně, tak to pak lze rozklíčovat). Tím se ale ze souboru stane naprosto příšerný bordel a stálo by za to ukládat to do sqlite.

[JiK]

uzasne. 5 andulek.

[Brilantní modř]

Myslím, že zápisek je prakticky hodnotný a půvabný.

Ale co když tu historii někdy prostě nechcete?

history -c smaže historii současného uživatelova sezení, ale to, co bylo uloženo dříve, ponechá. Potom už jen jedno nebo druhé:

history -c && exit, případně history -c && logout

alias exitnoh='history -c && exit'

[Heron]

Pěkný zápisek.

Koncept history má jeden zásadní nedostatek. Je vázán ke konkrétnímu účtu na konkrétním stroji.

Tj místo šperkování příkazů a dopisování tam ještě komentáře je lepší (pro mě určitě) si vedle psát nějakou wiki nebo tak něco. Protože Murphy nikdy nespí a nějaký důležitý příkaz (na který si zrovna v danou chvíli nemůžu vzpomenout), je na jiném stroji, pod jiným účtem apod. Takže za mě, lepší je si psát dokumentaci.

[pavele]

To seřazení podle abecedy třeba pro mě není dobrý nápad, někdy potřebuju najít posloupnost příkazů, history edituju ručně:

history -w && vim "${HISTFILE}" && history -c

[xkucf03]

Skvělý článek, díky. Ta kombinace grepu a vykřičníku je užitečná. Většinou tedy používám Ctrl+R, ale někdy je lepší si filtrované příkazy vypsat pod sebe než je procházet po jednom.

Pokud sami mate nejake vychytavky ktere pouzivate v souvislosti s historii prikazu v terminalu tak se sam rad poucim.

Psal jsem zrovna před dvěma lety taky o Vánocích: GNU Bash: Vánoční tipy

[Bherzet]

Cože, on se ten Shift mačkat nemusí? :D Achjo.

[Bherzet]

Díky za pěkný zápisek.

Historii v Bashi nijak extenzivně nepoužívám. Nedávno zadávané příkazy lovím přes Ctrl+Shift+R a jinak si píšu poznámky. Ostatně mi i vyhovuje, zvlášť u složitějších příkazů, připravit si je stranou a až pak je spustit. Editovat delší příkazy v terminálu je horror, občas se to vizuálně rozbíjí, k tomu všemu je třeba dávat pozor, abych nezavadil o Enter omylem…

Mimochodem, ještě užitečný trik: u rm jsem si zavedl pravidlo, že přepínač -r píšu vždy až úplně na konci. Sice se mi nikdy nestalo, že bych omylem odenteroval dřív než po dopsání celé cesty, ale proč to riskovat?

Pokud nechci, aby se něco do historie uložilo (typicky hesla, když třeba posílám nějaký request curlem), zadávám to s mezerou na začátku.

[Max]

Zásadně zakazuji history, a to jak u bash, tak u mysql. Důvod je prostý, nevěřím sobě ani jiným adminům. Kdysi se mi podařilo dostat do jednoho systému tak, že v adresáři uživatele root byla záloha uživatele root pod právy 755. V rámci zálohy byly i soubory s historií bashe i mysql. A hádejte co, ano, v jednom z nich bylo i zalogované heslo, které bylo platné. Tím pádem jsem měl hned roota do cizího systému. A od té doby preventivně na svých systémech historii zakazuji. Raději oželím lepší komfort, než abych riskoval svůj nebo něčí omyl, který by nějakou náhodou nebo dalším omylem eskaloval dál.
Zdar Max

[JiK]

to jsou ty rozdily...nekdo dela admina na serveru, kteri ridi termonuklearni jaderna sila, nekdo na raspberry zero, ktere zapina meri teplotu ve spajzu...

[Bherzet]

To mi přijde extrémní. Zrovna tak by v té záloze mohly být nešifrované SSH klíče. Úplně vypnutá historie by mě dost frustrovala, muset všechno zadávat znovu… Akorát bych dělal překlepy.

[xkucf03]

Já bych si tam připadal jak v DOSu/Windows – tam bych se fakt nechtěl vracet.

Na nějakém extra zabezpečeném serveru bych to možná chápal, ale na normálních serverech a pracovních stanicích jsem za historii rád a hodně mi pomáhá. A to bez ohledu na to, že na často používané věci si dělám aliasy nebo skripty. Ono předem často člověk neví, jestli ten příkaz bude potřebovat opakovaně nebo to nechce v tu chvíli řešit. Nejdřív to píšeš ručně, pak si vzpomeneš, že to máš v historii tak to taháš z ní a když se to opakuje, tak si z toho uděláš alias nebo skript.

Když jsem přišel k cizímu serveru a měl jsem tam něco dělat nebo to opravit, tak mi historie mnohokrát pomohla. I když předchozí správce nic nedokumentoval, tak v té historii po něm zbyly užitečné příkazy, ze kterých šlo zjistit, co ten server obvykle potřebuje, kde jsou jaké soubory atd. Ano, je to svým způsobem bezpečnostní riziko, ale většina lidí/firem má jako prioritu to, aby to rychle zase fungovalo, a ne nějakou absolutní bezpečnost, která pokrývá všechny hypotetické vektory útoku (na které pravděpodobně nikdy nedojde).

Ale ta nekonečná historie má taky svoji stinnou stránku – pak můžeš mít pocit, že všechno najdeš v historii a budeš na to příliš spoléhat. Když víš, že ti v ní věci časem mizí, tak tě to podvědomě nutí si udržovat ty skripty a aliasy, což je čistější a systematičtější řešení (můžeš to verzovat, lépe zdokumentovat, dát tomu parametry…).

[Max]

Nějak nevím, co bych z historie lovil. Když dělám něco složitějšího, tak to píšu do skriptu, jinak v rámci bashe mám relativně jednoduché cmd.
Zdar Max

[Heron]

Na nějakém extra zabezpečeném serveru bych to možná chápal

Já ne. Tohle je další z řady pseudozabepečení. Citlivé údaje by se neměly na terminál a tedy do historie mít jak dostat a pokud se dostanou, tak je to špatně navrženo. Ke všem slušným technologiím se dá připojit bezpečně bez nutnosti psaní hesla buď do parametrů, nebo do promptu.

Už jsem pracoval i na serveru, kde sice vůbec nebyli schopni popsat, co vlastně chtějí, ale měli tam shell, který hned logoval každý příkaz kamsi na síť, aby potom měli audit (rozuměj na někoho to hodit). Takhle se to nedělá. V průmyslu je běžné, že pracovník (a admin není v té chvíli nic jiného než dělník), dostane pracovní příkaz a podle toho pracuje. Není přípustné, aby si pracovník v rozvodně VN nebo třeba v metru náhodně cvakal s odpojovačema. V IT tohle samozřejmě nefunguje, takže se k tomu pustí náhodný člověk z ulice a potom se řeší výmaz historie...

tak si z toho uděláš alias nebo skript

+1 A potom si musíš někam zapsat, že na to máš skript Takto vždycky po x letech objevím perly v ~/bin.

Když jsem přišel k cizímu serveru a měl jsem tam něco dělat nebo to opravit, tak mi historie mnohokrát pomohla. I když předchozí správce nic nedokumentoval, tak v té historii po něm zbyly užitečné příkazy, ze kterých šlo zjistit, co ten server obvykle potřebuje, kde jsou jaké soubory atd.

Jo, někdy to jinak nejde.

Ale ta nekonečná historie má taky svoji stinnou stránku – pak můžeš mít pocit, že všechno najdeš na v historii a budeš na to příliš spoléhat. Když víš, že ti v ní věci časem mizí, tak tě to podvědomě nutí si udržovat ty skripty a aliasy, což je čistější a systematičtější řešení (můžeš to verzovat, lépe zdokumentovat, dát tomu parametry…).

No ona hlavně ta nekonečná historie moc nefunguje (by default). Asi nejsem jediný, kdo používá tmux / screen. Takže tam mám měsíce puštěný tmux, v tom x panelů, potom dojde na restart a uloží se historie z toho posledního zabitého panelu. Který tam může být klidně i rok. Tj history se fakticky vymaže. Tj potom všude ještě je potřeba nastavit shopt -s histappend.

[xkucf03]

Ke všem slušným technologiím se dá připojit bezpečně bez nutnosti psaní hesla buď do parametrů, nebo do promptu.

Některé široce používané programy jako MySQL obsahují rovnák na ohýbák, který přepisuje heslo zadané na příkazové řádce tak, aby nešlo přečíst z výpisu procesů (viz Přepisování parametrů příkazové řádky).

Souhlasím, že heslo by se na příkazové řádce (a tím pádem v historii) nemělo nikdy objevit a programy by měly být psané tak, aby k tomu nesváděly nebo to vůbec neumožňovaly.

Ale těžko to vysvětlíš lidem, kteří si libují v posílání HTTP/REST požadavků přes curl. Stejně tak jsem v praxi několikrát zažil, že se hesla omylem ukládala do aplikačních logů se spoustou dalších dat. Tohle by se taky dít nemělo.

Ale zrovna ty logy se vyplatí chránit a šifrovat, i když si věříš, že ti do nich žádná hesla neunikají – protože i bez těch hesel bývá v logu spousta potenciálně zneužitelných informací (nejsou třeba zneužitelné samy o sobě, ale když se dají dohromady s dalšími informace, které se můžou někde povalovat, tak už to útočníkovi pomůže).

Co se týče té historie, tak se spíš nabízí opačný extrém – logovat úplně všechno (ale šifrovaně), aby byl o každém zásahu na serveru záznam, kdo a co tam kdy dělal. Tím se jednak dá zpětně dohledat pachatel a jednak to funguje i psychologicky-preventivně. To se ale nebavíme o nějaké historii shellu a musí to být udělané tak, aby to ani root toho serveru nemohl obejít.

[Heron]

široce používané programy jako MySQL

Psal jsem slušné

obsahují rovnák na ohýbák, který přepisuje heslo zadané na příkazové řádce

Jo, tohle se svého času řešilo u hodně programů.

Ale těžko to vysvětlíš lidem, kteří si libují v posílání HTTP/REST požadavků přes curl.

Já už nemám potřebu nikomu nic vysvětlovat. V tomto roce jsem pochopil, že lidi jsou prostě nepoučitelní. Nemají zpětnou vazbu. Funguje zpětná racionalizace všeho. V IT platí, stejně jako všude jinde, reklama, hype a současné trendy. Já nevím, mě vždy bavilo poslouchat staré mazáky, jak si s kdečím uměli poradit s minimem prostředků a sám se snažím věcem nejdřív rozumět a potom je dělat. Kupříkladu zmíněné logy jsem za 15 let praxe potřeboval co by na prstech jedné ruky napočítal. Bez přehánění. Správný automechanik pozná vadu motoru podle zvuku ne proto, že má šestý smysl nebo podobnou kravinu, ale podle toho, že už jej 40x rozebral a sestavil. Ne, namísto toho mě všichni přesvědčují, ze základem jsou logy. Klidně udělejte si to podle sebe, ale proč vlastně za mnou chodíte? Jen proto, abyste si postěžovali že VÁM něco nefunguje a ještě odmítnete moje řešení? No nic, to jsem odbočil

Ale zrovna ty logy se vyplatí chránit a šifrovat, i když si věříš, že ti do nich žádná hesla neunikají – protože i bez těch hesel bývá v logu spousta potenciálně zneužitelných informací (nejsou třeba zneužitelné samy o sobě, ale když se dají dohromady s dalšími informace, které se můžou někde povalovat, tak už to útočníkovi pomůže).

Jo, šifrovat. Logy jsou od toho, aby tam byly zajímavé informace. Nemusí se jednat vždy o hesla nebo tak něco.

Co se týče té historie, tak se spíš nabízí opačný extrém – logovat úplně všechno (ale šifrovaně), aby byl o každém zásahu na serveru záznam, kdo a co tam kdy dělal.

Ne. Nabízí se udělat ten systém tak, aby chyba jednotlivce nezpůsobila problém. Aneb jak já říkám při komentování různých mimořádností na dráze, pokud se to dá hodit na chybu jednotlivce (což různí potentáti rádi dělají), tak to automaticky znamená chybu systému. Systém, který selže na chybě jednotlivce je špatně navržený.

Tím se jednak dá zpětně dohledat pachatel

Jaký pachatel? Pachatel čeho?

Doporučuju tuhle přednášku. Není správné se ptát kdo, ale co.

[xkucf03]

Ne. Nabízí se udělat ten systém tak, aby chyba jednotlivce nezpůsobila problém. Aneb jak já říkám při komentování různých mimořádností na dráze, pokud se to dá hodit na chybu jednotlivce (což různí potentáti rádi dělají), tak to automaticky znamená chybu systému. Systém, který selže na chybě jednotlivce je špatně navržený.

Souhlas, tohle je ideál. Ale na to bys potřeboval mít systém nastavený tak, že k němu musí přijít dva lidi, každý zadá část hesla nebo každý svým klíčem něco odemkne a až když tam jsou prokazatelně oba dva, tak lze dělat v systému zásahy – předpokládá se, že selhání dvou lidí ve stejnou chvíli je dostatečně nepravděpodobné, měli by se navzájem kontrolovat. Pokud tím budeš odpalovat rakety nebo tak něco, tak je to fajn. Ale většina firem na tohle prostě nemá kapacity a jsou rádi, když mají aspoň toho jednoho člověka, kterému můžou kdykoli zavolat, aby šel něco opravit. Nemluvě o tom, že spousta firem nemá ani tohle a musí prostě počkat, až ten člověk přijde do práce nebo si doma druhý den ráno zapne počítač a milostivě se na to podívá.

Pokud ti nevadí nějaký ten výpadek a stačí ti nepřijít o data, tak k požadovanému výsledku stačí, aby se o zálohování staral jiný člověk, než který se stará o server, a aby ze serverů nešlo přepsat/smazat staré zálohy.

Úniky dat lze zase z velké části vyřešit šifrováním a rozložením dat a procesů na různá místa, tak aby neměl vše pod kontrolou jeden člověk nebo jeden tým. Osobně se snažím všude dodržovat princip minimálních práv – aby každý směl dělat jen to, co prokazatelně ke své činnosti potřebuje. To nás moc nestojí a velkou část útoků/problémů to zažehná.

Ale jinak to zase nejde hnát moc do extrému a snažit se o nějaké absolutní zabezpečení – ta obrana by měla být přiměřená těm rizikům a tomu, co chráníš. Taky by to nemělo být extrémně nepohodlné, protože pak to lidi začnou obcházet a sabotovat. Je to jako s hesly – ukázalo se, že k lepším výsledkům vede to, když lidi mají kvalitní hesla, byť pořád stejná, než aby byli nuceni je každého půl roku měnit.

Jaký pachatel? Pachatel čeho?

Za velkou částí, možná většinou, útoků stojí bývalí a současní zaměstnanci. Málokde jsou ty systémy a procesy nastavené tak, aby dotyčný nemohl způsobit žádné škody, když chce. Takže se to minimálně zčásti řeší nikoli technickými, ale různými sociálními prostředky – chceš mít prověřené a důvěryhodné lidi a chceš, aby věděli, že jsou pod dohledem a budou pravděpodobně odhaleni, když se tě pokusí zradit.

[Heron]

každý zadá část hesla nebo každý svým klíčem něco odemkne a až když tam jsou prokazatelně oba dva, tak lze dělat v systému zásahy

Ne, takhle se řeší odpalování ICBM. Systém, o kterém mluvím já, se nezhroutí po zásahu do jedné jeho části. Tj nepotřebuješ dva adminy s půlkou hesla, ale potřebuješ, aby to, co potom zadání hesla provedou, nevedlo k (úplnému) zhroucení. Tj do kabiny strojvedoucího nedáš 6 strojvůdců, ale na trati máš zabezpečení takové, které vlak přivede do bezpečného stavu i kdyby se všichni strojvedoucí zbláznili.

Za velkou částí, možná většinou, útoků stojí bývalí a současní zaměstnanci. Málokde jsou ty systémy a procesy nastavené tak, aby dotyčný nemohl způsobit žádné škody, když chce. Takže se to minimálně zčásti řeší nikoli technickými, ale různými sociálními prostředky – chceš mít prověřené a důvěryhodné lidi a chceš, aby věděli, že jsou pod dohledem a budou pravděpodobně odhaleni, když se tě pokusí zradit.

Pokud bývalí zaměstnanci útočí, tak k tomu pravděpodobně mají nějaký důvod, zřejmě tedy od bývalého zaměstnavatele. (Aneb vzpomněl jsem si na díl ano šéfe s hláškou: máte takové zaměstnance, jaké si zasloužíte.)

a důvěryhodné lidi a chceš, aby věděli, že jsou pod dohledem a budou pravděpodobně odhaleni

Důvěra je oboustranná záležitost. Nemůžeš mít důvěryhodné lidi, kterým nevěříš a proto je máš pod dohledem. Toto nejde dohromady.

Jinak to je teda fascinující odstavec:

útoků, škody, sociálními prostředky, prověřené, dohledem, odhaleni, zradit

Bavíme se stále o firmě, nebo o nějaké tajné službě v nějakém totalitním zřízení?

Toto vede k tzv. sovětskému myšlení. Pokud je jednotlivec za každou chybu potrestán, sledován, odhalen, tak potom žádné chyby dělat nebude. Tedy, bude je skrývat, tutlat. Všechno funguje naprosto bezvadně, nejlepší systém na světě, nikde nenajdete žádnou chybu.

Problém je, že lidi prostě dělají chyby. Všichni. Cílem tedy vůbec není za chyby trestat (a vše výše uvedené), ale naopak povzbuzovat jejich nahlášení. A nikdy nevinit nikoho konkrétního za nějakou chybu, protože to reálně jeho chyba není. Pokud systém dovolil, aby chyba jednoho člověka měla závažné následky, je to chyba systému, ne toho jednotlivce.

[Bherzet]

Jak si to představuješ? Nikdo se nebude nikam sám SSHčkovat, každý příkaz, který bude chtít spustit, půjde automaticky do review? Nebo všechny služby budou zálohované a nikdo nebude mít přístup ke všem strojům současně? A pokud se o něco stará jeden člověk, tak… ?

Přijde mi, že to moc zveličuješ. Někde se na to kašle, všechno se dělá manuálně, lidé jsou vystresovaní a dřív nebo později někdo udělá drobnou chybu, která skončí fatálně. To je to, co kritizuješ. Na druhou stranu, ne každá firma je Google. O určitou službu/služby se musí postarat třeba jen jeden jediný člověk a pak prostě nelze zabránit tomu, aby to sám nemohl totálně sestřelit. Existují metody, jak tu pravděpodobnost závažného průšvihu snížit. Pro začátek třeba zálohovat, zásahy prvně testovat jinde, u kritičtějších věcí si třeba připravit záložní stroj (alespoň dočasně)… Pořád by to ten jeden člověk mohl rozbít, ale pokud si aktivně neřekne „teď tady napíšu systemctl stop a už to nezapnu!“, tak to neskončí katastrofou.

Druhá věc je, jestli bys neměl mít těch lidí víc. Na to někdy peníze prostě nejsou. Nemůže se o každou online vizitku místního kadeřnictví starat tým 10 adminů. Jednou za rok, když bude potřeba překopírovat zaktualizované *.html někam na hosting, to udělá jeden člověk. A holt nezbývá než spoléhat, že než tam po smazání starých souborů začne kopírovat nové, tak nedostane infarkt.

Svým způsobem máte pravdu oba (i když to „útoků, škody, sociálními prostředky, prověřené, dohledem, odhaleni, zradit“ mě taky zarazilo :D), ale je fakt rozdíl mezi tím Googlem a tím místním kadeřnictvím. K odolným/blbuvzdorným systému je samozřejmě dobré směřovat vždycky a někteří lidé si na sebe naprosto zbytečně pletou bič v podobě systémů, které jsou jako domečky z karet, ale zase mít všechno postavené tak, aby to nemohl rozbít jeden člověk, to prostě fakt nejde.

[Heron]

Nebo všechny služby budou zálohované a nikdo nebude mít přístup ke všem strojům současně?

No třeba.

A pokud se o něco stará jeden člověk, tak… ?

Nevim.

Přijde mi, že to moc zveličuješ.

Já si z toho hlavně dělám prdel. (I když bych asi neměl.) Někdo tady píše o zabezpečení mazáním historie...

drobnou chybu, která skončí fatálně

Hmmm.

o je to, co kritizuješ.

Ano.

O určitou službu/služby se musí postarat třeba jen jeden jediný člověk a pak prostě nelze zabránit tomu, aby to sám nemohl totálně sestřelit.

Musí... Pokud to ten jeden člověk může totálně sestřelit, tak se tomu ale ti ostatní nemají divit. To je asi tak pointa.

Druhá věc je, jestli bys neměl mít těch lidí víc.

Souhlas.

Nemůže se o každou online vizitku místního kadeřnictví starat tým 10 adminů.

No to je jasné a kde je problém? Když vizitka kadeřnictví půl roku nepojede, tak se prd stane.

(i když to „útoků, škody, sociálními prostředky, prověřené, dohledem, odhaleni, zradit“ mě taky zarazilo :D)

ale je fakt rozdíl mezi tím Googlem a tím místním kadeřnictvím

Ale mě to nevykládej. Já se jenom bavím tím, že někdo tady mluví o nějakém zabezpečení a potom napíše, že nejsou lidi nebo tak něco.

Takže co jako, chce to zabezpečit, nebo jen chce aby to vypadalo zabezpečeně, nebo to chce na někoho hodit nebo co teda vlastně?

[Max]

Někdo tady píše o zabezpečení mazáním historie...

Nikdo tady nepíše o zabezpečení mazáním historie, ale nepoužíváním historie jako prevence před případnými omyly. A jak už jsem zmínil, hesla se do historie dostanou i v případě, že je člověk nedá přímo do terminálu, viz jako příklad zmíněné mysql history.
Zdar Max

[Bherzet]

drobnou chybu, která skončí fatálně

Je rozdíl, jestli se chirurg sekl o desetinu milimetru nebo o centimetr. V obou případech to následky může mít fatální, ale velikost té chyby se liší.

[Max]

Tohle právě řeším, jak předejít omylům. Už jsem se např. několikrát setkal s tím, že admin nainstaloval třeba UPS, ale nezměnil na ní heslo. Zatím děláme pravidelné penetrační testy, které takové věci odhalí, ale jak tomu předejít skutečně? Mohu vygenerovat nějaký dokumenty s checklisty, ale to stejně není zárukou toho, že to ten člověk udělá. Napadá mně vše kontrolovat, ale to pak samozřejmě generuje šílený overhead. Asi se to dá řešit najmutím 2x tolik lidí včetně dalšího, co bude vymýšlet nějaké šílené procesy, ale jde to řešit nějak fakt efektivně? Protože ty vždy píšeš, jak mají věci vypadat, což já vím samozřejmě také, ale už nevím, jak toho reálně docílit :-/.
Zdar Max

[Heron]

Zatím děláme pravidelné penetrační testy, které takové věci odhalí, ale jak tomu předejít skutečně?

Tak testy jsou dobrý nápad, jinak v průmyslu fungují revizáci (další kanál ke sledování, mě tohle prostě baví). Tj další člověk, který na to dá razítko. Není to neprůstřelné, ale to není nic.*

A co se přesně stane, když ta UPS není za heslem? Kdo se k ní dostane? Jak? Proč? Co může udělat?

Napadá mně vše kontrolovat, ale to pak samozřejmě generuje šílený overhead.

No tak on to někdo zkontrolovat musí. Jako vážně. Proč se dělají (několikanásobné) code review? Proč se u vědeckých textů dělají peer review (a i ty by zasloužily pořádnou revizi)?

Asi se to dá řešit najmutím 2x tolik lidí včetně dalšího, co bude vymýšlet nějaké šílené procesy, ale jde to řešit nějak fakt efektivně?

Nevím, co myslíš tím fakt efektivně. Vždy se na misku vah dávají náklady a možné ztráty. Jsou náklady na kontrolu vyšší než ztráty, když to všechno shoří?

Protože ty vždy píšeš, jak mají věci vypadat, což já vím samozřejmě také, ale už nevím, jak toho reálně docílit :-/.

Proto píšu ty příklady z průmyslu. Je naprosto normální, že to někdo navrhne, někdo jiný zkontroluje, někdo udělá, někdo zreviduje. V IT jsme si, k vlastní škodě, zvykli, že to všechno zvládne jeden člověk.

*) Jo a nejlepší strategie je: zhotoviteli říct, jestli se na tom najde jedna chyba, nedostanete zaplaceno. Revizákovi řeknete, že pokud na tom nenajde chybu, tak nedostane zaplaceno. Ti dva se nikdy nepotkají. Samozřejmě joke na Frantovi "sociální prostředky", ale tohle mě napadlo už před mnoha lety při jedné rekonstrukci (kde byly skvělé obě strany).

[Petr Fiedler]

To video z té stavby, to je fakt masakr! Já úplně nenávidím, když takhle lidé něco dělají. A naopak miluji, když člověk rozumí tomu co dělá a dělá to ze srdce.

[Max]

Myslím, že mysql history by default loguje kompletní selecty, takže se v historii objeví hesla při vytváření uživatelů nebo jejich změně.
A to je jen příklad, jak se dají dostat čitelná hesla do historie.
A pokud si dobře vzpomínám, tak zrovna takto jsem získal heslo roota, protože nějaký admin si měnil heslo do db a bylo stejné jako do OS.
Zdar Max

[k3dAR]

[...]Asi nejsem jediný, kdo používá tmux / screen. Takže tam mám měsíce puštěný tmux, v tom x panelů, potom dojde na restart a uloží se historie z toho posledního zabitého panelu. Který tam může být klidně i rok. Tj history se fakticky vymaže. Tj potom všude ještě je potřeba nastavit shopt -s histappend.

tomu prave pomaha v blogu zminene "PROMPT_COMMAND="history -a; $PROMPT_COMMAND", takze po restartu mas akorat ty historie ze vsech panelu promixovane

jinak, pokud neznas, tak zkoukni pro tmux (pouzivam s byobu nad tmux) plugin tmux-resurrect pro save/load rozlozeni, pred casem sem to resil tady a od te doby pouzivam vsude vcetne routeru s openwrt:)

[Bherzet]

Přesně tak. Mně třeba přišlo i užitečné, že když jsem se připojil na server, viděl jsem informace o posledním loginu (v takovém tom vítacím banneru, nevím přesně, jak se tomu nadává) a v historii viděl, co tam spouštěl kolega. Samozřejmě to byl jen doplněk k normální komunikaci, znalostní bázi, ticketovacímu systému atd., ale občas se na něco prostě zapomene a takhle hned vidíš, že někdo něco dělal a můžeš se zeptat. Ta historie není neprůstřelná a nedá se na ni spoléhat, ale je to prostě další forma nějakého logu. Ono koneckonců do obyčejných textových logů taky můžou probublat citlivé údaje, taky se jim nedá 100% věřit (někdo by je po sobě mohl upravit/promazat), a přesto mají smysl.

[Heron]

vítacím banneru

MOTD

[Max]

Jen párkrát se mi stalo, že jsem něco potřeboval z historie, abych ušetřil čas, jinak opravdu ne. A v rámci jedné session je historie v paměti, takže opakovaně mohu dělat cokoli, než se odhlásím. Jinými slovy, zakazuji flush historie na disk, nic víc.
Zdar Max

[Max]

Jinak ještě dodám, že klíče jsou vesměs zašifrovaný, takže zjistit k nim heslo je zase jiný level, než si ho přečíst v txt podobě.
Ale jinak souhlas, jakákoli záloha, co nemá root:root 600 je nebezpečná.
Zdar Max

[z_sk]

A premmena HISTORY?

[Gréta]

taková neni ne?? :O :O když napišu příkaz echo $HISTORY tak to jako neukáže vubec nic :O :O

[JiK]

protoze jste vsichni rasisti a fasisti. Je 2020 a melo by se pouzivat vyhradne HERstory, ne HISTORY. Dnes uz to ma kazda pokrokova univerzita. Stejne jako femistry and galgebra, ale ty jsou taky rasiticke uz obsahem.

[Jendа]

Chtěl bych nabídnout kacířský názor k problematice ukládání hesel jako hashe.

Živil jsem se, a stále ještě trochu nedobrovolně živím, tím, že mě zavolají k zanedbanému serveru, kde nastal nějaký průšvih, neexistuje k tomu dokumentace, člověk co to instaloval už tam pět let nedělá, a potřebují to opravit.

Poměrně častý jev je „botnet uhodl heslo nějakého uživatele“. Co pak udělám je, že usoudím, že tato firma má problémy s hesly, dumpnu si všechny hashe odevšud (což je v naprosté většině případů databáze - wordpress, ispconfig, ... občas též shadow, protože z nepochopitelných důvodů ve skutečném světě téměř nikdo nepoužívá ssh login klíčem) a zkusím je cracknout. Když se to podaří, dám jim seznam uživatelů, kteří si musí změnit heslo.

Zrovna teď se ale jedné firmě stalo, že botnet uhodl heslo, které jsem neměl ve slovníku (heslo bylo doménafirmycz a já zatím nezkoumal mutační pravidla; botnet to uvařil z domény jednoduchým odstraněním tečky), a tedy (by) ho takový audit neodhalil. Zatímco kdyby prostě hesla byla v té databázi v plaintextu, tak bych se na ten seznam podíval a bylo by jasné kdo má slabé heslo. Nemusel bych crackovat hashe.

Ze zkušenosti, scénář „heslo je tak slabé že ho někdo uhodne po síti“ se vyskytuje řádově častěji než scénář „někdo ukradl shadow nebo databázi, aniž by kompromitoval zbytek systému, a až díky heslu z něj dokázal kompromitovat ten zbytek“ (vlastně jediné kde vím že se tohle stalo je když jsem já hackoval ty botnety).

Preventivní odpověď: Ano, všichni víme, jak se tento problém má správně řešit.

[Josef Kufner]

Ze zkušenosti, scénář „heslo je tak slabé že ho někdo uhodne po síti“ se vyskytuje řádově častěji než scénář „někdo ukradl shadow nebo databázi, aniž by kompromitoval zbytek systému, a až díky heslu z něj dokázal kompromitovat ten zbytek“ (vlastně jediné kde vím že se tohle stalo je když jsem já hackoval ty botnety).

To je právě díky tomu, že (dobře) hashovaná hesla nejsou moc užitečná. Kdyby se hesla nehashovala, tak to bude mnohem lákavější cíl a ty útoky budou.

Ověření proti slovníku a mutacím běžných věcí má smysl spustit při změně hesla, kdy máš (dočasně v paměti) dostupné nehashované heslo. Případně to jde udělat při plain-text přihlašování (po šifrovaném spojení), kdy se například přehashovávají hesla na bezpečnější hash. Potíž je, že to nespustíš offline na už rozdrbaném systému, ale musíš čekat, než se uživatelé přihlásí. Na druhou stranu, pokud nespěcháš, můžeš to nechat týden běžet a těm, co se v té době nepřihlásí, heslo zrušit a nechat je, ať se přihlásí e-mailem jakoby ho zapoměli (pokud ta možnost je).

[xkucf03]

V případě nesvéprávných uživatelů by takovýto „paternalistický“ přístup dával možná smysl. Akorát pak máš SPoF – toho kontrolora hesel, který je pak schopný se nepozorovaně přihlásit pod libovolným uživatelem. A často dokonce i k jiné službě (nesvéprávný uživatel bude dost možná používat stejné heslo všude).

Aspoň bych to ale oddělil a ta hesla nenastavoval v jednotlivých aplikacích (tam by se změna hesla musela zakázat), ale přes nějakou centrální aplikaci (když to bude sofistikovanější, tak se tomu pak dá říkat IDM), která zkontroluje heslo proti různým pravidlům a slovníkům a případně si k sobě uloží heslo v čistém tvaru pro ruční kontrolu tím SPoF Jendou. V těch webových aplikacích totiž bývají chyby a někdo by z nich hesla mohl vykrást.¹ Kdežto v té tvé aplikaci to můžeš udělat např. tak, že se hesla v čistém tvaru budou zapisovat do tabulky, kam má aplikace jen právo INSERT, ale ne SELECT, nebo se dokonce budou odesílat na jiný server nebo šifrovat veřejným klíčem (ke kterému má soukromý klíč jen SPoF Jenda, někde bezpečně offline). Prostě princip minimálních práv (ta aplikace nepotřebuje hesla číst, jen zapisovat, tak právo čtení vůbec mít nemá).

Pak je tu ještě právní hledisko – asi bys to potřeboval ošetřit smluvně, protože rozhodně není běžná praxe, že někdo ručně kontroluje uživatelům hesla (a to ani v případě, že v databázi v čistém tvaru uložená jsou – nemluvě o tom, že tohle je různými normami a standardy zakázané…). Další věc je, že když by někomu z uživatelů vykradli internetové bankovnictví nebo třeba jen e-mailovou schránku nebo jiný účet, z tebe se automaticky stává podezřelý. Ano, uživatel je blbec, že používá všude stejné heslo, ale nemění to nic na tom, že podezřelý jsi teď ty, protože jsi tu možnost, měl. Ze stejného důvodu jsem klidnější, když nemám přístup na produkci a jsem čistě v roli vývojáře-dodavatele, který dodává software, ale nemá přístup k produkčním datům, a na produkční servery to instaluje někdo jiný. Byť často se tomu vyhnout nedá (pro zákazníka má větší hodnotu to, že mu můžu systém rychle opravit, než riziko, že mu ho můžu rozbít nebo vykrást).

Nakonec tedy asi nezbude než se pouze vcítit do role útočníka, pokusit se co nejvíc přiblížit algoritmu, kterým hádají hesla, a ten pouštět automaticky, aniž by na ta hesla koukal nějaký člověk.

_{[1] mimochodem, jen velmi zřídka vídám aplikace, které rozlišují mezi vlastníkem databáze a aplikačním účtem, který by měl jen vybraná práva k vybraným tabulkám – já tohle považuji za normální a mívám jeden účet jako vlastníka schématu, pod kterým se vytvářejí tabulky a další objekty a nastavují práva, a pak aplikační účet, který může některá data jen číst nebo naopak jen přidávat, ale ne všechno najednou (INSERT, SELECT, UPDATE, DELETE), protože to z principu věci nepotřebuje}

[Heron]

Koukám, že tohle téma tady rezonuje. Sám jsem o tom kdysi taky něco ublognul.

Další věc je, že když by někomu z uživatelů vykradli internetové bankovnictví nebo třeba jen e-mailovou schránku nebo jiný účet, z tebe se automaticky stává podezřelý.

Je k tomuto nějaký právní rozbor?

Ze stejného důvodu jsem klidnější, když nemám přístup na produkci a jsem čistě v roli vývojáře-dodavatele, který dodává software, ale nemá přístup k produkčním datům, a na produkční servery to instaluje někdo jiný.

Já jako admin jsem byl také spokojený, když jsem spravoval systém s daty zašifrovanými uživatelskými klíči. Protože potom mi někdo volal "jakože na technickou pohotovost", abych v nějaké zakázce změnil nějaké údaje. Tak jsem dámě sdělil, že k tomu jednak nemám přístup a že tam jsou navíc časová razítka a podpis je veřejný. Tak jsem ji asi moc nepotěšil.

[xkucf03]

Je k tomuto nějaký právní rozbor?

To nevím, ale zkus si představit, co se asi stane, když policajti budou z oběti páčit, kdo jiný mohl znát dané heslo (manželka atd.), a oběť si pak vzpomene, že stejné heslo měla i v aplikaci XY. Tam se pak dá čekat, že policie provozovatele té aplikace navštíví. Pokud budou hesla hashovaná, tak to pravděpodobně¹ tou jednou návštěvou skončí, ale pokud by se ukázalo, že hesla leží někde v čistém tvaru, nebo že je dokonce čas od času nějaký Jenda ručně kontroluje, bude se to dál zkoumat a bude to otravovat život dalším a dalším lidem.

Je to podobná situace, jako kdyby ti někdo svěřil klíče k trezoru, do kterého nepotřebuješ chodit. Když je nepotřebuješ, tak je lepší je nemít, protože kdyby se tam něco ztratilo, tak máš o problém méně a nikdo tě nebude zbytečně otravovat a vyslýchat.

_{[1] ono sice hashované heslo v databázi nezaručuje, že aplikace ta hesla v čistém tvaru třeba neloguje nebo neposílá někam dál… to už pak je věc nějakého důkladnějšího auditu, což je ale zase práce navíc a snižuje to pravděpodobnost, že se do toho někdo pustí}

[Heron]

To nevím, ale zkus si představit, co se asi stane, když policajti budou z oběti páčit, kdo jiný mohl znát dané heslo (manželka atd.), a oběť si pak vzpomene, že stejné heslo měla i v aplikaci XY. Tam se pak dá čekat, že policie provozovatele té aplikace navštíví. Pokud budou hesla hashovaná, tak to pravděpodobně1 tou jednou návštěvou skončí, ale pokud by se ukázalo, že hesla leží někde v čistém tvaru, nebo že je dokonce čas od času nějaký Jenda ručně kontroluje, bude se to dál zkoumat a bude to otravovat život dalším a dalším lidem.

To je teda dost vyšroubovaná konstrukce. Jednak nevím o tom, že policajti z oběti (čeho zase?) něco páčí a taky se hraje na osobní odpovědnost. Nevím, že by policie zkoumala, kdo má kde stejné heslo, ale pokud to heslo zná někdo další, tak je jim to celkem jedno. Ale můžu se zeptat, znám někoho na policejním prezidiu.

Je to podobná situace, jako kdyby ti někdo svěřil klíče k trezoru, do kterého nepotřebuješ chodit. Když je nepotřebuješ, tak je lepší je nemít, protože kdyby se tam něco ztratilo, tak máš o problém méně a nikdo tě nebude zbytečně otravovat a vyslýchat.

Hele, nevím, co všechno musí být v trezoru, aby mě někdo vyslýchal, ale řeknu ti, že při řešení opakovaného trestného činu krádeže kolem 40tis. mě policie nekontaktovala. Klasická krádež z kolárny v domě, (dva bezpečnostní klíče, který si nemůže jen tak někdo okopírovat - ale samozřejmě "může"), klíče má omezený počet lidí, včetně mě, nikdo nechtěl ani seznam lidí, ani mě. A to mi policie volá xkrát do roka při pátrání po osobách (nevím v jakých případech, jestli pohřešovaných, nebo podezřelých, to neříkají), zejména v nájemních bytech a pokaždé jim pravdivě řeknu, že já seznam osob nemám a vlastníci nemají povinnost nám hlásit, kdo u nich přebývá. Tím je to vyřízeno. Tj to že mám od všeho klíče ještě není důvod k výslechu (spíše k podání vysvětlení a to ještě kdyby někdo zahájil úkony přípravného řízení).

[xkucf03]

Já jako admin jsem byl také spokojený, když jsem spravoval systém s daty zašifrovanými uživatelskými klíči. Protože potom mi někdo volal "jakože na technickou pohotovost", abych v nějaké zakázce změnil nějaké údaje. Tak jsem dámě sdělil, že k tomu jednak nemám přístup a že tam jsou navíc časová razítka a podpis je veřejný. Tak jsem ji asi moc nepotěšil.

Tohle ale není tvoje starost. To je věc toho, kdo ty procesy, pravidla a ten systém navrhl – on musí zvážit, jaké jsou priority, co má jaké výhody a nevýhody a čemu dá přednost. Pak to (že ty jako správce nemůžeš jen tak do systému zasáhnout a něco změnit) je prostě známá (a chtěná) vlastnost, nikoli chyba. Ten, kdo to navrhl, měl vymyslet i různá náhradní řešení ve výjimečných situacích, když tam nejde udělat ruční zásah.

[Heron]

Aha, možná že to nebylo moc jasné, ale dotyčná chtěla neoprávněný zásah do dat jedné veřejné zakázky a proto volala na technika na pohotovosti a nikoliv na (právní) podporu. To, že to nejde změnit je chtěná vlastnost toho systému. Proto jsme to tak s analytikem navrhli (ano, podílel jsem se na tom).

Proto mám obecně rád šifrovaná data, protože já jako admin se k nim nedostanu a můžu všechny rovnou odpálkovat, že tu jejich úpravu stejně nemůžu (nikdo nemůže) provést. Ne, že by těch neoprávněných pokusů něco změnit bylo moc, ale některé mi zůstanou v hlavě ještě hodně dlouho.

[xkucf03]

Aha, OK :-)

[xkucf03]

Sám jsem o tom kdysi taky něco ublognul.

U starých článků máš vypnuté komentáře (proč?), tak odpovím tady.

Jak jsem psal před několika odstavci, heslo je pro každou službu unikátní. Pokud není, a pokud někdo používá jedno heslo pro X služeb, vůbec žádná metoda ukládání hesel v hash ho nezachrání. Důvod je jednoduchý. Stačí, aby jedna služba z oněch X nebyla poctivá, hesla si ukládala bokem (a třeba interně používala třeba onen moderní SCRAM-SHA1) a je to. Už znají vaše heslo i pro X dalších služeb. A vy o tom ani nevíte. Jediná cesta je tedy používat pro každou službu unikátní heslo.

Metoda ukládání ho sama o sobě nezachrání, ale dobře navržený systém celkově ano. Kdysi jsem psal článek Ověřování uživatelů na webu¹ a tam je popsán systém kontroly hesla tak, že se ho server nedozví.

Na webu je trochu problém, že uživatel nemá klientský kód moc pod kontrolou, většina uživatelů ho nezkoumá, a server tak uživateli může ledasco podstrčit. Ale kdekoli jinde (SMTP, IMAP, POP, SSH, FTP atd.) by to fungovalo, protože tam klientský program patří uživateli a měl by být pro něj důvěryhodný (není na počítač uživatele podstrčen ze serveru).

Jinak s tebou souhlasím, že nemá cenu moc hystečit a dělat skandál² z toho, že někdo na serveru měl hesla v čistém tvaru. Jako uživatel k tomu přistupuji vždy tak, jako by provozovatel moje heslo vidět mohl a volím vždy unikátní heslo (případně bych vědomě použil nějaké jednoduché heslo opakovaně tam, kde je mi to jedno). Na druhou stranu: přínosy v ukládání hesel v čistém tvaru moc nevidím, takže pro mne je výchozí možnost: hesla přisolit a zahashovat. Pak se dá jít směrem k tomu CRAMu nebo se ideálně zodpovědnosti za hesla úplně zbavit a oddělit roli SP a IdP. Aplikace (SP) pak hesla vůbec neřeší a pouze se napojí na poskytovatele identit (IdP) nějakým standardizovaným protokolem (typicky SAML). Tohle se hodně používá v univerzitním prostředí, kde existují i federace a dá se přihlašovat ke službám napříč organizacemi. Ale má smysl to použít i třeba jen v rámci firmy – je to trochu podobné případu, kdy všechny aplikace ověřují uživatele proti firemnímu LDAPu, ale v tomto případě hesla netečou přes jednotlivé aplikace, takže když bude v nějaké chyba nebo její správce bude záškodník, nedojde k vyzrazení hesel uživatelů, kteří se k té aplikaci přihlásili.

_{[1] pozor, je to z roku 2007, něco bych asi už dneska napsal jinak
[2] někteří si na tom asi snaží udělat jméno}

[Heron]

U starých článků máš vypnuté komentáře (proč?)

Protože se mi nechce řešit komentářový spam. U většiny článků není diskuse žádná, u některých jen taková zdvořilostní a jen u naprostého minima je nějaká významnější. (Vůbec nejlepší diskuse jsou emailem, když má někdo motivaci napsat email, tak to už fakt stojí za to.) Už hodně dávno jsem chtěl web převést na staticky generovaný (tak jak mám doc.heronovo.cz), ale zatím jsem se k tomu nedostal.

Takže jsem komentáře nechal zapnuté jen na 14 dnů po vydání článku a to obvykle stačí. Když jsem to měl zapnuté trvale, tak každý den chodila tuna spamů, většinou odfiltrovaná, ale někdy něco proklouzlo a naopak to někdy označilo jak spam rozumný komentář od člověka. Ale viz výše, diskuse pod webem do budoucna zmizí a přejdu na statický obsah.

Zbytek souhlas, ten článek je hlavně pro ty, kteří si myslí, že hashování hesel na serveru je nějak magicky ochrání proti jejich zvyku používat všude jedno a totéž heslo. I když bude na serveru jejich heslo skutečně neprolomitelně uloženo, tak vůbec nic nikomu nebrání jej odchytit po cestě (ten článek je z doby, kdy ještě vůbec nebylo obvyklé nasazení https). Takže jejich rozčílení nad tím, že někde unikla hesla v plaintextu je zcela zbytečné, protože to jejich jedno heslo už stejně mohli odchytit buď útočníci, nebo přímo provozovatelné některých webů. Tj jediné řešení ze strany uživatele je mít na každou službu jiné heslo.

Navíc je otázka (a to tam řeším taky), proč na každou krávovinu musím mít účet? Od té doby je to jen horší. Když přijdu na kdejaký web, hned mi to vnucuje účet a aby toho nebylo málo, tak přihlášení pomocí FB nebo Google. Já nechci účty, k ničemu je nepotřebuju. Nepotřebuju je ani při nákupech v eshopech, tak proč mi je vnucujete na webu, kde jsou jen články nebo slide? Nehledě na to, že kromě účtu mě to samozřejmě upozorní na cookies a seřve za to, že mám adblock. Web je prostě v super stavu.

[Bherzet]

Protože se mi nechce řešit komentářový spam.

Mně se strašně líbí ten antispam, co má Franta. Všiml jsem si toho před časem, když tu linkoval nějaký svůj článek. Nedalo mi to a zkusil jsem pár otázek postahovat; už si nepamatuji výsledek (nechtěl jsem mu DoSovat server, tak jsem sesbíral pár unikátních a killnul to), ale je jich docela dost a ještě by mě nepřekvapilo, kdyby tam byla nějaká rotace/poolování (např. že se každý den část otázek obmění).

Odpovídat na některé ty otázky automatizovaně by byl docela problém i s neomezeným přístupem ke Googlu nebo Wolframu. Pár příkladů:

• Kolik je jedna kopa a třetina tuctu? (číslovka)
• Cyklista jede do kopce rychlostí 10 km/h. Tentýž kopec sjede rychlostí 30 km/h. Jaká je jeho průměrná rychlost? (číslovka)
• Jaké písmeno se nachází na běžné klávesnici mezi J a L?

Kdyby někdo chtěl napsat spambota specificky pro jeho web, musel by sesbírat těch otázek co nejvíc a pak na ně odpovědět. Ale protože je to přecejen malý osobní web, kde se asi úplně nepředpokládá, že by z jedné IP adresy (nebo sousedních IPv6 adres) chodily stovky komentářů, tak tam možná budou implementované i další jednoduché ochrany. Ať už nějaký tvrdý limit na počet komentářů z jedné adresy, a nebo třeba použití úplně nové sady otázek…

Celkově mi to pro osobní blog přijde jako skvělé řešení. Občas investuješ trochu času do přípravy otázek (nemusíš to ani dělat celé najednou) a systém je lepší a lepší. Předpokládám, že generický spambot tím nemá šanci prolézt a kdyby se někdo snažil škodit mu záměrně, tak by do toho musel investovat úplně absurdně moc času, pokochal by se pohledem, jak mu to tam zaspamoval, a docílil by maximálně tak toho, že se zabanuje pár adres, nebo se prostě nasadí nějaké ještě účinnější řešení. Zatím ale stačí tohle.

Fakt se mi to líbí.

[JiK]

to ovsem uz neni detektor toho, zda to neni robot, ale detektor toho, zda to neni debil.

[Bherzet]

Předpokládám, že to je feature, not a bug. Ale na webech, které upřednostňují kvantitu před kvalitou (komentáře na YouTube, …), by to samozřejmě bylo na škodu.

Do budoucna tohle bohužel asi skončí nějakým „credit score“, kdy se bude dělat predikce podle nějaké sady faktorů. Ostatně se to částečně děje už teď. Čím podezřelejší návštěvník, tím těžší captcha. Potíž je v tom, že pro lidi je to už občas na hranici řešitelnosti. Např. reCAPTCHA na tu nejtěžší úroveň dokáže zabrat několik minut. Za chvíli už to nepůjde zesložiťovat, protože na jakoukoliv masově používanou generickou captchu půjde natrénovat solver. Obávám se, že to nebude trvat moc dlouho a všechno to bude už jen o nějaké historii účtu u pár nadnárodních korporací, nebo elektronické občance. To druhé zmíněné by snad nakonec možná ještě bylo nejlepší, kdyby to byl jen nějaký klíč, kterým se dá vygenerovat omezený počet nových identit, ale nedají se spárovat (čehož netuším, jak docílit).

[Jendа]

Obávám se, že to nebude trvat moc dlouho a všechno to bude už jen o nějaké historii účtu u pár nadnárodních korporací, nebo elektronické občance.

Co třeba muset pro odeslání komentáře dát třeba 5 Kč na jeden měsíc do úschovy, pro založení účtu 100 Kč na půl roku atd.? V Ethereu, možná i Bitcoinu, by to šlo snadno naprogramovat. Akorát se to bude blbě provozovat na skutečně globálních webech, protože jsou země, kde je cokoli moc.

[Bherzet]

O tom jsme se kdysi bavili, no. Teoreticky je to velmi pěkné řešení, prakticky to je horší. Jednak jsou kryptoměny zatím málo rozšířené než aby to šlo opravdu nasadit, jednak aby to k něčemu bylo, tak tu cenu musíš upravovat tržně – musí být alespoň tak vysoká, aby pokryla náklady na mazání spamu, a tak vysoká, aby se to spammerům nevyplatilo. Což může být oříšek, protože založení nového účtu je otázka pouze peněz a nic než peněz. Tzn. asi bys mohl postavit systém, do kterého nasypeš určitý objem peněz, a potom je to teorie her. Zkoušíš upravovat strategie tak dlouho, dokud nedosáhneš dostatečně nízké míry banování. Mezitím z druhé strany provozovatelé čelí spamu zálohám navzdory, tak je zvyšují, čímž ale klesá množství lidí ochotných to zaplatit – částečně spammerů, částečně ovšem i legitimních uživatelů. Zatím se do generátorů obtížně odhalitelného spamu moc neinvestuje právě proto, že to není potřeba.

Trochu komplikovaná může být i právní stránka věci. Tvůj komentář bude označen za spam, peníze ti propadnou. Můžeš to reklamovat? Za co ty peníze byly? Za právo poslat komentář, ale bez práva na jeho zveřejnění? Jak bychom se tvářili, kdyby to uplatňoval třeba Facebook? Na člověka s nepohodlnými názory naběhne armáda „elfů“, kteří mu nareportují pár příspěvků. O účet přijde a záloha propadne ve prospěch Facebooku.

Scammování je další varianta. Uděláš si web, který provokuje k reakci, ale každý druhý komentář smažeš. Na to má provozovatel samozřejmě právo, protože on svou část závazku splnil – umožnil ti poslat komentář. Zveřejnit ho nemusí, z důvodů se zpovídat taky nikomu nemusí, a zálohu si může nechat. Co to ale znamená na druhé straně barikády? Že lidé budou ještě daleko méně ochotní posílat komentáře na malé neznámé weby. Velké „renomované“ firmy zase budou ve výhodě.

A potom samozřejmě to, co píšeš. Co jsou pro jednoho drobné jsou pro druhého peníze na jídlo na příští týden. Pokud bys chtěl ceny nastavovat dle lokality, musel bys i ten obsah omezovat jen na danou lokalitu. V opačném případě by to nemělo valný smysl a spammer by samozřejmě šel po nejnižší ceně.

Vymyslet univerzálně použitelné řešení je fakt velký problém. Ta elektronická občanka by „fungovat“ mohla. Mohl by sis někde v obchoďáku koupit „los“, který si přineseš domů a setřeš si soukromý klíč, kterým pak budeš na důkaz „člověkosti“ podepisovat nějaká tajemství. Problémy jsou dva. Jednak musí existovat nějaká centrální autorita, která tiskne a prodává ty losy. No a za další musíš spoléhat na to, že ti při kupování „losu“ někdo nějaké nepodstrčí. Pokud by se to používalo opravdu jen jako důkaz toho, že jsi člověk, ale nic dalšího, tak by nebylo možné se za tebe vydávat – přihlášení na tvůj účet by pořád vyžadovalo heslo. No a kdyby si někdo založil se stejným klíčem účet třeba na jiné službě, tak co – nepoužívalo by se to jako důkaz identity, ale jen jako důkaz toho, že jsi člověk. Policie nebo tajná služba by ale byla schopná díky znalosti toho klíče sledovat, jaké služby používáš, a tvé účty odhalit. Je to feature, nebo bug? Na jednu stranu policie musí být schopna nějak fungovat. Na druhou stranu tohle může být při byť jen mírném otřesu politické svobody hůl na uživatele sociálních služeb s nepohodlnými názory, zatímco skutečně nebezpeční lidé můžou dál volně komunikovat na dark netu a nějaká „elektronická občanka“ je vůbec nemusí zajímat.

Nějaké lepší nápady?

[Jendа]

Minimálně půlka toho příspěvku je naprosté nepochopení. Ta záloha se ti vrátí za danou dobu nezávisle na čemkoli. Provozovatel webu s ní vůbec nemůže manipulovat.

Tzn. asi bys mohl postavit systém, do kterého nasypeš určitý objem peněz, a potom je to teorie her. Zkoušíš upravovat strategie tak dlouho, dokud nedosáhneš dostatečně nízké míry banování.

Tak celé to předpokládá, že spamerskou aktivitu dokážeme odhalit, jinak je to xkcd 810.

los

Tohle nechápu. Co mi brání koupit si 65535 losů a nacpat sem 65535 spamů? Jestli cena losu, tak to má nevýhody mého řešení a navíc ještě tu nevýhodu, že cena losu propadne, a celé to má režii. A žádnou policii a reálnou identitu do toho tahat nechceme.

[Bherzet]

Ta záloha se ti vrátí za danou dobu nezávisle na čemkoli. Provozovatel webu s ní vůbec nemůže manipulovat.

Aha. No, ale pokud ta záloha nemůže propadnout, tak k čemu vlastně je? Budeš jen pořád dokola reinvestovat ty vracející se zálohy. Samozřejmě by to spammerům život znepříjemnilo a museli by mít potenciálně dost velký finanční polštář, ale stačilo by to?

Co mi brání koupit si 65535 losů a nacpat sem 65535 spamů? Jestli cena losu, tak to má nevýhody mého řešení a navíc ještě tu nevýhodu, že cena losu propadne, a celé to má režii.

Ano, tím regulačním faktorem samozřejmě je cena losu. Stačí ti ale jeden jediný los na neomezené množství služeb, takže je to levnější. Ale to si teď říkám, že je vlastně asi taky problém, protože spammer si koupí 1000 losů a když je všechny vystřílí (nechá zabanovat) na jednom webu, tak pořád může škodit o doménu dál. A nic to neřeší, protože ten objem použitelných webů bude tak obrovský, že žádná cena, která je rozumná pro běžnou populaci, pro ně nebude dost vysoká. Achjo.

[Jendа]

Aha. No, ale pokud ta záloha nemůže propadnout, tak k čemu vlastně je? Budeš jen pořád dokola reinvestovat ty vracející se zálohy.

Záloha je k tomu, že když do toho vrazíš 18 kKč (což IMHO běžný troll nebude chtít pro své pobavení dát, i když ví, že když trollit přestane, tak se mu to postupně zase vrátí), tak si budeš moct zakládat jeden účet denně, který ti Kolibáč vždycky po prvním hate komentáři jedním kliknutím smaže. Nemůže se ti stát další petrfm nebo gretobot.

[Bherzet]

Rozumím. Na tyto případy by to samozřejmě stačilo, ale tam nakonec stačí i to Frantovo řešení. U větších služeb se to začne různě komplikovat…

No, zas je ale na druhou stranu pravda, že i ti profesionální spammeři asi stěží mají z Abclinuxu příjmy takové, aby se jim vyplatilo mít dlouhodobě v úschově 18 000 Kč jen zde (a znovu a znovu na dalších webech). To je asi možné ty peníze investovat lépe. A na praní špinavých peněz by se to asi taky zas tak moc nehodilo, když ti to prostě přijde zpátky na účet/peněženku, ze které jsi to zaplatil.

[Bherzet]

ale tam nakonec stačí i to Frantovo řešení

Ne, nestačí samozřejmě, míchám páté přes deváté. To stačí na automatický spam, ne na někoho, kdo to bude chodit posílat ručně, den co den. Tam by ta vratná záloha skutečně byla nejlepší ze všech zde zatím nabízených řešení.

[Bherzet]

Kdysi jsem si pohrával s myšlenkou vyžadovat vyřešení nějakého výpočetně náročného challenge. Základní problém s proof-of-work je ovšem úplně zbytečné plýtvání s elektřinou. U mobilních zařízení to je problém i ryze praktický. Co by se na desktopu vyřešilo za minutu, to mobil bude louskat podstatně delší dobu a ještě mu to pořádně vyždímá baterku. Čím víc náročnost snížíš, tím víc to ale zase usnadňuješ spammerům, kteří můžou mít farmy rozmístěné různě po světě, úlohy louskat tam, kde je zrovna nejlevnější elektřina (nebo kde má botnet online ovečky, takže nakonec to zaplatí BFU se zavirovanými počítači), a je to prostě celé na hovno. Mám pocit, že něco podobného dělá Cloudfare (nebo podobná firma), protože občas načtení stránky trvá několik vteřin a něco to prý ověřuje, ale tam je to jako ochrana před DDoSem. DDoS přecejen stojí na předpokladu, že requesty jsou velmi levné, takže tam to smysl dávat může. U komentářů se obávám, že asi spíš nikoliv.

[xkucf03]

Do budoucna tohle bohužel asi skončí nějakým „credit score“, kdy se bude dělat predikce podle nějaké sady faktorů.

V tom nevidím až takovou tragédii, spíš naopak. Za důležité považuji, aby to nebylo napojené na tvoji fyzickou identitu a osobní údaje. Jinak s tím ale nemám problém – moje vize je taková, že si vygeneruješ pár soukromého a veřejného klíče (nezávisle, bez jakékoli CA) a na ně budeš sbírat kredit, budovat si reputaci. To už úplně decentralizovat nejde (možná přes kryptoměny), ale to až tak nevadí – těch stran, u kterých si tu reputaci budeš budovat by bylo víc a záleželo by na ostatních, kterým budou věřit a jakou váhu jim budou přikládat.

Když tím klíčem budeš podepisovat všechny komentáře a e-maily, tak půjde prokázat a rozsoudit, jestli jsi spammer nebo ne – nemůže o tobě někdo začít tvrdit, že jsi spammer, když žádný tebou podepsaný spam nebude existovat (což třeba v případě e-mailových blacklistů neplatí).

Pokud se zdiskredituješ tím, že budeš někde spamovat, tak tím riskuješ reputaci, kterou sis do té doby budoval. Někdo sice může vybudovat reputaci a pak ten pár klíčů prodat spammerovi, ale to bude na jedno použití, takže se to nevyplatí.

Nemusí to sloužit jen jako anti-spam. Když někam pošleš komentář, tak ostatní tomu mohou dávat větší váhu, když uvidí, že za tebou je nějaká práce – např. tam můžeš mít reputaci za příspěvky ke svobodnému softwaru, za dobře hodnocené články atd.

Dnešní stav e-mailu je naprosto tragický a velké korporace (Google, Microsoft…) tuto technologii už prakticky zničily. Dneska pošleš e-mail a je to sázka do loterie, zda skončí ve spamu nebo dokonce nepozorovaně mizí. Vypadá to, že tito velcí poskytovatelé dokonce určité procento e-mailů od nezávislých poštovních serverů prostě zahazují. Pak nevíš, jestli ti adresát neodpovídá nebo se k němu tvoje zpráva vůbec nedostala. Adresátovi to zase dává prostor se vymlouvat – i když si vyžádáš a dostaneš doručenku, že zpráva byla přijata poštovním serverem příjemce, on se stále může vymlouvat, že to nečetl a že to „asi spadlo do spamu“, protože tohle je bohužel běžná praxe – padají tam často i legitimní e-maily.

Když jsem ještě dělal pošťáka na škole, tak jsme měli zásadu, že jakmile tvůj server přijme e-mail (odpoví po SMTP, že ho zařadil do fronty), tak za něj přebíráš odpovědnost a nesmíš ho jen tak ztratit nebo zahodit. Pokud něco považuješ za spam, tak to máš odmítnout ještě v rámci SMTP relace, takže se o tom odesílatel dozví (a může adresátovi místo toho třeba zatelefonovat). Pokud usoudíš, že jde o spam, až po tom, co jsi druhé straně řekl, že zprávu přijímáš a řadíš do fronty pod určitým ID, tak to máš jen označit jako spam pomocí MIME hlavičky a je na příjemci, aby si třeba nastavil Sieve filtry pro třídění takových podezřelých zpráv. Případně v tom můžeš dodatečně najít viry nebo třeba nějaké podvodné odkazy a zařadit to do karantény, ale pak to vždy musí někdo dořešit – neexistuje, aby se ta zpráva jen tak ztratila. Těch pár velkých korporací se tě snaží donutit k tomu, abys měl účet u některé z nich (což zcela zabíjí decentralizovanou/federalizovanou povahu této technologie), jinak je e-mail nespolehlivý a nepoužitelný pro cokoli seriózního. S tímhle se nehodlám smířit – asi je pomalu na čase dát tyto poskytovatele na blacklist, přestat s nimi zcela komunikovat, všem doporučit, aby se jich zbavili – a do té doby těm lidem asi radši telefonovat nebo komunikovat nějak jinak než e-mailem.

Přitom by to mohlo fungovat jinak a aniž bychom se museli prohrabávat hromadami spamu. Současně s tím by měl fungovat i nějaký systém záloh. Často jsem v situaci, kdy bych klidně složil zálohu, abych měl jistotu, že druhá strana moji zprávu dostane. Pokud příjemce usoudí, že jde o spam, záloha připadne jemu, pokud ji označí jako legitimní nebo neudělá nic, tak se záloha vrátí mně. Sice to vytváří prostor pro podvody – někdo by mohl vyvolat zájem, aby mu lidi psali, a pak všechny jejich e-maily odznačovat jako spamy a inkasovat zálohy, ale to by se rychle provalilo a reálně by na tom moc nevydělal.

Ty zálohy by mohly být povinné jen při nějaké nízké reputaci – pro nově založené identity, potenciální spammery.

Taky se na to dá dívat tak, že tou propadlou zálohou platíš za čas druhé strany, za to, že věnuje pozornost tvému sdělení. Tím to vlastně přestává být spam a stává se z toho normální obchod. Pokud mám pocit, že mám pro někoho zajímavou nabídku, tak mu ji můžu poslat a zaplatit mu za čas, který stráví jejím zvážením. Zbyteční lidé, kteří nabízejí odpad a ostatní akorát otravují, by na tomhle skončili. Naopak v případě relevantních nabídek a užitečného zboží a služeb by to pomohlo tomu, aby informace lépe proudily a aby se zákazník a dodavatel na trhu lépe našli. Mohl bych mít na webu např. adresu, u které řeknu: pokud dáte zálohu 10 Kč, tak si přečtu předmět, pokud dáte zálohu 50 Kč, tak se podívám i dovnitř e-mailu. A když si někdo věří, že má pro mne zajímavou nabídku, tak mi může napsat. Pokud zpráv bude chodit moc nebo málo, tak ty částky upravím. Tím by se mělo dosáhnout rovnováhy, kdy člověk netráví zbytečně čas čtením nesmyslů a zároveň dostane zajímavé informace.

Totéž by mohlo fungovat u technické podpory. Jsou lidi, kteří otravují s nesmysly a kteří si mohli odpověď přečíst někde v dokumentaci, ve FAQ nebo použít zdravý rozum a přijít na to sami. Ti akorát přetěžují podporu a plýtvají kapacitami, které se mohly věnovat ostatním. A pak jsou lidi, kteří narazili na nějaký závažnější problém, třeba našli chybu v systému, dali si práci s jejím popisem a otestováním, nebo prostě víc spěchají a potřebují to vyřešit rychle – ti by mohli zase složit zálohu a tím se ve frontě posunout dopředu. Kdyby se pak ukázalo, že tomu dali vyšší prioritu neoprávněně a jen otravují s nějakou banalitou, tak by jejich záloha propadla, v opačném případě by se jim vrátila. Tohle je opět založené na praktické zkušenosti – kolikrát se mi už stalo, že jsem plýtval čas na „diskusi“ s nějakou AI nebo nějakým nekvalifikovaným dementem, a pak jsem se na to buď vykašlal (dneska už takové věci předvídám a interakci někdy ani nezačnu, protože vím, že to nemá smysl) nebo jsem se nakonec k někomu kompetentnímu dostal, ale řešení trvalo zbytečně dlouho ke škodě všech zúčastněných. Jsou tedy opět případy, kdy si věřím, že řeším něco významného, a kde bych klidně složil tu zálohu – zároveň bych věřil, že druhá strana uzná, že to skutečně významné bylo, a zálohu mi vrátí.

Často by to asi mohlo fungovat jen na základě důvěry a toho, že člověk případnou ztrátu té malé zálohy riskne. Časem by třeba vznikl systém na sledování reputace těch, kdo ty zálohy přijímají a rozhodují o jejich vrácení nebo propadnutí.

Pak je tu možnost, že bychom vyžadovali, aby druhá stran místo složení zálohy propálila nějaký výpočetní výkon např. počítáním nějakých hashů. Tu náročnost by šlo dynamicky upravovat podle potřeb. Ale tady je problém v tom, že ten výpočetní výkon lze snadno převést na peníze resp. lze si ho za peníze koupit. Takže je to ekvivalentní záloze, která automaticky propadne – a pokud tato záloha bude příliš nízká, tak nás spammeři budou otravovat, protože se jim to vyplatí. A když najdeme vhodnou výpočetní náročnost na to, aby spammeři otravovat přestali, tak ale nutíme všechny legitimní odesílatele k tomu, aby propálili netriviální výpočetní výkon jen tak (zatímco zálohu ve stejné výši by složili a následně dostali zpět, takže by k žádné ztrátě a plýtvání nedocházelo).

V čem vidím možná úskalí:

• Kdo a proč takový systém vytvoří a bude provozovat? Jaká bude jeho motivace a odměna?
• Technologie: asymetrická kryptografie je dobře použitelná. Mám ale trochu pochybnosti o kryptoměnách: jak si poradí s velkým množstvím malých transakcí a jaké budou transakční náklady resp. náklady na provoz toho platebního systému?
• Jak to vysvětlit uživatelům, aby to pochopili a chtěli používat? Tzn. systém musí být odolný a propracovaný, ale zároveň jednoduchý a pochopitelný (na tohle narážíme i u šifrování – ať už GPG nebo X.509 – lidi často nechápou, jak funguje řetězec nebo pavučina důvěry, nejsou ochotní investovat ani minimum času, aby to pochopili, a následně nejsou schopní ten systém používat – i když ho používají, tak chybně, takže je to spíš kontraproduktivní).

[Bherzet]

Jinak s tím ale nemám problém – moje vize je taková, že si vygeneruješ pár soukromého a veřejného klíče (nezávisle, bez jakékoli CA) a na ně budeš sbírat kredit, budovat si reputaci.

Ono to tak do jisté míry ostatně už funguje, akorát se místo klíčů používají účty, které jsou případně nějak „prolinkované“ dohromady. Je to technicky méně čisté, ale princip je to v podstatě stejný. Takhle potom fungují různé invite-only komunity jako např. Lobsters – pozveš někoho, koho znáš odjinud. Přinejmenším pro menší komunity to je v současnosti velmi dobrý systém.

Zásadní problém je v tom, že to v podstatě celé stojí na předpokladu, že existují „bezbariérové“ komunity, které ti umožní si tu reputaci začít pěstovat. Pokud všichni budou vyžadovat nějakou reputaci, prakticky to zamezí příchodu úplně nových členů. Aby to fungovalo, tak musí existovat pár „dobrodinců“ s vysokou reputací, kteří budou ochotní se čas od času pobavit s někým, kdo třeba reputaci nemá žádnou, a dát mu šanci vyšplhat nahoru.

No a jsme zase zpátky u toho, že na tenhle „vstupní bod“, na tohle slabé místo, se zaměří různí spammeři, scammeři a další havěť a budou otravovat tak dlouho, až nakonec i tahle varianta padne a bude se muset hledat zase něco jiného.

Obávám se, že není možné vytvořit systém, který by byl při globálním použití dlouhodobě stabilní. Je to věc, která bude vyžadovat asi neustálé iterace a přizpůsobování okolnostem.

Bylo by smutné, kdyby to nakonec vedlo na vznik nějakého kastovního systému, kde jediný způsob, jak získat nějakou reputaci, by byl přenosem z rodičů na potomka, nebo v raném dětství na nějakých kroužcích atd. Nejde jen o to, že by ta reputace nemusela jít už výrazně zvyšovat, ale taky o to, že by byla vázaná jen do určitých zájmových skupin. Existence „sociálních bublin“ je docela problematický jev už v současnosti a přijde mi, že se to bude jen zhoršovat.

Každopádně když jsem psal o těch predikcích podle sady faktorů, tak jsem myslel spíš to, že Obří Korporace nahlédne do databáze a pokusí se odhadnout, co jsi asi zač. Zatím se tak děje podle relativně měkkých kritérií a v podstatě pokud nepoužíváš nějakou podezřelou IP adresu, ze které chodí nějaké automatizované requesty apod., tak jsi v pohodě. Taky by to ale mohlo skončit tak, že se budou dívat na to, jaké máš předplacené služby, jak dlouho, jestli tam existuje nějaká vazba na příbuzné, atd. No a lidi jsou dost blbí, aby jim to zprvu nevadilo, i do 3rd party webů nacpali různá ověřovátka a přihlašovátka přes tyhle korporace, protože přece „it just works“ a je to skvělé a moderní a výsledkem bude totálně rozmrdaný nesvobodný Internet. Toho se bojím nejvíc a přijde mi, že to k tomu směřuje.

Dnešní stav e-mailu je naprosto tragický a velké korporace (Google, Microsoft…) tuto technologii už prakticky zničily. Dneska pošleš e-mail a je to sázka do loterie, zda skončí ve spamu nebo dokonce nepozorovaně mizí. Vypadá to, že tito velcí poskytovatelé dokonce určité procento e-mailů od nezávislých poštovních serverů prostě zahazují.

Ano, tohle je naprosto odporné. Na Lobsterech na toto téma kdysi probíhala diskuze a někdo tam navrhoval vznik aliance provozovatelů nezávislých mail serverů s tím, že pokud tyhle zmrdské korporace budou někoho blokovat, tak aliance by odpověděla odvetou a blokovala je taky.

Kromě antimonopolních zákonů by to bylo asi jediné možné řešení, ale asi by nebylo úplně jednoduché to nějak zorganizovat a takovou alianci vytvořit. Těch incidentů, kdy se někde ztratí e-mail, bude vznikat docela dost a bude obtížné každý z nich pečlivě posoudit.

Když jsem ještě dělal „pošťáka“ na škole, tak jsme měli zásadu, že jakmile tvůj server přijme e-mail (odpoví po SMTP, že ho zařadil do fronty), tak za něj přebíráš odpovědnost a nesmíš ho jen tak ztratit nebo zahodit. Pokud něco považuješ za spam, tak to máš odmítnout ještě v rámci SMTP relace, takže se o tom odesílatel dozví (a může adresátovi místo toho třeba zatelefonovat).

Pěkné.

Tím to vlastně přestává být spam a stává se z toho normální obchod. Pokud mám pocit, že mám pro někoho zajímavou nabídku, tak mu ji můžu poslat a zaplatit mu za čas, který stráví jejím zvážením.

Přesně tak. U e-mailu jsem se také zamýšlel nad „platbou za doručení“ a myslím si, že by to mohlo fungovat. V praxi by bylo nejjednodušší jít na to přes ty náhodně generované adresy/aliasy. Pokud někomu dáváš kontakt nebo se někam registruješ, vygeneruješ si novou adresu. Pokud jsi CEO velké firmy a nechceš, aby tě otravovali lidé s nesmysly, uděláš si nějakou platební bránu, kde se po zaplacení vygeneruje adresa automaticky.

Integrovat to přímo do e-mailu přes kryptoměny by bylo technicky možná hezčí (a hlavně by to mělo výhodu, že by ty peníze šlo případně vracet), ale jinak asi stačí tohle.

[xkucf03]

Přílohy:

• mixxx-discourse-01.png (205531 bytů)
• mixxx-discourse-02.png (200701 bytů)

Ano, tohle je naprosto odporné. Na Lobsterech na toto téma kdysi probíhala diskuze a někdo tam navrhoval vznik aliance provozovatelů nezávislých mail serverů s tím, že pokud tyhle zmrdské korporace budou někoho blokovat, tak aliance by odpověděla odvetou a blokovala je taky.

Někdy mám pocit, že tohle se děje i na webu, ale možná je to jen moje paranoia… Např. na Redditu nebo zrovna dneska na Discourse fóru programu Mixxx. Zřejmě to zablokoval nějaký automatický systém (někdo už to ručně opravil). Možná kdyby to byl odkaz na Facebook nebo na Twitter, tak by se to nestalo. Ale vážně chceme takový internet, kde se dají posílat odkazy nebo e-maily jen, když ses upsal některému z těch pár velkých poskytovatelů a svěřil jim svoje data?

[Bherzet]

Jo, to se děje. Většinou se asi blokuje porno, ale nejenom. Našel jsem teď /r/BannedDomains, problémy s novou doménou na Facebooku tady a tady, u starších domén to řeší tady atd. Internet jde do sraček. Mělo by se s tím něco udělat.

[Fluttershy, yay!]

Facebook je komerční platforma pro propagaci obsahu. Neplatíš, nepropaguješ. Kapi^tališto?

[Bherzet]

Samozřejmě, že to chápu. Však jsem taky všechny důležité kontakty naučil používat něco jiného. Můj účet na FB je ve stavu klinické smrti. Už roky tam nekonzumuji obsah z News Feedu (pár zajímavých účtů mám v záložkách a jednou za čas je projdu ručně; jestli někdo umíte export do RSS nebo znáte nějaké dobré API/knihovnu, tak budu moc rád za tipy), účet mám registrovaný pod unikátním e-mailem, který nepoužívám vůbec nikde jinde, atd.

Facebook považuji za hrozbu v několika rovinách a snažím se jim do toho co nejvíc házet vidle.

[Petr Fiedler]

účet mám registrovaný pod unikátním e-mailem, který nepoužívám vůbec nikde jinde, atd.

Viděl jsi dokument Temné stránky Facebooku aneb něco za něco?

Facebook považuji za hrozbu v několika rovinách ...

V jakých?

A od Anonymous: Pravda o Facebooku - jak ničí společnost.

[Bherzet]

Viděl jsi dokument Temné stránky Facebooku aneb něco za něco?

Neviděl.

V jakých?

Odehrává se tam obrovská část veřejných diskuzí. Cenzura může hravě změnit výsledek voleb. Pokud se navíc nebavíme rovnou o mazání příspěvků a banování uživatelů, tak ta cenzura ani nemusí být vidět a vzbudit podezření. Stačí někomu snížit dosah příspěvků, čili dávat jim menší váhu v doporučovacích algoritmech. Někoho jiného naopak můžou upřednostňovat, což je taky cenzura a má to úplně stejné důsledky.

Boj s dezinformacemi je další kapitola. Když hořela Notre-Dame, na Facebooku začala kolovat fotka dvou muslimsky vypadajících mladíků, jak tam stojí a smějí se. Fact-checkingová agentura napsala rozsáhlé pojednání o tom, jak je ta fotka strašný fake. Když později jeden z těch mladíků dal rozhovor do médií, kde vysvětlil, že na místě opravdu byli a někdo je vyfotil zrovna ve chvíli, kdy se tam zamotali do bezpečnostní pásky a zasmáli se, tak fact-checkingová agentura článek zaktualizovala, že fake to teda není, ale na svém stanovisku nic nemění. Na Facebooku se u té fotky od té doby zobrazuje varování, že je to dezinformace – což je dezinformace, protože se jedná o reálnou fotku. Najednou už nejde o to, že by ta fotka byla nepravdivá, ale že dělá špatný dojem a někteří pitomci by si z ní mohli dělat nesmyslné závěry. V tom je potřeba jim zabránit za každou cenu – třeba jim i lhát. To určitě nenapáchá škody ještě větší a horší…

Centralizace je potom problém hned v několika rovinách. Od větších důsledků případného technického výpadku až po to, že je to jedno místo, na které může tlačit vláda. Lidé nenavyklí na jiné komunikační prostředky můžou mít problém se pak rychle zorganizovat. A v praxi se to navíc děje spíš salámovou metodou, ta svoboda se ukrajuje kousek po kousku, a lidi si nějak zvykají a zvykají. Na YouTube si skoro nikdo netroufne se o kovidu zmínit jinak než „však víte, jaká je teď situace ve světě“. Tak vehementně se bojuje s dezinformacemi, že nakonec spoustu těch legitimních kanálů se na to raději vysere než aby jim z jedné strany chodily výhružky od diváků, kterým se jejich názory nelíbí, a z druhé strany je penalizoval YouTube za špatné téma. Takže nejvíc obsahu je pak logicky od lidí, kteří už jsou zvyklí pohybovat se někde na okraji, mají svoje publikum atd.

No a v neposlední řadě ty sociální sítě a potažmo celý moderní web vedou k totální degeneraci. Lidé celé dny čumí na profesionálně naaranžované fotky z nejkrásnějších koutů planety, profily influencerek, ze kterých to vypadá, že celé dny tráví vysedáváním nad kávičkou a nakupováním, a pak mají deprese, protože i kdyby vedli sebezajímavější a sebenaplněnější život, nikdy nebudou schopni stihnout všechno. Není možné být na deseti místech současně.

[xkucf03]

+1

[Petr Fiedler]

Díky za odpověď.

V tom dokumentu třeba říkají, že i když si zrušíš FB účet a půjdeš na internet na zcela novém zařízení a nebudeš na FB přihlášen, tak tě algoritmy FB stejně po čase identifikují podlé tvého chování na internetu. To je šílené. Možná by tě ten dokument neoslovil tak jako mě, protože dané problematice rozumíš více, ale i tak ti jej doporučuji shlédnout.

U těch Anonymous nevím. Do včera jsem o nich moc nevěděl. Když jsem ti odkázal to jejich video, tak jsem se pak na pár jejich videí podíval a nestačil jsem se divit. Považoval jsem je za úplně jiné lidi. Určitě jsou rozdíly i mezi nimi samotnými, ale teď mi spíše přijdou jako konspirátoři.

[Bherzet]

V tom dokumentu třeba říkají, že i když si zrušíš FB účet a půjdeš na internet na zcela novém zařízení a nebudeš na FB přihlášen, tak tě algoritmy FB stejně po čase identifikují podlé tvého chování na internetu. To je šílené.

Facebook sbírá obrovské množství dat pomocí sdílecích, lajkovacích a přihlašovacích tlačítek, které si lidi cpou do webů. Když je to jen ikona hostovaná přímo na tom webu a odkaz, který se aktivuje až po kliknutí, tak to ničemu nevadí. Pokud tam ale někde vidíš živý počet lajků, je to s velkou pravděpodobností kvůli tomu, že je to do stránky vložené ve stylu <iframe src="https://www.facebook.com/..." . A tam už to vadí, protože z prohlížeče každého návštěvníka, ať používá Facebook nebo ne, budou chodit požadavky přímo na Facebook. Ten pak u každého takového požadavku vidí, z jaké jde IP adresy, vidí kompletní identifikace prohlížeče, která je dnes do nějaké míry unikátní atd. (viz třeba anonymity checker na Security-Portalu).

Další data získají v okamžiku, kdy jim nějaký dement dá přístup ke svojí e-mailové schránce a nahraje k nim všechny svoje kontakty. Díky tomu zjistí, že se třeba Alice bavila s nějakým Bobem s adresou bob@example.com. Bob Facebook vůbec nemusí používat, ale Facebook už o něm ví, že se kamarádí s Alicí. To je jedna bezvýznamná hrana obrovského a neuvěřitelně komplexního grafu. Teď si ale představ, jak se ty jednotlivé uzly tohoto grafu začnou propojovat ve chvíli, kdy to neudělá jedna Alice, ale dalších 30 lidí. A ti budou na Facebook nahrávat společné fotky s Bobem, označovat ho tam, aby to AI pro detekci ksichtů měla ještě jednodušší, budou se o něm bavit na chatu apod.

Najednou už to není o jedné bezvýznamné e-mailové adrese, ale někde hluboko v datacentru ve chřtánu Ksichtbooku vzniká kompletní identita. Vědí, že někde po světě běhá nějaký Bob, jaký má e-mail, jak vypadá a s kým se stýká. Do toho vstupuje nějaká další sociologie a pravděpodobnost. Asi půjde odhadnout jeho národnost, jeho věk (kdyby AI byla na pochybách), no a protože „vrána k vráně sedá“, tak nejspíš i jeho povolání, politickou orientaci a sociální postavení.

Přijde ti to jako scifi? Facebook to ale opravdu dělá – však si jen zadej do vyhledávače „facebook shadow profiles“.

A úplně stejně to může fungovat i opačným směrem. Svůj profil na Facebooku sice zrušíš, ale ono se to možná stane jen tak na oko a kdesi v hloubi toho potemnělého datacentra si ten profil bude žít vlastním životem dál. A protože o tobě mají těch dat tolik a celý web mají prošpikovaný miliony očí, zidentifikovat tě skutečně mohou.

Na Facebooku dodnes visí dva mé staré profily, o kterých jsem si poměrně silně jistý, že jsem je smazal. Ne deaktivoval, ale skutečně smazal – přes takový ten dobře zašitý odkaz. Oba ty profily byly na smyšlené a poměrně kryptické jméno a visí tam oba i s profilovým obrázkem. Že bych nějak zapomněl smazat jeden ještě nějak dokážu pochopit, ale dva? Já se Facebooku od začátku dost vehementně bránil, ale nakonec jsem na střední podlehl sociálnímu tlaku a fungovalo to u mě potom tak, že jsem měl vždycky jeden účet, ten jsem pak zrušil, založil další a takhle pořád dokola. Teorie byla taková, že po sobě aspoň zanechám menší stopu. No a taky jsem většinou mezi smazáním jednoho profilu a založením dalšího zkoušel, jestli už by se teda bez Facebooku fungovat dalo. Takže opravdu nechápu, proč to tam je…

Možná by tě ten dokument neoslovil tak jako mě, protože dané problematice rozumíš více, ale i tak ti jej doporučuji shlédnout.

Já toho mám ke zhlédnutí docela dost a zrovna na tyhle česky dabované dokumenty začínám už být nějak alergický. Nevím ani přesně proč, asi mi to přijde jako dlouhé monotónní povídání s často pochybnou informační hodnotou, divnými pseudoexperty atd. Kdo sleduje třeba Maxwellovi démony na YouTube a jeho sérii Televize nám lže, tak jistě rozumí.

U těch Anonymous nevím. Do včera jsem o nich moc nevěděl.

Já se o ně nezajímám vůbec. Za Anonymous se ostatně může prohlásit kdo chce, že.

[JiK]

existenci shadow profilu potvrzuji, pise se o ni z mnoha zdroju. To celkem komplexni sledovani funguje jeste lip, oni totiz hromady lidi maji i FB aplikaci na telefonu, a povoli ji kde co (nebo spis uplne vsechno) a pak je Bob s FB i bez nej je v riti, protoze se s nim ostatni FB alice stykaji (nejen) v kyberprostoru, ale i v realu, a nablble postuji jeho fotky, FB vi, kdy a komu zvedl/nezvedl telefon, kdy se s kym sesel v realu, kde se ktere dny/hodiny vyskytuje, staci, kdyz treba nektery clen jeho rodiny ma ten facebookuv fizlovaci messenger na telefonu...je to creepy...zajimalo by mne, jestli se tomu da nejak branit, treba prave vytvorenim 10 deseti skoro realnych Bobovych profilu...klasicke pravidlo maskovani rika, ze kdyz uz neco nemuzu schovat, tak to aspon zmnozim a preplnim cilovy prostor terci...fungovalo by to? Zabyva se tim nekdo? prijde mi, ze tohle by bylo zajimavejsi tema na security research nez obskurni metody odposlechu konverzace ve vzdalene mistnosti prostrednictvim teleskopu zamereneho na zdroj svetla, nebo 1B/s vysilani pomoci pameti...rozhodne by to byly realnejsi use case. Jak nejlepe zblbnout ruzna AI, od obfuskovani analyzy pohybu v kyberprostoru, po obfuskovani facial recognition, nebo analyzy kroku a kompletni sledovani jednotlivce...protoze to vede na svet jako z Black Mirror.

Mimochodem, jsem si jist, ze treba takovy google to dela take, jeste mnohem otevreneji, protoze data polohy, kontakty, emaily, hangouts, ma od kazdeho, kdo ma (nebo mel) android, nebo pouziva cokoli od googlu na smartphonu, nebo vola s nekym, kdo kdy neco takoveho pouziva...nebo pouzival.

V tom kontextu je celkem legracni, kdyz se nekteri jedinci boji cipovani, protoze proc by jim nejaky Evil Lord mel nastrelovat cipy, kdyz si je sami za nemale prachy koupi, updatuji je, plati jim konektivitu, kazdy vecer je dobijeji, nosi je vsude s sebou a staraji se o ne lip nez o vlastni deti, ktere zaparkuji pred monitorem a nechaji je debilizovat algoritmem youtube?

[Bherzet]

Příloha:

• ThisPersonDoesNotExist01.small.png (415483 bytů)

Ta obfuskace dat by byla problematická. Samozřejmě můžeš mlžit ohledně těch parametrů, které Facebook nezná s jistotou. Jednou budeš předstírat, že fandíš Losnovi, podruhé Mažňákovi. K čemu je to ale dobré? Když policie půjde po zloději v zelených ponožkách, nedává smysl začít lhát o tom, jestli doma chováš křečka nebo morče, ale buď zahodit zelené ponožky, nebo zařídit, že všichni kolem tebe budou mít zelené ponožky.

Když někdo nahraje na Facebook fotku s tebou, obuje tě do těch zelených ponožek. Obličej ale narozdíl od ponožek nejde snadno přezout, takže zbývá jen ta strategie cíleného vytváření šumu. Asi bys mohl zkusit generovat fotky obličejů (This Person Does Not Exist* znáte?), mixovat to do nějakých koláží, kde to bude vypadat, že spolu sedíte u stolu, a doufat, že ta jejich AI nebude schopná poznat, že je to podvrh. Což pokud je trénovaná na hledání obličejů a ne detekci fotomontáží, tak možná nebude. Ale zase s tím bojem proti dezinformacím a fake news… Těžko říct. No, předpokládejme, že by to u nějakého soukromého nepříliš podezřelého alba fungovalo. Tím vytvoříš mlhu, kdy sice Facebook bude mít k dispozici skutečnou fotku A s B, ale taky bude zaplaven falešnými fotkami A s C, D, E, …

Mohl bys jít ještě o úroveň dál a pomocí AI generovat nějaké variace svého obličeje s tím, že na každém profilu budeš používat trochu jinou. Tam by se sázelo na to, že rozpoznávání obličejů není 100% spolehlivé. Do budoucna se ale bude pouze zlepšovat a dříve nebo později tě stejně dokážou identifikovat správně. Rozpoznají tu jednu jedinou pravou fotku, kterou jsi zkoušel zamaskovat stovkami podvrhů, a rozpoznají možná i ty podvrhy. Můžeš je zdržet, ale ne zastavit.

Podle mě je nesmysl na to jít takovýmto individuálním odbojem, protože by to bylo jednak dost náročné a jednak pokud je v ohrožení tvoje vlastní soukromí, aniž bys ty sám aktivně něco udělal, je zjevně problém jinde. Existují v zásadě dvě možnosti:

1. Reálně začít kriminalizovat tvé kamarády a známé, kteří „zpronevěří“ tvé osobní údaje tím, že bez tvého souhlasu uploadují fotku, která zachycuje i tebe, do nějakého cloudu (= na počítače cizích lidí) apod.

2. Jít na to přes nějaké GDPR-like mechanismy a v podstatě říct, že když Pepíček vyfotí Aničku, tak i pokud k tomu měl její souhlas, Facebook by stejně potřeboval Aniččin přímý explicitní souhlas (tedy bez prostředníka), aby mohl údaje o ní začít nějak analyzovat a uchovávat. Dokud by se tedy Anička nezaregistrovala na Facebook a nevstoupila s ním do smluvního vztahu, Facebook by nesměl legálně např. zanalyzovat fotky Aničky s Pepíčkem a Aničky s Honzíkem a na základě toho usoudit, že Pepíček a Honzík se možná znají.

To druhé je dle mého názoru správná cesta. A samozřejmě rozšiřovat povědomí o tom, jaká je Facebook – a samozřejmě i další podobné služby! – rakovina. Není nutné hned lidi přesvědčovat, ať si smažou účty (ostatně ho tam mám taky). Ale na kauzy jako je Cambridge Analytica už lidi slyší a vysvětlit jim, proč by Facebooku měli svěřovat co nejméně dat, je podstatně snažší. Stejně tak se může dařit vysvětlit, proč si mají nainstalovat nějakou další bezpečnou komunikační aplikaci** a tu používat alespoň s lidmi, kteří Facebook používat nechtějí (tzn. nevyvíjet na někoho tlak, aby se kvůli nim zaregistroval na Facebook).

*) čas od času to vygeneruje strašně creepy věci, jakože po padesáti realistických obrázcích tam má někdo čtyři oči apod. Hodně často to dělá různé šílené artefakty okolo toho obličeje (viz příloha).

**) to mimochodem fakt nevím jakou. Ideální řešení by bylo decentralizované, end-to-end šifrované, mělo kvalitní mobilní aplikace pro Android a iOS a pro desktop minimálně webové rozhraní (ideálně samozřejmě i nativní aplikace).

V decentralizaci jasně vyhrává Jabber. Šifrování se tam dá taky našroubovat. Server-side historie a její synchronizace na klienty je ale AFAIK stále ve stádiu draftu a především to neumí hovory, obrázky apod. Je nesmysl snažit se masové veřejnosti prodat právě Jabber. Té technologii ujel vlak a UX existujících softwarových řešení bude působit zastaralým dojmem.

Pokud vezmu striktně bezpečnostní aspekty, nejvíce vychvalovaný bývá Signal. Není ale decentralizovaný a to UX je dost hrůza. Když zapnu ten electronový nesmysl na desktopu, tak se mi to každou chvíli rozpojí, musím znovu scannovat QR kód v mobilu, pak na desktopu přijdu o část historie zpráv (protože přece bezpečnost) atd. Celé to působí strašně nepříjemným dojmem a i ten argument o úžasné bezpečnosti je jaksi upozaděn ve světle toho, že je nutné účet vázat oproti telefonnímu číslu a mobilní aplikaci. Ještě navíc v českém kontextu, kde by bylo dobré taky veřejnost zmobilizovat třeba k nějakému odporu vůči mobilním operátorům…

No, takže nejlepší je asi Telegram. Je to o něco lepší než Facebook, ale o žádném skutečném soukromí prostě nemůže být řeč. Není to end-to-end šifrované a s telefonním účtem je to svázané taky. To UX je ale opravdu naprosto špičkové, je to bezkonkurenčně nejlepší IM, co jsem kdy používal, a to jak na mobilu, tak v nativní desktopové aplikaci. Dobře se v tom posílají fotky, videa, realizují hovory, vedou skupinové chaty. Umí to odpovídat na jednotlivé zprávy, takže i komplexnější konverzace jsou přehledné. Zprávy lze editovat a opravovat si překlepy, nebo i mazat. Konverzace je možné snadno exportovat vč. veškerých příloh. Umí to hlasové zprávy, což je sice náročné potom na straně posluchače („no, já jsem v práci přemýšlela …“, sklouznutí k rozečtenému článku/programování, „moment, o čem, že to mluvila?“, rewind zpátky, takhle ještě dvakrát, OK, odložení činnosti, vyslechnutí zprávy a dalších 5, které mezitím přišly, sepsání odpovědi), ale holkám se to líbí.

Ideální by bylo vzít tohle, udělat to decentralizované jako Jabber, ale mít veřejné servery pro BFU (kdo chce, rozběhá si vlastní), pořešit šifrování a zbavit se závislosti na telefonním číslu. Kdybych měl být ještě o kousek náročnější, tak bych ocenil lepší ovládání klávesnicí na desktopu.

Někdo tu před časem zmiňoval Delta Chat postavený nad klasickým e-mailem, což je docela zajímavý nápad, ale ještě jsem se nedostal k tomu to vyzkoušet.

[xkucf03]

Psal jsem teď do jednoho uzavřeného fóra, tak ať je to i někde veřejně:

I say it all the time: centralized social networks like Twitter, Facebook etc. are evil and people using them or even depending on them are making a big mistake and calling for trouble. Even if such corporation is not evil in particular phase of its development, that centralized power is a too tempting target and there is high risk that evil people will take over such corporation and misuse that power.

But it does not mean that private property and contracts should not be respected. They should be. And you should think twice, what contract you will sign and in which relationship you will participate and who you will depend on.

What happened to Donald Trump, should be a big warning for every user of such social network. They are so powerful because we – the users – give them the power, because we use them (or better said: are used by them). Why should you give the power to someone, who will eventually silence, censor or manipulate you? This recent and publicly known experience is a great argument to tell people and discourage them from giving the power to someone who will eventually betray.

Maybe you do not like Donald Trump, maybe you think that you are completely different and that it will not be your case. But this could happen to anybody.

Pubs, squares, cafés, saunas, clubs etc. where people meet and discuss all over the world are not controlled by a central authority (or few of them). But internet social networks are. This is just a wrong way. Nothing else. The same case is most of the electronic payment systems. Cash is freedom, electronic money is dystopia (in most cases). We have to take a step back – return to the decentralized nature of the internet.

[Petr Fiedler]

No nevím, jestli se s tím dá úplně souhlasit. Myslím, že FB deaktivoval účty radikálů z ISIS a jsem za to rád.

Když mluvíš na náměstí, v hospodě nebo kavárně, tak tím nemluvíš k tolika lidem, jako na Facebooku. Nedá se to podle mě takto srovnávat.

A že je někdo umlčen, s tím souhlasím. Podívej se, co udělali Hitler s Goebbelsem jazykem. Kdyby dnes žili, určitě bych jim na FB nedával prostor. A vlastně se i stačí podívat, jaké ovoce přineslo Trumpovo vyjadřování. Manželka toho policisty, co dostal do hlavy hasičákem a pak zemřel a zanechal po sobě jí s 3 dětmi by s tebou asi nesouhlasila. A třeba navádění k trestné činnosti je taky trestný čin a je v pořádku, když někomu takovému zablokují na FB účet. Lepší, než když by se pak jeho moudry nechal někdo inspirovat a pak škodil.

Samozřejmě, že ta mince má i druhou stranu a děje se i to, že umlčují i toho, koho nemají. To je samozřejmě špatně. Nemyslím si, že se tohle celé dá nějak paušalizovat. Prostě je k tomu potřeba přistupovat individuálně a pokud se někdo vyjadřuje zle, tak ať je mu v tom zabráněno. Za mě dobrý.

[Petr Fiedler]

Čtu si to teď po tobě i sobě znovu a ten můj druhý odstavec v kontextu tvého příspěvku nedává smysl. Sice je to pravda, ale mimo rámec toho, o čem jsi psal. Beru zpět.

[Petr Fiedler]

Já jsem o to celkově začal asi tak před 2 lety dbát. Smazal jsem účet na FB, který jsem stejně vůbec nepoužíval a měl jsem tam jen jednoho přítele kvůli obnovení účtu, nebo tak něco. Přešel jsem z Windows na GNU/Linux na pc i nb, v RPi mám Buster, v routeru mám OpenWrt, v mobilu mám LineageOS bez GApps - používám F-Droid, ve Firefoxu mám Privacy Badger, používám Tor, přestal jsem používat Gmail a mám vlastní e-mailovou schtánku, používám NextCloud s vlastní sync kontaktů a kalendáře, používám open source, šifruji a pro sync dat používám to RPi - FreeFileSync přes sshfs. Jako laik asi více udělat nemůžu. To, jakým se to všechno ubírá směrem mi dost vadí, jenomže co naděláš?

[Bherzet]

Pěkné. To toho děláš víc než já, mám resty :)

[Petr Fiedler]

Svým způsobem je to ale stejně k ničemu. Snažíš se, ale pak stejně musíš poslat e-mail na gmail. Lidé tě mají v kontaktech a syncují si vše o tobě do goolgu. Nejraději bych používal end to end šifrování pošty, ale zkus to někomu z běžných lidí vysvětlit. Jsem rád, když někoho přesvědčím, aby místo googlu používal duckduckgo.

[Jendа]

Pěkné, připomnělo mi to vinohradské schéma.

[Heron]

Potom je tu ale stále otázka, zda ty komentáře stojí za tuto námahu. Na to si musí každý odpovědět sám. Podle mě komentáře nejsou zrovna vhodný nástroj pro nějakou hodnotnější diskusi. Fakt nejlepší připomínky chodí emailem. Je jich samozřejmě nejméně, ale přinášejí největší informaci.

Btw, v loni se rozjely online přednášky na YT. Na jednu stranu dobrý počin, protože se bylo na co koukat a některé kanály měly ve skutečnosti větší počet přednášek než kdykoliv před tím (prostě byl na to čas). Na druhou stranu naprosto nevhodná platforma, protože v chatu pouze 200 znaků na dotaz. Jeden můj dotaz moderátor zkomolil tak, že bych jej sám nepoznal. Takže už jen ze záznamu, není důvod ztrácet čas na online přenos.

[Jendа]

Na druhou stranu naprosto nevhodná platforma, protože v chatu pouze 200 znaků na dotaz.

Jo, tohle nechápu, nedávno jsem dostal dementní nápad, že budu s někým diskutovat na Roumingu (512 znaků limit; neumožňuje newlines). Nevermore.

[Jendа]

Ještě bych chtěl přidat jeden hejt když jsem tenhle incident řešil. Tentokrát to bude na TLS, resp. koncepci jeho implementací.

Takže máme bota, který se nám přihlašuje, a hash, který se nepodařilo cracknout. Bot zjevně zná plaintext a posílá ho (není tam digest autentizace). Tak si zapneme Wireshark a… narazíme na problém, že to tam nevidíme, protože je to TLS. Co s tím?

• Wiresharku se dá dát privátní klíč a on TLS dešifruje. Nefunguje s Perfect Forward Secrecy.
• Některé programy umí dumpovat vyjednané ephemeral klíče a dávat je Wiresharku. Každý to dělá jinak a některé to neumí vůbec.
• Můžeme zkusit debuggerem zahookovat openssl funkce.
• Můžeme před to postavit socat proxy a nechat to dumpovat všechen provoz na stdout.

!@#$%^&*

Současné implementace TLS vypadají tak, že se v každém programu nastavuje zvlášť: klíč, CA, jaké šifry a módy má používat, a 1024 dalších parametrů. V každém jinak, někdy nejdou všechny. Komunikace nejde sniffovat a nejde to ladit. Program pro to musí mít podporu, každý si to musí řešit sám. Proč tohle nemůže být systémové? Mohlo by to vypadat jako interface, na kterém by program poslouchal, i by se s tím jako s interface pracovalo, jenom by to celé dělalo TLS. Podobně jako když se dělá IPSec. Jediná speciální podpora by musela být pro přihlašování klientským certifikátem.

[Martin Tůma]

Proč tohle nemůže být systémové?

Protože to nikdo nezaplatí.

[xkucf03]

Tohle je správná úvaha. Jde obecně o IoC a DI a dělá se to, byť asi ne tak často, jak by bylo vhodné. Je to vlastně pokračování klasické unixové myšlenky

Make each program do one thing well.

Např. Java EE aplikace neřeší šifrování (a další věci, jako třeba připojení k DB, e-mailu, k JMS frontě zpráv a jiným zdrojům) samy, ale řeší to za ně aplikační server, který jim potřebné zdroje injektuje nebo nabízí k vyhledání.

Totéž můžeš dělat na úrovni operačního systému a nezávisle na programovacím jazyce. Např. můžeš dědit FD soketu a aplikaci předat až nešifrovaný proud nebo bys mohl předat FD nějakého proxy serverového soketu, ze kterého by aplikace brala nešifrované sokety. Šifrování a případně i ověřování uživatelů by se pak řešilo systémově na jednom místě. Pak tu máš superservery jako xinetd nebo stunnel, který přesně tohle dělá – stará se o šifrování, zatímco aplikace si řeší jen aplikační logiku.

Co ale často chybí, je předávání nějakých dodatečných metadat – např. klientského certifikátu nebo IP adresy klienta. K tomu je potřeba definovat dobré rozhraní. Jinak ale ta teorie je dobře popsaná a vyzkoušená jinde a současné technologie to umožňují implementovat.

[JiK]

Běhají po internetu nějaké soubory s často používanými hesly v češtině nebo cestine? Něco jako omezeny slovník který by bylo vhodně vyzkoušet aby se upozornili nejvíc problematičti uživatele ať si to změní na něco lepšího než nbuser123?