Apple představil nový MacBook Pro s čipy M4, M4 Pro a M4 Max.
Na GOG.com běží Halloween Sale 2024. Při té příležitosti lze získat zdarma počítačovou hru Return of the Phantom.
Společnost OpenAI spustila internetový vyhledávač ChatGPT search.
Konference OpenAlt 2024 proběhne již tento víkend 2. a 3. listopadu v prostorách FIT VUT v Brně. Začíná ale už v pátek na warm-up party ve Studentském klubu u Kachničky v 17:00. Pokud jste ještě areál FITu nenavštívili, k dispozici jsou pokyny k orientaci. Na programu je 54 přednášek a workshopů. Témata jsou od silně technických témat jako je třeba GCC nebo PostgreSQL po méně technické témata jako eGovernment, nebo třeba detailní analýzu … více »
Byla vydána nová verze 6.9 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přehled změn v příslušném seznamu. Tor Browser byl povýšen na verzi 14.0.1. Tor client na verzi 0.4.8.13. Thunderbird na verzi 115.16.0.
Vývojáři free a open source synchronizačního nástroje (a p2p náhrady Dropboxu) Syncthing oznámili, že z důvodu odporu ze strany Google Play ukončují podporu OS Android. Bohužel v rámci toho zmizí i vydání Syncthing na F-Droid, který má slabší uživatelskou základnu. Syncthing je na Androidu implementován formou wrapper aplikace, která spustí Syncthing démon, vyžádá potřebná oprávnění a zpřístupní webové rozhraní démona. Ve srovnání se
… více »V červnu 2022 bylo oznámeno, že z K-9 Mailu se stane Thunderbird pro Android. Trvalo to poněkud déle, než vývojáři předpokládali, ale včera byl první stabilní Thunderbird pro Android 8.0 vydán.
Projekt microDMG Racer na Kickstarteru nevyšel, tak se autor rozhodl uvolnit na ESP32 postavené autíčko i ovladač jako open source.
Byl vydán TrueNAS SCALE 24.10 „Electric Eel“. Přehled novinek této open source storage platformy postavené na Debianu v poznámkách k vydání.
Byla vydána nová verze 24.10.29 svobodného multiplatformního video editoru Shotcut (Wikipedie) postaveného nad multimediálním frameworkem MLT. Nově s podporou AI (whisper.cpp) pro generování titulků. Nejnovější Shotcut je již vedle zdrojových kódů k dispozici také ve formátech AppImage, Flatpak a Snap.
historyZadavane prikazy se nam hromadi v:
~/.bash_historyPokud 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:
~/.bashrcJedna se o tyto parametry (-1 znamena neomezene):
HISTSIZE=-1 HISTFILESIZE=-1Netreba 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.txtSoubor 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 ffmpeA 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:
!458Po tomto zadani je prikaz ihned vykonan coz casto neni zadouci a proto pouzijeme malou upravu a to:
!458:pNyni 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 stopuPrikaz 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:clearNyni 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=ignorebothToz 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.
Tiskni Sdílej:
To je super zápis. Díky
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í.
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é?
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?
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.
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á.
~/.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.
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í.
Takže na desktopu je dobré mít nastavené heslo u sudo, nebo je to zbytečné?
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.
ssh root@localhost
příkaz s autentikací klíčem.
Díky.
+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í).
~/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.
Takže mít nastaveno heslo u sudo je tedy zbytečné, ano?
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.
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í.
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.
%wheel ALL=(ALL) NOPASSWD: ALL
Tvojí odpověď nechápu. Mohl bys mi k tomu prosím tě něco napsat?
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.
A není to nebezpečné?
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ě.
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...
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?
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.
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.
Protože 96b bylo hrubou silou prolomeno už docela dávnoO 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é.
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.
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).
ale taky by mě zajímal zdroj té informaceKryptografická 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.
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á...
Symmetric Factoring Elliptic-Curve Hash 256 3072 384 384Tj 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é.
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
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.
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.
ZdrojNo 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é.
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. :)
Při použití abecedy o 37 znacích to vychází na 25 písmenProč 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 264 krocích. 256 bitů klíče Vám moc nepomůže, když velikost bloku zůstává 128 bitů.
franta:$6$h6761JCqLNwoNicM$sGpJbJQ3VxBWzed3Mtpw.GpY4TDo91xboF/PLcsPPRvVcZ65wqrFCedaYzBKij0DQpoD8QSNgg8ugAOL4aB1n0:18627:0:99999:7:::Zdar Max
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.
Jakých tabulek? Myslíš rainbow tabulek se seznamy hashů?
Ne, myslim tyhle tabulky
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?
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...
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 )
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é?
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.
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í).
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.
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.
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.
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í...
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ží.
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.
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ý.
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.
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í.
že osmimístný heslo jde zlomit za pár hodinJá 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 bruteforceNo spíš je to rovnák na ohejbák. Lidi mají slabá hesla, tak tam dáme pomalou fci.
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ší.
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.
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.
Jediný, co se tady ukázalo je, že já nejsem ochotný to heslo lámatNe, 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.
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.
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é.
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.
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.
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.
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.
reality check: na začátku čovidu měla polovina českých domácností úspory na nejvýše dva měsíceA presto jim vystacily na mesicu 8, asi zazrak Chanuky, ne?
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
Taky to tak vidím, ale řekl bych, že to neuzná.
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í"...
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.
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.
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.
V tom tvém příkladu je jako hash použita SHA512.sha512crypt není SHA512.
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ý...
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.
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/sDal jsem na pastebin cely ten soubor s vysledky, kdyby to nekoho zajimalo.
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...
Š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...
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.
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í.
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 heslaAha, 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.
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.
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.
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.
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:
Takže mám zatím smůlu a budu si muset časem postavit nějaký server.
Jinak dík.
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?
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.
%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?
[Install package file] Identity=unix-group:sudo Action=* ResultActive=yes
Paráda. Dík
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.
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ě...
třeba když daný ssh server nepodporuje klíčeKaždý má své peklo, které si hýčká.
nebo když je potřeba zadat heslo k tomu klíčiJasně, 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.
cat .bash_history | grep passwd | wc -l 0Účty bez hesla, přihlašování klíčem.
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.
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:Normální lidi mají v historii čas (což se tipuju zaplo tím, že jsem udělalsed 's/^[ \t]*//;s/[ \t]*$//' ~/.bash_history | sort | uniq > vystup.txt
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:K tomuto je hlavně potřeba dodat, že pomocí# Ulozi prikaz po odentrovani do .bash_history aniz by bylo treba zavrit (opustit) terminal: PROMPT_COMMAND="history -a; $PROMPT_COMMAND"
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.
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'
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
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.
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…).
Na nějakém extra zabezpečeném serveru bych to možná chápalJá 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
.
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.
široce používané programy jako MySQLPsal jsem slušné
obsahují rovnák na ohýbák, který přepisuje heslo zadané na příkazové řádceJo, 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 pachatelJaký pachatel? Pachatel čeho? Doporučuju tuhle přednášku. Není správné se ptát kdo, ale co.
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.
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ásahyNe, 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ě odhaleniDů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, zraditBaví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.
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.
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ímAle 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ě?
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ší.
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).
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.
[...]Asi nejsem jediný, kdo používátomu prave pomaha v blogu zminene "PROMPT_COMMAND="history -a; $PROMPT_COMMAND", takze po restartu mas akorat ty historie ze vsech panelu promixovanetmux
/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 nastavitshopt -s histappend
.
taková neni ne?? :O :O když napišu příkaz echo $HISTORY tak to jako neukáže vubec nic :O :O
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.
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).
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.1 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
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.
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ě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.
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í
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í).
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.
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 webu1 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ál2 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
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.
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ů:
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.
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.
losTohle 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.
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.
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.
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í.
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í:
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.
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?
úč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.
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ě.
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.
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.
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.
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ý.
Č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.
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áš?
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.
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.
Proč tohle nemůže být systémové?
Protože to nikdo nezaplatí.
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.