Tím, že máte uloženo
challenge
md5(hash_hmac(‚md5‘, $challenge, md5($password)))
už nemůžete ten challenge změnit. Pokud pošlete uživateli jiný challenge, nemůžete ověřit jeho heslo, protože máte uložen jen md5(hash_hmac(...)) s tím původním challenge.
Pokud se někdo dozví hodnotu vašeho
md5(hash_hmac(‚md5‘, $challenge, md5($password)))
je to jako by se dozvěděl heslo v plaintextu. Ví co má poslat až dostane ten jedinný challenge, který máte u příslušného uživatele uložený.
Ale neprozradí to jeho heslo, které uživatel možná používa i do jiných služeb. To je pravda.
Prave jste porusil prvni pravidlo kryptografie - don’t roll your own crypto. Opet se vyjadrujete k necemu, cemu nerozumite.
Pouhym hashovanim hesla jen problem odsunete, ale nevyresite anavic podlehnete falesnemu pocitu bezpeci. Na Zero-knowledge password proof se daji tu jsou ruzne Digest Authentication, CRAM-MD5, Secure Remote Password protocol...
myšlenka to je hezká, ale v praxi nic takového nefunguje, http digest je závislý na md5, nemá podporu napříč prohlížeči, nepodporuje odhlášení a ani více účtů. Nemluvě o ne neuživatelské přívětivosti přihlašovacích formulářů v prohlížečích.
CRAM je založen na md5 a není moc rozšířený a pro mě je již mrtvý, z rodinky Challenge–response se ale používá třeba CHAP nebo RADIUS, ale pouze v uzavřených skupinách, nic pro otevřené weby, potřebuje SW na klientské straně. Na webu jsou za mě dobře použitelné deriváty nad oAuth s OTP.
Nakecejte zájemcům o takové informace cokoli, jen ne pravdu!
Lhát svým zákazníkům a uživatelům není zrovna nejlepší strategie a provozovatelům webů bych ji rozhodně nedoporučoval.
Se sociálním inženýrstvím to má opravdu pramálo společného. Navíc nesbírám informace o celkovém zabezpečení, ale jen o ukládání hesel a zveřejnit informaci o tom, jak provozovatel hesla uživatelů ukládá ničemu neuškodí, zvlášť pokud je ukládá doporučeným způsobem. Pokud by se v hashovací funkci objevil nějaký problém, a že se občas nějaký objeví, tak samotná informace o použití dané funkce je útočníkovi k ničemu. Musel by nejdřív sehnat ta zahashovaná hesla. A kdyby je sehnal, tak ve většině případů stejně pouhým pohledem pozná, o jakou funkci se jedná.
Pokud používáte doporučené funkce pro hashování hesel, nemusíte se bát to zveřejnit. Firmy jako Facebook, Slevomat, Mall.cz, Apiary, Dropbox a další to udělaly dobrovolně, aniž by se jich někdo vůbec ptal. Pokud doporučené funkce nepoužíváte, tak to také budeme rádi vědět, ale ještě lepší bude, když to co nejdříve předěláte a dáte nám vědět třeba až potom.
Děkuji za vysvětlení, ale pořád mi to není úplně jasné, pokud vytvořím hash původního hashe a výzvy serveru a ten odešlu při autentizaci, tak aby ho server ověřil, musí být schopen udělat totéž, to znamená, že má ten původní hash někde u sebe uložený v otevřené podobě (či obecně tak, že původní hash získat lze). Je to tak?
Asi je to profesní deformace, ale opřít bezpečnost o to, že se k té databázi nedostane nikdo nepovolaný... Na to bych si fakt nevsadil. A zabránit MITM tím, že někde centrálně uchovávám vše potřebné k autentizaci... Určitě existují prostředí, kde to smysl dává, ale že by jím byl "internet obecně", to mi nepřijde.
Zajímavější by mohly být ty novější protokoly, kde k přihlášení data na serveru nestačí. Nějaký příklad? Takový, který je pořád použitelný pro situaci "uživatel se přihlašuje z mnoha prohlížečů na mnoha zařízeních a jediné, co má k dispozici (a co je tedy přítomno při všech pokusech o autentizaci), je heslo v hlavě", protože to je maximum, co se dá od většiny uživatelů očekávat.
"Když z prohlížeče odejde hash(web+heslo), nezná provozovatel původní heslo."
To je pravda, nicméně dnes se toto dá implementovat pouze pomocí JavaScriptu (případně pomocí JavaScriptu a Web Crypto API), což znamená, že provozovatel to heslo pořád znát může. Může totiž svůj JavaScriptu (třeba cíleně) upravit tak, aby browser heslo vlastně nehashoval a poslal v čitelné podobě a nikdo to nezjistí, bohužel.
Dnes se tedy toto nepoužívá, protože stále musím věřit provozovateli, že jeho kód je v pořádku a to se moc neliší od toho, že mu musím věřit, že moje heslo nezneužije. A pokud se ve speciálních případech (správce hesel apod.) něco takového používá, tak se používá protokol SRP, ale pro většinu běžných webů (ať už to znamená cokoliv) se to nehodí už třeba jenom z důvodu náročnosti implementace.
PBKDF2 používá např. LastPass. V seznamu ho nemám proto, že jsem ještě nevymyslel, jak přidávat služby, které z hesla odvozují šifrovací klíče a heslo samotné neukládají.
PHP funkce password_hash()
je dostatečně dobrá na ukládání hesel a v některých ohledech lepší, než PBKDF2. Má jednodušší nastavení: není třeba vybírat hashovací algoritmus, počet iterací je trochu srozumitelnější na zadávání a konkrétně v PHP není třeba ani vymýšlet a zadávat salt. To je dokonce v novějších verzích PHP již deprecated, funkce password_hash()
ho vyrobí sama. Z toho by se mohli vývojáři knihoven pro ukládání hesel pro jiné jazyky poučit a funkce na hashování hesel udělat podobně jednoduché.
Když z prohlížeče odejde hash(web+heslo), nezná provozovatel původní heslo. Přičemž znalost hesla je to, co je problematické – protože lidé používají na více místech stejná hesla. Když uniknou hashe pro danou službu, je to problém jenom té služby.
Hashovací funkce má být univerzální, je závislá na heslu a na identifikaci serveru, sůl se nepřidává. Pro vlastní autentizaci se pak vytvoří hash toho prvního hashe a výzvy serveru, takže ani při odposlechnutí komunikace nezíská útočník údaje potřebné pro opakované přihlášení. I když to je při použití HTTPS méně zajímavé. Takhle funguje třeba HTTP Digest, novější protokoly fungují tak, že ani to, co má uložené provozovatel webu, nestačí pro přihlášení.
Mimochodem,i v prohlížeči pak může být místo hesla uložený ten hash (heslo + identifikace webu), takže heslo pak útočník nezíská ani z prohlížeče (může získat ten hash, kterým se přihlásí na ten konkrétní web).
Tady je důvod, proč DANE nepodporuje Chrome
"Some years ago now, Chrome did an experiment where we would lookup a TXT record that we knew existed when we knew the Internet connection was working. At the time, some 4–5% of users couldn't lookup that record; we assume because the network wasn't transparent to non-standard DNS resource types."
Pro představu, šlo by to implementovat třeba tak, že si na základě hesla vygeneruješ deterministicky RSA keypair (to prvočíslo se velmi zjednodušeně řečeno generuje tak, že uděláš náhodné číslo a pak ho inkrementuješ dokud nenarazíš na prvočíslo -- a to prvotní náhodné číslo můžeš získat jako hash(doména + heslo)) a na server při registraci pošleš jeho veřejnou část. Při přihlašování pak prostě serveru podepíšeš challenge.
Podobný protokol je SCRAM.
To, že to uživatelé nepoužívají, je klíčové. Bezpečnost se dá zvýšit jedině tak, že se typické chování uživatelů učiní bezpečným, ideálně tak, aby to pro uživatele neznamenalo komplikaci. Dát uživatelům možnost chovat se bezpečněji je skoro k ničemu.
Ony v tom mají prsty i autoři prohlížečů, protože jejich password manažery nejsou zrovna uživatelsky přívětivé a například zcela postrádají funkci generování hesel. A další problém je opět v přihlašování přes formuláře – jak má chudák prohlížeč hádat, co je heslo k webu a k jakému webu. Kdyby se používala HTTP autentizace, je to pro prohlížeč mnohem jednodušší.
problemom je, ze vobec nejake vychozi heslo existuje. IoT si este poriadne nenaslo zabezpeceny sposob konfiguracie. Netvrdim, ze je to jednoduchy problem. Len ze zatial nema vseobecne uznavane riesenie. Na webe sa celkom dari OAuth. V spojeni s dvojfazovou autentikaciou a behavioralnou analyzou (zrazu sa k uctu pripoji niekto v bangladeshi) je to super.
Nebojte, já jsem pochopil, jak to David Grudl myslel – to jedno heslo v otevřeném tvaru, které je pro uživatele důležité, je heslo k password manageru, a to se nikam neposílá. Heslo k příslušnému webu pak může být nějaké generované, které uživatele nezajímá.
„Běžné“ přihlašování pomocí hashe funguje tak, že se z uživatelského hesla nějakou jednosměrnou funkcí odvodí hash, kterým se uživatel autentizuje. Passsword manager funguje vlastně stejným způsobem, akorát že ta odvozovací funkce není žádná kryptografická funkce, je to prostě mapa web:heslo.
Tohle se ale míjí s podstatou problému. Když vám někdo řekne, jak ukládá hesla, můžete mu věřit a nemusíte. A i když bude dotyčný mluvit podle svého nejlepšího vědomí a svědomí, pořád se dozvíte akorát to, jak si myslí, že ukládají hesla – jenže v implementaci může být chyba nebo hesla mohou unikat někudy po cestě.
Správné řešení je, že se provozovatel webu heslo vůbec nedozví. Aby to bylo bezpečné, heslo nesmí nikdy opustit webový prohlížeč – prohlížeč ho má zahashovat a posílat jedině hash (i při registraci).
Tlačit na provozovatele, aby prohlásili, že hesla hashují, povede k jedinému – provozovatelé prohlásí, že hesla hashují. Ostatně to, že v roce 2016 není přihlašování pomocí hashů standard a že ani neexistuje norma pro registraci, která by provozovateli webu nezasílala heslo, ale jen hash, to je ostuda všech lidí „od webu“.
Jenda: nedochazi, dane nema s siforvanim jako takovym nic spolecneho, dane rika, ze pokud jste na https, tak toto je ten jediny spravny certifikat. Zadna CA pak nemuze vydat jiny.
MS: HPKP je v tomto ohledu naprosto knicemu. Stejne jako HSTS. Oboje je naprosto technicky nesmyslna technologie. Jedno i druhe je o tom, ze si browser bude pamatovat databazi miliard webu. Hole silenstvi.
Ano, jiz vidim reseni ala google ... zeptejte se nasi jedine duveryhodne databaze ...
> dane rika, ze pokud jste na https, tak toto je ten jediny spravny certifikat. Zadna CA pak nemuze vydat jiny
Já to chápu. Ale pokud jsem útočník a mám v ruce falešný certifikát, k jeho použití potřebuju MITM na uživatelovo připojení -- čímž téměř určitě získám i MITM na jeho DNS dotazy.
Můžeš nadhodit nějaký scénář útoku, kde DANE, které se samo deaktivuje, když se TXT nepodaří přeložit, pomůže?
Což je to jediné, o co v situaci popisované v článku doopravdy jde.
Ne, není to to jediné, protože:
a tím, že by se přihlásil jménem uživatele, už nic dalšího nezíská.
Může. Databázi hashů může stánout jinde, než ze systémů provozovatele (například zapomenuté zálohy na cizích serverech apod.), v databázi mohou být nějaká data zašifrovaná a k jejich rozšifrování je potřeba právě to heslo, případně se data po přihlášení získávají odjinud, z jiných systémů, ke kterým útočník přístup neměl.
Pokud by měl přímo přístup na servery a mohl změnit nebo spouštět kód, tak je to samozřejmě jiná, ale to naštěstí není tak častý případ, jako získání databáze např. pomocí "read only" SQL Injection.
Pokud kdokoli veřejně deklaruje, jaké používá zabezpečení, je blázen. Sociální inženýrství pak zákonitě navazuje...
Dnes se budu veřejně chlubit, jaké zabezpečení používám a zítra se objeví "security issue" v mnou používaných komponentách zabezpečení. Bezva!
Závěr: Nakecejte zájemcům o takové informace cokoli, jen ne pravdu!
Zkusenost rika, ze hesla nejsou v bezpeci vubec nikde ... vyjimku pak mohou tvorit ti, kteri zverejni maximum dostupnych informaci. Pokud se necemu takovemu nekdo apriori brani, je prakticky jiste, ze patri prave mezi ty prusvihare, kterym nejspise s vysokou mirou pravdepodobnosti jiz hesla dokonce unikla.
Tohle moc nechápu. Pokud jediné, co odejde z prohlížeče, je hash, čím se to liší od situace, kdy jediné, co odejde z prohlížeče, je heslo? Ano, ten hash je sice výrazně silnější heslo než password123, takže ho asi nikdo neuhodne, ale pokud někdo odposlouchává komunikaci či pokud protistrana ten hash uloží tak, jak přijde (což by se imho stávalo častěji než ukládání plain hesel dnes, protože leckomu by přišlo zbytečné hashovat hash) a ta databáze unikne, jste na tom stejně. Přijde mi, že řešíte jen brute-force attack, což ale opravdu není vše.
Navíc mě napadá další problém, který ale možná má nějaké řešení, rád se ho dozvím. Uživatelé svůj účet chtějí používat v různých prohlížečích na různých zařízeních, přičemž všude by platilo, že pokud zadají své heslo, musí z toho vypadnout stejný hash (ten, který byl vypočítán při registraci, opomíjím situace, kdy by bylo možné říct, že dva různé hashe patří stejnému heslu, stejně jako možnost, že by server posílal nějakou sůl, přijde mi, že funkce, která umožňuje říct "ano, tento hash patří neznámému heslu se solí A a tento stejnému heslu se solí B", nebude zrovna bezpečná - ale třeba je tohle právě to, co už bylo vyřešeno).
To ale znamená, že hashovací funkce by musela být univerzální a závislá jen na zadaném heslu. Jenže pak by se daly použít úplně stejné metody pro brute-force attack jako dnes, akorát by se jim předřadila rainbow table pro tuhle funkci.
A to je právě ta ostuda, že už na to dávno neexistuje standard a dávno to není implementované v prohlížečích. Protože v tomto případě to technicky vyřešit jde, na rozdíl od prohlášení provozovatele webu, že s hesly určitě ale určitě zachází bezpečně.
Mimochodem, ta implementace v JavaScriptu by pořád byl závislá na session cookies. Výhoda přihlašování pomocí HTTP hlavičky Authorization je i v tom, že řeší problém únosu session, protože je autentizován každý jednotlivý požadavek.
Jestli to sami nezveřejňují nejlépe hned na titulní stránce, tak hesla z logiky tohoto článku ukládají zřejmě nebezpečně a nelze jim tedy důvěřovat.
Btw. touto ironií bych chtěl jen naznačit, že článek má myšlenku hezkou, ale tohle vnucování "nezveřejníte, automaticky vás označíme jako méně důvěryhodné" je podle mého neetické a zbytečné. Těch důvodů, proč někdo na takovouhle otázku novináře neodpoví, může být celá řada, včetně prostého "nemám na vás čas" a to ani v nejmenším není totéž, jako "hesla uživatelů pravděpodobně nejsou v bezpečí".
Předávání hesla v otevřeném tvaru provozovateli webu a spoléhání na to, že ho nikdo cestou neodposlechne, že ho nezneužije provozovatel a že s ním dokáže pracovat tak, aby ho nezneužil někdo jiný, to také nefunguje. Rozdíl je v tom, že standardizovat nějakého nástupce HTTP Digest jde a není to tak složité, donutit všechny provozovatele webu, aby s hesly zacházeli bezpečně, je nemožné. Mimochodem, i HTTP Digest s MD5 by byl milionkrát lepší, než se přihlašovat webovým formulářem a session cookies.
DANE je vyšší úroveň zabezpečení jedině v případě, kdy máte certifikát vydaný uznávanou certifikační autoritou, a DANE vás chrání, aby vám někdo nepodstrčil certifikát vydaný jinou důvěryhodnou certifikační autoritou. Takže útočník by musel umět vystavit falešný certifikát důvěryhodnou certifikační autoritou a zároveň umět zahodit váš DNS dotaz. To už je hodně schopný útočník.
Navíc pokud nebudou fungovat TXT záznamy, nebudou nejspíš fungovat ani DS záznamy, a prohlížeč prostě může uživatele upozornit, že nějaká bezpečnostní funkce je vypnutá.
A do třetice, když může zrovna Chrome tlačit na podporu HTTPS, na opuštění slabých algoritmů, na podporu IPv6, proč by nemohl tlačit na to, aby sítě nekazily DNS?
Já za ignorováním DANE a DNSSEC vidím jiný důvod – Google to nepotřebuje, protože pár svých certifikátů si dá přímo do prohlížeče.
Instead, for this we have HPKP
Ano, jak jsem psal, Google má pro sebe řešení. Ale HPKP není řešení pro celý web, protože na spoustu webů chodí uživatelů výjimečně nebo tam jdou poprvé. HPKP by bezpečně fungovalo jenom tehdy, když by uživatel měl v prohlížeči certifikáty od všech existujících webů. Navíc když už máme útočníka, který dokáže vystavit falešný důvěryhodný certifikát a stornovat DNS dotaz, je pro něj zahození HPKP hlavičky trivialita.
Ale neprozradí to jeho heslo, které uživatel možná používa i do jiných služeb. To je pravda.
Což je to jediné, o co v situaci popisované v článku doopravdy jde. Pokud útočník dokáže získat ze systémů provozovatele webu hash hesla, často získá i další data nebo má přímo přístup do systému, a tím, že by se přihlásil jménem uživatele, už nic dalšího nezíská.
Proto tam byla ta slovíčka „doopravdy“ a „často“, která naznačují, že to není absolutní. Ale je potřeba vědět, jaké je pořadí. Nejdůležitější je, aby se provozovatel nedozvěděl přístupové údaje k jinému webu. Protože koneckonců ty údaje nemusí zneužít jenom útočník, který daný web napadne, ale může je zneužít i samotný provozovatel. Další v pořadí je, aby od provozovatele neunikala data. Protože se může stát, že uniknou jenom hesla a nic jiného, ale spíš se stane, že uniknou i další údaje. A upřímně řečeno, mně na takových únicích ze všeho nejmíň vadí právě to heslo, protože náhodných hesel vygeneruju útočníkovi kolik chce, ať si je užije, ale e-mail, adresa, objednávky, e-maily nebo co daný systém zrovna eviduje, to nechci vytrubovat do celého světa. Dále je v pořadí to, aby se na bezpečnostní problém přišlo, když už k němu dojde. A i v takové situaci se pořád útočníkovi jednoduše znemožní přístup tím, že se hesla resetují. A teprve na konci celého tohle seznamu je taková třešnička na dortu – když útočník získá přístupové údaje pro jeden server, nepodaří se mu získat jiná zajímavá data, a na útok se nepřijde, tak aby se útočník nedokázal přihlásit na web jménem uživatele. Což by zase měly odhalit bezpečnostní mechanismy, protože se přihlásí odjinud, z jiného prohlížeče atd. No a vzhledem k tomu, že by se ten standard stejně teprve musel vytvořit, nemusí se stavět na HTTP Digest, ale třeba na SCRAM, který by měl být odolnější i v případě, kdy útočník získá údaje uložené na serveru.
Lhát svým zákazníkům a uživatelům není zrovna nejlepší strategie a provozovatelům webů bych ji rozhodně nedoporučoval.
Ukládat údaje zákazníků a uživatelů tak, že se k nim dostane někdo cizí, také není nejlepší strategie a provozovatelům webů bych ji nedoporučoval. Což ale neznamená, že se to neděje.
Navíc problém nemusí být jenom v záměrném lhaní, ale v tom, že si dotyčný provozovatel neuvědomí nějaké souvislosti – ty samé, které pak zneužije útočník. Přečteme si tady na Lupě, jak má nějaký web dobře zabezpečená hesla, a pak budeme stejně jako provozovatel webu překvapeni, že hesla unikla ze záloh.
Se sociálním inženýrstvím to má společného dost. Argument sbíráním informací „jen o ukládání hesel“ je nesmyslný, to je princip sociálního inženýrství, vylákat „jen“ takové informace, u kterých dotyčný nepojme podezření, že by říkal něco nebezpečného. A sociální inženýrství to je – provozovatel může pod tlakem zveřejnit i informace, které mohou útočníkovi pomoci (i když hesla ukládá podle vás správně), může pod tlakem prozradit, že údaje neukládá úplně správně, a nebo se bude prostě jenom snažit vám vyhovět a rychle to „opravit“ – a svůj dříve bezpečný systém ukládající třeba nešifrovaná hesla „opraví“ na systém sice ukládající hesla hashovaná ale obsahující nějakou banální díru.
Ten váš „doporučený“ způsob ukládání hesel je akorát potěmkinovská vesnice. Provozovatel má ukládat všechny údaje tak, aby se k nim nedostal nikdo nepovolaný. Hashování hesel je jenom pojistka pro případ, že údaje uniknou – mírně se tím zmenší obrovský průšvih. Jenže to, že uživatel zadává heslo do obyčejné webové stránky často plné různých cizích skriptů, že se to heslo s každým přihlášením posílá provozovateli, že je uživatel dál identifikován jenom cookie, to všechno jsou průšvihy horší než ukládání hesel v otevřeném tvaru.
Tlačit na provozovatele webu, aby hesla hashovali, je dneska o několik let pozdě. Pokud chcete udělat něco pro to, aby se reálně zvýšila bezpečnost uživatelů (s dnes dostupnými prostředky), tlačte na to, ať umožňují přihlášení přes OpenID, Facebook, Google, nebo třeba Twitter nebo GitHub, kde to dává smysl. Žádné heslo je milionkrát lepší než hashované heslo. Pokud chcete opravdu zvýšit bezpečnost uživatelů, naučte je pro důležité služby používat dvoufaktorovou autentizaci. Pokud chcete opravdu zvýšit bezpečnost uživatelů, naučte je používat správce hesel a generovaná hesla.
Mediální tlak na „používání doporučených funkcí pro hashování hesel“ není nic jiného, než bublina namířená na lidi, kteří toho o bezpečnosti mnoho nevědí – ale aspoň si mohou společně zanadávat, jak to někdo dělá špatně. Takový styl Novinky.cz. Protože pokud má někdo systém děravý jak řešeto, a na základě mediálního tlaku to „zachrání“ použitím „doporučených funkcí pro hashování hesel“, bude mít dál systém děravý jak řešeto a nic se nezmění. Někdo jiný naopak může mít systém velmi dobře zabezpečený, „doporučené funkce“ nepoužívá a dobře ví proč – ale rozumbradové v diskusích, kteří vědí akorát že „používání doporučených hashovacích funkcí je dobré“ se mohou poplácávat po ramenech, jak to tomu Googlu natřeli. To chcete podporovat?
Pokud bychom se bavili o skutečném certifikátu (OV nebo EV), ne o parodiích na certifikáty (DV), pak žádný MitM není potřeba – vlastník domény třeba www.komercni-banka.cz nemusí nijak útočit na síťové vrstvě, jemu „stačí“, když se mu podaří získat certifikát na jméno „Komerční banka a. s.“ a nasměruje uživatele na svůj web třeba e-mailem.
Ale to se bavíme o certifikátech jak mají být, o uživatelích, kteří vědí, že u důležitých webů musí být certifikát na jméno a ne na doménu, a o situaci, kdy je DANE stejně k ničemu. V reálném světě je to pořád stejné, když se útočníkovi podaří „vypnout“ HTTPS, DNSSEC nebo DANE, oslabuje tím zabezpečení – takže prohlížeče musí přitvrzovat v tom, jak důrazně varují uživatele, že je něco nestandardní, což zároveň tlačí na provozovatele sítí, aby u nich aspoň HTTPS, DNSSEC a DANE fungovalo normálně.
Mam svoje zasady. Na systemech, ktere nemam pod fyzickou kontrolou, pouzivam zasadne trivialni anebo zcela nahodna hesla. Zadny hash totiz nikdy neochrani tak dobre jako D-H mezi dvema zajistenymi zarizenimi.
Autorovi bych nabidl jine, rovnez zajimave tema. At se projde po dostupnych SSH instancich v ruznych firmach (statni firmy samozrejme nevyjimaje) a zjisti si, jestli by napriklad dokazal napadnout jimi nabizene KEXy. Vysledky by mozna prekvapily nejednoho odbornika.
Zcela se ztotožnuji s názorem, že "z důvodu bezpečnosti neprozrazujeme, jakým způsobem jsou uložena hesla, nebo cokoli jiného".
Proč ?
Protože na bezpečnost systémů je třeba nahlížet jako na celek, ze kterého není moudré vyzobávat jednotlivé položky.
Je to stejná logika jako u konfigurace firewallu - "tedy tato informace není potřebná, čili neprojde" versus "tohle je nebezpečné, to musíme zakázat" - správně je první varianta.
A argument aby měli novináři nad čím onanovat není důvod pro porušení jedné z vrstev bezpečnosti - tedy neposkytovat informace tam kde to není potřeba.
Sociální inženýrství je jednou z největších, ne-li největší hrozbou počítačové bezpečnosti.