Příspěvky

991

Windows a jiné systémy / Re:Jak nastavit odemknutí BitLocker

« kdy: 21. 11. 2019, 21:03:58 »

V powershellu (PS musí být spuštěný v privilegovaném režimu "Spustit jako správce"):

Enable-BitLockerAutoUnlock -MountPoint "D:"

992

Vývoj / Re:SQL dotázek

« kdy: 19. 11. 2019, 09:58:23 »

Kód: [Vybrat]

select jmeno
from T
where auto in ('Nissan','Audi')
group by jmeno
having count(*) = 2 -- nebo > 1 pokud hledáte vlastníka alespoň jednoho z vozidel

Jsem jen blba uklizecka, ale tohle podle me vubec neresi situaci, kdy ma uzivatel napr. 2 Nissany a zadne Audi.

Na to stačí přepsat na HAVING count(DISTINCT *).

993

Vývoj / Re:SQL dotázek

« kdy: 18. 11. 2019, 21:27:13 »

A nejde to třeba jednodušeji pomoci průniku?

Ano, to by šlo, ale např. MySQL INTERSECT neumí.
(Jen pro doplnění: INTERSECT by sloužil pro AND, pro OR by se zase použil UNION)

Nevýhodou tohoto řešení by byla komplikovanost, pokud by se hledal průnik (nebo union) pro více hodnot než pro vzorové dvě. Dotaz by pak (ne)úměrně narůstal.

994

Vývoj / Re:SQL dotázek

« kdy: 18. 11. 2019, 21:03:48 »

Jak pak asi dopadne tohle?

Kód: [Vybrat]

jmeno;auto
Petr;Audi
Petr;Citroen
Petr;Audi
Ludvik;Nissan
Jarda;Nissan;
Jarda;Citroen
Karel;Audi
Filip;Audi

Ale to už tu bylo zmíněno, že?

Pokud se Vám toto v datech vyskytuje, pak musíte změnit podmínku na HAVING count(DISTINCT vazba_right).
Smysluplnější by bylo přidat UNIQUE INDEX ON tbl_vazba (vazba_left, vazba_right).

995

Vývoj / Re:SQL dotázek

« kdy: 18. 11. 2019, 17:55:05 »

Nějak tu nevidím ten SELECT, asi se vám při vkládání komentáře ztratil.

Asi narážíte na to, že joiny budou dva. Máte pravdu.

SELECT jmeno
FROM tbl1
LEFT JOIN tbl_vazba USING (vazba_left)
INNER JOIN tbl_hodnoty USING (vazba_right)
WHERE tbl_hodnoty.auto IN ('Audi', 'Nissan')
HAVING count(*) = 2
GROUP BY jmeno

Podtržené having když vynecháte, tak získáte požadovaný operátor Audi OR Nissan.
Pokud ho doplníte, získáte operátor Audi AND Nissan.

(Pro operátor OR by šlo použít DISTINCT, ale výkonnostně je totožné, takže je výhodnější si to abstrahovat do jednoho dotazu a HAVING přidat podle potřeby)

Select je jen schematicky, prosím nepeskujte mě, pokud neprojde, píšu je z ruky.

996

Vývoj / Re:SQL dotázek

« kdy: 18. 11. 2019, 14:01:10 »

V tom dotazu je, že vlastní Nissan a Audi. Pokud budete mít každé auto ve zvláštním řádku tabulky, bez vícenásobného JOINu se neobejdete. Leda by vaše databáze podporovala pole a vy jste z těch řádků nejprve udělal pole.  Nicméně když řešíte efektivitu, JOINy umí optimalizovat každá databáze; vytvářet z více záznamů jeden záznam s polem hodnot asi nebude zrovna věc, kterou by databáze optimalizovaly.

Ale houby, jeden join na tabulku s auty.
Buďto (a to bývá nejčastější) vyhovuje navrátit více řádků ke každému jménu (co řádek, to jedna značka), nebo
značky můžete agregovat do pole, to zvládne i MySQL.

997

Vývoj / Re:SQL dotázek

« kdy: 18. 11. 2019, 10:47:48 »

Záleží na množství. V malých počtech bude navržené řešení podobně efektivní, udělá se index nad textem.
Ve větších množstvích by vazba samozřejmě pomohla, protože tabulka hodnot by byla unique not null a indexoval by se pouze číselný typ. Join by to pak jednoznačně výkonově vyhrál.

998

Sítě / Re:Teplotní odolnost telefonního kabelu a zapojení

« kdy: 11. 11. 2019, 17:00:59 »

Prodávají se kabely pro venkovní použití. Aby vydržely UV záření, mráz a vlhkost.

999

Studium a uplatnění / Re:Uplatnění v oblasti kybernetické bezpečnosti -- bez, nebo s VŠ?

« kdy: 04. 11. 2019, 16:11:12 »

Neexistovala by možnost najít uplatnění v podobě právního poradenství nebo něčeho jiného?

To chcete radit v oblasti, které sám nebudete rozumět? Co byste pak radil?
Bezpečák je takový renesanční člověk - musí znát od všeho dostatek (ale nemusí znát nic do hlubokého detailu).

1000

Studium a uplatnění / Re:Uplatnění v oblasti kybernetické bezpečnosti -- bez, nebo s VŠ?

« kdy: 04. 11. 2019, 14:50:59 »

...

V bezpečnosti si budujete jméno postupně. Ono je to strašně složité v praxi, protože musíte umět najít kompromisy, aby ostatní mohli fungovat. Nastavit systém technicky co nejdokonaleji jde, ale ostatní pak nemůžou ani programovat, ani nasazovat, ani zpřístupňovat.

Podle mě to nejde ani bez znalosti programování (musíte umět ostatním nabídnou alternativu, jak to dělat lépe), ani bez toho práva.

1001

Studium a uplatnění / Re:Uplatnění v oblasti kybernetické bezpečnosti -- bez, nebo s VŠ?

« kdy: 04. 11. 2019, 14:42:45 »

Co jsem se koukal, tak jednou z možností by byl obor Bezpečnostně právní studia, přičemž bych se ovšem musel 24/7 biflovat právo a kriminalistiku.

Bezpečnost bez znalosti práva nemůžete stejně uplatnit. Bezpečák při své práci vyvažuje rizika vs. technická opatření.

1002

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

« kdy: 29. 10. 2019, 15:39:46 »

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č?

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.

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

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.

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

U raketoplánů také NASA věděla o tom, že při startu docházívá k poškozování termoizolace. Nikdy to však nepředstavovalo problém. Pak shořela Columbia. Byly to taky spekulace, že by se mohlo něco stát, jak někteří zaměstnanci oficiální cestou varovali? Kdepak, byl to klasický příběh povyšování chyby na standard.

1003

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

« kdy: 29. 10. 2019, 12:09:43 »

...

Já se s Vámi vůbec nepřu o tom, jestli je kombinace klientské číslo / nešifrovaná SMS / PIN dostatečná. V obecném případě ano.

Co říkám je, že bezpečnost devalvovala (z tokenu na sim toolkit, ze sim toolkitu na planou SMS).
To je potřeba vzít v potaz ve chvíli, kdy dojde k opakovanému pokusu (dorazí SMS bez vyžádání oprávněným).

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.

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í.

1004

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

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

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

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ý.

1005

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

« kdy: 29. 10. 2019, 10:00:55 »

Od toho je IS banky, aby útoky včas zastavil

Což se očividně nestalo, když klientská linka pouze ujistila, že se ani v případě opakovaného pokusu o nic nejedná.