Planeta.OpenAlt.org

WiFi Teploměry - novinky letošního léta

září
22
Petr Stehlík
Od března jsem o WiFi Teploměrech nic nového nenapsal, tak dnes, v den podzimní rovnodennosti, se hodí malé ohlédnutí a nějaké novinky k tomu. Možná bude někoho zajímat, že používám už dvanáctou verzi plošného spoje (tedy že už proběhlo dvanáct cyklů zlepšení návrhu a zapojení), a zrovna v těchto dnech chystám verzi třináctou. Stejně tak verze firmware je nyní na hodnotě 11.0 a s přicházejícím podzimním počasím chystám další zajímavé změny a zlepšení.

Teď už ale pár slov o větších hardwarových změnách u WiFi Teploměrů za poslední půlrok:

Přepětí

Letní bouřky ukázaly, že venkovní vedení k teplotním čidlům funguje jako skvělá anténa na indukované přepětí, které poté chce zabít jak čidla, tak i samotný WiFi Teploměr. Proto všechny WiFi Teploměry, co vyjíždějí z mé "manufaktury", už od června obsahují ochranu proti přepětí na vstupu, kam se připojují čidla (teplotní a další).

Tato přepěťová ochrana by měla zachránit WiFi Teploměr i čidla k němu připojená při bouřce - blízký úder blesku by to sice nejspíš neustálo ani tak, ale na indukovaná přepětí v řádu tisíců voltů by to mělo pomoci výrazně. Samozřejmě ještě lepší je vést vedení k čidlům pod zemí nebo v kovových trubkách, které slouží jako Faradayova klec a stíní kabeláž před indukovaným přepětím...

Bezpotenciální kontakt

DC verze WiFi Teploměru původně měla na termostatickém výstupu napětí zdroje, tedy nejčastěji 9 V. Bylo to kvůli prapůvodnímu PWM. Čas ale ukázal, že mnohem praktičtější je mít bezpotenciální kontakt, tedy jen spínač, který se dá připojit třeba na místo tlačítka, co zapíná kotel či jakékoliv jiné zařízení s vlastním napájením. Proto DC verze WiFi Teploměru už někdy od jara obsahuje vestavěné maličké relé, jehož spínací kontakty jsou vyvedeny ven (v případě, že je vestavěn termostatický výstup).



Tímto relé a celým WiFi Teploměrem jsem také zachránil ledničku před jistou smrtí. Obecně je díky tomuto relé a jeho bezpotenciálním kontaktům DC verze WiFi Teploměru správnou náhradou za typický termostat, ať už je v ledničce, nebo třeba v obývacím pokoji, odkud řídí vytápění celého bytu/domu.

Zatím je toto relé opravdu maličké - zvládne spínat jen 0,5 A, ale chystám se vyvinout další verzi plošného spoje, kde ještě víc přeskládám vnitřnosti a tak se mi tam snad vejde i o něco větší, a hlavně výkonnější relé.

16 A = 3500 W

AC verze WiFi Teploměru dostala většího bratříčka, který dokáže při sepnutí termostatického relé přes sebe propustit až 16A proud nebo 3500 W výkonu.


Kromě silnějšího relé je tu ještě jedna zásadní výhoda: svorky terminálu už umožňují připojit nejen fázi (L) a nulák (N), ale i ochranný vodič (E), takže je možné jednoduše připojit kompletní trojlinku od zástrčky, a pak na výstup směrem k zásuvce či přímo spotřebiči.



Ostatní vlastnosti jsou stejné jako u 10A AC verze WiFi Teploměru - tedy stejný 3,5mm konektor pro teplotní čidla, stejná ochrana proti přepětí, stejný firmware. Tato verze ještě není zmíněná na webu www.teploty.info, ale snad brzy bude.

Co s WiFi Teploměrem/termostatem?

Baví mě, s jakými nápady lidé v e-mailech na info@teploty.info přicházejí - co všechno se dá měřit a řídit. Kromě obligátního vytápění vzdálených místností (nejčastěji na chatách a chalupách), a samozřejmě řízení topení v domech (často extrémně komplexních - s akumulačními nádržemi, soláry, kotli na pevná paliva řízenými dle teplot spalin v komíně!), se na jaře vyskytly udírny, přes léto vinné sklípky a bazény a teď na podzim vířivky a sauny. Po loňských tenisových kurtech (teplota povrchu) a rozvážkových chladírenských vozech jsou to myslím pěkné příklady použití. Málem jsem zapomněl na terária a teď nejnověji pak dokonce nápad měřit teplotu regenerace DPF (filtru pevných částic ve výfuku) za jízdy autem :-)

Huawei P10 Lite - zkušenosti

září
22
Petr Stehlík
Rád bych navázal na blogpost o kupování telefonu a popsal zkušenosti s Huawei P10 Lite po téměř pěti měsících střídmého používání..

První a nejdůležitější věc - bezpečnost systému: jeden z dvou hlavních důvodů pro koupi nového telefonu byl, že na můj předchozí telefon, skvěle fungující Nexus 5, výrobce přestal poskytovat bezpečnostní záplaty. Proto jsem koupil co možná nejnovější telefon (v podstatě v prvních týdnech distribuce v Česku), abych měl po co nejdelší dobu plnou podporu od výrobce. Od syna s Huawei P8 Lite jsem věděl, že Huawei se o Lite telefony celkem stará a záplaty pravidelně posílá.

U P10 Lite tomu tak však není a mám-li být upřímný, tak na tento model výrobce doslova sere (promiňte expresivní, leč naprosto přesný termín). Ještě začátkem července jsem měl "úroveň záplat 5. února", tedy pětiměsíční skluz! Pak se Huawei "pochlapil" a poslal první update systému, který posunul "úroveň záplat" o pouhé dva měsíce, tedy na začátek dubna. Je 21. září a já mám v telefonu pořád 5. duben!! Přes pět měsíců už je telefon děravý jak řešeto - aktuální útok přes Bluetooth mi dokáže hacknout přístroj do 10 sekund. Za tohle jsem platil 9 tisíc korun? Dopr!!

Nejhorší je, že jsem se nějak po fórech dopídil k tomu, že Huawei ve skutečnosti potichu nějaké updaty systému ubastlil, dokonce nejnovější má snad datum 24. srpna, ale jaksi je zapomíná pouštět mezi lidi přes OTA update. Navíc začátkem září nepochopitelně zrušil stránky, ze kterých si lidé mohli stahovat firmware a aplikovat nové verze svépomocí. Nyní jsou všichni odkázaní na OTA update, které, jak jsem výše uvedl, má nejméně 3-5 měsíční zpoždění, což je u této "vlajkové lodi nižší střední třídy" trestuhodná nedbalost!

Další věc - rychlost: telefon má sice neuvěřitelných 8 jader (4x víc než můj stolní počítač!), ale občas se očividně zamyslí, než dokreslí nějakou pitomou animaci třeba při spouštění či zavírání aplikace. Musím najít, kde se všechny vypínají. Když mi jednou docházela baterka, tak se mi systém sám nabídl, že animace dočasně vypne, a jak to byl potom svižný telefon!

Periferie: foťák celkem fotí, video natáčí (ale ne ve více FPS, pokud se člověk nespokojí se sedmkrát horším rozlišením nahrávky), displej je rozumný, čtečka otisků prstů spolehlivá a rychlá - celkem to jde.

Senzory: ty jsou docela peklo. Kdo by byl býval čekal nepřesnou GPS v roce 2017? Přitom tato čínská sleduje satelity americké, ruské a navíc i čínské. A stejně dokáže určit pozici s NEpřesností +- 13 metrů, zatímco Nexus 5 na stejném místě pracuje s +- 3 metry. Dost zlé! Asi jsem se měl držet Snapdragonu za každou cenu..

Dále elektronický kompas - ukazuje mírně šejdrem a ještě se u toho celou dobu třese jak ratlík. Kompas u Nexu je mnohem klidnější.

Baterie: to je snad jediný klad na celém přístroji. Při mém mírném používání vydrží telefon běžně 4 dny v provozu bez dobití. Pokud za 4-5 dní poklesne pod 20 % kapacity baterie, nabídne se automatické vypnutí animací a podobných nesmyslů, čímž se zbývající životnost protáhne z necelého dne na další třeba tři dny. A to ještě není ta nejagresivnější optimalizace, kterou systém nabízí - to by pak běžel ještě mnohem déle. Nevím, jestli tu tleskat Androidu 7, anebo Huawei/EMUI. Nevím, kdo z nich k tomuto přispěl více.

Navíc pokud už baterie potřebuje dobít, tak se s originální nabíječkou dobije z nuly na 100 % za necelou hodinu (protože nabíječka valí 9 V a 2 A). To je tak dobré, že jsem mu skoro odpustil chybějící indukční dobíjení.

Jinak mě velmi mrzí, že tento čínský telefon nemá probuzení poklepem na obrazovku. To, co má každý drek z Číny i za blbých 1000 korun, tento telefon postrádá. Nejhorší na tom je, že je to zase jen nějaká "vlastnost" konkrétního modelu dováženého do Česka. Modely pro jiné země tuto vlastnost mají dostupnou (sice někde "v tajném menu", ale mají). Přitom má kreslení gesty na obrazovku pro spuštění aplikací, ale probuzení poklepem či zvednutím ze stolu nejde. Ach jo.

To je tak asi vše, co si aktuálně vybavuju, že mě pálí. Podruhé bych si tento telefon nekoupil ani za 4000 Kč, větší cenu opravdu nemá (pro někoho, komu záleží na výše uvedených věcech). Sáhl bych nejspíš po Xiaomi či nějakém jiném Číňanovi (Lenovo / Motorola).

EDIT: zapomněl jsem na nové Nokie, taky výborné čínské telefony s čistým Androidem. A samozřejmě pak další telefony v edici Android One...

Oblíbené pořady na YouTube, díl VI

Po nějaké době je tu opět sbírka mých ublíbených pořadů na YT. Tentokrát trochu více ze světa technické hudby a suchého humoru.

Techmoan

Stará hifi technika, kamery do auta, různé technické kravinky, skvělý humor.

BigCliveDotCom

Kupuje nejlevnější shit, aby vy byste nemuseli. Sem tam něco shoří, vybuchne, někoho to zabije. Skvělý humor.

8-Bit Guy

Staré 8-bit počítače, opravy, vylepšení, review.

8-bit key

Sesterský kanál od stejného borce, staré levné klávesy, herní hudba.

Markus Fuller

Opravy, úpravy a nějaká hudba ze syntezátorů. Tentokrát z přesně opačné cenové kategorie jako v předchozím případě.

Phishing na klienty mBank

Poslední dny se šíří nová phishingová kampaň, která nabádá uživatele k tomu, aby si přes formulář změnili přihlašovací údaje do mBank.

Příspěvek Phishing na klienty mBank pochází z Spajk.cz

Školení WordPressu nejen pro učitele 28. listopadu 2017 v Praze

září
18
Vlastimil Ott
Pořád školím méně, než bych chtěl, ale tradicí se stává pražské jarní a podzimní školení pod křídly organizace VISK. Takže i tento podzim budu školit WordPress. Primárně je školení určeno učitelům, ale protože zájem o školení bývá v těchto kruzích bohužel omezený, tak jsme nikdy netrpěli přecpanou učebnou. Pokud bych školil klasicky komerčně, cena by...

Bitcoiny – založení peněženky

Bitcoin – založení peněženky Tímto článkem začínám miniseriál věnující se bitcoinu. Postupně si projdeme celým procesem, od teorie, přes založení

Příspěvek Bitcoiny – založení peněženky pochází z Spajk.cz

Avast šíří CCleaner s trojským koněm

Vtipná věc se podařila hackerům, kteří se nabourali do britské firmy Piriform. To je tvůrce populárního softwaru pro čistění a

Příspěvek Avast šíří CCleaner s trojským koněm pochází z Spajk.cz

Letí to

září
17
Vlastimil Ott
Znáte takový ten pocit… …když někde náhodou uvidíte své první auto, se kterým jste strouhali silnice, najeli první stovku (no dobře, celkově první nebyla, ale první na jednom autě), jezdili po celé republice, všichni říkali, „jé, ty máš ale hezké auto“ a někteří vám ho záviděli, zažili jste s ním první pořádnou nehodu a odtah...

Nešťastné důsledky omezování cílené reklamy pro online trh

Nešťastné důsledky omezování cílené reklamy pro online trh tereza.tumova@… Pá, 09/15/2017 - 09:34
Na základě tiskové zprávy IAB Europe

Studie ze září 2017 realizované GfK a IHS Markit o možných dopadech stávající podoby ePrivacy nařízení na trh s online reklamou, spolufinancované European Interactive Digital Advertising Alliance (EDAA) a Interactive Advertising Bureau Europe (IAB Europe)

 

Nemožnost shromažďovat a využívat údaje v online reklamě v sobě skrývá nezamýšlené důsledky, které ohrozí hospodářství EU, nezávislé sdělovací prostředky i dostupnost internetu jako takového. Tato a další zjištění přináší výzkum, který se zabýval pravděpodobnými dopady návrhu Nařízení o soukromí a elektronických komunikacích navrženého v loňském roce Evropskou komisí jako další pokračování nechvalně známého zákona o cookies (směrnice 2002/58 / ES).

Ekonomický přínos digitální reklamy zmizí

Analýza nezávislé finanční výzkumné společnosti IHS Markit ukazuje, že digitální reklama přispívá k ročnímu HDP EU jak přímo, tak díky růstu, který umožňuje evropským podnikům [1]. Nicméně až polovina trhu s digitální reklamou by mohla zmizet, kdyby vstoupila v platnost navrhovaná omezení využívání dat pro cílenou reklamu.

Studie IHS Markit odhaluje, že 66 % ze současných výdajů na digitální reklamu je závislých na behaviorálních datech. Užívání těchto dat pro cílenou reklamu zajišťuje 90 % ročního růstu trhu s digitální reklamou. Cílená online inzerce je o více než 500 % účinnější než reklama necílená a pro inzerenty je klíčová. Nebudou-li moci inzerenti využívat cílenou reklamu, omezí své investice do tohoto segmentu reklamy.

Postupné chudnutí mediálního trhu

Snížení výdajů na digitální reklamu by mělo vážné důsledky pro hospodářství EU stejně jako pro evropská média. Cílená digitální reklama zvyšuje hodnotu reklamních formátů na internetu o 300 %, což je zvlášť významné pro menší vydavatele, kteří by se jinak k příjmům z digitální reklamy nedostali[2]. Z ekonometrické analýzy IHS Markit vyplývá, že dopad omezování cílené reklamy by byl 5x větší pro menší nezávislé vydavatele.

Studie GfK zkoumala postoje k digitální reklamě, sdílení dat a k možnosti platit za obsah mezi 11000 uživateli internetu v 11 zemích EU[3]. Z výzkumu plyne, že pokud by byly zpravodajské weby a aplikace placené, 70 % respondentů by nebylo ochotno zaplatit. Kdyby existovaly zároveň s placenými zpravodajskými weby i neplacené služby, pak by bylo ochotno zaplatit jen 8 % dotázaných. Průměrná částka, kterou jsou Evropané ochotni zaplatit (3 € měsíčně), je mnohem nižší než částka, kterou potřebují zpravodajské stránky pro financování tvorby obsahu a případné náhrady ušlých zisků z reklamy. Přidá-li se k poklesu příjmů  z digitální reklamy neochota uživatelů platit za přístup k obsahu, nejsou vyhlídky vydavatelů optimistické. Shromažďování údajů je zásadní pro příjmy z cílené reklamy, která financuje online žurnalistiku. Omezení této možnosti způsobí, že média nebudou schopna nabídnout kvalitní obsah a služby, což bude mít nezamýšlený dopad na sociální a politické prostředí v Evropě.

Internetové služby, které již nebudou přístupné všem

Studie GfK rovněž odhalila pravděpodobný dopad poklesu výnosů z digitální reklamy na přístupnost k online světu jako takovému. Více než dvě třetiny Evropanů (68 %) nikdy nezaplatily za žádný online obsah nebo služby, které používají. Na otázku, jak by se jejich užívání internetu změnilo, pokud by museli za všechno na internetu platit, 88 % uvedlo, že by výrazně omezili čas, který tráví online. Naproti tomu 69 % respondentů uvedlo, že souhlasí s užitím údajů o prohlížení  (browsing data) pro reklamní účely, pokud si tím zajistí přístup k bezplatnému obsahu. Celkově 83 % uvedlo, že dávají přednost obsahu zdarma s reklamou před placeným obsahem.

Nečekané důsledky omezení cílené reklamy

„Tato zjištění by měla dát poslancům Evropského parlamentu velmi vážné důvody k obavám, až budou projednávat navrhované nařízení o soukromí a elektronických komunikacích,“ řekla Townsend Feehan, generální ředitelka asociace IAB Europe. „Alternativou cílené reklamy založené na datech není jen méně cílená reklama - je to digitální reklamní průmysl poloviční velikosti, než jakou má dnes. To má obrovské důsledky na zkušenost Evropanů s internetem, na hospodářství EU i existenci svobodných a vyvážených médií. Nejnovější výzkumy ukazují, že chuť platit za online obsah jednoduše není mezi občany EU životaschopná. Ignorování této skutečnosti je receptem na hospodářskou, společenskou a politickou katastrofu.“

Klíčové údaje studie s názvem Evropa online: zkušenost založená na reklamě (Europe online: An experience driven by advertising)

  • Dvě třetiny evropských uživatelů internetu nikdy za služby či obsah neplatily.
  • Uživatelé preferují bezplatné služby a obsah (s reklamou či bez ní) před placenými (63 % vs. 40 %).
  • 9 z 10 uživatelů by přestalo využívat bezplatné zpravodajské weby či aplikace bez ohledu na to, zda jsou na nich reklamy nebo nikoliv, pokud by za tyto služby či obsah museli platit.
  • Uživatelé si sice cení svého soukromí v online prostředí, ale ještě důležitější je pro ně hodnota online služeb, které mají k dispozici zdarma.
  • Evropští uživatelé jsou ochotni poskytnout svá data pro účely cílené reklamy, aby dostali přístup k bezplatnému obsahu financovanému z reklamy. Dvě třetiny by byly ochotny poskytnout svá data za tímto účelem, 8 z 10 by preferovalo bezplatné stránky s reklamou před tím, než aby za obsah platili.
  • Uživatelé dávají přednost snadnému přístupu k informacím o tom, co se s jejich údaji děje, před nutností při každé návštěvě stránky dávat souhlas s použitím cookies. Uživatelé zároveň vnímají pozitivněji možnost mít přístup informacím a rozhodovat se případ od případu, než mít standardní výchozí nastavení, které brání sdílení dat (67 % vs. 8 %), přičemž tento postoj je ještě markantnější u uživatelů z Východní Evropy (v ČR 75 %).

 


[1] The Economic Contribution of Digital Advertising in Europe – IHS Markit Study – vydáno 2017.

[2] The Economic Value of Behavioural Targeting in Digital Advertising – IHS Markit Study – vydáno 2017.

[3] Europe Online: An Experience Driven by Advertising – GfK Study – vydáno 2017.

Fotogalerie

Wallpapery z iOS 11

iOS 11 wallpapery iOS 11 vyjde 19. září, ale malou ochutnávku z něj můžete mít již teď. Wallpapery, které budou použité v nové

Příspěvek Wallpapery z iOS 11 pochází z Spajk.cz

Pozvánka na 144. sraz OpenAlt – Praha

září
13
Openalt.org

Máš rád svobodný software a hardware nebo se o nich chceš něco dozvědět? Zajímá tě DIY, CNC, SDR nebo morseovka? Přijď na sraz spolku OpenAlt – tentokrát netradičně v pondělí: 18. září od 18:00 v Radegastovně Perón (Stroupežnického 20, Praha 5).

Lamy na 144. brněnském srazu

září
12
Openalt.org

Další sraz zpříznivců svobodného přístupu nejen v oblasti SW probhěne jako součást celosvětového Software Freedom Day (počet zapojených států nebude náhoda). Zahájíme stylovou exkurzí mezi lamy, poté se přesuneme k povídání o open tématech a občerstvení na nedalekou Kamenou horku. Zahájení jako obvykle v 18:00 třetí pátek v měsíci tj. 2017-09-15 (lamy již od 17:00 viz. dále)

SPIR připravil online průvodce GDPR: přehledný a srozumitelný popis kroků a změn, kterými firmy musí projít

SPIR připravil online průvodce GDPR: přehledný a srozumitelný popis kroků a změn, kterými firmy musí projít tereza.tumova@… Út, 09/12/2017 - 07:09
Tisková zpráva

Praha 12. září 2017 ­–  Sdružení pro internetový rozvoj (SPIR) připravilo online průvodce problematikou Obecného nařízení o ochraně osobních údajů (GDPR). Reaguje tak na opakované žádosti trhu o poskytnutí srozumitelného a jasného návodu, jak postupovat. S přibližující se účinností GDPR v květnu 2018 řada zvláště menších společností hledá informace, které jim pomohou se zorientovat v tom, co je nezbytné provést. Osobní údaje, interní audit, analýza rizik nebo informace, zda firmy potřebují pověřence pro ochranu osobních údajů, to jsou některá z témat, kterým se online průvodce věnuje.

V posledním půl roce dostáváme od našich členů, ale i od řady dalších společností digitální branže žádosti o informace a konkrétní návod, jak postupovat, aby firmy byly v souladu s GDPR. Protože se této problematice věnujeme několik let, rozhodli jsme se vytvořit online průvodce, který pokrývá nejčastější oblasti nakládání s osobními údaji pokud možno jednoduše a srozumitelně. Jedná se o první verzi, kterou budeme průběžně upravovat, podle toho, jak bude EU, potažmo národní regulátor, vydávat vodítka a komentáře k jednotlivým tématům,” popisuje vznik projektu Kateřina Hrubešová, výkonná ředitelka Sdružení pro internetový rozvoj.

SPIR se tématu ochrany osobních údajů kontinuálně věnuje již více než čtyři roky. GDPR pravidelně zařazuje na program každoroční Internet Advertising Conference (IAC), v květnu letošního roku publikoval infografiku, partnersky se účastnil konference GDPR minus 365 dní, účastní se pracovních setkání s Úřadem pro ochranu osobních údajů, pracovní skupiny k legislativě v oblasti ochrany osobních údajů a v srpnu připravil video, které shrnuje tři základní kroky, které by měla firma učinit, aby se na Nařízení připravila. Ve své činnosti týkající se GDPR bude SPIR nadále pokračovat jak formou aktivní participace na pracovních skupinách a workshopech, tak aktualizací online průvodce a přípravou dalších materiálů

Online průvodce naleznete na adrese http://gdpr.spir.cz.

vpsAdmin v2.9 přináší jednoduchý monitoring VPS

září
11
vpsFree.cz

Vydali jsme nový vpsAdmin, který přináší hlavně možnost jednoduchého monitoringu vašeho VPS.

Nový vpsAdmin v2.9 přináší zejména jednoduchý monitoring VPS. Není to monitorovací systém, který byste mohli využívat pro sledování stavu vlastních služeb, pracuje jen nad údaji, které vpsAdmin sbírá z VPS a nodů. Aktuálně monitoring kontroluje volné místo v datasetech, využívání CPU podle pravidel a počet přenesených dat. Monitoring jen upozorňuje, sám žádnou akci nevykoná.

Nejdůležitější je funkce sledování volného místa ve VPS, neboť už se mnohokrát stalo, že místo nečekaně došlo a na VPS se pak nedalo ani přihlásit. Takto budete o zaplněném disku včas informováni.

V každém e-mailu z monitoringu máte odkaz na tzv. acknowledge, tj. potvrzení události. Pokud událost potvrdíte, berete ji tím na vědomí a vpsAdmin o ní až do vyřešení dále nebude informovat. Lze nastavit i kompletní ignorování události, tzn. efektivně vypnutí monitoringu. Sledované události najdete ve vpsAdminu v menu Status → Monitoring.

Jestli k tomu máte nějaké připomínky, nebo to nefunguje dle očekávání, dejte prosím vědět. Další změny jsou spíše na pozadí, viz changelog.

Jak skrýt fotky v aplikaci Fotky Google

Pokud používáte zálohování fotografií z telefonu na Google účet, určitě na něm občas někomu nějakou fotografii ukážete. Přátelům fotky z večírku, rodině

Příspěvek Jak skrýt fotky v aplikaci Fotky Google pochází z Spajk.cz

Renovace reprobeden

září
07
Josef Jebavý
Po mnoha letech bezproblémového užívaní jsem musel přistoupit k renovaci reprobeden, protože při testování opraveného zesilovače a historické elektrické kytary odešel basový reproduktor ........

Změna hashování existujících hesel

září
05
Michal Spacek

Z internetové nákupní galerie Mall.cz unikla uživatelská data včetně zahashovaných hesel. Někdo zatím neznámým způsobem získal přes 750 tisíc účtů, nahrál je na Ulož.to a odkaz v 27. července zveřejnil na Pastebinu. O incidentu informovala firma prostřednictvím poměrně skvělého příspěvku na blogu a e-mailu zákazníkům, ve kterém jim oznamuje, že Mall hesla resetoval a pokud se chtějí znovu přihlásit, tak si musí nastavit heslo nové. Data na Ulož.to již nejsou dostupná, ale Lupa soubor získala a prozkoumala a zjistila, že obsahuje 750 tisíc e-mailových adres a hesel v čitelné podobě. U části zákazníků byla uvedena i telefonní čísla.

Zatím není známé, jakým způsobem útočník získal čitelná hesla, Mall totiž údajně hesla hashoval:

Od listopadu 2012 jsme bezpečnost hesel zajišťovali hashovací metodou SHA1 + unikátní solí a od října 2016 chráníme přístupové údaje jednou z nejsilnějších hashovacích metod bcrypt. Do roku 2012 byly údaje hashovány metodou MD5, která dnes již není považována za bezpečnou. Většina prolomených hesel pochází právě z doby, kdy byla používána tato metoda. U starších účtů jsme proto změnili heslo a automaticky je převedli na zmiňovanou nejnovější hashovací metodu bcrypt, kterou aktuálně chráníme přístupové údaje všech účtů.

Pomineme-li, že bcrypt je z roku 1999 a že Mall.cz dříve MD5 zatajil, tak z toho nelze vyčíst, jestli hesla hashovaná pomocí MD5 nějak převáděli na bezpečnější bcrypt. V komentářích pod příspěvkem na blogu pak dodávají, že heslo „přehashovali“ po úspěšném přihlášení uživatele.

Jak to lze udělat lépe, aby ani při případném úniku nebyla ohrožena stará slabě hashovaná hesla uživatelů, kteří se dlouho nepřihlásili? Před několika lety jsme to udělali na Slevomatu a kdyby na to dělala návod IKEA, tak by vypadal asi nějak takhle:

SHA-1 → bcrypt nebo Argon2i

Změna hashování

Nejdřív bych měl připomenout, co to vlastně takový na ukládání hesel nevhodný algoritmus je. Jsou to všechny ty MD5, SHA-1, SHA-2, SHA-3 a to v jakékoliv variantě. Se saltem („solí“), nebo bez, „zesílené“ pomocí několika stovek tisíc iterací, nebo jen jedno volání, je to jedno. Na ukládání hesel by se měla použít některá z těchto funkcí: Argon2i, bcrypt, scrypt, nebo PBKDF2. Jsou relativně pomalé, takže pro lamače je časově i finančně náročně hesla cracknout.

Také bych měl zmínit, že tento článek není o reakci na bezpečnostní incident. Pokud už vám jakkoliv uložená hesla unikla (a vy jste si toho všimli), tak je všem uživatelům vyresetujte. Nová hesla pak rovnou ukládejte pomocí „nového“ hashe.

Jestli používáte PHP, tak na uložení použijte funkci password_hash(..., PASSWORD_DEFAULT) a na ověření password_verify(). „Algoritmus“ PASSWORD_DEFAULT aktuálně zajistí použití bcryptu, do budoucna to může být např. Argon2i, nicméně hashe uložené dnes půjdou ověřit i po změně defaultního algoritmu. Ten se totiž určuje jen při vytváření hashů, pro ověření se použije nastavení zapsané do samotného hashe, resp. nastavení je součástí výstupu z password_hash().

Pokud chcete vylepšit hashování hesel již zaregistrovaných uživatelů, tak máte tyto možnosti:

  1. Vymazat hesla všem uživatelům a tím je donutit zadat nové heslo hashované novým způsobem. To není moc dobrý nápad, uživatelé nebudou nadšení, bude je to otravovat a budou se vcelku oprávněně zlobit, proč jste jejich hesla nezabezpečili mnohem dříve. Reset hesel se dá provést v aplikacích pro pár stovek zaměstnanců, ale rozhodně ne v aplikacích, do kterých se může registrovat kdokoliv.
  2. Můžete heslo uživatele „přeuložit“ po úspěšném ověření při přihlašování, v tu chvíli totiž v aplikaci máte heslo k dispozici v čitelné podobě, takže ho můžete pěkně zahashovat bezpečnějším hashem. Z pohledu uživatele je tento způsob mnohem lepší, nicméně databáze bude stále obsahovat slabé hashe hesel uživatelů, kteří se od změny hashování nepřihlásili. A těch může být docela dost, protože například zvolili „permanentní přihlášení“ apod. Podle všeho Mall zvolil právě tento způsob.
  3. Všechny staré hashe najednou „přehashujete“ novým silnějším hashem a při ověřování pak vezmete uživatelské heslo z přihlašovacího formuláře, zahashujete starým hashem a pošlete na ověření novým hashem. Když se ověření povede, tak to trochu vyčistíte: heslo zahashujete pouze novým hashem a uložíte. První krok tohoto způsobu nevyžaduje žádnou akci na straně uživatele, takže ochrání i hesla uživatelů, kteří se dlouho nepřihlásili.
  4. Můžete zkusit cracknout všechna hesla a ta cracknutá pak uložit pomocí nového algoritmu. Kdepak, nedělejte to. S největší pravděpodobností nedokážete obhájit útočení na uživatelská hesla, mohla by se z toho celkem jednoduše stát PR pohroma. Navíc byste potřebovali přesunout hashe z vaší databáze někam mimo a nějakou dobu někde uchovávat cracknutá hesla v čitelné podobě, z čehož se může rychle vyklubat i bezpečnostní problém. Vaší prací je chránit hesla, ne na ně útočit nebo je nechat uniknout. Tohle prostě nedělejte.

Pojďme ten třetí způsob trochu rozebrat na atomy. V příkladech se objeví pár PHP funkcí, ale na principu to nic nemění, ten se dá využít i v jiných jazycích nebo prostředích (třeba takhle se to dělá v Djangu). Kód zde uvedený je spíš ukázkou, jak takovou věc udělat, rozhodně ho nekopírujte, tohle není Stack Overflow.

Úprava databáze

Ujistěte se, že do sloupečku password se vejde nový hash, doporučuje se nastavit VARCHAR(255) nebo podobný typ, který pojme alespoň těch 255 znaků, bude se to hodit i pro případné rozšiřování do budoucna.

Budete potřebovat nový sloupeček, ve kterém bude uložen způsob hashování hesla pro toho konkrétního uživatele. Skript na přehashování (viz dále) může běžet klidně i několik dní, takže v databázi budou staré i nové hashe zároveň a přihlašování s tím musí počítat. Ten nový sloupec pojmenujeme např. type. Nenastavujte NOT NULL, hodnota NULL bude určovat starý hash.

Pokud váš starý hash používá unikátní salt pro každého uživatele (statický salt, stejný pro všechny uživatele, není salt), tak budete ještě potřebovat sloupeček, do kterého tento „starý“ salt uložíte, můžeme mu říkat třeba old_salt.

Tabulku s přihlašovacími údaji není třeba upravovat, typ a případný starý salt si můžete ukládat do jednoho sloupečku společně s hashem a oddělit je třeba dvojtečkou nebo dolarem a při zpracování si je zase „odseknout“. Pro jednoduchost budu používat samostatné sloupečky.

Skript na přehashování

Vlastní přehashování zajistí skript, který spustíte a on najednou „upgraduje“ všechna hesla. Skript vezme třeba tisíc řádků s type IS NULL a pro každý provede tuhle operaci:

  1. Vypočítá nový hash „přehashováním“ starého:
    $newHash = password_hash($row->password, PASSWORD_DEFAULT)
  2. Pokud starý hash používá salt, tak ho uloží do proměnné např. $oldSalt
  3. Provede UPDATE v databázi a uloží $newHash do sloupce password (a případně $oldSalt do sloupce old_salt), type nastaví na 1, ale vše pouze v případě, že typ je NULL, abychom nepřepsali heslo změněné uživatelem v době od vytažení dat z databáze do přehashování

Kód by mohl vypadat nějak takto:

$rows = $db->query('SELECT ... FROM ... WHERE type IS NULL LIMIT 1000');

foreach ($rows as $row) {
    $newHash = password_hash($row->password, PASSWORD_DEFAULT);
    $oldSalt = ...;
    $db->query('UPDATE ... SET password = ?, old_salt = ?, type = 1
        WHERE username = ? AND type IS NULL',
        $newHash,
        $oldSalt,
        $row->username
    );
}

Doporučoval bych takový skript spustit z příkazové řádky. Může totiž běžet docela dlouho, v případě velkých databází klidně i několik dní. Taky může z nějakého důvodu spadnout a vy ho budete muset spustit znovu. To nebude vadit, s tím se počítá, již přehashovaným heslům se skript vyhne.

Před spuštěním skriptu je potřeba upravit přihlašování, aby počítalo i s novým hashem.

Přihlašování

V databázi budeme mít uložen (nový) hash z původního (starého) hashe, takže do funkce na ověření hesel nebudeme posílat heslo zadané uživatelem do formuláře, ale nejdříve musíme znovu spočítat původní (starý) hash a teprve až ten pošleme na ověření. Ověřování ale musí počítat i se zatím nepřevedenými hesly, jinak by se část uživatelů nemohla přihlásit, dokud se jim heslo nepřehashuje.

K rozhodnutí jak uživatele ověřit využijeme obsah sloupce type. Neprovádějte ověření hesla nejdřív pomocí „nového hashe přes starý“ a pak, v případě selhání, pomocí starého. To je zbytečně pomalé, využijte raději ten sloupeček. Vůbec nevadí, když je způsob hashování známý, stejně musíte předpokládat, že nepřítel systém zná.

Podstatná část kódu:

$row = $db->query('SELECT ... FROM ... WHERE username = ?', $_POST['username']);

switch ($row->type) {
    case null:  // starý hash
        $verified = hash_equals($row->password, sha1($row->old_salt . $_POST['password']));
        break;
    case 1:  // nový hash přes starý
        $verified = password_verify(sha1($row->old_salt . $_POST['password']), $row->password);
        break;
    default:
        $verified = false;
        break;
}

Pokud starý hash nepotřebuje salt, tak $row->old_salt samozřejmě vynechejte. Funkce pro bezpečné porovnávání hashů hash_equals() je dostupná od PHP 5.6, pokud máte starší, tak upgradujte. V nejhorším případě ji můžete nahradit za obyčejné porovnání $row->password === sha1(...), to platí i pro ostatní jazyky.

Takovéhle „skládání“ různých hashovacích funkcí není z kryptografického hlediska úplně čisté, běžně se nedoporučuje a není to moc prozkoumáno, ale v tomto případě je mnohem lepší, než používat slabé hashe pro hesla uživatelů, kteří se dlouho nepřihlásí.

Uložení čistého nového hashe

Po úspěšném přihlášení má aplikace k dispozici heslo v čitelné podobě, takže ho můžeme zahashovat „čistým“ novým hashem a této kryptografické nedokonalosti se zbavit. Využijeme opět sloupeček type, aby ověřování hesla vědělo, že tentokrát nemá před voláním password_verify() dělat žádný cviky. V tomto případě určitě nepoužívejte ověřování stylem nejdřív zkusím čistý nový hash, pak nový přes starý a pak starý, šlo by se totiž přihlásit jen hashem nalezeným v nějaké zveřejněné databázi, jak správně podotkl David Grudl.

Připravíme si funkci pro uložení nového hashe, nastavení nového typu (2 pro „čistý“ hash) a případné vynulování starého saltu, už ho nebudeme potřebovat:

function saveNewHash($username, $password)
{
    $db->query('UPDATE ... SET password = ? , old_salt = NULL, type = 2 WHERE username = ?',
        password_hash($password, PASSWORD_DEFAULT),
        $username
    );
}

A po ověření hesla pomocí nového + starého hashe ji zavoláme. Můžeme ji volat také po ověření jen pomocí starého hashe, ničemu to vadit nebude a aspoň nepatrně ulehčíme skriptu na převod všech hashů. Dále přidáme větev case 2 pro ověření pouze pomocí nového hashe:

$row = $db->query('SELECT ... FROM ... WHERE username = ?', $_POST['username']);

switch ($row->type) {
    case null:  // starý hash
        $verified = hash_equals($row->password, sha1($row->old_salt . $_POST['password']));
        if ($verified) {
            saveNewHash($_POST['username'], $_POST['password']);
        }
        break;
    case 1:  // nový hash přes starý
        $verified = password_verify(sha1($row->old_salt . $_POST['password']), $row->password);
        if ($verified) {
            saveNewHash($_POST['username'], $_POST['password']);
        }
        break;
    case 2:  // pouze nový hash
        $verified = password_verify($_POST['password'], $row->password);
        break;
    default:
        $verified = false;
        break;
}

Spuštění skriptu

Náš úžasný skript na přehashování můžeme konečně spustit. Doporučuji ho předtím velmi dobře otestovat a případně si udělat zálohu té správné tabulky, kdyby se něco náhodou nepovedlo. Po doběhnutí skriptu můžete odstranit větev case null z přihlašování, staré hashe by již v databázi neměly být. Dá se to ověřit pomocí SELECT COUNT(*) ... WHERE type IS NULL, výsledkem by měla být nula.

Pokud jste si udělali zálohu, tak ji nezapomeňte bezpečně smazat. To se týká i všech ostatních pravidelných záloh databáze, ty také zlikvidujte nebo z nich staré hashe odstraňte. Zálohy se velmi často ztrácejí a mohou být zdrojem úniku starých slabých hashů.

Co dál

Nezapomeňte při registraci a změně hesla (i zapomenutého) ukládat pouze nový hash a nastavit typ na „pouze nový“ (v našich příkladech to je type = 2). Tedy v podstatě to, co dělá námi vytvořená funkce saveNewHash($username, $password).

Použití silného (a relativně pomalého) hashe samotnému lámání hesel nezabrání, jen útočníkovi bude trvat příliš dlouho, takže ho to snad přestane bavit. Slabá hesla typu password i přesto získá vcelku rychle (protože budou to první, co vyzkouší), takže by bylo fajn mu v crackování nějak zabránit. Občas se doporučuje přimíchat do hesla tzv. pepper („pepř“, jakože sůl a pepř, chápete), tedy další statickou „sůl“ stejnou pro všechny uživatele. Pravděpodobnost, že by útočník získal databázi i pepper z konfigurace, a mohl tak začít crackovat hesla, je o dost menší než že získá jen databázi.

Na pepper zapomeňte, hashovací funkce na jeho použití nejsou navržené a na jeho použití neexistuje žádný rozumný výzkum. Stejného efektu se dá dosáhnout zašifrováním hashů (ne hesel), to je navíc kryptograficky čistá operace. Ale o tom zas někdy příště.

V některém dalším článku si také ukážeme jak transparentně měnit parametry hashovacích funkcí, příp. jak změnit algoritmus z bcryptu na Argon2i. V současnosti je použití bcryptu stále v pořádku, hesla ochrání dostatečně i když použijete defaultní cost (měl by být aspoň 10) a na Argon2i se dá přejít třeba až bude v PHP jako PASSWORD_DEFAULT. Pak to bude stačit udělat způsobem 2), tedy přeuložením po přihlášení, ale nebudeme předbíhat.

Prosím, chraňte hesla svých uživatelů.

Hlasujte pro naše přednášky na LinuxDays

září
05
vpsFree.cz

Podzim se blíží a s ním i tradiční konference LinuxDays, která proběhne 7. a 8. října v Praze. Hlasujte pro přednášky!

Šestý ročník konference LinuxDays se blíží, jako každý rok se jí plánujeme zúčastnit a jako obvykle máte možnost ovlivnit její podobu. Podívejte se na fotky z minulého ročníku.

Opět plánujeme stánek, budeme si povídat s lidmi a připravili jsme i několik zajímavých přednášek. Budeme rádi, když budete hlasovat o přednáškách pro letošní rok a budeme rádi, když nás podpoříte. Co konkrétně si naši členové připravili?

ZFS na Linuxu: co je nového (Pavel Šnajdr)

Linuxové distribuce houfně opouštějí Btrfs, ale ZFS je tu s námi dál a valí se neohroženě zpět. Jak to vypadá se ZFS na Linuxu? Přichází nativní šifrování, declustered raid, all-flash pole založené na na ZFS a podobně.

Smart karty v Linuxu a proč by vás měly zajímat (Jakub Jelen)

Bezpečné uložení privátních klíčů a identifikačních údajů není jednoduché. Smart karty to umožňují relativně jednoduše. Ale je jích mnoho druhů, které je potřeba podporovat, každý používá jiné karty, některé nemají otevřenou specifikaci nebo implementují (uzavřené) ISO standardy.

Icinga 2 (na steroidech) (Věroš Kaplan)

Po instalaci umí Icinga spoustu věcí, ale pokud ji trošku poladíme, tak toho dokáže toho mnohem víc. Hlídat z několika nezávislých lokalit, dynamicky měnit svoji konfiguraci podle stavu zdrojů, a mnohé další. Pojďme se na to podívat.

nftables – budoucnost linuxového firewallu (Petr Krčmář)

Firewall iptables je s námi v Linuxu už přes 15 let a v poslední době mu roste konkurent: nftables. V čem je zajímavý, proč je lepší a proč se o něj zajímat už teď?

MySQL sežere Vaše data (David Karban)

Při přípravě MySQL školení jsem narazil na několik věcí, které u databáze nečekáte. S MySQL je velice snadné ztratit data. Nevěříte? Ukážu.

Errbot: chat-centric way of life (Michal Halenka)

Praktická ukázka vlastností chatovacího bota Errbot. Prezentace obsahuje představení Errbota, instalaci, základní možnosti použití, a tvorbu vlastních pluginů.

IPv6 tunely pomocí OpenVPN (Ondřej Caletka)

Když skončila platforma SixXS, ocitla se spousta sítí bez globální konektivity. Bohužel, ne všude je možné dočkat se nativního IPv6 od ISP, často je problém i s veřejnou IPv4 adresou. Je tedy třeba vymyslet nějaké dočasné náhradní řešení. Ve vpsFree.cz jsme připravili vlastní tunelovací službu, kterou provozujeme pomocí OpenVPN. Jak to funguje, jaká jsou úskalí a jak se zapojit?

Na čem rozeběhnout startup aneb opravdu potřebujete platit za cloud? (Ondřej Flídr)

Cloud je sexy, IaaS je sexy, tahat se se serverama a kabeláží ne. Nebo je to jinak? Pojďme se pobavit jak vybrat správnou variantu infrastruktury pro váš projekt a to nejen z pohledu coolovosti řešení ale i z pohledu technického a obchodního. Odstrašující příklady z praxe included!

Disassembling pomocí radare2 (Tomáš Antecký)

Představení open sourcové sady nástrojů pro reverzní inženýrství. Část přednášky bude věnována praktické ukázce použití radare2 k vyřešení jednoduchého crackme.

Tvorba multiplatformních GUI aplikací v jakémkoliv jazyce (Daniel Kolesa)

Používání C knihoven z jiných programovacích jazyků byl vždycky trochu problém. Je sice možné napsat bindingy, ale složitost těch stoupá s velikostí původního projektu a nutnost další údržby často znamená to, že pokrytí není ani zdaleka ideální. S novým řešením jsme přišli v Samsung Open Source Group a projektu Enlightenment, resp. jeho aplikačním frameworku EFL.

Tak hlasujte a hlavně určitě přijďte!

Jak stahovat soubory z Uloz.to do iOS

Jak stahovat soubory z Uloz.to do iPhonu či iPadu Na netu najdete mnoho návodů jak stahovat soubory z populárního serveru Ulož.to do

Příspěvek Jak stahovat soubory z Uloz.to do iOS pochází z Spajk.cz

Slovenští novináři mají po 20 letech aktualizovaný etický kodex

Slovenští novináři mají po 20 letech aktualizovaný etický kodex tereza.tumova@… St, 08/30/2017 - 07:36

Slovensko přijalo v červenci aktualizovanou verzi Etického kodexu novináře. Jedná se o zásadní krok, které mj. zohledňuje aktuální potřeby z online prostředí.

V rámci Asociace na ochranu noivnářské etiky (zastřešující organizace pro Tiskovo-digitální radu) se ke znění Etického kodexu vyjadřovali zástupci vydavatelů, SSN (Slovenský syndikát novinářů) a zástupci online prostředí reprezentovaní IAB Slovakia.

V rámci aktualizace kodexu došlo také k přejmenování Tiskové rady SR na Tiskovo-digitální radu a vyvrcholí na podzim jejím rozšířením o čelny z online prostředí.

Kodex naleznete zde.

Více informací zde.

Chrome, `ERR_SPDY_PROTOCOL_ERROR` a chybná HTTP hlavička

:-( This site can’t be reached ERR_SPDY_PROTOCOL_ERROR

Jedním z důvodů zobrazení chyby ERR_SPDY_PROTOCOL_ERROR může být špatná HTTP hlavička posílaná ze serveru. Chrome je trochu citlivka, při zpracovávání binárního HTTP/2 mu vadí i hlavička s mezerou místo pomlčky (např. Referrer Policy místo Referrer-Policy), takže si zkontrolujte, jestli všechny hlavičky posíláte správně. Firefox takovou chybnou hlavičku ignoruje a stránku načte.

Jak najít hlavičku, která to způsobuje? Jděte do chrome://net-internals/#events (na odkaz se nedá kliknout, ale můžete ho jednoduše zkopírovat), do vyhledávacího políčka zadejte vaši doménu (v mých příkladech to je example.com), v jiném tabu prohlížeče zkuste váš web načíst. Pak se vraťte do chrome://net-internals/#events a klikněte na řádek s HTTP2_SESSION v sloupci Source Type.

chrome://net-internals/#events HTTP2_SESSION Source Type

V pravé části okna se objeví detaily protokolu HTTP/2, důležitá je tato část:

t=50413 [st=7]  HTTP2_SESSION_RECV_INVALID_HEADER
                --> header_name = "referrer policy"
                --> header_value = "same-origin"
t=50413 [st=7]  HTTP2_SESSION_SEND_RST_STREAM
                --> description = "Could not parse Spdy Control Frame Header."
                --> error_code = "1 (PROTOCOL_ERROR)"
                --> stream_id = 3

Všimněte si řádku s HTTP2_SESSION_RECV_INVALID_HEADER, pod ním je uvedená chybná hlavička, v tomto případě je to referrer policy, tedy s mezerou, bez pomlčky. HTTP/2 názvy hlaviček zmenšuje, takže i když z aplikace pošlete hlavičku Referrer-Policy, tak do prohlížeče dorazí referrer-policy. Nebo, jako v tomto případě, nevalidní hlavička referrer policy.

V chrome://net-internals/ se dozvíte o vnitřních procesech a požadavcích prohlížeče a extenzí, které ani Developer Tools nezobrazí, doporučuju to pořádně prozkoumat, může se vám to později hodit. Já jsem toho využil například při zkoumání „VPN“ v Opeře i nešifrované „VPN“ v UR browseru.

Snění o dokonalém systému souborů

Problematikou ukládání dat se v praxi zabývám více než 10 let, a jako koníček mi to bylo v podstatě od základní školy, kdy jsem na disketách (FAT) kamarádům vytvářel kružnice místo stromů a tropil další hlouposti. A přibližně těch 10 let mi v hlavě leží myšlenka na dokonalý systém souborů. V podstatě od té doby, co jsem si poslechl první přednášky o ZFS.

Než se pustíme do popisu toho, jak by podle mě měl být FS postaven, ukažme si několik příkladů. Postupně asi bude více jasné, z jakého základu moje myšlenka vychází. Omezuji se pouze na FS s podporou více diskových zařízení, staré jednoduché fs nad jedním diskem už jsou pro mě v podstatě pasé.

ZFS

Začněme hned tam, kde moje myšlenky na dokonalý fs začaly. U ZFS. ZFS je velmi vyspělý fs, který umí použít více diskových zařízení, umí se vypořádat s výpadkem disků a to hned v několika modech. Jak jsem psal již v dřívějším článku, ZFS řeší redundanci na úrovni vdevů:

V ZFS jsou disky spojovány do vdevů (typu single, mirror, raidz), tyto vdevy se následně spojují do zpoolu odkud vyrůstají datasety v podobě fs, nebo zvolů (blokové zařízení).

Bohužel, s vdevy nelze hnout. Pokud začněte s mirrorem (zfs nad dvěma disku s vdev typu mirror) a chcete přidat třetí disk a udělat z toho třeba raidz (odolnost proti výpadku jednoho zařízení, něco jako raid5), nemůžete. Můžete jen přidat další vdev třeba typu raidz (to znamená koupit minimálně 3 další disky). Ani vdev jako celek už nelze odstranit.

Jak jsem psal, ZFS je dobrý FS, ale značně neflexibilní co do dalších změn uspořádání disků.

BTRFS

BTRFS řeší redundanci na úrovni celého fs. O BTRFS jsem toho napsal tolik, že to asi nemá smysl tady opakovat. Pojďme se tedy zaměřit jen na řešení odolnosti proti výpadku disku:

U BTRFS vytvoříte FS s určitou redundancí (aktuálně raid1, raid10), postupně můžete přidávat disky klidně po jednom a staré disky odebírat.

Bohužel, celý fs sdílí jeden typ redundance (který lze ale za běhu měnit), pokud tedy na jednom fs máte důležitá data (pro který třeba chcete raid1) a data, na kterých vám až tak moc nezáleží, takže byste pro ně rádi třeba použili nižší nebo žádnou redundanci, tak toto na btrfs v aktuálním stavu neuděláte.

Oproti ZFS ale BTRFS nabízí lepší flexibilitu co se týče přidávání a odstraňování diskových zařízení. (A v dalších aspektech.)

LVM

LVM není FS, pracuje na blokové vrstvě, ale LVM umožňuje vytvářet LV různých typů (linear, mirror, stripeset).

LVM se ale docela blíží tomu, co bych já od FS očekával a proto jsem jej do tohoto článku zařadil, i když se nejedná o FS.

Do LVM vstupují bloková zařízení (disky – PV), jejich bloky se spojují do poolu (VG), nad kterým jsou potom exportovaná bloková zařízení (LV) a to různých typů redundance. Redundanci si tedy můžeme zvolit později, nemusíme ji definovat při zakládání LVM. Což považuji za skvělou vlastnost, ale v praxi se používá pouze minimálně a v praxi mnohem častěji narazíme na to, že jako PV do LVM vstupují bloková zařízení třeba ze softwarových raidů (md).

Můj návrh

Snad už je to z výše uvedeného jasné. Zatímco ZFS řeší redundanci na úrovni vdevů, BTRFS napříč celým FS, tak osobně bych preferovat možnost zvolit si redundanci na úrovni subvolume (datasetů). Vytvořím si subvolume pro důležitá data a zvolím si redundanci třeba odolnost proti výpadků dvou disků. Potom můžu mít data, na kterých příliš nezáleží (snadno je získám znovu) pro ty vytvořím subvolume třeba typu stripe set. Když selže nějaký disk, tak o tuto subvolume prostě přijdu.

Pochopitelně, dneska v roce 2017 už bych se vůbec neomezoval jen na lokální disky. Disky vstupující do poolu bloků, nechť jsou klidně na síti. Do takového clusteru přidám další disk a zvětší se mi dostupné místo na fs. Odeberu disk a zbytek poolu se přepočítá dle zvolené redundace.

V tomto článku neřeším žádné další vlastnosti FS, jen jsem se chtěl podívat na způsoby řešení redundance v tom kterém systému. Většina FS vychází se starého rozdělení na: hw (disky), řešení redundance (raid, ať již v sw nebo hw), rozdělení blokových zařízení (MBR, GPT, LVM), FS. A většinou řeší redundanci na co nejnižší vrstvě. Což je jistě výhodné, vyšší vrstvy se nemusejí zabývat výpadky disků.

Na druhou stranu to není výhodné pro spoustu dalších vlastností, které bychom od FS dnes očekávali. Dneska automaticky očekávám možnost vytváření snapshoty subvolume. V libovolném množství. Každý snapshot je samostatná subvolume, tedy zapisovatelná a dále snapshotovatelná. Tuto vlastnost BTRFS používám každý den.

Jestli čekáte nějaké šokující odhalení na závěr, musím vás zklamat. V nabídce toho příliš není. Asi nejbližším FS blížící se mým představám je CEPH, který ale nepochopitelně opět řeší redundanci na úrovni celého clusteru a nikoliv jednotlivých blkdev nebo cephfs (i když ten je v clusteru jen jeden, takže z tohoto pohledu je to něco jako distribuované BTRFS), na druhou stranu je velmi flexibilní s práci s disky (OSD), disky můžete přidávat a odebírat kdykoliv potřebujete (s dodržením jistých pravidel a s ohledem na stav nodů). Na druhou stranu nejmenší doporučovaná hodnota redundace je 3 (data jsou v clusteru ve třech kopiích), tedy těch disků budete potřebovat ještě o dost víc než dnes.

Přitom zrovna u architektury CEPH by nebyl problém si zvolit redundanci při vytváření objektů. Ostatně, stejně jako BTRFS by na toto mělo být interně připraveno, protože při změně módu fs jsou na disku bloku s různým data profilem.

Z letenky na Facebooku až k unesenému účtu

Aktualizace článku

  • 25.8. Přidána poznámka o dalším kroku při resetu hesla United Airlines

Výlet do Hong Kongu

Petr Mára je fajn člověk. Školí a přednáší, natáčí videa a věnuje se nasazování iOS a macOS ve firemním prostředí. A taky docela dost pracovně cestuje. Se svou ženou se v květnu 2016 vydali do Hong Kongu oslavit její narozeniny, ale Petr se bohužel nezmínil, na jak dlouho tam letí. No a mě to samozřejmě strašně moc zajímalo. Všiml jsem si, že na palubních vstupenkách, které před odletem dal na Instagram je vidět rezervační kód YJVFKG a nějaký čárový kód. Obojí jsou informace, které byste neměli zveřejňovat.

Palubní vstupenka British Airways

Detail fotky, kterou Petr Mára zveřejnil

Jen na pět dní? Takovou dálku? Pro zjištění odletu z Hong Kongu stačilo v Petrovo případě jít na web British Airways a rezervační kód zadat do správného políčka. Po zadání jsem se mimo jiné dozvěděl, že Petr má všechny požadované údaje správně vyplněné. No aby taky ne, když už odletěl. A pak jsem si všiml červeného tlačítka View or change details. A tak jsem na něj kliknul.

Přihlašovací formulář British Airways

Přihlašovací stránka letecké společnosti

Údaje Petra Máry jsou vyplněné

Všechny údaje jsou vyplněné

Aerolinky chtěly ověřit, že já jsem Petr. Mohl jsem zadat číslo pasu, to jsem (zatím) neměl, nebo datum narození. Petr má narozeniny uvedené na svém Facebookovém profilu, dá se také najít třeba v obchodním rejstříku nebo živnostenském rejstříku. Vaše datum narození je vcelku veřejná informace, často je součást DIČ živnostníků, není to nic tajného.

Zobrazené detaily Petra Máry

Zadané údaje

Ha, konečně mám to číslo pasu! A hele, můžu ho i změnit. V tu chvíli mě napadlo, že bych mohl Petrovi oslavu narozenin jeho ženy o pár dní prodloužit. Stačilo by zadat číslo pasu nějakého mezinárodně hledaného zločince nebo něco takového.

Žádná data jsem ale nezměnil a Petrovi to všechno napsal. Zároveň jsem se mu omluvil, protože jsem mu na 24 hodin zablokoval přístup, to když jsem zkoušel tipnout datum narození jeho ženy. Později jsem si ho samozřejmě vygůgloval, jak jinak. Petr to všechno vzal skvěle, patří mu za to velký dík. Podle další fotky palubních vstupenek zveřejněné o pět měsíců později se i poučil.

Fotky na Facebooku a Instagramu

Spoustu fotek boarding passů najdete na Facebooku i na Instagramu. Někteří lidé dokonce část údajů rozmažou, ale čárové kódy ponechají v původní podobě. Třeba jako slečna Anna.

Palubní vstupenka

Náhodně vybraný čárový kód z Instagramu

Slečna Anna Ferenčáková, která v dubnu 2017 cestovala do Bělehradu. Po oskenování čárového kódu z fotky se to dozvíte. Čárové kódy také najdete na palubních vstupenkách „zapomenutých“ v letadlech nebo na jiných místech.

Obrazovka aplikace Barcode Scanner

Oskenovaný čárový kód

S příchodem „chytrých“ zařízení se čárové kódy z palubních vstupenek najdou třeba i na fotkách rukou s hodinkami. Níže je palubní vstupenka s aztéckým kódem (Aztec code), který obsahuje stejné nebo podobné údaje jako kódy vytištěné na papíře. Boarding pass tedy nemusíte tisknout, stačí pak jen přijít ke skeneru a vykloubit si ruku při přikládání kódu ke snímači na letišti.

Aztec code na hodinkách na ruce

Aztécký kód na chytrých hodinkách

Ruka (i hodinky) patří Stephenovi Fenechovi, který letěl ze San Francisca do New Yorku. To jsme se dozvěděli po oskenování toho aztéckého kódu a potvrdili si to přečtením článku o nástrahách používání palubních vstupenek v „chytrých“ hodinkách, které se i s rukou do některých snímačů nevejdou. Aztécký kód obsahuje i další důležitou věc: číslo věrnostního programu (frequent-flyer program). Pan Fenech má ve věrnostním programu American Airlines číslo 4708760.

Obrazovka aplikace Barcode Scanner

Oskenovaný aztécký kód

Únos cizího účtu

Na Facebooku jsem našel vyfocený aztécký kód od člověka, který si nepřál být jmenován, ale je v určitých kruzích vcelku známý, na Twitteru má asi 120 tisíc followerů a založil něco v Evropě i v Americe. Kód na fotce obsahoval číslo věrnostního programu United Airlines. Tahle letecká společnost se k takovému číslu chová jako k nějakému super tajnému přístupovému kódu. Když už ho na nějakou oficiální korespondenci vytisknou, tak jen poslední 3 číslice a zbytek je „zahvězdičkován“. V aztéckém kódu byl samozřejmě v celé své kráse a tak mě napadlo toho využít k únosu účtu toho člověka. Protože proč ne, že jo, to přece nemůže být tak lehký.

Na webu United Airlines jsem zvolil, že jsem zapomněl heslo, zadal jsem jméno, příjmení a číslo z oskenovaného aztéckého kódu. Následovaly dvě jednoduché bezpečnostní otázky, na které se odpovědi daly zjistit během pár vteřin: „první navštívené velké město“ bylo to, ve kterém se ta osoba narodila a „oblíbený zimní sport“ v zemi alpských velikánů nebyl golf. Systém správně poznal, že jsem on a pak už jsem mohl nastavit nové heslo k účtu. Aktualizace 25.5.: tohle se stalo v červnu 2016, od té doby v United Airlines přidali další krok, ve kterém uživatel musí kliknout na odkaz v zaslaném e-mailu, aby mohl nastavit nové heslo. Vypadá to, že dnes bych mohl tomuto pánovi jen nechat poslat tento e-mail.

Stránka pro nastavení nového hesla United Airlines

Vytvoření nového hesla

Nové heslo jsem nenastavil, nechtěl jsem nikomu způsobit nějaké trable. Té osobě jsem to napsal, stejně jako Petrovi Márovi. Obrázek z Facebooku smazal (je pořád na Twitteru), ale nevěřil mi, že bych mohl unést celý účet. Domníval se, že by systém poslal nové heslo jemu.

Po chvíli vysvětlování to pochopil. Do háje, máš pravdu. Právě jsi mohl to heslo změnit, to je šílený. Jo, to je. Jenom proto, že někam dal fotku palubní vstupenky jsem mohl unést jeho účet. Třeba by tam mohl mít uloženou platební kartu na nákup letenek nebo bych se mohl postarat, aby někde zůstal.

Fotky různých kódů na fejsbůky nedávejte

Uživatelé často zveřejňují data, o kterých neví, co znamenají. Na první pohled není totiž vidět, co to je za data nebo k čemu slouží. Někomu se mohou na něco hodit, v nejhorším případě je možné unést nějaký účet. Dávejte si pozor na data, která zveřejňujete. Když úplně přesně nevíte, co data na fotkách a screenshotech znamenají, raději je začerněte (rozmazání někdy nemusí stačit), nebo obrázky raději nezveřejňujte. V odpovědích na bezpečnostní otázky lžete a odpovědi si pamatujte v password manageru, stejně jako vaše hesla. A taky nenechávejte palubní vstupenky v letadlech.

Video k GDPR

Video k GDPR tereza.tumova@… St, 08/23/2017 - 08:20

SPIR připravil video, které jednoduše a přehledně ve 3 krocích shrnuje, jak se připravit na GDPR.

 

Čtvrté číslo newsletteru (2017, 22.-33. týden)

TLS, SSL, HTTPS

Skoro již tradičně začneme certifikační autoritou Symantec. Ta se v posledních letech potýká s mnoha problémy, mj. vystavila několik desítek tisíc falešných certifikátů, kvůli kterým jí výrobci prohlížečů přestávají důvěřovat. Předběžně se proto dohodla s Googlem, že od 8. srpna budou certifikáty vydávat nezávislé certifikační autority. V reakci na tuto předběžnou dohodu Symantec tvrdil, že po diskuzích s potenciálními partnery nelze termín stihnout, partneři Symantecu by prý neměli dostatek času na posílení infrastruktury, která by tak nemusela zvládnout nápor nových žadatelů. Symantec je podle měření firmy Netcraft největším vydavatelem OV (Organization Validation) a EV (Extended Validation) certifikátů a ověření žadatelů o tyto certifikáty nelze vždy automatizovat jako v případě běžnějších DV (Domain Validation) certifikátů, které vystavuje například autorita Let's Encrypt. Finální situace je tedy taková, že aktivity certifikační autority Symantec převezme od 1. prosince 2017 autorita DigiCert. Existujících certifikátů vydaných před 1. červnem 2016 se změny dotknou až od dubna 2018 ve stabilní verzi Chrome, v Canary od ledna 2018, do té doby bude Chrome certifikátům důvěřovat. Certifikátů vydaných po 1. červnu 2016 se změny dotknou až v říjnu 2018. Mozilla ve svém prohlížeči Firefox udělá změny v podobný čas, plusmínus pár týdnů podle plánu vydání nových verzí. Je dobré připomenout, že Symantec má i další značky certifikátů (GeoTrust, Thawte, RapidSSL) a týká se to všech

Testovací verze Firefoxu označovaná jako Nightlypokusně vypnutou kontrolu platnosti „základních“ DV (Domain Validated) certifikátů pomocí protokolu OCSP (Online Certificate Status Protocol). Prohlížeč může po obdržení certifikátu poslat dotaz na OCSP servery aby zjistil, jestli certifikát nebyl revokován (zrušen). To může zdržovat načtení stránky, podle Mozilly skoro 9 % úspěšných OCSP trvá déle než 1 vteřinu. Například výpadek OCSP serverů certifikační autority Let's Encrypt minulý měsíc způsobil problémy některým návštěvníkům stránek, které certifikáty od Let's Encrypt používají, a tato změna ve Firefoxu by tomu měla předejít. Pokud se po změně načítání výrazně zrychlí, tak bude kontrola vypnutá ve všech verzích Firefoxu. Chrome takové online kontroly neprovádí již několik let. Místo posílání požadavků by se měla používat technika zvaná OCSP Stapling. Ta spočívá v připojení OCSP odpovědi rovnou k počátečnímu navázání šifrovaného spojení mezi serverem a prohlížečem, jenže implementace OCSP Staplingu v serverech Apache i nginx je bohužel chybná.

HTTPS je dobro. A taky chrání před cenzurou. Po přechodu Wikipedie na HTTPS v červnu 2015 se snížil počet cenzurování této „otevřené“ encyklopedie. Nepřející vlády sice pořád mohou cenzurovat celou Wikipedii, zkoumání provozu odhalí doménu nebo IP adresu, na kterou se uživatel připojuje, ale takové zablokování se většinou setká s velkou nevolí a je to „vidět“. Jednotlivé stránky zablokovat nejdou.

Certifikační autority WoSign a StartCom mají, podobně jako Symantec, za sebou také pěknou řádku problémů. Autorita WoSign vydávala certifikáty s do minulosti posunutým začátkem platnosti, certifikáty s duplicitními sériovými čísly a také nezveřejnila nákup certifikační autority StartCom. Chrome 61 (aktuální je verze 60) těmto certifikačním autoritám přestane úplně důvěřovat a žádné jimi vydané certifikáty nebudou platné. StartCom je známá svými certifikáty zdarma, které pro nekomerční účely poskytovala ještě před vznikem certifikační autority Let's Encrypt. Společnost StartCom v červenci vydala zprávu, že prošla auditem, změnila majitele (nyní je vlastníkem StartComu čínská firma Qihoo 360, která v roce 2016 koupila prohlížeč Opera), a že znovu Mozillu požádala o přidání na seznam důvěryhodných certifikačních autorit.

Nedávný výzkum inspekce HTTPS, tedy sledování zašifrovaného provozu, ukázal, že webový server může „inspekci provozu“ detekovat podle charakteristiky HTTPS spojení, která je pro každý prohlížeč a skenovací software jiná. Webový server Caddy detekci inspekce implementoval, takže provozovatel webu si může logovat, kolik návštěvníků je inspekcí postiženo, případně může rovnou uživateli ukázat, že jeho načítání stránek není tak bezpečné, jak na první pohled vypadá.

Prohlížeče

V aktuální verzi Chrome 60 je zpátky zkratka pro zobrazení informací o certifikátu. Stačí kliknout na ikonku zámečku v řádku s adresou a hned se dozvíte, jestli je certifikát validní, nebo ne. Když nad „odkazem“ Valid chvilku necháte myš, tak se zobrazí i informace o autoritě, která certifikát vystavila. Zkratku je potřeba nejdříve zapnout, to provedete na speciální adrese chrome://flags/#show-cert-link, po novém spuštění prohlížeče už ji budete moci využít. V budoucnu by zkratka měla být standardně zapnutá, vývojáři Chrome prý čekají na nějaké úpravy panelu, který se po kliknutí na zámek objeví. Informace o certifikátu naleznete také v Developer Tools (ty zobrazíte např. stiskem F12), v záložce Security je na to tlačítko.

Chrome začne počátkem příštího roku blokovat nepřijatelné reklamy. To jsou ty, které nebudou splňovat standard Better Ads, tedy např. reklamy, které začnou automaticky přehrávat nějaký zvuk nebo reklamy v pop-up oknech. Celkem bude blokovat 4 typy nepřijatelných reklam pro desktop a 8 typů pro mobilní zařízení. Už jen dodám, že Google je zakládajícím členem koalice, která standard definovala a dalšími členy jsou mj. Facebook, Interactive Advertising Bureau (IAB) a GroupM.

Úniky dat

Firma Zomato (působí i v Čechách) nedávno oznámila, že si někdo odnesl 17 milionů uživatelských účtů, teď už víme, jak k tomu došlo. V roce 2015 byla zveřejněna data z úniku ze služby 000Webhost, na které měl účet i vývojář Zomata. Ze služby unikla i hesla v čitelné podobě a ten vývojář používal to samé heslo i na GitHubu. Někdo tak získal přístup ke zdrojovým kódům Zomata, našel v nich chybu, kterou zneužil pro získání přístupu do databáze. Firmy by se o své vývojáře (a tím i o svoji budoucnost) měly starat trochu víc, třeba by jim mohly pořídit správce hesel.

Správci hesel mají určitá rizika, ale ta jsou pořád menší, než když někdo používá jedno heslo na více místech. Často jsou terčem útoků, ale při dobrém návrhu to zas tak moc nevadí. Ze správce hesel OneLogin unikla data na konci května a útočník prý data může i dešifrovat, dostal se tedy i k šifrovacím klíčům, eh, což o moc dobrém návrhu nesvědčí. OneLogin možná budete znát, před rokem spolknul českou firmu Portadi. Dat zákazníků Portadi se to prý netýká.

Sbohem a šáteček

Děje se toho fakt dost, co? Nepíše se mi to lehce, a trvalo to, než jsem to ze sebe dostal, ale tohle je poslední newsletter v této podobě. Ani jsem ho nestihl pojmenovat a už jsem ho zabil. Nezbývá mi tolik času, abych každou událost, novinku a změnu v prohlížeči detailně popisoval tak, jak bych v newsletteru chtěl, mrzí mě to. Aktuální novinky a události místo toho najdete u mě na Twitteru a/nebo na Facebooku. S radostí si tedy můžete vyhodit RSS newsletteru z čtečky (protože Inbox Zero, že), ale přidejte si místo toho RSS pro všechny články, mám „rozdělaných“ pár pěkných článků. Moc děkuji za dosavadní přízeň i pochopení.

Kam dál

Newsletter týkající se TLS/SSL/HTTPS vydává Feisty Duck, knižní vydavatelství, které má na svědomí třeba Bulletproof SSL and TLS – „živou“, neustále aktualizovanou knihu o… no, však víte. Na Rootu najdete seriál Postřehy z bezpečnosti a v Hospodářských novinách vychází Bezpečnostní svodky Michala Altaira Valáška. Plánované změny v prohlížečích tweetuje účet Intent To Ship.

Pozvánka na 143. brněnský sraz

srpen
15
Openalt.org

OpenAlt s meteorology očekává v Brně abnormální hic, proto jsme hledali něco takového. Blíží se tomu restaurace U kotvy, ale díky četným firemním akcím tam je rezervačka tak 1/2 dopředu. Volíme tedy na protějším břehu BeachPub Sokolák.

Pozor na falešné profily na Facebooku

Falešné profily neslouží jen k trolení, ale už i k phishingu, díky kterému můžete přijít o nemalou částku. Kamarádka se mi včera

Příspěvek Pozor na falešné profily na Facebooku pochází z Spajk.cz

Předvolební debata: Od otevřených dat k otevřenému vládnutí

Co plánují politické strany v dalším volebním období v oblastech otevřených dat a českého e-governmentu vykonat? Přijďte 7. září do Městské knihovny v Praze diskutovat s kandidáty do poslanecké sněmovny na předvolební debatu s podtitulem Od otevřených dat k otevřenému vládnutí.

Potřebujete mít web na HTTPS?

Infografiky EU: dopady reformy ochrany údajů (GDPR)

Infografiky EU: dopady reformy ochrany údajů (GDPR)
Jak reforma ochrany údajů ovlivní sociální sítě?
tereza.tumova@… Po, 08/07/2017 - 08:54
Fotogalerie