Příspěvky

136

Odkladiště / Re:Zadaní telefonu při přihlášení do Komerčky

« kdy: 02. 04. 2023, 09:45:17 »

komerčka je srandovní. Taky ji zatím mám. "Nejlepší" mi přijde, že ona po přihlášení (a ověření SMS kvůli dvoufaktoru) pak už někdy vůbec SMS nevyžaduje na potvrzení platby (jen zadání hesla)

Takhle to mají všechny banky. Vyhodnocují rizika u každé platby zvlášť a podle toho také přizpůsobují požadavky na ověření. Kdyby na všechny platby aplikovaly ta nejpřísnější pravidla, banky by nikdo nepoužíval. (A ne, to, že potvrdíte platbu v mobilní aplikaci, není ta nejpřísnější možná kontrola.) To, že u té druhé platby není potřeba potvrzení, není závislé jen na době od první platby. Závisí to nejspíš také na částce, možná na tom, zda už jste na ten účet dříve platil, případně jestli cílový účet banka zná a jakou má reputaci.

137

Odkladiště / Re:Zadaní telefonu při přihlášení do Komerčky

« kdy: 02. 04. 2023, 09:40:13 »

Myslím to víceméně tak, jak to pochopil RDa citovaný nad vámi (akorát mu asi telefon opravil "fakta" na "faktury"). Vypadá to jako "útok" podle šablony na vysávání dat, aby se potom útočník mohl vydávat za banku. Banka prostě uživatele nutní provést něco, co se dá čekat u podvodných stránek (žádá neobvyklé informace navíc), a před čím jsou uživatelé varováni. I když to může být jen jejich snaha doplnit autentizaci něčím dalším kromě hesla pro dočasné (?) zvýšení bezpečnosti.

Prakticky si to pořešíme přímo s bankou. Sem jsem ten dotaz myslel spíš tak, jestli vám připadá v pořádku tyhle údaje požadovat a jak moc je takový požadavek v rozporu s tím, jak se uživatelům vtlouká do hlav, že mají být opatrní a nic navíc nikam nezadávat. Nemám tušení, jak je dneska běžné a časté (zvlášť přes HTTPS) podvrhnout část stránky nebo k ní něco přidat (a tipuju, že řádově složitější, než v nějakém phishing mejlu poslat "falešný" odkaz, který by si uživatel mohl v adresním řádku zkontrolovat).

Jestli to vypadá nebo nevypadá jako útok nevíme, protože to jediné, co rozhoduje o tom, zda to je nebo není útok – tedy doménové jméno a to, zda je potvrzené důvěryhodným certifikátem – jsme se zatím nedozvěděli.

Každopádně je to ale zajímavý test, jestli byste útoku podlehl – a tím testem jste neprošel. Protože útok nepoznáte podle toho, jak stránky vypadají, ani podle toho, co po vás ty stránky chtějí. Útok rozeznáte právě jen kontrolou domény.

Uživatelům se netlouká do hlavy, že nemají nikam zadávat nic navíc. Vtlouká se jim do hlavy, že údaje mají zadávat jenom tehdy, když mají ověřeno, že je zadávají na správný web.

138

Odkladiště / Re:Zadaní telefonu při přihlášení do e-bankingu Komerčky????

« kdy: 01. 04. 2023, 21:02:42 »

Za prvé, také si myslím, že je to dotaz především na banku. Za druhé, nevím, co si představujete pod termínem „MitM scam“. (Víc, co znamená zkratka MitM i co znamená slovo scam, právě proto se ptám, co si pod tím představujete vy.) Podle zpráv na webu KB aktuálně probíhá nějaká kampaň s falešnými stránkami KB, takže je možné, že KB aktivovala další úroveň zabezpečení.

Proti podvodným webům se uživatel brání především tím, že když má otevřený přihlašovací formulář, zkontroluje si, jestli doména zobrazená v adresním řádku prohlížeče je ta správná, a jestli je tam zámeček označující zabezpečené spojení. Pokud ano, zadává ty údaje bance. Pokud ne, nemá tam zadávat nic, i kdyby to po něm chtělo jenom login a nic jiného.

139

Server / Re:RCPT TO na různé domény stejného MX v jedné SMTP transakci vrací chybu 451

« kdy: 30. 03. 2023, 09:06:03 »

Nedíval jsem se do standardů (ale tam se můžete podívat sám). Řekl bych, že tu sdružené odeslání v jedné transakci není vyloženě proti konkrétnímu ustanovení v RFC, ale je to v rozporu s procesem odeslání e-mailu, který RFC předpokládá a popisuje ho. Protože ten proces vypadá tak, že máte e-maily k odeslání roztříděné podle cílových domén. Vezmete skupinu e-mailů pro cílovou doménu, z DNS získáte informaci, se kterým serverem máte komunikovat, navážete spojení a odesíláte e-maily. Když tenhle postup dodržíte, nikdy se vám nemůže stát, že byste v rámci jednoho spojení posílal e-maily pro různé domény – protože to nevíte, že někdy později se vám jiná doména náhodou přeloží také na stejnou IP adresu.

140

Sítě / Re:Pakety tečou neNATované do veřejného rozhraní

« kdy: 29. 03. 2023, 16:30:31 »

je to sice k mikrotiku, ale funguje to rovnako u kazdeho routra

Jenom drobnost – funguje to tak u každého routeru založeného na linuxu. Jiné systémy to mohou mít pojmenované jinak nebo dokonce mohou mít jiné schéma zpracování paketů.

Každopádně to grafické znázornění pomáhá představit si, jak se ten paket zpracovává. A je důležité si uvědomit, že u spojení (třeba TCP/IP) tohle schéma platí jen pro první paket (ten, který navazuje spojení). Pro další pakety to dorazí jen do bodu „connection tracking“ a jakmile se v něm paket zařadí do spojení, další manipulace s ním už odpovídá tomu, co se provádělo s prvním paketem (případně zrcadlově obrácené operace u odpovědních paketů).

141

Sítě / Re:NAT prerouting pravidlo iptables neotevře port

« kdy: 29. 03. 2023, 16:06:35 »

Obávám se, že odpověď na 3 roky starý dotaz už nikdo neocení. To akorát uživatel Vietnamka má bůhvíproč potřebu komentovat roky staré dotazy.

142

Sítě / Re:pakety tečou neNATované do public interface

« kdy: 28. 03. 2023, 23:25:30 »

Firewall iptables bere v úvahu spojení, tj. u TCP provádí maškarádu u odchozích paketů odchozího spojení, u příchozích paketů stejného spojení provádí inverzní úpravu vůči nakonfigurované maškarádě, takže příchozí pakety po té přijdou tak, jak mají být. Na příchozí spojení se maškaráda neuplatňuje. U iptables v tabulce nat platí, že pro spojení píšete pravidla pro paket navazující spojení, a u ostatních paketů už se iptables samy postarají, aby byly správně (v souladu s prvním paketem).

iptables naopak vůbec nerozhodují o směrování přes konkrétní rozhraní. O tom rozhodují routovací pravidla a routovací tabulky. Aby pakety odcházely přes správné rozhraní musíte zařídit tam.

143

Server / Re:Postgres - velikost text sloupecku v bytech

« kdy: 22. 03. 2023, 15:13:43 »

Záleží na kódování znaků. Existují jednobajtová kódování znaků, jde jeden znak = jeden bajt – třeba ISO-859-2, Windows-1250 (pro české texty), ISO-8859-1 (pro západoevropsé jazyky). Existují kódování, kde jeden znak = jeden až čtyři bajty – třeba kódování UTF-8. Znaky anglické abecedy jsou dlouhé 1 bajt, české znaky s diakritikou jsou dvoubajtové, nějaké emoji znaky mohou mít čtyř bajty. Jsou kódování, kde jeden znak jsou vždy dva bajty – třeba UCS-2, do kterého ale nejde uložit plný Unicode, jenom jeho podmnožina (ve které ale jsou všechny české znaky).

Délku textu v bajtech vrací funkce octet_length(). Počítá délku textu v kódování serveru (což je asi to, co chcete).

144

Odkladiště / Re:Obsluha relací u klienta nebo na serveru

« kdy: 20. 03. 2023, 21:32:46 »

Tady bych si tipnul, že když nějaký komplexní stav je udržován serverem, tak klient musí pouze identifikovat sebe, klidně anonymně nějakým číslem nebo klíčkem přiděleným při navázání relace. Čemuž dál už velmi dobře odpovídá Vaše zmínka o Session ID.

Je možné to udělat i tak, že klient identifikuje sebe, resp. asi by bylo vhodnější napsat uživatele). Pak třeba nemůže mít ve dvou různých záložkách prohlížeče dva různé stavy (třeba dva různé košíky). Častější bývá to, že je identifikován opravdu stav, tj. nějaký soubor údajů uložený na serveru (to, čemu se říká session, česky by se asi dalo použít relace). Pak jeden uživatel může mít víc aktivních stavů/session, tj. může být přihlášen vícekrát nezávisle na sobě. Součástí stavu obvykle bývá i informace o přihlášeném uživateli.

Ale myslím, že oba píšeme o tom samém – prostě klient posílá nějaký identifikátor, a na serveru je k tomu identifikátoru v nějaké méně či více sofistikované mapě uložena hromada údajů, které dohromady tvoří stav.

145

Odkladiště / Re:Obsluha relací u klienta nebo na serveru

« kdy: 20. 03. 2023, 14:04:28 »

Kdybyste napsal, odkud ten text kopírujete, nemuseli bychom to hádat.

Obecně platí, že stav může udržovat klient, a pak musí serveru poslat s každým požadavkem alespoň tu část stavu, který server bude potřebovat. Tohle řeší třeba JWT. Nebo stav může udržovat server, a pak klient musí udržovat nějakou identifikaci stavu a tu posílat s každým požadavkem – k tomu se používá třeba cookie se session ID.

146

Software / Re:Jak taru určit cílovou složku do které se má archiv rozbalit?

« kdy: 19. 03. 2023, 00:13:13 »

Já nevím proč vás to překvapuje, hledal jsem v nápovědě a man tar pipe grep -i target a nenašlo nic užitečného

Hledat grepem v manuálové stránce jedno jediné slovo není dobrý nápad. Pravděpodobnost, že se trefíte do toho správného slova, je dost nízká. Manuálová stránka tar není tak dlouhá, abyste si nemohl projít všechny volby, které tar nabízí. Aspoň byste získal povědomí o tom, co tar umí, a příště byste už měl lepší představu, co od něj můžete chtít.

147

Server / Re:Při absenci MX se nedoručí na AAAA

« kdy: 17. 03. 2023, 23:15:36 »

No a čemu na tom nerozumíte? MX ukazuje na jméno nebo jména. Když neexistuje MX záznam, použije se samotné doménové jméno z e-mailu (a přiřadí se mu priorita 0). Takhle získáte seznam jmen s prioritou a tahle jména berete podle priority a standardním způsobem je překládáte. Tj. když máte IPv4 i IPv6 konektivitu, můžete překládat A i AAAA záznamy. Jak naložíte s jednotlivými získanými IP adresami (v jakém pořadí je vyzkoušíte) je už na vás.

148

Server / Re:Při absenci MX záznamu:doručení na A~doménu OK,ale na AAAA~doménu NE

« kdy: 17. 03. 2023, 21:27:01 »

Tady.

149

Hardware / Re:Telefonní hovor v blízkosti notebooku a externího HDD

« kdy: 16. 03. 2023, 21:53:55 »

Až na takovou drobnost, že elektromagnetické vlnění je něco úplně jiného, než zvukové vlny (pohyb vzduchu a pevných látek)…

150

Windows a jiné systémy / Re:Jak rozbalit v IE všechny pluska?

« kdy: 15. 03. 2023, 15:28:46 »

Je to opravdu nějaká interní funkce Internet Exploreru (napadá mne jenom FTP klient)? Nebo je to nějaká webová aplikace otevřená v Internet Exploreru? Pokud je to to druhé, musíte pátrat po tom, zda to umí ta webová aplikace – a tipoval bych, že neumí.