Homebrew (Wikipedie), správce balíčků pro macOS a od verze 2.0.0 také pro Linux, byl vydán ve verzi 4.5.0. Na stránce Homebrew Formulae lze procházet seznamem balíčků. K dispozici jsou také různé statistiky.
Byl vydán Mozilla Firefox 138.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 138 je již k dispozici také na Flathubu a Snapcraftu.
Šestnáctý ročník ne-konference jOpenSpace se koná 3. – 5. října 2025 v Hotelu Antoň v Telči. Pro účast je potřeba vyplnit registrační formulář. Ne-konference neznamená, že se organizátorům nechce připravovat program, ale naopak dává prostor všem pozvaným, aby si program sami složili z toho nejzajímavějšího, čím se v poslední době zabývají nebo co je oslovilo. Obsah, který vytvářejí všichni účastníci, se skládá z desetiminutových
… více »Richard Stallman přednáší ve středu 7. května od 16:30 na Technické univerzitě v Liberci o vlivu technologií na svobodu. Přednáška je určená jak odborné tak laické veřejnosti.
Jean-Baptiste Mardelle se v příspěvku na blogu rozepsal o novinkám v nejnovější verzi 25.04.0 editoru videa Kdenlive (Wikipedie). Ke stažení také na Flathubu.
TmuxAI (GitHub) je AI asistent pro práci v terminálu. Vyžaduje účet na OpenRouter.
Byla vydána nová verze R14.1.4 desktopového prostředí Trinity Desktop Environment (TDE, fork KDE 3.5, Wikipedie). Přehled novinek i s náhledy v poznámkách k vydání. Podrobný přehled v Changelogu.
Bylo vydáno OpenBSD 7.7. Opět bez písničky.
V Tiraně proběhl letošní Linux App Summit (LAS) (Mastodon). Zatím nesestříhané videozáznamy přednášek jsou k dispozici na YouTube.
24.2.2015 15:19
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
Bohužel, máme problémy s nastavením apache a nginxu tak, aby nebyl problém s více certifikáty na jednom IP (zejména win XP to nezkousnuly), ale na druhou stranu je taky pravda, že už se na to zase dlouho nikdo nedíval...
Win XP už nepodporuje ani jeho výrobce, proč byste měl vy? Dále všechny aktuální protokoly TLS1 TLS1.1 TLS1.2 podporují SNI, takže se bez obav můžete pustit do konfigurace https na jedné ip 
Co se týče MITM, jediné co teď útočník může udělat, je podvrhnutí jiného javascriptu
Získá ale hesla daného uživatele (pakliže uživatel napíše správné primární heslo).
24.2.2015 18:49
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
S takovým přístupem chcete navrhovat něco "bezpečnostního"?Ne to určitě ne, co se eshopu týká tak tam si dávám na bezpečnost majzla, tam už přestává legrace, navíc bezpečnostní prvky ve kterých by mohla být sebemenší díra se kontrolují (nejen já)
MD5proč ne? md5 nepoužívám k zahashování hesla a ověrování s jiným atp, pouze jako prostředek, jak významně změnit klíč i při sebemenší změně hesla, její slabiny znám, ale defacto mi vzhledem ke způsobu použití nevadí, nebo se ošklivě pletu?
Substituční šifra?ano, vlastně symetrická polyalfabetická substituční šifra, přesněji Vigenèrova šifra jak jsem se dočetl později (zarazilo mě, že jsem napsal víceméně to samý, bez její předchozí znalosti), jen oproti ní mám ještě 36 znaků navíc (malá písmena + číslice) a klíč šifry se mění s každým heslem stejně tak jako způsob, jakým se šifra používá (první znak hesla neznamená, že je zašifrován prvním znakem klíče). Vzhledem k tomu, že portál je určený k ukládání náhodných alfanumerických hesel a kromě znalosti jednoho z hesel nebo možnosti jeho vyzkoušení není (aspoň mi jej nikdo nezdělil) způsob jak rozhodnout zda je klíč správný, myslím, že je to dostatečné.
Obfuskace kódu algoritmu?Proč ne? ano, vím že obfuskace se ani zdaleka nepodobá např. kompilaci a kód je s měnší či větší dávkou snahy stále čitelný a mohl jsem to nechat pro účely testování bez obfuskace, ale když to můžu udělat pro případného útočníka složitější, tak proč toho nevyužít.
Používání prolomených algoritmů na webu?Co přesně je tím myšleno?
25.2.2015 06:19
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
nebo se ošklivě pletu
Nevím. Pokud nějakou funkci kryptologové označí jako prolomenou (a je mi jedno jak moc prolomenou) tak ji prostě přestanu používat. U MD5 k prolomení došlo před 19 lety, před 10 lety se hledaly kolize během sekund. Dneska už je beztak slabá, i kdyby nebyla prolomená. Za těchto okolností mi přijde poněkud zvláští si to obhajovat způsobem "na moje použití je ještě dobrá". Možná jo, nejsem kryptolog, ale právě proto, bych ji nepoužíval vůbec. Už jen proto, že se někdo může inspirovat a tu funkci použít v situaci, kam opravdu nepatří.
ale když to můžu udělat pro případného útočníka složitější
Zkušenější útočník si to jistě umí upravit do čitelné podoby, tomu obfuskace v ničem nezabrání. Security by obscurity prostě nefunguje.
Co přesně je tím myšleno?
Pokud potřebuje přístup pro WinXP, tak zřejmně musíte mít aktivovaný SSL. Z rodiny SSL už nezbyl jediný bezpečný protokol (SSLv1 nikdy nevyšelv platnost, SSLv2 byl pro chyby zrušen v roce 1996, SSLv3 potom v roce 2014). Pokud byste jej nemusel mít aktivní, tak klidně můžete použít SNI.
Pokud vezmu data (pouze z jednoho jediného eshopu) za posledního půl roku a vynásobím počet objednávek z WinXP s průměrnou cenou obj. za stejné období, dostávám se k cca k číslu 1.200.000,- Kč, myslím, že mít milion nebo nemít milion je k*rva velkej rozdíl ;)Když to postavíš takto, tak to vypadá tak, jak tvrdíš. Ovšem je také rozdíl přijít o 1 M z 10 M, z 50 M, ze 100 M… Navíc mluvíš o obratu, ne zisku, takže ono „nemít“ není úplně vhodné slovo. No a nakonec máš tam obdobnou chybu jako protipirátské organizace, když odhadují škodu. Opravdu zákazník půjde jinam, či nenakoupí, když to z XP nepůjde? Nebude to pro něj další pobídka k tomu, aby zvážil upgrade?
pro podobná hlavní hesla dává, zřejmě, výsledky uloženému heslu podobné.Hlavní heslo je prohnané přes md5tku právě z toho důvodu aby se klíč dostatečně lišil i při malé změně hesla, potom je ještě u každého hesla osoleno jiným stringem
A myslím si, že rozhodnutí o úspěchu nebo neúspěchu je v případě náhodných alfanumerických hesel nemožné pokud ani jedno z hesel neznám a nemám je jak vyzkoušet, to i za předpokladu že mám neomezenou sadu šifrovaných řetězců... tedy ovšem pokud by v uložených náhodně generovaných heslech nebyl nějaký vzor nebo pravidlo.Nebo pokud tam nějakou pravidelnost nevnese tvůj nakoleně vyrobený šifrovací algoritmus (nejspíš vnese).
Použitý algoritmus jsem napsal v rychlosti, nechtělo se mi hledat silný algoritmus který by nepoužíval jiné znaky než [A-Za-z0-9], potřeboval jsem to udělat rychle aby to mohla přítulka nějak prezentovat.Tak to je 100% děravé, pokud nemáš IQ 250. Myslíš, že dokážeš „v rychlosti“ vymyslet silný algoritmus? Co znamená nepoužíval jiné znaky než [A-Za-z0-9]? Ty píšeš bezpečnostní aplikaci a neumíš výstup šifry protáhnout base64?
Nejsem si úplně jistej jestli znalost šifrovacího algoritmu útočníkovi nějak pomůže, může mu to práci ulehčit ale zatím sem to udělal takhle...Security by obscurity nefunguje. Proč se vlastně snažím implementovat nějaký vlastní algoritmus a nepoužiješ nějaký, který vyvinul tým lidí, kteří tomu rozumí (nic proti, já si taky netroufnu vyvíjet vlastní šifru), a jehož bezpečnost už deset let prověřují odborníci z celého světa?
Všechny "spolehlivé" šifrovací algoritmy které znám, využívají v zašifrovaném textu spoustu jiných znakůCokoli (AES, Blowfish…) + base64.
navíc při dešifrování špatným klíčem dochází k rozbití celého řetězce, takže útočník snadno pozná že nemá správný klíčbase64 „špatným“ směrem.
Cokoli (AES, Blowfish…) + base64.Ale i base64 používá jiné znaky než číslice a písmena
base64 „špatným“ směrem.to je ale problém, já nevím kdy uživatel zadal heslo správně a kdy dobře, takže o tom jestli se ma enkodóvat nebo dekodóvat nedokážu rozhodnout
Ale i base64 používá jiné znaky než číslice a písmenaPlus, lomeno a rovná se. To by neměl být takový problém :) Navíc v heslu by stejně měly být i jiné, než alfanumerické znaky.
Ne že by to bylo nějak extrémně podstatné, ale v té hlavní nabídce nahoře je "Registace" místo "Registrace" :)
.
Vždy něco potřebuješ. Ty taky svěříš heslo prohlížeči…
Já jsem měl podobnu aplikaci udělanou asi pře deseti rokama - možná ji ještě někde mám (v PHP), měl jsem to na https, DB MySql všechny informace v DB šifrované aplikačním heslem (uloženém mimo DB), username a heslo pak šifrované SHA1 z části přihlašovacím hesla a soli, a nakonec se ke klientovy dostala blok dat o velikosti násobků 256znaků (myslím minimálně 1/2 dat musela být random), kde bylo heslo + kontrolní kód někde vložen a symetricky zašifrován a v JS se to decryptovalo na klientské straně dalším heslem. Ale je to naprd. pokud chceš přistoupit z nesvého HW, tak si stejně v háji, takže standardní způsob, otevření vzdálené ověřené klíčenky přes ssh tunel má mnohem vyšší úroveň…
Je však můj způsob šifrování a ukládání hesel online bezpečný?Ne. 1. Tvůj algoritmus není bezpečný. Párkrát jsem si taky zkusil nějaké schéma týkající se bezpečnosti navrhnout. Je to dobrý jako cvičení, když člověk pochopí, v čem to má díry. Ale prakticky to na 99.999..% k ničemu není. 2. Jestliže nedůvěřuješ HTTPS a hostingu, že přenesou a zpracují uživatelovo heslo bezpečně, nemůžeš věřit ani tomu, že doručí tvou JavaScriptovou aplikaci uživateli nenarušenou. Tzn. JS crypto nepřidává žádnou bezpečnost.
použít alespoň pro přenos Diffie-HellmanTo by se mi moc líbilo, ale jak zaručit bezpečnou výměnu klíčů?
možnost přidání položky (i stejného názvu)Je to psaný fakt na rychlo, i kontrolu duplicity emailové adresy a uživ. jména při registraci jsem dělal až dodatečně...
ve většině případů jsem schopen poznat, zda je heslo dekódováno či ne vzhledem k délce "hashe"Délka "hashe" se právě nemění, stejně tak jako se v něm neobjevují jiné znaky než [A-Za-z0-9], takže pokud mi něco neuniklo, takto to poznat nejde
Je to psaný fakt na rychlo, i kontrolu duplicity emailové adresy a uživ. jména při registraci jsem dělal až dodatečně...A o unikatnich klicich jste uz v mysql slysel?
Je však můj způsob šifrování a ukládání hesel online bezpečný?
Problém nebude až tak v šifrách a ukládání hesel, ale v tom, že je to webová aplikace – z toho pramení ta nebezpečnost/nedůvěryhodnost. Provozovatel webu nebo MITM útočník po cestě (není tam ani HTTPS) může kdykoli poslat uživateli upravený JavaScript, který ukradne jeho heslo/klíč. To je princip webových aplikací – neinstalují se a nemají z pohledu uživatele žádnou jasně definovanou verzi, kterou by si mohl zkontrolovat a zafixovat, zůstat u ní. I když si něco zkontroluje, stejně se mu nainstaluje a spustí jiný kód, kdykoli ho provozovatel umístí na server (nebo ho za letu změní útočník mezi nimi).
Chápu, že jsi to myslel dobře a aplikace vypadá přívětivě (jednoduchá, přehledná, použitelná), ale z pohledu bezpečnosti je to tragédie …tak jak je to postavené teď.
Jestli to nemá být jen školní cvičení a chceš to uvést do praxe, tak to předělej na intranetovou aplikaci pro firmy – dodávej to včetně zdrojových kódů pod svobodnou licencí, přidej k tomu možnosti auditování (kdo a kdy si jaká hesla četl), v další verzi i řízení práv, ať nevidí všichni všechno. Tím, že si to bude firma provozovat sama na své bezpečné síti, tak to začne mít smysl. Využití si to najde – zdaleka ne všude se používají asymetrické klíče, zdaleka ne všude má každý svůj osobní účet → firmy potřebují sdílené účty k různým systémům. Potřebují dát svým zaměstnancům přístup k těm heslům, aby mohli pracovat, ale zároveň to nemůže být texťák na sdíleném disku – je potřeba řídit práva k jednotlivým heslům a evidovat, kdo, co a kdy četl případně zapsal.
(ano, sdílené účty jsou špatné, klíče nebo důvěryhodná třetí strana a SSO jsou dobré… ale než se situace zlepší, dá se to překlenout nějakou takovou aplikací – lepší než mít v těch heslech bordel a posílat si je e-mailem nebo je mít volně hozená na sdíleném disku)
25.2.2015 13:35
Bystroushaak | skóre: 36
| blog: Bystroushaakův blog
| Praha
Ať to vezmu jak chci, tak mi celý nápad přijde jako opravdová bezpečnostní tragédie, a to i kdyby byl na intranetu.
Záleží, s čím to porovnáváš – pokud byl výchozí stav to, že se hesla válí na volně přístupných síťových discích, „Google Sheetech“, nešifrovaných discích zaměstnaneckých notebooků a posílají se nešifrovaným e-mailem kde komu… tak zavedení takovéto aplikace představuje zlepšení.
Být utočník v takové síti, tak se popadám smíchem za břicho a roním slzy štěstí. Všechny hesla centrálně, vždyť co víc si přát, stačí mi přepsat jen jeden soubor s javascriptem..
Servery a síťovou infrastrukturu ve firmě má pod palcem pár lidí, kteří kdyby chtěli, tak napáchají mnohem větší škody.
jj, textak na dropboxu ale napred protahnuty gpg .., ah vlastne jinak : http://www.passwordstore.org/
25.2.2015 23:19
Bystroushaak | skóre: 36
| blog: Bystroushaakův blog
| Praha
konečně někdo =D ano, výchozí stav je docela přesný, napřed se mi hesla válely všude možně, pak jsem začal používat klíčenky a nakonec jsem se dostal k aplikacím které ovšem byly pouze lokální což ne vždy stačilo.Tohle není taková chyba, protože to jsou jen tvoje hesla, která když ti vyhackuji počítač stejně odsniffuji (případně si dám hooky přímo do aplikací, takže ti nepomůže ani kopírování), tudíž vůbec nezáleží, kam si je uložíš, nebo jestli si je pamatuješ. Když vyhackuji ten server, tak mám rázem přístup ke všem uživatelům, jako kdybych se dostal někam na radius/active directory server. Nechci tvrdit, že řešení je technicky špatně - není. Jen vytváří bod potenciálního selhání, který pokud ti někdo hackne hosting ohrozí spousty uživatelů.
26.2.2015 08:37
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
mě to stačí
Ale mě ne. https://www.ssllabs.com/ssltest/analyze.html?d=uschovnahesel.cz
Kromě celkem očekávaných chyb (SSLv3, RC4, což se dá snadno napravit) mě zarazilo to, že ti StartSSL dává certifikáty od autority s SHA1. Dělal jsem u nich 5 crt tento týden a všechny mají root a intermediate SHA256. U tvých ne.
26.2.2015 11:30
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
Co bylo tomu předchozímu intermediate crt?
Tiskni
Sdílej:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
24.2.2015 13:59
25.2.2015 07:28
25.2.2015 09:28
25.2.2015 19:20
25.2.2015 13:22
25.2.2015 01:39