Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - Filip Jirsák

Stran: 1 ... 7 8 [9] 10 11 ... 375
121
Software / Re:Elektronický podpis v Thunderbirdu
« kdy: 18. 04. 2023, 17:53:44 »
Zdravím,

jen upozorňuji že Gmail žádné české certifikační autoritě nedůvěřuje, viz. seznam důvěryhodných kořenových certifikátů: https://support.google.com/a/answer/7448393?hl=en

To je možná ten důvod, proč gmail vyhazuje tuto chybu, pokud tedy emaily protistrana čte v gmailu ve webovém prostředí. Pokud si protistrana čte emaily například v outlooku nebo v Thunderbirdu, tak se zde zase pro změnu uplatňuje důvěryhodnost certifikátů dle Microsoft trust storu, kde jsou české certifikační autority důvěryhodné.

Dodatek: Až teď jsem viděl přiložený obrázek :) Toto chyba důvěryhodnosti nebude.
Já teda žádný obrázek nevidím. Každopádně to, co popisujete vy, by znamenalo, že GMail nedůvěřuje certifikátu autority, ne že s obsahem zprávy někdo manipuloval. Samozřejmě je možné, že GMail mate uživatele úplně chybnou hláškou, ale nesázel bych na to.

122
Software / Re:Elektronický podpis v Thunderbirdu
« kdy: 18. 04. 2023, 15:44:31 »
Bylo by dobré, kdybyste sem mohl nějaký takový podepsaný e-mail přiložit, aby bylo možné zjistit, kde je chyba – za v GMailu nebo v Thunderbirdu a případně kde konkrétně (zda třeba je e-mail dobře podepsaný, ale je někde špatně nastavené kódování; nebo zda je podpis vygenerovaný ze špatných dat).

123
Server / Re:Cloud a disky
« kdy: 10. 04. 2023, 09:29:32 »
AD  by nemělo mít intenzivní diskové operace, u záloh asi tolik nezáleží na době zápisu ani čtení. Takže zbývá ten SQL server pro účetnictví. U SQL serveru nezáleží jen na počtu uživatelů, ale i na charakteru práce. Pokud uživatel nechá vytvořit nějaký report, který bude muset číst spoustu dat, i jeden uživatel může databázi dost zatížit. Ale jak je ta databáze reálně využívané, to můžete zjistit akorát z monitoringu, to vám takhle od stolu nikdo neřekne. Na jednu stranu by bylo divné, kdyby účetnictví bylo napsané tak, že jeden uživatel při běžné práci vytíží databázi intenzivními diskovými operacemi. Na druhou stranu si dovedu představit, že se nad tím účetnictvím dělají nějaké nestandardní operace, které databázi vytíží. Není to moc pravděpodobné, ale vyloučit se to (bez monitoringu databáze) nedá.

124
Sítě / Re:Blokování spojení
« kdy: 05. 04. 2023, 22:30:35 »
...tady bych si dovolil vlažně polemizovat, že pokud sama aplikace neumí "třikrát a dost", ale každému příchozímu si řekne o login a heslo, tak je fai2ban přínosem v rovině bezpečnosti. Omezí hádání hesel hrubou silou. Že sám představuje nějakou zátěž na systém, o tom žádná.
Dovolil bych si připomenout, že jsem napsal často, ne vždy. To za prvé. Za druhé, o žádném přihlašování jménem a heslem vůbec nebyla řeč – aplikace, na kterou míří spojení, vůbec nemusí žádné jméno a heslo podporovat, může to být veřejný HTTP server, SMTP server apod. Omezovat hádání hesel zrovna tímhle způsobem bych považoval až za úplně krajní možnost, pokud nic jiného nepůjde udělat. Protože to má spoustu nevýhod a je to velmi náchylné k tomu vyrobit si sám na sebe DoS.

125
Sítě / Re:Blokování spojení
« kdy: 05. 04. 2023, 21:43:48 »
Existuje, jmenuje se to fail2ban, funguje to na základě monitorování logů (takže budete potřebovat ty pokusy zapisovat do logu), a často to má větší režii, než odmítat ta spojení v cílové aplikaci.

126
Odkladiště / Re:Obsluha relací u klienta nebo na serveru
« kdy: 04. 04. 2023, 17:39:45 »
Ano, long polling se používal před dvaceti lety. Dnes vskutku existují modernější technologie jako WebSockets nebo server-sent events. Na serveru nejde ani tak o framework, který všechno zachrání, ale o počet souběžně otevřených spojení. A že když si klient drží otevřené spojení k serveru, nejde to moc dohromady s bezestavovým rozvažováním zátěže mezi více serverů, které umožňuje třeba dynamicky měnit počet serverů podle zátěže nebo bezvýpadkové aktualizace.

127
Úplně stačí nedělat na základě jednoho pozorování nepodložené závěry, zejména když přispíváte do diskuse, kde jsou uvedena jiná pozorování. No a když už někdo ty nepodložené závěry udělá a jiný upozorní na to, že to tak být nemusí, dá se třeba mlčet a poučit se z toho. Ale vymýšlet si a dělat nepodložené závěry, a když na to někdo upozorní, tvrdit, že si vymýšlí on, to není dobrý způsob diskuse.

128
Nepotrebuji fakta a osobni zkusenosti doplnovat dukazy - nejsme na Wikipedii.
Pak ovšem vaše komentáře nemají moc velkou hodnotu, protože spousta lidí naštěstí nevěří nepodloženým tvrzením anonymů v diskusi. A někteří si vás už pamatují a vědí, že vašim nepodloženým tvrzením není radno věřit.

Napsal jsem jak to bylo a jak to je.
Ne, napsal jste, jak si myslíte, že to je.

Vy jste ten, co rozviji ruzne teorie ze to tak nemusi byt, protoze rad postujete univerzalni odpovedi ve tvaru nekolika otazek, ktere vam poskytuji zadni vratka na dalsi zbytecne kecy. A tohle jsem rozporoval - ze si vymyslite, protoze zatimco ja ze sve zkusenosti vim jak to bylo, tak vy si muzete jenom vymyslet fantazijni scenare, odhadovat, tipovat, ci aplikovat teorii a buhvi co, ale realne postradate informaci o skutecnem stavu veci a zda se ze nemate ani zadnou konkretni zkusenost, o kterou by jste se podelil. Ale rad se podelite o fabulace na vsechny zpusoby, jen aby rec nestala, vid?
Protože ono to tak být opravdu nemusí. Dokonce i v případě Fio banky to může být jinak u jiných účtů, nebo při přístupu z jiné země, nebo kdyby to chybné zadání hesla bylo z různých sítí.

Váš problém je, že z jednoho velmi omezeného pozorování děláte dalekosáhlé závěry, ke kterým v tom pozorování nemáte žádnou oporu. Když si přečtete ostatní komentáře v diskusi, s praktickými příklady, zjistíte, že banky už řeší bezpečnost dynamicky, tj. v různých situacích budete pozorovat různé chování a různé požadavky. Takže to, co rozporujete u mne, je ve skutečnosti chyba na vaší straně. To vy si vymýšlíte, to vy ignorujete zkušenosti ostatních, to vy jednu svou omezenou zkušenost generalizujete na celý svět.

129
Nemyslím si, že je rozumné počet pokusů na zadání hesla navyšovat.
Je to rozumné. Protože když po pár pokusech účet natvrdo zablokujete, je to pro útočníka velice efektivní způsob, jak udělat DoS na vlastníka účtu.

Pokud někdo zná vaše uživatelské jméno a chce vám zablokovat přístup zadáním špatného hesla, tak je to stejné, jako když někdo ví kde bydlíte, a strčí vám sirky do zámku... Je to nepříjemné, ale to je asi tak vše.
Není to jen nepříjemné. Může to znamenat, že něco zaplatíte pozdě a zaplatíte penále. Někdo je zvyklý zamykat platební kartu a odemykat ji jen pro konkrétní platby – takže nezaplatí kartou. A hlavně – tohle není o jednorázovém uzamčení. Útočník vám takhle může účet držet trvale zamknutý. Do té doby, než si změníte přístupové jméno – a to zase bude fungovat jen do té doby, dokud útočník nezjistí nové jméno.

130
O cemz slusne informovali vlastnika uctu emailem - ve kterem je presne 0% sance, ze by se dalo prihlasit z jine adresy pred uplynutim doby.
Ať hledám jak hledám, tuhle informaci ve vašem komentáři nevidím. A nevidím ji ani ve vaší reakci na můj komentář, kde jsem tvrdil, že to nemusí být tak, jak jste napsal. Stačilo slušně odpověď, že jste to nejdůležitější ve svém prvním komentáři zapomněl napsat a doplnit citaci e-mailu. Místo toho jste mi začal podsouvat něco, co jsem nenapsal.

Jsi zde opakovane upozornovan na to, ze si vymyslis jako male dite a nejsi schopen si to uvedomit.
Vaše opakovaná upozornění jsou celkem k ničemu, když se ukázalo, že ten, kdo si vymýšlí, jste vy. Já jsem napsal, že to nemusí být tak, jak jste to vy popsal. Je to výmysl? Ne, není, opravdu to tak být nemusí a jiné systémy mají omezení hádání hesel implementováno jinak. Za to vy jste napsal, že já tvrdím, že je to implementované jinak. A to není pravda, já jsem nic takového nenapsal. Takže kdo si tu vymýšlí? No vy.

131
Blokace je zde na ucet, ne na IP adresu (prave z duvodu ze IP jde snadno menit - kdyz jste utocnik).
A to jste zjistil z jednoho počítače? Gratuluju, jak se vám to podařilo? Víte o tom, že banka k přihlašování přistupuje jinak, podle toho, odkud se přihlašujete? Že třeba při přihlášení odněkud z Asie po vás bude chtít vyšší stupeň ověření, zatímco když se hlásíte z počítače, odkud už jste se přihlašoval, bude po vás chtít nižší stupeň ověření?

Mimochodem, já jsem si nic nevymyslel. Já jsem napsal, že to tak může být. To vy tvrdíte s jistotou, jak to je – aniž byste měl šanci to ověřit.

132
FIO presne tohle dela - jsem potreboval neco vyridit z telefonu mimo domov (nemam appku, kdyz jedu PC only) a nemohl jsem si vzpomenout na heslo (nemam hesla sdilene online), tak po asi patem pokusu se ucet zablokoval na nejakou dobu.

Takze pokud vite nekoho prihlasovaci login (email), jde mu znacne zneprijemnit zivot.
Zablokoval jste si přístup z jednoho počítače. Z toho bych ještě neusuzoval na to, že útočník z opačného konce Země by vám dokázal stejným způsobem zablokovat přístup. To je právě to, o čem jsem psal – že je potřeba rozlišovat útoky z jednoho zařízení a distribuované útoky.

133
Omezit zadání hesla na X pokusů není v prostředí internetu tak snadné, když každý pokus může jít od jiného počítače, a kdybyste pokaždé po X pokusech účet zamknul, vytvoříte tím ideální prostředí pro DoS na přihlašování.

Normální systém, který používá dvoufaktorovu autentizaci, vám neřekne ani to, zda je špatně jméno, heslo nebo druhý faktor. Protože kdyby vám to řekl, je obtížnost útoku rovná obtížnosti útoku na heslo + obtížnosti útoku na 2. faktor, zatímco když vám to neřekne, je obtížnost útoku násobkem obtížnosti útoku na heslo a útoku na druhý faktor.

Přihlašovací jméno není tajný údaj, často je to třeba e-mail, který nemusíte hádat. Takže jméno se do ochrany účtu nepočítá.

134
Dříve bylo normální posílat SMS až nakonec, třeba po zadání platného hesla
To by umožnilo hádání hesla. Druhý faktor by se měl vyžadovat bez ohledu na to, zda první faktor byl správně nebo ne.

135
Doménové jméno je v pořádku. Ono to je v tom prvním postu tak nějak implicitně řečeno, ale chápu, že ta moje formulace vypadá, že jsme to nezkontrolovali.
Tohle jsou ale ty dvě nejdůležitější věci – jestli je to správná doména a jestli má důvěryhodný certifikát. To není něco, co můžete nechat jen tak implicitně. To je věc, kterou musíte napsat jako první, pokud to chcete nějak řešit. A ne „jméno je v pořádku“, ale zkopírovat to, co máte v adresním řádku prohlížeče.

Z laického pohledu teď mají stránky všechny údaje, aby se před uživatelem mohly vydávat za banku.
To je právě ale chybná úvaha. Musíte počítat s tím, že útočník má vždy všechny údaje, aby se mohl vydávat za banku. Kombinaci e-mailu a telefonu zná kde kdo.

Tím si právě nejsem moc jistý. To opravdu není možné, aby mi někdo (případně s mojí "dopomocí", zvlášť jestli třeba čtu poštu v Gmailu) propašoval do prohlížeče nějaký add-on nebo něco takového, co se pověsí na kód stránky banky (i když se k ní připojuji přes HTTPS) a doplní k ní dotaz na další údaje?
Je to možné, ale to je pak vaše chyba, že instalujete do prohlížeče rozšíření, o kterých nevíte, co dělají. Je to to samé, jako instalovat si do počítače neznámý software.

A protože tohle je problematická část (zejména u toho softwaru, pro instalaci nějakých rozšíření nevidím u neprofesionálního uživatele důvod), používá se dvoufaktorové ověřování. Tj. když provádíte platbu, přijdou vám na jiné zařízení údaje o platbě, které ověříte a teprve po ověření platbu schválíte.

Pořád to ale nijak nesouvisí s údaji, které po vás banka chce po přihlášení. Ty máte zadávat pouze do stránky, u které jste si ověřil, že je to ta správná stránka. A máte to dělat vždy, ať se hlásíte kamkoli. Ideální je používat na to správce hesel integrovaného s prohlížečem, který ty údaje vyplní za vás a vyplní je jenom do správné stránky.

Pokud by útočník měl pod kontrolou váš počítač nebo prohlížeč, protože jste nainstaloval jeho trojského koně, nepotřebuje váš mobil získávat zrovna z přihlašovacího formuláře k bance. A pokud by se útočník snažil získat přístup k vašemu bankovnímu účtu, vaše telefonní číslo k ničemu nepotřebuje. Potřebuje kód, který vám na telefon přijde (pokud používáte autorizaci přes SMS), ale telefonní číslo ho nezajímá.

Stran: 1 ... 7 8 [9] 10 11 ... 375