Za prve je to kravina. Novy useri byli i pred 20 lety a taky zijou dodnes. Za druhe. Pokud chteji hvezdicky tak snad kazdej sw dneska generuje pri jednom stlaceni nahodny pocet hvezdicek takze delku nezjistis.
To není úplně pravda. Naopak jsem dlouho nezažil software který generuje náhodný počet hvězdiček. Je to tak trochu anti-ux a nepoužitelné pro běžné usery. Pro uživatele je to zpětná vazba že něco napsal a kolik toho napsal.
Možná že to snižuje bezpečnost ale ten systém používají lidé -- a pro lidi by to mělo být intuitivní a příjemné.
Spíš by bylo na čase konečně ve výchozím nastavení zobrazovat zadávané heslo. Pokud uživatel opravdu musí zadávat heslo s nějakým publikem za zády (které mu určitě nevidí na prsty, že…), ať má možnost si ty hvězdičky zapnout. Nebo aspoň ať se zadaný znak na chvilku objeví a pak se změní na hvězdičku, když má někdo pocit, že by někdo heslo mohl zahlédnout z dálky.
Resp. zrovna u sudo by bylo vůbec nejlepší, kdyby to ve výchozím nastavení heslo vůbec nechtělo. Dá se to změnit v konfiguraci, ale to výchozí nastavení nedává smysl. Vede to jen k tomu, že je heslo náchylnější k prozrazení a uživatel si zvykne psát bez přemýšlení heslo pokaždé, když si o něj někdo řekne.
Nejlepší jsou GUI aplikace, které zobrazí políčko jenom pro heslo, žádný jiný input (a neumožňují jinam přepnout), neumožňují heslo zobrazit a nezobrazí, jaká je aktuálně nastavená klávesnice. Samozřejmě heslo musí obsahovat i speciální znaky a po třech neúspěšných pokusech se účet zamkne.
Jenže UAC je něco trochu jiného. Když budu mít na Windows uživatele se standardními právy, tak v UAC dialogu bude výzva k zadání loginu a hesla do jiného účtu, který to oprávnění má. To co myslíte patrně vy, že vyskočí jen výzva k potvrzení okna, funguje ale jenom ve chvíli, kdy ten uživatel už má práva administrátora (aka na linuxu se přihlásit jako root) a jenom to chce potvrzovat... což zní hezky dokud člověk nezjistí, že v tom systému existuje x jiných způsobům, jak vykonávat příkazy pod tím daným uživatelem s jeho oprávněními bez triggnutí UAC.
No jenže ten zásadní rozdíl je, že na Linuxu ten standardní účet má omezená práva, zatímco na Windows má práva plná. Pokud na Linuxu uživatel spustí něco nehezkého a to obejde sudo, tak to nebude mít efekt, protože na to nemá práva. Pokud ale ten samý malware tohle udělá na Windows (a spustí to třeba přes RPC, které je tam standardně povolené a spuštěné), tak se ta daná věc spustí s plnými právy. Takže ve chvíli kdy tam ještě nic cizího neběží, ale uživatel něco špatného otevře, je tohle ten moment, kdy tomu UAC nijak nebrání a je celé k ničemu... (ano, pokud uživatel otevře virus pro Win95, tak u něj ten prompt asi vyskočí :-) ).
Jenže z toho omezeného účtu na Linuxu se zavoláním sudo bez hesla dostanete na účet s plnými právy. Navíc bezpečnostní chyby eskalace práv z lokálního účtu na roota nejsou zas až tak výjimečné, a poměrně snadno lze takovou chybu vytvořit v systému i pouhou chybnou konfigurací. Podle mne je podstatně důležitější bránit se tomu, aby se pod uživatelským účtem nespouštěl škodlivý kód, než bránit škodlivému kódu v úniku z uživatelského účtu do administrátorského. Ostatně u většiny SOHO uživatelů je všechno důležité a citlivé dostupné pod uživatelským účtem, pod administrátorským účtem není nic zajímavého navíc.
Jako ano, sudo bez hesla taky zrovna bezpečné není. Nicméně sudo bez hesla není výchozí konfigurace, narozdíl od defaultní instalace Win, která toho uživatele jako admina udělá. Moje pointa v reakci na první příspěvek byla v tom, že UAC vypadá, jak je to dobře vymyšlené, ale ve skutečnosti je tam několik cest, kudy ho lze obejít i bez aktivní zranitelnosti v systému, takže je to celé jenom takové na oko, ačkoliv uživatel má pocit, že se nic nestane... zatímco když si aktivně půjde nastavit sudo tak, abych nezadával heslo, tak většinou tuším, jaké to může mít následky...
Bránit tomu, aby na té stanici nemohl běžet škodlivý kód, je šlechetná myšlenka, ale ta cesta je poměrně dosti obtížná, ne-li nemožná. V situaci, kdy na každý běžně používaný software vychází každý týden alespoň jedno CVE s nějakou RCE zranitelností se prostě může stát, že k tomu spuštění dojde i u těch lepších a poučenějších uživatelů. Realita s uživateli je nicméně ještě o dost horší a většina z nich jde vysloveně naproti tomu, aby k něčemu takovému došlo. A technicky tomu bránit je dosti komplikované - na Windows sice existuje něco jako software execution policies, ale pokaždé když po někom chcete, aby to nastavil, tak se začne dost kroutit... Protože nastavit to tak, aby to něčemu reálně zabránilo, ale zároveň ten počítač šel ještě používat, zvlášť když u tohohle systému se rozmohlo, že ty aplikace jsou naházené úplně všude kam je to napadne (včetně těch přímo od MS, které si spustitelné soubory taky cpou někam do AppData uživatelského profilu...) je prostě nadlidský úkol. A sice bych v tuhle chvíli rád řekl zlatý linux, kde nastavím noexec na /home a /tmp a ono to nic nerozbije... jenže ani tady to úplně neplatí, protože stejně dneska na každém systému je minimálně python... a vlastně nač python, když ten shell tam je stejně. Takže v situaci, kdy mi čtvrtina uživatelů klidně zkopíruje z web page do shellu string python -c "neco" jenom proto, že jim ta stránka slíbila, že se jim zvětší po odbouchnutí genitálie, je dost těžké s tím bojovat...
Ohledně admin práv - úplně nesouhlasím. Ano, data, ke kterým má uživatel přístup, to získá i bez admin práv. Nicméně pokud na tom stroji třeba jsou i data jiného uživatele, tak se to k nim nedostane, ale s admin právy ano. Stejně tak pokud si ten malware pokouší vytvořit nějakou persistenci, aby zůstal běžet i po restartu, tak s admin právy má mnohem větší pole působnosti, kde se může realizovat (včetně případných snah jak se vyhýbat nějakým antivirům nebo něčemu, co na té stanici může běžet). A s admin právy to taky může dělat nějaké další věci, co pod běžným uživatelským účtem nejdou - třeba poslouchat data na síti, posílat spoofované pakety a tak podobně. Tedy výrazně to zvyšuje šanci, že se to může dostat ještě někam dál, než na tu již napadenou stanici. Takže si úplně nemyslím, že když už selžu v té části, že se nepodaří zabránit spuštění závadného kódu, že je úplně jedno jestli to dostane nebo nedostane admin account. V autě jsou taky bezpečnostní pásy a poutáme se s nima, ikdyž je mnohem lepší vůbec nebourat.
Tipuju, že množství SOHO počítačů, které sdílí víc lidí, zároveň tam mají oddělené uživatelské účty, a zároveň nemají většinu dat sdílených, je mizivé.
sudo bez hesla si sice musíte explicitně nastavit, ale sudo s heslem původního uživatele je nesmysl – i když je to výchozí nastavení. Navíc je sudo s heslem spíš větší nebezpečí, protože prozradíte ještě svoje heslo.
Pro spuštění kódu po přihlášení uživatele má útočník dost možností i u běžného účtu. A pro napadení ostatních zařízení v síti použije útočník tu samou díru, kterou použil pro napadení daného počítače – k tomu nepotřebuje ani poslouchat na síti ani posílat podvržené pakety.
No sudo bez hesla ten příkaz prostě pustí a uživatel ani nezjistí, že to co se pustilo udělalo sudo. Pokud vyskočí prompt na heslo, tak je to nějaký red flag, že se tam děje něco divného. V tomhle případě bych řekl že je to ekvivalent toho, když UAC zobrazí to okno, které stačí odklepnout. Akorát sudo alespoň nejde obejít několika jinými validními způsoby, které nejsou považovány za security bug.
Jenže na napadení počítače nemusí nutně v tom softwaru být díra. Úplně stačí, že uživatel copy pastne random příkaz z webu do cmd liny a tím ti infikuje (což se očividně děje, viz některé postřehy z bezpečnosti, kde byly ty windowsí jako BSOD s tím že pro opravu je potřeba zmáčknout win+r, ctrl+v a enter. A tohle reálně v té síti stejně někdo udělá, nicméně pokud ten malware navíc dostane admin práva, tak tam následně může škodit více i u uživatelů, co by na tohle neskočili.
Pokud uživatel zkopíruje příkaz z webu a bez kontroly ho spustí, potvrdí pak UAC nebo napíše heslo do sudo. Ani jedno nebylo myšleno jako ochrana před kombinací „záškodník plus naivní uživatel“. Obojí (sudo i UAC) je ochrana pouze před chybou (omylem) uživatele nebo programu.
Pro znalé uživatele je dostatečný red flag to, že píšou sudo, nemusí pak ještě psát heslo. Pro neznalé uživatele není požadavek na heslo po zadání příkazu v terminálu žádné překvapení, protože to po nich chce heslo prakticky pokaždé, když něco spouští v terminálu. Myslím si, že dokonce spousta neznalých uživatelů považuje terminál za nástroj pro spouštění administrátorských příkazů, takže to, že přijde požadavek na heslo, považují za přímý důsledek toho, že spustili nějaký příkaz v terminálu. Pro ně terminál a sudo jedno a to samé jest.
BTW, o zbytečnosti hesla u sudo psali I autoři QubesOS: https://doc.qubes-os.org/en/r4.3/user/security-in-qubes/vm-sudo.html
Ano, protože většina konzolových aplikací si táhne relikty z 80-90tek (kdy UX bylo neznámé slovo a všeobecně počítače nepoužíval každý). Všechny moderní grafické programy, browsery -- prostě celý grafický stack až na pár mohykánů vždy ukazuje puntíčky. Dokonce některý aplikace umožnují na chvíli to heslo i zobrazit. Osobně bych teda věřil spíš UXákům z Google, Mozilly, KDE, Microsoftu, Apple atd. atd. než programátorovi co programoval login před X lety že ví jak uživatel očekává že se počítač bude používat a jak to je pro něj příjemné aby si nerval vlasy.
Imho porovnavate jabka s hruskama. Nebo spis hyeny a rybicky. Co je dobre pro jednoho, bude dobre i pro druhe. Verim prece Googlu a Applu.
Nemuzete prece srovnat, ze kdyz google ma v prohlizeci pro uzivatele, ze se mu ukazuji hvezdicky, tak to tak bude po tech 40 letech odted i pro uplne jine spravce na upne jinem rozhrani. Vase logika by znamenala, ze se Vam odted po otevreni prohlizece otevre instagram Kardashian, protoze si to tak ostatni preji a jsou na to zvykli.
Sam zminujete "graficke" programy... Takze by meli spravci instalovat vsude i Xka? Protoze maji lepsi UX? Wtf? Nebo aspon Borland IDE kdyz uz maji "jen" textovy rezim?
Pokud udelaji po 40 letech zmenu a jeste defaultni, tak se nemuzes divit ze nekdo zacne remcat.. :D
Vzdyt roubujete reseni pro jednu skupinu jine skupine s jinym problemem. Pletete si rodinne auto s tankem. Automaticka prevodovka je prece doknale UX, takze bude teda i v tanku. Default.
Je to obyčejný uživatel, který je jediným uživatelem toho počítače a tudíž i správcem. Píše to pokaždé, protože to tak vidí napsané všude možně na internetu. Spousta lidí, kteří píšou rady a návody, píše automaticky sudo všude, bez ohledu na to, o jaký příkaz se jedná. Natož aby to rozlišoval běžný uživatel. Pro něj je to prostě formulka, kterou začíná každý příkaz napsaný v terminálu.
Sice to nelze považovat za žádný tvrdý důkaz, ale pokud vezmu laické linuxáky (tedy uživatele, kteří tomu v podstatě nerozumí, jen to používají) v počtu několika málo desítek kusů, tak jsou mezi nimi pouze dva, kteří si ten systém sami instalovali.
Ti ostatní mají systém tak, jak jim to připravil jejich rodinný ajťák
(což v drtivé většině případů nejsem já!), tedy s administrátorským účtem odděleným od uživatelského. (Teď z úvahy vynechám těch několik málo sdílených - zpravidla dětských
strojů, takže zůstávají modely jeden počítač, jeden uživatel
.) Zhruba polovina jich ani nemá přístup k administrátorskému účtu, protože do toho nechtějí vrtat, druhá zhruba polovina se umí přihlásit či přepnout na administrátora, pokud něco instalují.
Jenže v jejich případě se obvykle spokojí s klikacím rozhraním
. A pokud potřebují něco v příkazovém řádku čili terminálu, tak ti, co mají na takové kroky odvahu, vědí alespoň přibližně kdy sudo napsat a kdy nikoliv. Případně se dtží zhruba hesla jednoho z dědků:
.sudo znamená: Sháněj Už DOktora (= nějakého zkušeného linuxáka)
Ti dva samoinstalatéři
jsou na cestě stát se linuxovým profíkem
a na administrátora/roota se nepřihlašují; a vědí, na co to sudo potřebují, a na co ne.
Netvrdím, že zlozvyk být jediným uživatelem a zároveň adminem
neprobublal z Windows Home i do Linuxu, ale tak nějak je to (zatím?) zřídkavý jev.
"ale dá se tím dost omezit počet pokusů na bruteforce"
To nepomuze temer vubec. Mejme abecedu o k symbolech na generovani hesla. Mejme heslo delky N.
Pak to chce k^N pokusu. To je zrejme.
Kolik pokusu treba pro vsechny delky mensi N? k+k^2+...+k^(N-1)= (k^N-k)/(k-1).
To je stale jen o neco vice nez 1/k pokusu oproti delce N. Takze je to zanedbatelne.
A mimo to bruteforcovat sudo? To nekdo dela?
A co bezna situace, kdy někdo zlý kouká přes rameno. Pokud uvidí třeba 4 hvězdičky a méně tak si řekne OK, to je prolomitelné, pokud jich uvidí 16 tak to asi ani zkoušet nebude. Takže bezpečnější bude náhodný počet hvězdiček, ale to zase jde proti UX (matoucí odezva pro uživatele). A mimo to do sudo se zadává uživatelské heslo, takže pak se dá udělat bruteforce v podstatě na cokoliv tj. login, ssh (telnet, pokud ho tam uživatel má). Prostě hvězdičky jsou z hlediska bezpečnosti podle mě krok, když ne stranou, tak zpět.
2. 3. 2026, 09:08 editováno autorem komentáře
Pokud má někdo 4znakové heslo, je problém v tom 4znakovém hesle, ne v hvězdičkách. Pokud někdo zlý kouká přes rameno, dost možná vidí i na prsty a vidí heslo, které píšete. Nebo může nahrát zvuk stisknutých kláves, podle kterého se dají písmena určit s docela vysokou přesností. Zkrátka hvězdičky nemají dopad na bezpečnost prakticky žádný, ale je to podstatné zlepšení UX.
wtf ?
Uz jsem se smiril s myslenkou, ze kvuli par mladym aktivistum prepisem 20 let stary a 20 let stabilni kod do nejakeho nahypovaneho hypermoderniho neproverenyho shitu.
Cert to vem, mladi vpred a zelenou na kazdickou krizovatku jejich smelych cest ... ale kua proc za kazdou cenu "reinvent the wheel" ?
Prece kdyz zadavam heslo, tak ma byt terminal hluchy a tise zrat znaky, ne ? Jaky a hlavne proc kua by mel vypisovat hvezdicky ?
A pokud uz ses hvezda, co se nam nezda, tak "pls use windows" a tam budes mit tdch hvezdicek, ze se z toho mlecna draha zese...e. A nadavkem i reverzibilni hash. Enjoy
Hvezdicky nebo puntily pouziva jiz davno kdejaky formular na vypsani hesla, tudiz bych to povazoval za de facto za standardni chovani. Drive ve formularich nebejvala volba zobrazit heslo, nyni je obecne dostupna na vyzadani. Jinak pro SSH preferuju SSH klice (SSH klic je de facto velmi slozite dlouhe heslo, ktery uzivatel neposila po siti a zustava na lokalnim zarizeni). Podlbe me by celkove prihlasovani pomoci kryptografickych klicu mel byt standard (a udalt to presne, jako to ma SSH)