Michal Čihař - Blog Archives for Czech

Jak už jsem tu popisoval , za nemalého úsilí se mi podařilo pořídit tramvajenku na OpenCard. Tušil jsem, že spolehlivost dosavadního papírového řešení je nedostižná (kolikrát se vám stalo, že by nešel papírový kupón přečíst?), ale zážitky z dvou týdnů používání OpenCard předčily má očekávání.

Protože bydlím na okraji Prahy, kam jezdí příměstské linky (3xx), mám tu úžasnou možnost otestovat spolehlivost čteček na OpenCard v každodenním provozu - při nástupu člověk musí ukázat platnou jízdenku. Zhýčkaný jinými místy, kde RFID používám, jsem začal nejjednodušším způsobem - peněženku, ve které je několik RFID karet, dám ke čtečce a předpokládám, že ta bude natolik inteligentní, že se domluví s tou správnou kartou. Bohužel to jí očividně dělá problémy a po několika chybách při čtení jsem donucen kartu stejně vyndat. U samostatné karty už je pravděpodobnost úspěchu o něco vyšší, ale zatím se stejně pohybuje někde kolem 50% - na první pokus málokdy uspějete. Nakonec to mnohokrát končí mávnutím ruky řidiče, a vy můžete vesele nastoupit, aniž by veděl jestli na OpenCard něco nahraného je, nebo není.

Dnes mě ovšem dorazila kontrola revizorem v metru. Naštěstí jsem měl cestu dlouhou a kontrola probíhala za jízdy, takže mi nevadil jeho desetiminutový boj s tímto zázrakem techniky. Aspoň měli případní černí pasažéři dost času se přesunout z jeho dosahu :-). Ale pěkně po pořádku - po té co mu dávám kartu, loví z brašny čtečku, přikládá kartu a v zápětí cosi zamumlá. Z tašky vytáhne jakousi svojí kartu a přikládá jí ke čtečce. Pak mnohokrát karty prohazuje a zjevně se pořád nemůže přiblížit ke kýženému výsledku. Nakonec se mě zeptá co tam mám nahráno za kupón, po odpovědi že mám měsíční prohlásil, že je to v pořádku a vrací mi kartu. S omluvou, že to ještě nefunguje úplně dokonale odešel a slečny sedící naproti mě už neudržely záchvat smíchu...

Už delší dobu se mi nelíbilo, na jakých stránkách prezentujeme phpMyAdmina a chtěl jsem s tím něco udělat. Ale prostě je pořád těžší a těžší najít si čas a tenhle úkol čekal v mojí frontě poměrně dlouho.

Největším problém se stránkami je asi způsoben hostováním na SourceForge.net a omezeními, která tam pro webhosting mají nasavená. V podstatě je nemožné do stránek nějak začlenit externí zdroje (když nepočítám JavaScript/AJAX a podobná řešení), přitom externí zdroje (resp. RSS feedy ze SourceForge.net) obsahují velkou část informací, které na webu mají být (novinky, informace o vydáních atd.). Jediná rozumné řešení je generovat statické stránky jinde a nahrávat je na web server SourceForge.net.

Toto řešení problému bylo jasné a je také jasné, že pro statické generování HTML není PHP zrovna nejlepší jazyk. Tak jsem se rozhodl použít můj oblíbený Python spolu s šablonovacím nástrojem Genshi . Ano je to tak, jedna z nejoblíbenějších aplikací napsaných v PHP používá Python pro vytváření svého webu.

Začal jsem si hrát s Genshi a feedparserem asi před měsícem, bez jakékoliv představy o vzhledu a jakékoliv naděje na úspěch, prostě jsem se jen chtěl naučit je používat. Ale hned první nástřel se pokusným králíkům (kamarádi, členové týmu phpMyAdmina a častí návštěvnící kanálu #phpmyadmin) zalíbil a tak jsem na něm trochu zapracoval, aby stránky byly připraveny před vydáním verze 3.1.0.

A dnes nastal okamžik, kdy byly nahrazeny staré stránky a už se těším na kritiku. Tož podívejte se na http://www.phpmyadmin.net/ .

Až do nedávna jsem překlad phpMyAdmina obstarával vlastními silami. Bohužel už v poslední době nějak nestíhám a není jiná možnost než se pokusit sehnat někoho, kdo by tyto překlady obstaral. První pokus tedy činím zde, třeba se tu nachází nějaký dobrovolník co by rád pomohl známému projektu. Kromě znalosti angličtiny nejsou potřeba žádné další znalosti.

Stačí vzít soubor s překlady , přeložit nepřeložené texty (a odstranit text //to translate ) a pak už jen soubor poslat buď to trackeru s překlady nebo přímo mě. Více informací je třeba ve FAQ .

Pro začátek na překladatele čeká koňská dávka 350 textů pro nastavovací modul a 20 pro úložiště PBXT, takže jestli nemáte o dlouhých podzimních večerech co dělat, hurá do toho :-).

V Praze bude od příštího roku možné koupit roční jízdenku jen v elektronické podobě na OpenCard a dopravní podnik u té příležitosti vytvořil internetový obchod, kde je možné jízdenky nakoupit. Jakožto správný lenoch jsem nákup odkládal na poslední možný termín, kdy ještě mám nárok na 10% slevu - tedy na dnes.

Registrace

Registrace sice není poviná, ale prototože si ještě budu muset koupit dvě měsíční jízdenky, usoudil jsem, že to bude menší zlo než několikanásobné zadávání šestnáctimístného čísla. Vypním údaje (na co potřebují telefon? tak tam dávám 800123456), zhrozím se toho, že se nedá použít SSL a čekám na mail. Když už mi čekání přijde moc dlouhé, koukám se do spamu a vida, mail je tak zprasený, že ho můj spam filter prohlásil za spam. No co, prohrabal jsem si odpadky a účet je aktivní.

Nakupování

Logika obchodu je přesně opačná než všude jinde - proč nebýt originální? Tak začneme tím, že vybereme způsob placení. Pak už následuje jen lehce nepřehledný výběr co vlastně chci koupit. Dále se musím rozhodnout jestli chci kupón doručit elektronicky nebo elektronicky. Vybírám tedy elektronicky. Při druhém opisování captchy (první byla při registraci) jsem opět o něco víc naštvaný na tvůrce této aplikace, ale můžu přejít k placení. Následuje typický zbytečný krok mnoha obchodů - výběr platební karty. Proč tam tento krok musí být, když poznat typ karty z jejího čísla je triviální? Pak už mě naštěstí přesměrují na platební portál České Spořitelny, takže zadávání karty je celkem bezpečné. Akorát při přesměrování zpět Firefox (oprávněně) řve, že se přesměrovává na nezabezpečený server.

Překvapení na závěr

Po úspěšném zaplacení se dozvím, že kupón si na kartu můžu nahrát až zítra. Ne že by mi to tentokrát vadilo, ale proč systém nefunguje online nechápu.

Když jsem před třemi a půl lety opouštěl SUSE, myslel jsem si, že je to definitivní a osud už mě zavane někam jinam. Práce v nové firmě mi připadala zajímavá a příležitosti něco se tam naučit bohaté.

Nicméně po pár letech mě už práce u nového zaměstnavatele přestala bavit a motivovat a bylo na čase udělat změnu. První rozhodnutí bylo jednoduché - koncem května jsem podal výpověď a naplánoval si prázdniny. Idea byla taková, že během výpovědní lhůty se poohlédnu po jiném místě a od září zase začnu dělat.

Idea to byla pěkná, ale během těch dvou měsíců jsem se nějak nebyl schopný rozhodnout kam jít. Tak jsem to dočasně uložil k ledu a užíval si volna. Odpočinek od počítačů se skvělá věc, ale když je člověk trochu aktivní v pár projektech, nepřejte si vidět to množství mailů, které se nahromadí. Já se posledními nahromaděnými prokousal až včera.

Jak se blížil začátek září a tím termín, kdy jsem chtěl začít pracovat, do práce se mi chtělo čím dál tím méně. No tak co, práce mi nikam neuteče, udělám si volno ještě v září :-). V té době už v mém hledáčku zůstaly jen dvě nabídky - vývoj na Xenomai pro firmu Inova a L3 support v SUSE . Obojí mělo své výhody, ale nakonec převážila možnost práce na mých projektech v pracovní době v SUSE a tak se tedy po třech a půl letech vracím na místo činu. Uvidíme jak dlouho tam vydržím tentokrát :-).

PS: Debian právě dosáhl významného milníku - byla nahlášena chyba číslo 500000 .

9. září 1998 byla vydána první verze phpMyAdmina. O deset let později tento projekt stále existuje a vyvíjí se. Proto je na místě poděkovat všem, kteří toto umožnili:

• vývojářům MySQL a PHP
• vývojářům a překladatelé phpMyAdmina (minulí i současní)
• firmám, které podpořily projekt: SourceForge.net za hostování, Pack Publishing za příspěvky z knihy „Mastering phpMyAdmin“
• a samozřejmě uživatelům

Jsme rádi, že tu s vámi jsme už tak dlouho.

Do phpMyAdmina chtějí protlačit podporu pro jeden autentizační token. Jak tato věc funguje na hardwarové úrovni nevím (má tam být nějaký autentizační kalkulátor, který na výzvu vygeneruje nějakou unikátní odpověď), ale docela mě pobavil přístup k bezpečnosti softwarového řešení okolo. Celá popisovaná věc se jmenuje Swekey a stojí za ním firma Musbe, založená jen kvůli tomuto zařízení ( to develop and market an innovative authentication technology ).

Token se strká do USB (v dnešní době to asi ani jinak nejde) a celou věc obsluhuje v Linuxu jakási binárka komunikující s tokenem přes libusb. No aspoň, že to bude hnít v userspace a ne v kernelu. Bohužel pokud to chcete použít na něčem jiném než i386, máte smůlu. Protože nám se jedná o autentizaci webové aplikace, máme ještě k dispozici další binárku a to plugin do prohlížeče Firefox (pro Windows případně ještě ActiveX pro MSIE).

Když už se uživateli poštěstí toto rozběhat (a nebude řešit takové nepodstatné otázky, jako třeba: proč binárka obsluhující ten token musí používat curl?), může vyzkoušet úžasné možnosti, které nám tato autentizace skýtá. A hlavně se podívat na kód, který se o autentizaci stará, protože ten již k dispozici máme. Kromě phpMyAdmina, kde je jakási meziverze už v SVN, ještě existuje plugin pro SquirrelMail a prý i patch pro RoundCube, modul pro PAM atd.

Jak vlastně celá věc funguje?

1. Načte se ID z USB tokenu
2. Ze serveru se stáhne náhodný token (platný dvě minuty)
3. Náhodný token se nacpe do USB tokenu a ten vygeneruje OTP (jednorázové heslo)
4. ID tokenu, náhodný token a OTP se pošle na server a ten je ověří

No vypadá to celkem jednoduše, tož pojďme se podívat jak to soudruzi naimplementovali. Podotýkám, že v patchi pro phpMyAdmin, už pomaly níže popsané problémy mizí, ale za cenu víceméně kompletního přepsání kódu, jak se (ne)budou vyvíjet patche/pluginy pro ostatní programy netuším, nicméně autoři pořád někde preferují původní řešení.

Komunikace

První věc, která kohokoliv musela praštit do očí bylo použití nešifrovaného HTTP spojení při komunikaci se serverem. Což ve spojení s jednoduchým až triviální protokolem, znamená, že kdokoliv, kdo je schopný na jakýkoliv HTTP požadavek odeslat odpověď "HTTP/1.0 200 OK\n\nOK" se může stát autentizačním serverem, který autentizuje cokoliv komukoliv. Soudruzi sice v patchi pro phpMyAdmina přešli na HTTPS s ověřováním certifikátu, ale z výkonnostních důvodů jinde zůstane nadále HTTP. Vskutku inovativní řešení.

Umístění souborů

Mapování tokenů na uživatele mělo být umístěno v kořenovém adresáři phpMyAdmina a tedy přístupné přes web. Což ve spojení s předhozí zranitelností znamená, že jediná informace, kterou by případný útočník potřeboval - ID klíče, který mu dovolí přístu, může bez problémů získat napsáním správného URL.

Dočasné soubory

Protože náhodný token je platný dvě minuty, rozhodli se autoři ušetřit námahu jejich serveru s generováním a tento token cachovat. Bohužel ukládat pevně pojmenovaný soubor do adresáře /tmp není zrovna nejlepší nápad a už vůbec není dobrý nápad tento soubor vytvářet s právy 777 . Co by se asi stalo, kdyby náhodný uživatel na serveru do tohoto souboru uložil třeba nějaký film a ten se následně začal odesílat na jejich server jako náhodný token při autentizaci?

No nechtějte to

Většina zde zmíněných problémů existuje ve všech implementacích tohoto tokenu, do kterých jsem se koukal. Kromě toho každá implementace přidává spoustu unikátních programátorských chyb. Zájemcům o pobavení se doporučuji modul pro PAM, který je vlastně jen spouštěč skriptu v bashi, který volá curl a komunikuje se serverem.

Update

Při psaní tohoto článečku mě napadl ještě jeden problém, kterým to asi bude trpět, ale nechtěl jsem to psát dokud to neověřím, což se právě stalo. Přístup k tokenu z prohlížeče není pluginem nijak omezován, takže jakákoliv stránka může zjistit ID vašeho tokenu a vygenerovat si OTP heslo. No lepší podmínky pro krádež identity si už lze představit jen těžko :-).

Zase další krátký povzdech, po včerejším stěžování si na poštu :-). Včera jsem byl nucen poprvé od "reformy" navštívit lékaře. Kupodivu poplatek chtěli až na konci a ne jako první věc při vstupu do ordinace, jak jsem od mnoha známých slyšel :-).

Nicméně co mě neustále na mojí praktické doktorce překvapuje, je tradiční dotaz jestli jsem alergický na nějaká antibiotika. To už by sakra za tu dobu co tam chodím mohla vědět, ne? Obzvlášť, když v podstatě vždycky, kdy už mi je tak blbě, že tam zajdu, to těmi antibiotiky skončí...

Už jsem se České poště nechtěl nikdy věnovat, ale prostě to co jsem viděl dnes při odchodu z domu se nedá nekomentovat.

Víte jak vypadá doručování doporučených dopisů podle České pošty? Položí se na rozvaděč vedle vchodu :-).

Tak jsem si nějak povšimnul, že veškeré moje maily, odeslané na nejmenovaný největší český freemail, skončí jako spam. Kupodivu u jiných příjemců se tento problém nevyskytuje, tak to asi nebude úplně triviální problém a stojí za prozkoumání.

Posílám si tedy mail na jedno z nepoužívaných kont, které tam mám a v hlavičkách vidím X-Spam-Status: score=14.2 . No to je celkem slušné skóre, co za to asi může? Že by se tomu nelíbila moje adresa michal@cihar.com? Změna odesílatele na cosi@email.cz a hle, už mám jenom X-Spam-Status: score=8.2 . Bohužel pořád dost na to aby to skončilo ve spamu.

Jako první mě samozřejmě napadl nějaký obskurní blacklist, ale jakékoliv online nástroje pro kontrolu blacklistů mi potvrzují, že můj server na žádném není, tak v tom snad problém nebude. Zkouším ještě poslat mail přímo ze serveru a najednou to projde ... tak že by se kontrolovaly Received hlavičky oproti blacklistům?

Vložení Received s IP adresou přes kterou se připojuju (kabelovka, NAT pro nepočítaně lidí, takže nejspíš je na všech možných i nemožných blacklistech) opravdu způsobí onen závratný růst skóre. Proč má jediná hlavička takový vliv netuším, ale jediná moje možnost je přenastavit si mailserver aby tyto adresu maskoval.

Naštěstí nalezení návodu pro Exim je otázkou jednoho dotazu na pana Googla a změna je na světě:

 received_header_text = Received: \
  ${if def:sender_rcvhost {from ${if def:authenticated_id \
  {127.0.0.1 (helo=authenticated.user.fuck.seznam)} \
  {$sender_rcvhost}}\n\t}\
  {${if def:sender_ident \
  {from ${quote_local_part:$sender_ident} }}\
  ${if def:sender_helo_name {(helo=$sender_helo_name)\n\t}}}}\
  by $primary_hostname \
  ${if def:received_protocol {with $received_protocol}} \
  ${if def:tls_cipher {($tls_cipher)\n\t}}\
  (Exim $version_number)\n\t\
  ${if def:sender_address \
  {(envelope-from <$sender_address>)\n\t}}\
  id $message_exim_id\
  ${if def:received_for {\n\tfor $received_for}}

O tom nakolik je takovéto chování od mailserveru korektní spekulovat nebudu a názor si vytvořte sami.