it-swarm-eu.dev

„Uživatelské jméno a / nebo heslo je neplatné“ - Proč webové stránky zobrazují tento druh zprávy místo toho, aby informovaly uživatele, která z nich byla špatná?

Řekněme, že se uživatel přihlašuje na typický web, zadává své uživatelské jméno a heslo a nesprávně zadává jeden ze svých vstupů. Všiml jsem si, že většina, ne-li všechny, weby zobrazují stejnou zprávu (něco v řádcích „Neplatné uživatelské jméno nebo heslo“), přestože je chybný pouze jeden vstup.

Zdá se mi dost snadné informovat uživatele o tom, který vstup byl špatný, a to mě zajímá, proč to stránky neudělají. Existuje tedy bezpečnostní důvod nebo je to něco, co se stalo normou?

103
bobble14988

Pokud uživatel se zlými úmysly začne útočit na web hádáním běžných kombinací uživatelského jména a hesla, jako je admin/admin, útočník by věděl, že uživatelské jméno je platné, vrací zprávu „Heslo neplatné“ místo „Uživatelské jméno nebo heslo neplatné“.

Pokud útočník ví, že uživatelské jméno je platné, mohl by soustředit své úsilí na konkrétní účet pomocí technik, jako jsou injekce SQL nebo hrubé vynucení hesla.

128
user10211

Jak již uvedli ostatní, nechceme, abyste věděli, zda to bylo nesprávné uživatelské jméno nebo heslo, takže nejsme tak citliví na brute-force nebo slovník útoky ..

Pokud by některé weby chtěly informovat své uživatele o tom, který z nich selhal, přestože jsou stále v zeleném zabezpečení, mohli by implementovat uživatelská jména „ honeypot “ (například správce, správce atd.), Která by varovala web administrátoři, že někdo kolem svého webu slídí. Mohli byste dokonce nastavit nějakou logiku, aby zakázali jejich IP adresu, kdyby se pokusili přihlásit s jedním z těchto uživatelských jmen „honeypot“. Znám jednu osobu, která skutečně měla webovou stránku a do svého zdrojového kódu vložila komentář HTML, například „Protože stále zapomínáte na Richarda: Uživatelské jméno: sýr Heslo: Burger123“ poblíž přihlašovacího pole s cílem sledovat každou IP adresu, která se pokusila použít uživatelské jméno/heslo. Přidání monitorovací logiky, jako je tato, je při vývoji webových stránek hodně zábavné.

Samozřejmě funguje také protokolování neplatných pokusů o přihlášení a přidání vhodné logiky pro řešení těchto IP adres. Vím, že někteří by se mnou nesouhlasili, ale v závislosti na typu webových stránek si nemyslím, že by bylo příliš velké na to, aby to uživatel informoval, pokud přidáte další bezpečnostní opatření, která zabrání různým druhům útoků.

24
ROFLwTIME

Moje oblíbená zabezpečená implementace je prováděna bankou, kterou používám. Pokud zadám své uživatelské jméno správně, řekne: „Vítejte Jimbob!“ a poté mě vyzve, abych odpověděl na bezpečnostní otázky (pokud jsem se nikdy nepřihlásil z tohoto prohlížeče v tomto počítači), počkejte, až odpovím na bezpečnostní otázky správně, a poté se mi zobrazí bezpečnostní obrázek/titulek a zadejte heslo. Pokud zadám nesprávné uživatelské jméno, zobrazí se něco jako „Vítejte Bessie/Kareem/Randal!“ kde je zobrazené jméno velmi neobvyklé - i když vždy budete mít stejné jméno pro stejné uživatelské jméno (obvykle si nejsem jistý mezi jedním nebo dvěma uživatelskými jmény; a špatné mi vždycky říká Frenshelia). Předpokládám, že je implementován jako nějaký nekryptografický hash aplikovaný na jakékoli zadané uživatelské jméno, které jedinečně mapuje jedno uživatelské jméno na dlouhém seznamu poměrně neobvyklých jmen. To umožňuje oprávněným uživatelům vědět, zda zadali nesprávné uživatelské jméno (jako kdybyste měli neobvyklé jméno, jako je Bessie; je velmi nepravděpodobné, že nesprávné uživatelské jméno, které jste náhodně uhodli, mapuje zpět na vaše konkrétní neobvyklé jméno), aniž by to bylo zřejmé pro lidi, kteří se snaží najít náhodné účty, které uživatelské jméno neexistuje.

Mimochodem: Nejsem nijak zvlášť nadšený otázkami týkajícími se bezpečnosti/obrazu, které se zdají být na hranici bezpečnostního divadla. Sofistikovaný útočník, který provádí útok typu MITM (man-in-the-middle) (např. Po instalaci falešných certifikátů do vašeho webového prohlížeče a spoofing DNS/ARP k nasměrování yourbank.com na jejich IP adresu), může počkat, až se pokusíte přihlásit na web, poté se ve svém počítači přihlaste do skriptu s automatickým skriptem na skutečné stránky, získejte bezpečnostní otázky, zobrazte vybrané bezpečnostní otázky zpět, posílejte zpět odpovědi na stránky samy z jejich prohlížeče, počkejte, až získáte zabezpečení obrázek, posílejte zpět bezpečnostní obraz a poté počkejte, až heslo zadáte od jeho konce. Poté se pomocí hesla přihlásí jako vy a děláte škodlivé věci. Přidělení otázek + obrázek ztěžuje proces, než mít celý čas na světě, shromažďovat všechny bezpečnostní obrazy pro různé napadené uživatelská jména tím, že je mění na útok, který musí být proveden v reálném čase a případně ponechává podezřelý podpis .

18
dr jimbob

Další odpovědi poskytují dobrý přehled o bezpečnostních důvodech tohoto chování. Přestože jsou správné, jsem si jistý, že alespoň některé webové stránky mají naprogramovanou autorizační rutinu tak, že je nemožné zjistit, co se stalo - přihlášení nebo heslo.

Ukázkový dotaz:

SELECT COUNT(*) FROM users WHERE login = 'john' AND hash = '2bbfcdf3f09ae8d700402f36913515cd'

To vrátí 1 při úspěšném pokusu o protokolování a , pokud neexistuje žádný uživatel s tímto jménem nebo má tento uživatel jiné heslo. Neexistuje způsob, jak zjistit, která část podmínky selhala. Takže pokud jde o zobrazování chybových zpráv, programátor vám upřímně řekne, že něco není v pořádku a není si jistý, co přesně to je.

Osobně jsem viděl podobné dotazy na několika webech založených na PHP, takže jsem si docela jistý, že část důvodu pochází ze způsobu, jakým je proces autentizace kódován.

13
Dyppl

Existuje však další zajímavá technika, kterou lze použít k provedení user enumeration attack (a více). Říká se tomu Timing attack. Útočník jednoduše měří dobu odezvy na požadavek na ověření a jak se liší mezi platným a neplatným přihlašovacím údajem.

  1. Vzdálené časování útoků na noseosekundu je zapnuto PHP Aplikace: Čas je brát vážně?
    [.____. http://blog.astrumfutura.com/2010/10/nanosecond-scale-remote-timing-attacks-on-php-applications-time-to-take-them-seriously/

  2. Poučení z útoků načasování
    http://codahale.com/a-lesson-in-timing-attacks/

  3. Srovnání konstantních časových řetězců v PHP), aby se zabránilo časovým útokům
    https://codereview.stackexchange.com/questions/13512/constant-time-string-comparision-in-php-to-prevent-timing-attacks

Chci říci, že taková zpráva nestačí, pokud chcete svou aplikaci zabezpečit před tímto druhem hrozby.

8

Důvodem zabezpečení je jinak, že je mnohem snazší najít platná uživatelská jména.

5
Lucas Kauffman

Kromě všech již poskytnutých skvělých odpovědí existuje obecný bezpečnostní princip, podle kterého byste neměli neoprávněným uživatelům poskytovat nevyžádané informace. Tj. pokud máte na výběr odpověď „vaše ověřovací data nejsou platná“ nebo vysvětlete, která část není platná - měli byste si vždy vybrat první. Některé velmi ošklivé kryptografické útoky jsou založeny na nejmenším množství chybových informací poskytovaných implementací, které se snaží být „užitečné“ - viz Padding Oracle attack . Je proto vhodné vždy zvolit nejmenší možný kousek informací zveřejněných neoprávněné osobě - ​​tj. Pokud jeho kombinace se jménem a heslem není dobrá, vždy odpovíte „uživatelské jméno/heslo není dobré“ a už nikdy nic nezveřejňujete. data. I když v konkrétním případě (jako je gmail, kde je uživatelské jméno veřejné) to není důležité, je dobré použít výchozí nastavení.

5
StasM

Řekněme, že zadáte náhodné uživatelské jméno a stejně náhodné heslo (stačí si poznamenat, jaké heslo zadáte). Nyní mohou být hesla mezi n uživateli běžná. Takže, pokud web říká, že heslo je správné ... pak víte, co následuje dále ... chaos mezi skutečnými uživateli, protože získání přihlašovacích jmen je poměrně snadné.

4
aayush anand

Poskytnutí nejednoznačné odpovědi je užitečné, aby se zabránilo útoku výčet uživatelů .

V některých případech útočník nemusí kompromitovat uživatelský účet. Informace, které má uživatel k dispozici, jsou dostatečné bez jakékoli jiné akce. Například pro obchod je to cenná informace, kterou má jeho zákazník v konkurenčním internetovém obchodě.

4
Jakub Šturc

Oceňuji různé výše uvedené odpovědi, protože říkají nejvíce, ale někdy si aplikace také neuvědomují, co je špatné uživatelské jméno nebo heslo. V případě autentizace založené na tokenu speciálně pro implementaci SSO (Single Sign On), např. IBM Tivoli Access Manager Vaše aplikace buď obdrží úspěšný token, nebo obdrží chybu zpět.

4
Niks

je-li přihlašovací e-mailová adresa, je snadné zjistit, že je osoba zaregistrována na webových stránkách - možná bych nechtěl, aby >> Někdy lidé používají e-mailový účet skutečné heslo pro weby, které zaregistrují, když používají e-mailové ID jako přihlašovací ID :)

3