Použití hesel není bezpečné, řešení Google Apps I
Hesla se používají jako základní prvek autentizace (ověření identity) uživatele při přihlášení do různých systémů (operační systém, programy, webové aplikace atd.).
Před šesti lety jsem přednášel na Security fóru na téma bezpečnost hesel x RSA tokeny. Myslel jsem, že budu povídat o věcech všeobecně známých. A tak mě z přednášky trochu mrazilo. A proč podobné téma otevírám dnes? Ono se toho popravdě moc až nezměnilo. Nezměnil se především přístup uživatelů. Technické možnosti, jak uvedenou problematiku řešit, jsou však již naštěstí běžnější a dostupnější.
Hlavním spouštěčem k napsání článku však byla krádež mých osobních věcí (došlo sice ke ztrátě zařízení ale ne ke zneužití dat). Proto článek a možnosti, jak řešit problematiku hesel v prostředí Google Apps. Pokud tuto službu nepoužíváte, nezoufejte, doufám že zde popsané principy budou dostatečně obecné a dostatečně názorné, že je v podobném principu použijete i jinde.
Autentizace pomocí hesel není bezpečná, opravdu?
Pokud s uvedeným výrokem nesouhlasíte, napište mi o tom prosím. Proč si za uvedeným tvrzením stojím? Uvedu své důvody, možná si doplníte i některé další.
- Uživatelé mají snahu volit taková hesla, které si snadno zapamatují. Hesla pak mohou odkazovat nebo mít přímou vazbu k uživateli (jméno psa, manželky, milenky, auta atd.). Heslo pak může být útočníkem jednoduše odhaleno.
- Obdobně jako v předešlém případě, uživatelé volí jednoduchá hesla. Ty mohou být velice snadno a rychle odhaleny “slovníkovým” útokem, nebo útokem “hrubou” silou.
- Uživatelská hesla mohou být odposlechnuta (např. formou phishing útoku, odhalena při zadávání hesla, pomocí škodlivého kód atd.). Všimli jste si, kolik uživatelů svá hesla zcela nepokrytě zadává během cesty ve veřejných dopravních prostředcích? Odhalení takto zadávaného hesla je mnohdy velice jednoduché.
- Neomezeně dlouhá životnost hesla. Uživatel nemá mnohdy možnost kontroly, z kterých zařízeních došlo k přihlášení.
- Naopak častým vynucením změny hesla nebo požadavkem na složité, komplexní heslo může dojít k tomu, že uživatel ze strachu zapomenutí hesla si heslo zapíše. Známé jsou případy, kdy si uživatel heslo napíše na Post It štítek a hrdě nalepí na monitor:)
- Když už si uživatel heslo vymyslel, tak ho často používá i pro přihlášení na další a další služby.
Pro vaší představu, víte jaké heslo se dostalo do žebříčku nejhorších používaných hesel v roce 2014? 123456, ale na seznamu najdeme i další “vynikající” kandidáty, namátkou: password, qwerty, batman (zřejmě faktem, že vyšel animovaný film Batmanův syn:).
Příklad Phishing útoku
Předpokládejme, že máme útočníka Freddyho a oběť Tomáše. Jednoho dne dostane Tomáš podvržený e-mail od Freddyho s textem, že jeho služba (doplňte si zde např. banka, online služba, portál atd.) se stala obětí útoku a je pro to striktně doporučeno (forma nátlaku) si změnit heslo. Součástí e-mailu je i pro jednoduchost i odkaz, kde se změna dá uskutečnit. Odkaz vede na podvrženou (falešnou) webovou stránku, která bývá shodná s originální stránkou.
Důvěřivý Tomáš vyplní své přihlašovací údaje (jméno, heslo). V tomto okamžiku Freddy získal Tomášovy přihlašovací údaje a je jen na něm jak s nimi naloží. Falešná webová stránka pak může Tomáše přesměrovat (případně i rovnou přihlásit) na originální webovou stránku (útočník Freddy nechce vzbudit podezření). Technické řešení je pak trošku odlišné (použití automatizovaných systémů), ale principiálně si tento útok dokážete představit.
Jaké jsou možnosti řešení?
Odpověď by mohla logicky znít, nepoužívejte hesla. Co vy na to? Jak ale zajistit autentizaci uživatele? Řešení je celkem jednoduché. Autentizaci (ověření identity při přihlášení) rozšíříme o další faktor (proto se budeme bavit o 2FA – two faktor authentication neboli česky o dvoufaktorové autentizaci). Ale o tom až příště:) Následně si pak povíme, jaké možnosti nám nabízí řešení Google Apps.
