Příspěvky

1006

Odkladiště / Re:Dvoufaktorové ověřování u Raiffky

« kdy: 29. 10. 2019, 09:54:51 »

Stačilo by zadávat přihlašovací jméno a současně IPIN. A až po jejich správném zadání odesílat SMSku
 
RB v nevyžádaných SMSkách nevidí problém. Takže jedině změnit banku, která má logiku přihlášení nastavenou jinak

To ovšem nezvýší bezpečnost, jen případný útok bude zprvu probíhat potichu, skrytě.

1007

Odkladiště / Re:Dvoufaktorové ověřování u Raiffky

« kdy: 29. 10. 2019, 09:51:42 »

Nemam rodne cislo, ale jine, relative kratke cislo. Na druhou stranu, proc se divate na "klientske cislo" jako na neco tajneho? Vzdyt je to obdoba prihlasovaciho jmena. Ty se za tajne nepovazuji.

Musíte se na to dívat komplexně.
Do banky vyžadujete 2FA.
SMS může být kompromitována - způsoby jsem popsal.
Takže buďto musíte mít 100% jistotu, že nedojde ke kompromitaci SMS, nebo počítat s tím, že k ní dojít může.

Pokud počítáte s tím, že ochrana pomocí SMS není dokonalá, musíte přidat "na jiné frontě". V tu chvíli zbývá jen klientské číslo nebo čtyřmístný pindík.

Znám lidi, co mají na autorizační SMS vyčleněný "hloupý" telefon, který na nic jiného nepoužívají. Pak si můžete škrtnout jedno z rizik.

Naopak kritické je přihlašovat se do banky z prohlížeče v mobilu. Dáváte všanc jedno jediné zařízení, na kterém se sejdou všechny informace.

1008

Odkladiště / Re:Dvoufaktorové ověřování u Raiffky

« kdy: 29. 10. 2019, 09:44:22 »

S tim nemohu souhlasit. Jedina spravna cesta je vzdy se nejdrive zeptat na heslo, a pak, bez ohledu na spravnost hesla, se ptat na SMS kod. Z toho utocnik nema sanci poznat, jestli heslo bylo spravne nebo ne. SMS se posila jen kdyz je spravne heslo, ale to utocnik nevi.

Myslím, že v tomto případě to neplatí. Do RB zadáte své klientské číslo a hned se to ptá na heslo i SMS. K žádnému leaknutí informace na jejich straně nedochází - když zadáte špatné klientské číslo, stejně tak to vypíše "Autentizační kód byl zaslán na Váš mobilní telefon" - takže vůbec nezjistíte, jestli jste se trefil do existujícího klientského čísla.

Zneklidňují mě pouze tyto situace:

• SMS přichází opakovaně - může jít o náhodu (jak píše Filip), nebo o cílený útok (tak bych to bral já, dokud se nepotvrdí opak)
• Chabá úroveň zabezpečení SIM (stačí "kamarád" na přepážce operátora, který vystaví duplikát SIM karty)
• Možnost malware v telefonu (přepošle útočníkovi SMS)

Kdyby RB otočila logiku - nejprve heslo, poté SMS, pak byste naopak přišel o varování, že se možná někdo snaží útočit. V tomto ohledu mi nastavení RB přijde správné, jste informován a můžete reagovat (neplatné pokusy o heslo bez SMS byste zjišťoval hůř). Zaráží mě však, že to RB bere na lehkou váhu - když už toto "varování" máte, měli by konat.

1009

Odkladiště / Re:Dvoufaktorové ověřování u Raiffky

« kdy: 29. 10. 2019, 09:29:39 »

V RB mi řekli, že toto je normální, k narušení bezpečnosti nedošlo. Co si o tom myslíte?

K narušení bezpečnosti částečně došlo. Někdo zná Vaše přihlašovací ID. Raiffka minimálně v minulosti doporučovala klientům si zadat jako přihlašovací jméno své rodné číslo (aby ho lidé nezapomínali, heh). Pokud tam máte RČ, nebo třeba jiné číslo, které zná širší okruh lidí (kolegové, účetní, ajťák v práci), pak je možné, že se někdo snaží cíleně získat přístup. Dokud se tato možnost nevyloučí, mělo by se k tomu přistupovat jako k narušení bezpečnosti, byť asi s nízkým rizikem.

Riziko se zvyšuje, pokud máte firemní (cizí) SIM kartu a ten, pod koho patří, může zažádat o duplikát (nebo o tzv. twin kartu). Pak už by měl útočník v ruce dva údaje ze tří - přihlašovací jméno a SMS. Zejména ta twin karta je nepříjemná, protože se může snažit jen na chvíli odklonit SMS k sobě a pak zase vrátit provoz k Vám.

Nutno zvážit i rizko malwaru v chytrém telefonu, který může obsah SMS přeposílat dál (útočníkovi).

V tu chvíli už Vás chrání jen 4místný PIN, a to je dost málo.

Raiffku bych za toto přezírání bezpečnosti nakopal, ve Vašem zájmu by bylo zajít si změnit přihlašovací ID do banky - to stejně po telefonu nevyřídí.

SMS je sama o sobě dost málo - právě kvůli rizikům leaknutí SMS (druhá karta, malware). Daleko lepší to bylo v době, kdy ověření prováděl SIM toolkit, který byl víc zabezpečený a nikdo nemohl získat přístup jen výměnou SIM karty. Leč pohodlí zákazníků zvítězilo, nikdo nechtěl běhat do banky aktivovat si SIM toolkit. Takže pokud SMS, tak jedině v kombinaci s ochranou i ostatních údajů - a k jejich kompromitaci u Vás zjevně došlo.

1010

Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky

« kdy: 27. 10. 2019, 19:31:10 »

radši neodpovědět vůbec, když už jsi příliš hrdý na to se omluvit.

Nezaměňujte hrdost s pýchou.

1011

Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky

« kdy: 25. 10. 2019, 16:53:44 »

Jenže v této diskusi je jiný problém. Že se někdo tváří jako expert, ale juniorovi doporučuje velmi nestandardní řešení – např. INNER JOIN psát pomocí OUTER JOINu + spojovací podmínky do WHERE (kterou navíc napíše špatně). Nebo se jako úplně normální prezentuje vypsat uživateli nestránkovaný seznam všech štítků, ať si v nich hledá duplicity očima.

INNER JOIN už Vám byl vyvrácen vícekrát, nemá smysl se k němu vracet.

Štítky pomocí DISTINCT nad velkou tabulí jsou blbina. Tímto vzorem zrychlíte zápis a update štítku na záznamu (což jsou operace méně používané), ale zpomalíte jakékoliv dohledání (což je častější operace).

1012

Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky

« kdy: 25. 10. 2019, 11:15:59 »

...

Pane kolego, tohle je zbytečná ztráta energie a snad i emocí. Správné postupy i argumenty jsme předložili, několikrát vysvětlili, že nováčkům se mají dávat prozíravé rady. Není účelem přesvědčit Filipa - ostatně se zdá, že je mimo jeho moc diskutovat jinak, než zastávat svoji pravdu. Točit se dokola opakováním opravdu nemá smysl, stejně to beztak kromě nás čtyř nikdo nečte.

Ve Filipových argumentech jsou opravdu veletoče - jinou metrikou hodnotí své argumenty a jinou cizí. Když už je v úzkých napíše něco ve smyslu "měl byste uvést konkrétní databáze" - aniž by sám takto postupoval. Jako příklad dává databázi, na které to jednoznačně nejde, navíc se sloupcem štítků "NOT NULL", ačkoliv později označuje patřičné indexy za "nestandardní implementaci" atd.

Mrzí mě, že z této diskuse si Racchek nemůže nic smysluplného odnést.

1013

Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky

« kdy: 25. 10. 2019, 09:28:49 »

Už výše bylo řečeno, že součástí toho klíče je i interní ID záznamu, které nemůže být duplicitní.

Podle tohoto popisu není v PostgreSQL ID záznamu součástí klíče, ale je ve stromu uložené jako hodnota, na kterou se ten klíč odkazuje. Z čeho usuzujete na opak?

Takže to má jinak a připouští duplicitu klíče, viz klíč '49'. Jak by z tohoto měl jít udělat distinct jinak, než poctivým traverzováním?

Já si myslím, že Filip hovoří o databázích, u kterých je (možná?) full table scan jednoho sloupce pomalejší, než totožné projití stejného počtu záznamů v indexu. Je to možné?

1014

Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky

« kdy: 24. 10. 2019, 22:33:48 »

Problém s B-Tree je jenom tehdy, pokud se používá upravená varianta, která umožňuje ukládat duplicitní klíče přímo jako samostatné uzly stromu – jako to má právě PostgreSQL nebo Oracle. To ale není obecná vlastnost B-Tree, naopak je to spíš odchylka těchto databází od standardní implementace B-Tree (i když je to odchylka logická, protože umožňuje řešit neunikátní hodnoty pořád v rámci jedné datové struktury B-Tree).

Aha, tak teď už rozumím, proč jste posílal explain z Postgresu. Chtěl jste demonstrovat, jak to Postgres ani nemůže umět!

1015

Studium a uplatnění / Re:Dohoda o pracovní činnosti a daně

« kdy: 24. 10. 2019, 13:09:11 »

Konkrétně musí odpovědět někdo ze Slovenska, ale obecně v EU platí princip, že daň se odvádí v té zemi, ve které je prováděna činnost. Takže ano, daň z DPČ určitě patří Slovenské republice. Je však možné, že v SR může být prováděna rovnou srážkou ze mzdy.

1016

Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky

« kdy: 24. 10. 2019, 07:08:43 »

V každém případě vyhledávání štítků pro účely našeptávání je zcela jiná úloha

Našeptávání je úplně jiná úloha. Když odmyslíme překlepy, tak našeptávání urychluje dohledání slova pomocí substringu (v nejjednodušším případě zleva). Na našeptání slova "hovado" je provedeno až šest dotazů a cílem je urychlit je jako celek. Naprosto nelze srovnat s dohledáním slova jedním dotazem, natož provedení distinkce.

Filipe, na DISTINCT opravdu indexy nezabírají. V mateřské škole pro databázové pracovníky se polopaticky učí, že je nutné data co nejvíc omezit a vyfiltrovat před tím, než se provádí distinct. Typickým zabijákem výkonu jsou distinct subselecty, distinct joiny apod., právě z tohoto důvodu.

1017

Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky

« kdy: 23. 10. 2019, 10:45:31 »

O existenci indexů jste už slyšel?

Radost indexovat field, ve kterém je pole štítků.

1018

Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky

« kdy: 23. 10. 2019, 10:15:27 »

Filipovi bylo potvrzeno to, že jeho řešení je funkční, jen bylo poznamenáno, že to lze řešit prozíravěji. Celý ten diskusní šprajc nechápu, připadá mi to jako "proč to dělat dobře a stejně jednoduše, když to jde i blbě a stejně jednoduše".

1019

Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky

« kdy: 23. 10. 2019, 09:53:43 »

Ostatně svědčí o tom i to, že já jsem popsal už dva příklady, ale Miroslav Šilhavý nebo Logik ještě ani jeden – asi ještě přidávají další tabulky. Tak doufám, že se někdy dočkám příkladu, kde by se podle nich použil INNER JOIN – tak, že nejprve obecně popíšou pravidlo, kdy se podle nich má používat INNER JOIN, a pak to ukáží na konkrétním příkladu.

INNER JOIN patří zejména tam, kde ze struktury dat musí existovat vazba 1:1-n. Typicky číselníky, nebo pravá strana dynamické vazby (zdroj_tbl LEFT JOIN vazba INNER JOIN cil_tbl). Tedy situace, kdy ani při odlišném pohledu na stejná data nedává smysl uvažovat o neexistující vazbě.

Dva příklady, které zde proběhly jsou přesně opačné. U tabulky oprávnění neexistence záznamu může vyjadřovat buďto to, že oprávnění je v implicitním nastavení, nebo že se má dědit z nadřazeného prvku (u stromové struktury). V případě nadřízených má OUTER JOIN taky smysl - nechcete z výpisu vyloučit nadřízeného, který jen dočasně nemá přiřazené podřízené. V obou těchto případech je důležité, aby si programátor tyto hraniční stavy uvědomoval. Pokud je zakryje INNER JOINEM, zdánlivě se mu bude zdát vše v pořádku - do doby, než problém vyplave na povrch v praxi.

Je to krátkozraké. Co když bude potřebný víc než jeden štítek? A co indexování štítků pro lepší vyhledávání? Bude to stíhat, když budu pravidelně potřebovat seznam štítků?

Ono se to dá řešit např. pomocí materializovaného pohledu ve kterém je DISTINCT, a refreshovat ho vždy jen po updatu. Otázkou je, jestli to není větší opičárna a jen omezeně škálovatelné.

1020

Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky

« kdy: 22. 10. 2019, 22:01:17 »

A jindy zase chci jednu sadu štítků pro jednu entitu a jinou sadu štítků pro jinou entitu. Ale pokud jste chtěl ukázat, že neexistuje jeden univerzální návrh databáze, který by se hodil na všechno, pak se vám to podařilo. Gratuluju, úžasný objev.

Jasně, zákazník chtěl jednoduché štítky, tak, jak je má každá aplikace. Ale vy mu z toho uděláte raketoplán, protože co kdyby to náhodou někdy potřeboval. Uživatel si původně chtěl jenom něco označit svými názvy, a teď musí určit prioritu štítku, přeložit ho do dalších jazyků a přes vedoucího požádat administrátora systému o založení štítku.

Tato dvě tvrzení mi nejdou do sebe. Doublethink?