Příspěvky

2146

Odkladiště / Re:Privacy - ako kratko a zrozumitelne vysvetlit dovody?

« kdy: 03. 11. 2019, 10:20:04 »

To, že je potřeba zachovávat tajemství, snad třeba psychologové vědí. Co nejspíš nebudou vědět je to, že zejména u e-mailu se na zachování tajemství nedá spolehnout, protože se e-maily posílají nešifrovaně – je to, jako kdyby si s klienty posílali pohlednice.

2147

Windows a jiné systémy / Re:Tisk A5 na šířku

« kdy: 03. 11. 2019, 09:17:52 »

A5 na šířku je A4 klasicky na výšku a je to podle mne nejjednodušší způsob, jak na A5 tisknout. Kdyby to nešlo jinak, dokument si dejte na klasickou A4 na výšku a spodní polovinu stránky nechte prázdnou. Podle mne byste naopak měl u některých tiskáren problém s tiskem A5 na výšku, protože neumí tak zúžit vedení papíru na vstupu.

2148

Sítě / Re:Jaký hardware pro správu sítě u rodičů

« kdy: 01. 11. 2019, 15:01:28 »

Myslíte ty vesnice, co "síťují" za dotace z EU https://wifi4eu.ec.europa.eu/#/home ?

Nebo ty, kde nabízí své služby Cetin https://zrychlujemecesko.cz/ ?

Konkrétně v případě domu mých rodičů je to spolek z nedalekého města, který má pokrytí i v přilehlých vesnicích. Před lety jsme měli spoj z vesnice do města na 2,4 GHz WiFi, dneska máme spoj o rychlosti ve stovkách Mbit/s /nevím teď z hlavy přesné číslo) a ve třetině vesnice jsme natahali optiku. Kdo se stará, ten má.

2149

Sítě / Re:Jaký hardware pro správu sítě u rodičů

« kdy: 01. 11. 2019, 13:56:31 »

Když nemáte co říct, tak mlčte. Takže mlčte pořád.

2150

Sítě / Re:Jaký hardware pro správu sítě u rodičů

« kdy: 01. 11. 2019, 13:26:31 »

Pokud by cena nebyla rozhodujícím faktorem, pak Turris Omnia + Turris Mox.

Se vším respektem k NIC.CZ a Turrisu bych si to nedovolil dát někam kde k tomu snadno nemůžu. Pokud se použije defaultní nastavení a nic moc extra se tam nenastavuje tak možná, pak je ale cena zbytečně velká.

Já takhle mám Omnii u rodičů na vesnici a mám za ní daný (samozřejmě vedle domácí sítě) i jeden server. Tagované VLANy jsem zprovozňoval na místě, ale pak už jsem s tím neměl problém. Za tu cenu to skutečně není pro každého – já věřím, že Omnia vydrží, a také mám možnost si ji uzpůsobit podle aktuálních potřeb, měl jsem tam chvíli třeba v LXC reverzní proxy. Navíc SoHo routerů se SPF moc není :-)

2151

Studium a uplatnění / Re:Nápad na bakalářskou práci se Spring

« kdy: 31. 10. 2019, 22:08:30 »

Nemyslím si, že by „REST server“ nebo „REST API“ byly nějaké všeobecně používané termíny, takže záleží na vás, jak si je definujete. Ale pod „používáno REST API“ bych si představil klienta, ne server. Pokud tam chcete mít „API“, napsal bych např. že server vystavuje API v podobě REST služeb.

2152

Studium a uplatnění / Re:Nápad na bakalářskou práci se Spring

« kdy: 31. 10. 2019, 19:18:23 »

V tomhle kontextu (použité technologie) bych psal o REST serveru, týká se to implementace. O REST API bych psal v případě, kdy není podstatná konkrétní implementace, ale jde o to samotné rozhraní (např. při popisu jednotlivých metod).

2153

Studium a uplatnění / Re:Nápad na bakalářskou práci se Spring

« kdy: 31. 10. 2019, 13:52:26 »

Já úplně nechápu, v čem ten reverzní server zde pomáhá. Řekněme, že uživatel spustí odeslání dotazu docmanager.com/documents, na IIS dojde ke směřování na docmanager.com:8443/api/documents. CORS předpokládám, že bude stejně muset být nastaven a tenhle nestandartní port (8443) bude stálen používán?

Webový prohlížeč pak komunikuje jenom se standardním portem 443 a pro něj se tváří, že je vše na jednom serveru (takže CORS není potřeba řešit, v rámci jednoho serveru je komunikace povolená automaticky). To, že vy máte API implementováno pomocí jiného serveru, je pak jenom váš implementační detail.

nejcasteji v roli reverzni proxy vidim pouzityho prave Apache

I Apache je na tohle docela bumbrlíček, podle mne nejčastěji se pro tohle používá nginx (pokud chcete servírovat i statický obsah). Případně se dají použít specializovanější varianty, jako HAproxy, Varnish, Traefik, Istio apod.

2154

Studium a uplatnění / Re:Nápad na bakalářskou práci se Spring

« kdy: 30. 10. 2019, 21:03:48 »

Ona je to vlastně ještě jedna varianta, příbuzná variantě 3, ale v produkci se obvykle nepoužívá. Z hlediska CORS se za shodnou adresu považuje trojkombinace protokol, hostname a port – jsou to dva nezávislé servery. Kdybych u toho bodu 3 škrtnul to upřesnění „na samostatných doménách“, to vaše řešení by tomu plně odpovídalo.

Důvod, proč se tohle řešení v produkci nepoužívá, je ten nestandardní port. U API by to teoreticky nemuselo vadit, uživatel to nevidí a v aplikaci je ten port zadaný. Jenže ve spoustě sítí se na nestandardní port nedostanete, takže by z nich ta vaše aplikace nebyla funkční (načetla by se statická stránka, ale API by bylo nedostupné). Proto se to v takovém případě nahradí variantou 2, kdy byst požadavky třeba na /api/* směřoval z webového serveru (IIS) na ten váš aplikační server (Tomcat na portu 8443). Uživatel by tedy vždy komunikoval jen s IIS na standardním HTTPS portu, a váš Tomcat pak nemusí být vůbec vystaven do internetu, bude se k němu přistupovat vždy jen prostřednictvím IIS. (Akorát tedy nevím, jak se takovéhle přeposílání požadavků na IIS konfiguruje – hledejte spojení „reverzní proxy“ / „reverse proxy“.) Je pak potřeba, aby to API mělo svůj jmenný prostor, abyste dokázal rozlišit, zda jde požadavek na statickou stránku nebo na API. Dobré je mít tam nějaký společný prefix, třeba právě to /api/.

2155

Studium a uplatnění / Re:Nápad na bakalářskou práci se Spring

« kdy: 30. 10. 2019, 15:06:23 »

Používají se všechny tři varianty:

• Máte aplikační webový server, na kterém běží API, a u něj je přibalen i statický web.
• Máte webový server, který servíruje statický web, a část adresního prostoru je přesměrována na „backend“ server, kde běží API. To API pak vlastně není přímo vystavené do internetu (i když ten web server tvoří jen velmi tenkou obálku, obvykle HTTP požadavky přeposílá bez větších změn – ale může třeba dělat terminaci SSL).
• Máte dva samostatné webové servery na samostatných doménách, jeden servíruje statické soubory, druhý poskytuje API.

Vše má svá pro a proti. Na úvodní konfiguraci je nejjednodušší 1. varianta, ale pak musíte i při změně webové části dělat nový deploy aplikace. Ve variantě 2 nemusíte řešit CORS (oproti variantě 3), aplikační server je trochu schovaný. Ve variantě 3 máte vše nezávislé, můžete mít klidně k API víc frontendů a klidně můžete statický web servírovat třeba z CDN od Cloudflare a a API mít na AWS, aniž by bylo nutné něco nějak konfigurovat (zrovna s Cloudflare to jde i ve variantě 2, ale pak všechny požadavky půjdou přes Cloudflare, ve variantě 3 půjdou z prohlížeče přímo do AWS).

2156

Sítě / Re:Jaký hardware pro správu sítě u rodičů

« kdy: 29. 10. 2019, 20:05:41 »

Pokud by cena nebyla rozhodujícím faktorem, pak Turris Omnia + Turris Mox. Pokud cena je důležitá ale není nejdůležitější,  pak asi něco od Ubiquiti. Pokud je nejdůležitější cena, je už to asi jedno…

2157

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

« kdy: 29. 10. 2019, 18:35:59 »

Protože tazatel může mít malware v telefonu, nebo si třeba mohl někdo na něj vystavit twin kartu a v jiných případech SMS odchytit.

Proto je tam ten druhý faktor – I-PIN.

Ano, to je klasický postup při řešení bezpečnosti. Dokud nemám doložený (prokázaný) opak, považuji chybu či narušení bezpečnosti raději za nejvážnější předpokladatelné. Tedy zcela logicky počítám s tím, že útoků mohlo být víc, než mi píplo na telefonu, a i to, že se mohl útočník s SMS dostat. Jediný, kdo k tomu má informace je RB a měla by informace poskytnout - např. kolik pokusů bylo, jestli se s "útočníkem" spojila, jestli zná jeho totožnost (aniž by ji prozradila) atd.

Když vám banka ty informace poskytne, co s nimi budete dělat? A co člověk, který ty SMS bude ignorovat a banky se nezeptá. Ten má být ohrožen? Není správný postup spíš ten, že to bude řešit banka, bez ohledu na ot jestli se někdo zeptá nebo nezeptá?

Chovat se obezřetně není spekulace. Naopak spekulace by byla spoléhat se na neověřenou a právně ztěžka závaznou radu.

Z vašeho textu ovšem plynulo, že to banka nijak neřeší, a to je spekulace. Ano, banka by mohla odpovědět o něco lépe – „nebojte, chyba není na vaší straně, o takovýchto případech víme a řešíme je; pokud vám zase taková SMS přijde, nemusíte se ničeho bát, bezpečnost účtu to nijak neohrožuje“. Jenže my vlastně nevíme, zda ta odpověď je přímo citace banky, nebo volný překlad od tazatele.

2158

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

« kdy: 29. 10. 2019, 13:06:18 »

Je to klasický příklad povyšování chyby na standard. Zatímco u SIM toolkitu by taková situace nemusela člověka pozastavit, v případě SMS už by měla.

Proč?

Bohužel, banka přenáší odpovědnost za ochranu SIM / SMS na zákazníka. Když se zákazník nakazí malwarem a někdo se mu do účtu dostane, banka od toho dává ruce pryč (pochopitelně). Nepochopitelně však ignorují nahlášené incidenty. Na místě by bylo, aby v tomto zmíněném případě banka konala. Běžný zákazník si vůbec neuvědomuje, že SMS může přeposlat malware, vůbec si neuvědomuje, že telefonní číslo se dá přenést na jinou SIM kartu atd. Banka je však odborně na výši a měla by na tyto situace umět reagovat. Minimem by bylo prověřit, kdo zadává požadavek na odeslání SMS a postavit na jisto, že se jedná jen o překlep v klientském čísle, nikoliv o útok. A zde nastupuje právní alibismus: bance je jednodušší popírat byť i jen potenciální narušení bezpečnosti, než ho řešit. Řešením by připustila svoji odpovědnost - minimálně od okamžiku nahlášení. To se jim nehodí.

Že to banka nijak neřeší je jen vaše ničím nepodložená spekulace.

2159

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

« kdy: 29. 10. 2019, 11:22:02 »

Opakujete mantru bez kontextu. Ano, přihlašovací jméno není tajný údaj.
SMS ověření v současné podobě není bezpečné.
Takže zbývá 4místný PIN - a ten těžko obstojí v měřítku bezpečnosti.

Takže musíte o situaci uvažovat jako o (možné) kompromitaci dvou ze tří údajů, a třetí veleslabý.

Ne, tajné údaje jsou dva, nešifrovaná SMS a I-PIN. Bezpečnost není hodnota ano/ne, je to celá škála. Nešifrované SMS nejsou z hlediska bezpečnosti neprůstřelné, určitou bezpečnost ale zajišťují. U SMS a I-PINu je podstatné to, že jsou to různé kanály, které by útočník musel kompromitovat. Banka zřejmě vyhodnotila, že riziko toho, že by útočník dokázal napadnout oba dva kanály, je nízké. Ostatně pro platby kartou zabezpečenými 3D Secure se používá jenom ta nešifrovaná SMS nebo ani to ne, a všichni to vesele používají.

Ostatně podívejte se na postupný vývoj zabezpečení zrovna v té RB (původně Expandia Baka a pak eBanka) – začínali s hardwarovým generátorem OTP, pak přidali šifrované SMS a dnes mají nešifrované SMS a I-PIN. Technické požadavky na bezpečnost u klienta se neustále snižují, protože lidé už se toho tolik nebojí a útoky jsou nepravděpodobné. Nakonec nejslabším článkem je obvykle uživatel, takže nemá moc smysl na jeho straně nějak extra posilovat technickou bezpečnost – pokud chcete skutečně posílit bezpečnost (ne mít jen alibi, že za to může uživatel), potřebujete bezpečnost posilovat spíš na straně banky, v detekci anomálií a podezřelých transakcí.

2160

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

« kdy: 29. 10. 2019, 11:00:16 »

K narušení bezpečnosti částečně došlo. Někdo zná Vaše přihlašovací ID.

Přihlašovací ID není tajný údaj, stejně jako uživatelské jméno v systému.

Pro srovnani s SSH: take vzdy pta na uzivatelske jmeno a pak na heslo, bez ohledu, jestli dany uzivatel existuje.

Nikoli. SSH se nemůže automaticky ptát na heslo už jenom z toho důvodu, že způsob přihlášení může být pro každého uživatele jiný. Mimochodem, pokud chcete zvýšit bezpečnost SSH, nechtějte, aby se ptal na heslo při zadání libovolného uživatelského jména, ale aby se na heslo neptal nikdy, protože přihlášení heslem bude zakázané.

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

Proč je tohle řešení méně bezpečné jsem vysvětloval v tom komentáři, na který jste reagoval trollením. Příště zkuste méně trollit a více číst.