Byly vyhlášeny výsledky letošní volby vedoucího projektu Debian (DPL, Wikipedie). Staronovým vedoucím zůstává Andreas Tille.
Jason Citron končí jako CEO Discordu. Od pondělí 28. dubna nastupuje nový CEO Humam Sakhnini, bývalý CSO Activision Blizzard.
Článek na Libre Arts představuje baskytarový multiefekt Anagram od společnosti Darkglass Electronics. S Linuxem uvnitř (licence, GitHub).
Městský soud v Praze vyhlásil rozsudek, který vyhověl žalobě novináře Jana Cibulky, který s podporou spolku IuRe (Iuridicum Remedium) požadoval omluvu od státu za to, že česká legislativa nařizuje operátorům uchovávat metadata o elektronické komunikaci. To je přitom v rozporu s právem. Stát se musí novináři omluvit a zaplatit náklady řízení. Především je ale součástí přelomové rozhodnutí o nelegálnosti shromažďování dat a o
… více »Americké technologické firmy Apple a Meta Platforms porušily pravidla na ochranu unijního trhu, uvedla včera Evropská komise (EK). Firmám proto vyměřila pokutu – Applu 500 milionů eur (12,5 miliardy Kč) a Metě 200 milionů eur (pět miliard Kč). Komise to oznámila v tiskové zprávě. Jde o první pokuty, které souvisejí s unijním nařízením o digitálních trzích (DMA). „Evropská komise zjistila, že Apple porušil povinnost vyplývající z nařízení
… více »Americká společnost OpenAI, která stojí za chatovacím robotem ChatGPT, by měla zájem o webový prohlížeč Chrome, pokud by jeho současný majitel, společnost Google, byl donucen ho prodat. Při slyšení u antimonopolního soudu ve Washingtonu to řekl šéf produktové divize ChatGPT Nick Turley.
Po roce vývoje od vydání verze 1.26.0 byla vydána nová stabilní verze 1.28.0 webového serveru a reverzní proxy nginx (Wikipedie). Nová verze přináší řadu novinek. Podrobný přehled v souboru CHANGES-1.28.
Byla vydána nová verze 10.0.0 otevřeného emulátoru procesorů a virtualizačního nástroje QEMU (Wikipedie). Přispělo 211 vývojářů. Provedeno bylo více než 2 800 commitů. Přehled úprav a nových vlastností v seznamu změn.
42 svobodných a otevřených projektů získalo finanční podporu od NLnet Foundation (Wikipedie).
Americký výrobce čipů Intel plánuje propustit více než 20 procent zaměstnanců. Cílem tohoto kroku je zjednodušit organizační strukturu ve firmě, která se potýká s problémy.
Diskuse vznikla z vlákna této diskuse.
Nj, sice to elegantně některé problémy řeší, ale pak to přináší taky další neelegantní problémy...Nepřináší. Jenom to odkrývá problémy, které existují i bez toho.
pořád je ještě nějaký rozdíl mezi tím, kdy provozovatel to heslo v plaintextu "vidí" (někde proběhne) a tím, kdy je doopravdy uloženoV tom sice rozdíl je, ale vy jako uživatel netušíte, co s tím provozovatel doopravdy dělá.
prosím přeformulovat nebo dokázatNe, to není reakce na poslední odstavec. V posledním odstavci jsem chtěl důkaz, že existuje nějaký web, který ta hesla určitě neukládá. Pokud to dokázat neumíte, musíte předpokládat, že hesla v otevřeném tvaru ukládá každý web. O tom tu celou dobu píšu, ale někdo evidentně raději strká hlavu do písku., pokud ovšem ukládáním nerozumíme dočasný přenos plaintextové informace - to je současně reakcí na poslední odstavec….
jen zpochybňuji tvrzení, že když je heslo uloženo v plaintextu, tak je to stejně jedno, protože při každém přihlašování tam to heslo stejně doběhne v plaintextuNic takového jsem ale já netvrdil.
Prostě není, ty rizika jsou výrazně vyššíK tomu ale pořád chybí ten důkaz, že web hesla neukládá.
nicméně to nelze postavit na stejnou úroveň trvale/hromadně/zaručeně uložených hesel - to je rozdíl mezí cíleným „útokem“ a náhodným únikemJak ten rozdíl jako uživatel zjistíte?
protože žádný 100% důkaz nemůže existovatNo sláva, jsem rád, že jste na to konečně přišel.
Rizika se (obecně) prostě eliminují v dané situaci všemi dostupnými prostředky a plaintext heslo v databázi neznamená skoro v žádné situaci „eliminovat dostupnými prostředky“.Ale asi to stále nechápete. Jako uživatel musíte u všech webů předpokládat, že heslo ukládají v otevřeném tvaru. Takže když to tak nějaký web opravdu dělá, nemůže to být pro uživatele nic nečekaného a nijak to jeho bezpečnost nezhoršuje. Když se mi majitel webu snaží namluvit, že on hesla neukládá a má vše perfektně zabezpečené, přece to ještě neznamená, že mu to budu věřit.
Prostě riziko je vyšší.Vyšší než co? Vyšší než stav, kdy jako uživatel nevíte, zda je heslo ukládáno v otevřeném tvaru? Takže když se někdo podívá do zdrojáků Abíčka a zjistí, že se hesla ukládají v otevřeném tvaru, jeho bezpečnost se snížila? To těžko.
I když to ten serveru může potencionálně dělat, tak to neznamená, že to dělá.Takové uvažování ale nemá s bezpečností vůbec nic společného.
A vy přistoupit na mou, že uložením hesla v plaintextu se vytváří další rizika, a že uživatel může i serveru důvěřovat a věří tomu, že je uděláno maximum pro uchování vzájemné důvěry, tudíž mu nemusí vadit, že server „vidí dočasně“ jeho heslo.Žádné další riziko se nevytváří. Já jako uživatel musím předpokládat, že server hesla v otevřeném tvaru ukládá (nemám žádný způsob, jak zjistit, že to nedělá). Takže když to server opravdu dělá, není to nic navíc oproti mému předpokladu.
uživatel může i serveru důvěřovat a věří tomu, že je uděláno maximum pro uchování vzájemné důvěry, tudíž mu nemusí vadit, že server „vidí dočasně“ jeho hesloPak mu nemusí vadit ani to, že má server heslo uložené.
Ne, heslo uložené v plaintextu je vyšší riziko úniku hesla třetí straněPořád dokola opakujete „vyšší riziko“, a pořád odmítáte napsat vyšší než co. Hesla uložená v otevřeném tvaru je větší riziko než hesla uložená v otevřeném tvaru? Vždyť to jsou dvě stejné věci, takže riziko je logicky v obou případech stejné.
má, součástí bezpečnosti je i důvěra.Ovšem důvěra a bezdůvodné spoléhání na to, že tohle se mi nelíbí tak se to nestane, to jsou dvě zcela odlišné věci.
pročpak ne, to že věřím, že systém se chová nějak ještě neznamená, že věřím tomu, že nemůže systém být napaden a DB zcizena, nebo že se do DB podívá neoprávněná osoba při servisním zásahu, nebo někdy se vyskytne záloha či si to vyžádá policie apod.Když může být systém napaden, může si tam útočník nainstalovat program, který bude hesla ukládat. Jaký je v tom z pohledu uživatele rozdíl? Nebo co když se ta hesla ukládají omylem, někdo třeba nechal zapnutou vysokou úroveň logování. Rozdíl je jen v tom, zda uživatel o ukládání ví nebo ne. To přece ale není rozdíl v bezpečnosti.
Hesla uložená v plaintextu než hesla uložená jako hash, jsou vyšší riziko, o kolik „nelze stanovit z placu“ ale lze to vyjádřit libovolným koeficientem větší než jedna.Jenže tady se nebavíme o tom, jak hesla jsou uložená – zda nejsou uložená i v otevřeném tvaru totiž nikdo neví. Takže celou dobu řešíme jen případ, že si uživatel myslí, že jsou data uložená v otevřeném tvaru, nebo si myslí, že jsou uložené jejich hashe. Podle vás v tom je rozdíl, podle mne není, protože když nevím skutečný stav, musím předpokládat tu nejhorší možnou variantu, a tou jsou v obou případech hesla uložená v otevřeném tvaru.
stavíte na roveň přenos a permanentní uloženíJá to nestavím na roveň. Já jenom vím, že když už k někomu to heslo doputuje, má možnost ho uložit – ať už záměrně, nebo chybou. Vy spoléháte na to, že jsou všichni kolem hodní a neomylní, a když vám někdo bude tvrdit, že ta hesla neukládá, budete mu to věřit. Kdyby tady Luboš nenapsal, že hesla neodpovídají, ale napsal by, že hash vytvořený z hesla neodpovídá, někteří lidé tady v diskusi by si pochvalovali, jak se zvýšila bezpečnost jejich hesel. Přitom fakticky by to bylo pořád stejné.
I když se 20 let nepřihlásíte na server, tak je zde 20let kdy někdo může přečíst vaše heslo.Oproti dvaceti letům, kdy někdo může přečíst mé heslo. Nemůžu si pomoct, ale je to to samé. Nevnesl jsem to sem já, ale vy.
No z pohledu uživatele v důsledku není rozdíl, ale to je důsledek.Jenže o pohledu uživatele se tady celou dobu bavíme. Nebo vy máte práva ke čtení hesel v LDAP databázi nebo administrátorská práva k počítačům, kde běží Abíčko?
já jsem si plně vědom, že k tomu může dojít, ale má víra je v tom, že tvůrce webu/aplikace se snaží rizika eliminovat a chránit tak mě i sám sebe.V tom případě zase nevím, proč vám vadí hesla uložená v otevřeném tvaru. To, jestli hesla jsou nebo nejsou uložená v otevřeném tvaru je z pohledu uživatele tak nepatrný rozdíl v bezpečnosti… Navíc jako uživatel si to stejně nijak nemůžu ověřit, takže to pro mne tu rozdílnost stírá na nulu. Nesrovnatelně větší dopad na bezpečnost má to, jak „velký a aktivní“ je profil toho, co to heslo chrání. Když je to nějaká registrace pro demoverzi programu, klidně tam budu používat stejné heslo, a je mi jedno, zda ho správce ukládá v otevřeném tvaru. V případě sociálních sítí nebo e-mailu, odkud už jsou dohledatelné další věci, zase budu používat unikátní hesla, i když mi správce bude tvrdit, že ukládá jenom hash. V ideálním případě samozřejmě použiju nějaký generátor a správce hesel na všechno, a pak už na způsobu uložení hesel na serverech nezáleží vůbec.
pokud by jsme vyšli ze stavu, že jsou hesla uložena v plaintextu a změna by bylo zašifrování či zaheshování, tak se ochrana hesel před zcizením zvýšila. Vztah mezi uživatelem a serverem v čistě logické bezpečnostní rovině se nezměnil, nicméně obecný vztah posílil, protože server zvýšil ochranu hesel.Takže stačí, aby tady Luboš napsal, že od teď jsou hesla hashovaná, a vaše bezpečnost se zvýší? Moje ne.
Říkáte, že je jedno jestli je heslo přístupné jen sem tam (při přihlášení), nebo je zaručeně někde 20let k dispozici?Neříkám, že je to jedno, ale že to jako uživatel nejsem schopen poznat. A 100% to není schopen zaručit ani správce – on sice může mít hesla uložená zahashovaná, ale těch 20 let mohou být uložena někde jinde.
Ne bavíme se šířeji o rizicích.Co to znamená „šířeji o rizicích“? Tady se bavíme konkrétně o uživatelích Abíčka. Prohlášení Luboše o tom, zda se hesla hashují nebo nehashují ta rizika nějak mění?
Nemám, doufám, ale pokud bych měl tak si ta hesla přečtu, ale pokud by byla hashovaná, tak ne.Pokud by byla hashovaná, tak si je přečtete také – pokaždé, když je klient pošle.
Znovu zopakuji „mně to nevadí tady“, jen neustále opakuji že to není stejné, protože možností k zcizení toho hesla a zneužití, je více.Jenže pořád vycházíte z nějaké virtuální situace, kdy uživatel ví, jak to na serveru ve skutečnosti je. Jenže v reálném světě to uživatel neví a vědět nemůže.
podle důležitosti volíte různá hesla nedefinuje zabezpečení toho heslaTo, že správce webu vidí hesla, je nebezpečné z jediného důvodu – když to samé heslo uživatel používá i někde jinde. Když je to heslo unikátní, není to žádný problém, protože správce webu může stejně udělat cokoli jménem uživatele i bez znalosti jeho hesla.
ano neustále operujete s tím, že nikomu nevěříte, ale tu mez máme obvykle stanovenou blíže než ji stavíte vy, protože pak by to opravdu znamenalo, že není třeba používat hesla protože jsou zbytečná. Já heslo chápu jako něco jako „podpis smlouvy“ mezi klientem a serverem a očekávám, že je server se snaží můj podpis chránit a jsem si vědom, že to nikdy nebude 100%, ale očekávám, že server minimalizuje příležitosti k použití toho podpisu.Jenže vy ty hranice máte právě nastavené nějak divně. Na jedné straně je absolutní důvěra, kdy se nepoužívají hesla. Pak není dlouho dlouho nic, a pak jsou hesla uložená v otevřeném tvaru a uložený hash hesel. Rozdíl v bezpečnosti je tam minimální, uživatel ani nemá možnost jej zjistit. Pak zase dlouho dlouho nic není, a pak je přihlášení pomocí hashe z unikátního hesla a výzvy (to unikátní heslo může být třeba hash základního hesla a jména serveru) a přihlášení dvojicí klíčů. Je nesmysl řešit pořád ten minirozdíl v různých variantách toho, když uživatel při každém přihlášení posílá otevřené heslo – zvlášť když uživatel nemá šanci zjistit, o kterou variantu jde, a to, že se hesla neukládají je pro uživatele jen šťastná náhoda, rozhodně ne něco, na co by se mohl spolehnout.
Pokud by byla hashovaná, tak si je přečtete také – pokaždé, když je klient pošle.No, ale on je třeba nepošle, žejo. Kolikrát denně se přihlašuješ na abc? Co jsem tak zběžně přeletěl tu diskusi, tak tvůj hlavní argument je, že z pohledu uživatele to je jedno. To ale platí pouze pro svědomitého uživatele, pak jsou uživatelé, kteří třeba použijí stejné heslo pro více služeb. V takovým případě je hashované (a řádně osolené) heslo bezpečnější, ačkoli třeba jenom o něco. Další věc je, že mnoho lidí může mít pro každý server jiné heslo, ale může mít nějaký systém v těch heslech - třeba nějakou společnou část a podobně. Koneckonců, kdo si má ty stovky unikátních hesel pamatovat? Znát jedno heslo pak může útočníkovi pomoct při lámání/hádání ostatních. No, a úplně nakonec, zatím afaik nepadl důvod proč nehashovat. Jestliže nemáme pádný důvod, proč nehashovat a zároveň víme, že eixstují situace, kdy hashování bezpečnosti pomůže (nepoučený uživatel,...), je odpověď celkem jasná.
Takové uvažování ale nemá s bezpečností vůbec nic společného.To tvrzení, že hashovat hesla nemá smysl, pač to ničemu nepomůže taky. Ostatně, když to vememe do konce - proč pak tu autorizaci vůbec máme? Jako uživatel musím počítat s tím, že to heslo může kdokoliv zneužít a že systém je natolik děravý, že se tam může kdokoliv dostat. Pak se tedy můžu smířit s tím, že se kdokoliv může přihlásit na svůj účet, hesla můžeme úplně zrušit a budeme zadávat jen username pro naše osobní nastavení...
To tvrzení, že hashovat hesla nemá smysl, pač to ničemu nepomůže taky.Souhlasím. On tady někdo něco takového tvrdil?
Jinak podivovat se nad tím, že provozovatel webu má k dispozici nešifrované heslo, je poněkud zvláštní.Lidé chtějí spoustu cípovin (např. většina chce heslo typu „123“).
Tiskni
Sdílej: