Kétfaktoros hitelesítés
Mindent, amit olvastatok a kérdéses azonosításról, az a tény alapján, hogy az igénylő tudja, ismeri az e-mail címét, tudja, hogyan férhet hozzá (azaz tudja az e-mail jelszavát) és tudja a titkos kérdésekre adott válaszokat.
A « tudás » egy hitelesítési tényezőnek számít; a másik két elterjedt tényező pedig az az, amivel rendelkezik, például egy fizikai eszköz, és az, aki ő, például az ujjlenyomat vagy a szem retina.
A legtöbb esetben a biometrikus azonosítás végrehajtása nehezen megvalósítható, különösen, ha webalkalmazások biztonságáról beszélünk, ezért a kétfaktoros hitelesítés (two factor authentication, 2FA) általában második attribútumot használ – « az, amivel rendelkezik ». Az egyik népszerű lehetősége ennek a második tényezőnek egy fizikai token, például :
A fizikai tokent gyakran használják hitelesítésre a vállalati VPN-ekben és pénzügyi szolgáltatásokban. A hitelesítéshez a szolgáltatásban szükség van a jelszóra és a tokenen található kódra (amely gyakran változik) együtt a PIN-nel. Elméletben a támadónak tudnia kell a jelszót, rendelkeznie kell a tokennel, és tudnia kell a token PIN-jét. A jelszó visszaállítási forgatókönyv esetén a jelszó nyilvánvalóan ismeretlen, azonban a token birtoklását fel lehet használni a fiók tulajdonjogának megerősítésére. Természetesen, mint bármely védelmi megoldás esetében, , de egyértelműen növeli a belépési akadályokat.
E megközelítés egyik fő problémája a költség és a megvalósítás logisztikai nehézsége; arról beszélünk, hogy minden ügyfélnek át kell adni a fizikai eszközöket, és meg kell tanítani őket az új folyamatra. Továbbá, a felhasználóknak mindig maguknál kell tartaniuk az eszközt, ami esetenként a fizikai tokenekkel nem mindig lehetséges. Egy másik lehetőség az, hogy a második hitelesítési tényezőt SMS-en keresztül valósítjuk meg, amely a 2FA esetén megerősítést nyújthat arról, hogy az, aki a visszaállítási folyamatot végzi, az fiók tulajdonosának mobiltelefonját használja. Így csinálja ezt a Google:
Szintén szükséges aktiválni , de ez azt jelenti, hogy a következő jelszó-visszaállításkor a mobiltelefonja második hitelesítési tényezővé válhat. Engedje meg, hogy bemutassam ezt az iPhone-om példáján, az okok, amelyek hamarosan érthetővé válnak:
Miután azonosította a Google-fiók e-mail címét, a rendszer észleli, hogy a 2FA be van kapcsolva, és visszaállíthatjuk a fiókot egy SMS-en keresztüli ellenőrzés segítségével, amelyet a fiók tulajdonosának mobiltelefonjára küldenek:
Most válassza ki a visszaállítási folyamat kezdetét:
Ez a lépés egy e-mailt küld a regisztrált címre:
Ez az e-mail tartalmazza a visszaállítási URL-t:
A visszaállítási URL-re való belépéskor SMS-t küldenek, és a weboldal kéri annak megadását:
Íme az SMS:
Miután ezt beírta a böngészőbe, visszatérünk a klasszikus jelszó-visszaállítás területére:
Valószínűleg kissé terjengősnek tűnik, és valóban az, de a forma megerősíti, hogy a visszaállítást végző személy hozzáfér a fiók tulajdonosának e-mail címéhez és mobiltelefonjához. Ez azonban kilencszer biztonságosabb lehet, mint a jelszó csupán e-mailes visszaállítása. Azonban vannak problémák…
A probléma a okostelefonokkal kapcsolatos. Az alább bemutatott eszköz csak egy hitelesítési tényezőt tud érvényesíteni — képes SMS-t fogadni, de e-maileket nem:
Ez az eszköz azonban képes SMS-t fogadni és jelszó-visszaállító e-maileket fogadni:
A probléma az, hogy az elektronikus levelezést első hitelesítési tényezőként, míg az SMS-t (vagy egy token-generáló alkalmazást) második hitelesítési tényezőként kezeljük, de ma már mindez egy eszközben van összegyűjtve. Természetesen ez azt jelenti, hogy ha valaki hozzáfér a okostelefonjához, akkor az összes kényelmet egy csatornára redukáljuk; ez a második tényező, „ami nálad van”, azt jelenti, hogy az első tényező is nálad van. És mindez egy négy számjegyű PIN kóddal van védve... ha a telefon egyáltalán rendelkezik PIN kóddal és lekorlátozva.
Igen, a Google 2FA funkciója bizonyosan további védelmet biztosít, de ez nem véd „a bolond ellen”, és biztosan nem független két teljesen autonóm csatornától.
Felhasználónév szerinti visszaállítás e-mail cím szerinti visszaállítással szemben
Meg kell engedni a jelszó visszaállítását csak e-mail címmel? Vagy a felhasználónak lehetősége legyen a felhasználónevével is visszaállítani? A felhasználónévvel való visszaállítás problémája abban rejlik, hogy nincs mód arra, hogy értesítsük a felhasználót, ha a felhasználónév hibás, anélkül, hogy felfednénk hogy valaki másnak lehet regisztrált fiókja ezzel a névvel. Az előző részben az e-mailes visszaállítás biztosította, hogy a jogos tulajdonos mindig visszajelzést kapjon anélkül, hogy nyilvánosan felfednék a rendszerben való létezését. Csak felhasználónév használatával ez lehetetlen.
Ezért a válasz rövid: csak e-mail. Ha megpróbálja a jelszót csak felhasználónév segítségével visszaállítani, akkor olyan esetek merülhetnek fel, amikor a felhasználó azt se tudja, mi történt, vagy felfedi a fiókok létezését. Igen, ez csak egy felhasználónév, nem e-mail cím, és igen, bárki bármilyen (elérhető) felhasználónevet választhat, de még mindig nagy a valószínűsége, hogy közvetve felfedi a fiókok tulajdonosait, mivel a felhasználók hajlamosak az ismétlődő névszerkezetek használatára.
Tehát mi történik, ha valaki elfelejti a felhasználónevét? Feltételezve, hogy a felhasználónév nem e-mail cím, akkor a folyamat hasonló ahhoz, ahogy a jelszó visszaállítása elkezdődik - beírjuk az e-mail címet, majd üzenetet küldünk erre az címre, anélkül, hogy felfednénk a létezését. Az egyetlen különbség az, hogy ezúttal az üzenet csak a felhasználónevet tartalmazza, nem pedig a jelszó visszaállításának URL-jét. Vagy az, vagy az e-mailben azt írják, hogy nincs fiók erre az címre.
Identitás ellenőrzés és e-mail címek pontossága
A jelszó visszaállításának kulcsfontosságú aspektusa, és valószínűleg a legfontosabb szempont az azonosítatlan személy ellenőrzése, aki megpróbálja a visszaállítást végrehajtani. Valóban ő a jogos fióktulajdonos, vagy valaki megpróbálja feltörni vagy kényelmetlenséget okozni a tulajdonos számára?
Nyilvánvaló, hogy az email a legkényelmesebb és legelterjedtebb csatorna a személyazonosság ellenőrzésére. Nincs védelem a gondatlan bánásmódtól („butaságtól”), és számos eset van, amikor a fiók tulajdonosának címére érkező levelek egyszerű lehetősége nem elegendő, ha magas fokú biztonságot igényel a hitelesítés, ezért használják a kétfaktoros azonosítást (2FA); ennek ellenére szinte mindig ez a folyamat kiindulópontja a visszaállításnak.
Ha az email szerepet játszik a bizalom biztosításában, akkor először is meg kell győződni arról, hogy az email cím valójában helyes. Ha valaki elgépel egy karaktert, akkor nyilvánvaló, hogy a visszaállítás nem fog megkezdődni. Az email cím ellenőrzési folyamata a regisztráció során megbízható módja a cím helyességének ellenőrzésére. Mindannyian láttuk ezt a gyakorlatban: regisztrálsz, kapsz egy emailt egy egyedi URL-lel, amire kattintani kell, ami megerősíti, hogy tényleg te vagy az az email fiók tulajdonosa. A rendszerbe való belépés lehetetlenné tétele, amíg ez a folyamat be nem fejeződik, biztosítja a motivációt a cím megerősítésére.
Mint sok más biztonsági aspektus esetében, ez a modell csökkenti a használhatóságot a felhasználó személyazonossága iránti magasabb fokú biztonság biztosítása érdekében. Ez elfogadható lehet egy olyan weboldalon, ahol a felhasználók értékelik a regisztrációt, és szívesen adnak hozzá még egy lépést a folyamat során (fizetős szolgáltatások, banki tevékenységek stb.), de az ilyen dolgok elriaszthatják a felhasználót, ha az ő fiókját „egyszer használatosnak” ítéli meg, és például csak a hozzászólás céljára használja.
Aki megkezdte a visszaállítási folyamatot, az azonosítása
Nyilvánvaló, hogy léteznek okok a visszaállítási funkció rosszindulatú felhasználására, és a támadók számos különböző módon használhatják ezt. Egy egyszerű trükk, amelyet felhasználhatunk a kérés forrásának megerősítésére (ez a trükk általában működik) — ez a kérés IP-címének csatolása a visszaállítási ajánlót tartalmazó emailhez. Ez az információval látja el a címzettet a kérés forrásának azonosításához. Ez egy példa a visszaállítási funkcióra, amelyet most integrálok az ASafaWeb-be:
Вот пример из функции сброса, которую я сейчас встраиваю в ASafaWeb:
A "find out more" link takes the user to the website , amely információkat szolgáltat, például a kérés helyét és a kérő szervezetét:
Természetesen bárki, aki el akarja rejteni a személyazonosságát, számos módszerrel elhomályosíthatja a valódi IP-címét, azonban ez egy kényelmes módja a kérő részleges azonosításának, és a legtöbb ez az esetek megfelelően elegendő betekintést ad arról, hogy ki indítja a jelszó visszaállítási kérelmet.
E-mail értesítés a változásokról
Ez a bejegyzés egyetlen témát jár körül – a kommunikációt; értesítsd a fiók tulajdonosát a folyamat minden lépéséről, anélkül, hogy bármi olyat felfednél, amit rosszindulattal fel lehetne használni. Ugyanez vonatkozik arra az esetre is, amikor a jelszó valóban megváltozik – értesítsd a tulajdonost!
A jelszó megváltoztatásának két forrása lehet:
- A jelszó megváltoztatása, miután a felhasználó bejelentkezett, mert új jelszót szeretne
- A jelszó visszaállítása bejelentkezés nélkül, mert a felhasználó elfelejtette azt
Bár ez a bejegyzés főleg a jelszó visszaállításáról szól, az első esetben az értesítés csökkenti annak a kockázatát, hogy valaki anélkül változtassa meg a jelszót, hogy a törvényes tulajdonos tudna róla. Hogyan történhet ez? Egy gyakori forgatókönyv, hogy a törvényes tulajdonos jelszavát (újra használt jelszó, más forrásból kiszivárgott jelszó, keylogging miatt megszerzett jelszó, könnyen kitalálható jelszó stb.) megszerzik, majd a támadó úgy dönt, hogy megváltoztatja, ezzel blokkolva a tulajdonost. E-mail értesítés nélkül a valós tulajdonos nem tud róla, hogy a jelszó megváltozott.
Természetesen, ha jelszó visszaállítás történik, a tulajdonosnak már magának kellett kezdeményeznie a folyamatot (vagy ki kellene kerülnie a fenti azonosító ellenőrző eszközöket), ezért a megváltoztatás nem kell meglepetésként szolgálnia, azonban az e-mail megerősítés pozitív visszajelzés és további ellenőrzés lenne. Ezen kívül biztosítja az összehangoltságot a fent leírt forgatókönyvvel.
Ó, és arra az esetre, ha ez még nem nyilvánvaló – ne küldj új jelszót e-mailben! Valakit ez megnevettethet, de :
Naplók, naplók, naplók és még több napló
A jelszó-visszaállító funkció vonzó a támadók számára: a támadó vagy egy másik személy fiókjához akar hozzáférni, vagy csak kellemetlenséget akar okozni a fiók/szolgáltatás tulajdonosának. A fenti gyakorlatok közül sok csökkenti a visszaélések valószínűségét, de nem akadályozza meg azokat, és biztosan nem fogja megakadályozni az embereket abban, hogy megpróbálják a funkciót nem kívánt módon használni.
A rosszindulatú viselkedés észleléséhez rendkívül értékes gyakorlat a naplózás, és itt arra gondolok, nagyon részletes naplózásra. Rögzítse a sikertelen bejelentkezési kísérleteket, a jelszó-visszaállítást, a jelszó módosítását (azaz amikor a felhasználó már be van jelentkezve), és gyakorlatilag mindent, ami segíthet megérteni, mi történik; ez a jövőben nagyon hasznos lesz. Rögzítse a naplókban még a különálló részeket a folyamatban, például egy jól tervezett jelszó-visszaállító funkciónak tartalmaznia kell a visszaállítás kezdeményezését a weboldalon (jegyezze fel a helytelen felhasználónévvel vagy e-mail címmel történő visszaállítási kísérleteket), rögzítse a visszaállítási URL meglátogatását (beleértve a hibás tokenek használatára tett kísérleteket), és jegyezze fel a titkos kérdésre adott válasz sikerét vagy hibáját.
Amikor a naplózásról beszélek, nemcsak az oldal betöltésének tényét értem, hanem minél több információ összegyűjtését is, ha az nem bizalmas. Fiúk, kérlek, ne rögzítsetek jelszavakat a naplókban! A naplókban regisztrálni kell a hitelesített felhasználó személyazonosságát (ő hitelesítve lesz, ha megváltoztatja a meglévő jelszót, vagy megpróbálja visszaállítani egy másik jelszavát miután belépett a rendszerbe), minden próbált felhasználónevet vagy e-mail címet, és bármilyen visszaállítási tokent, amit használni próbál. De érdemes rögzíteni a naplókban olyan szempontokat is, mint az IP-címek, és ha lehetséges, még a kérés fejlécét is. Ez lehetővé teszi, hogy újraalkossa, mit próbál tenni a felhasználó (vagy a támadó), és mit milyen fellépéseket tett. ki Ő ilyen.
Felelősségdelegálás más végrehajtóknak.
Ha azt gondolja, hogy ez hatalmas munka, akkor nincs egyedül. Valójában megbízható rendszer kiépítése a fiókok kezelésére nem egy egyszerű feladat. Nem arról van szó, hogy technikailag nehéz, hanem sok sajátossága van. Nemcsak a jelszó visszaállításáról van szó, hanem egy egész folyamatot magában foglal, a regisztrációtól a jelszavak biztonságos tárolásáig, a több hibás bejelentkezési kísérlet kezeléséig, és így tovább. Bár , emellett még sok más dolgot is el kell végezni.
Manapság számos harmadik féltől származó szolgáltató létezik, akik örömmel vállalják az összes nehézséget, és mindezt egy irányított szolgáltatásba absztrahálják. Az ilyen szolgáltatások között megtalálható az OpenID, az OAuth és még a Facebook is. Néhány ember (az OpenID valóban nagyon sikeres volt a Stack Overflow-nál), azonban mások .
Kétségtelen, hogy egy OpenID-hoz hasonló szolgáltatás számos problémát megold a fejlesztők számára, de kétségtelenül újakat is hozzáad. Van jelentőségük? Igen, de nyilvánvaló, hogy nem tapasztalunk tömeges használatot az authentikációs szolgáltatók szolgáltatásaiból. A bankok, légitársaságok és még az üzletek is saját authentikációs mechanizmusokat valósítanak meg, és nyilvánvaló, hogy ennek nagyon jó oka van.
Rosszhiszemű jelszó-visszaállítás
A fent említett példák közül az egyik fontos szempont, hogy a régi jelszó csak akkor tekinthető használhatatlannak, ha a fiók tulajdonosának személyazonosságát megerősítették. Ez fontos, mert ha a fiók visszaállítása tól azonosítási ellenőrzés nélkül lehetséges lenne, akkor ez mindenféle rosszindulatú cselekedetre adna lehetőséget.
Íme egy példa: valaki részt vesz a licitálásban egy aukciós oldalon, és a licitálási folyamat vége felé blokkolja a versenytársakat azzal, hogy elindítja a visszaállítási folyamatot, így eltávolítva őket a licitből. Nyilvánvaló, hogy ha a rosszul megtervezett visszaállítási funkciót nem megfelelően tudják kihasználni, az súlyos negatív következményekhez vezethet. Érdemes megemlíteni, hogy a fiókok blokkolása hibás bejelentkezési kísérletekkel hasonló helyzet, de ez már egy másik bejegyzés témája.
Ahogyan korábban említettem, ha anonim felhasználóknak lehetőséget biztosítunk arra, hogy bármilyen fiókot visszaállítsanak, ha ismerik annak e-mail címét, az kész helyzetet teremt a szolgáltatásmegtagadási támadásokhoz. Ez lehet, hogy nem az a , amiről általában beszélünk, de nincs gyorsabb módja a fiókhoz való hozzáférés blokkolásának, mint egy rosszul megtervezett jelszóvisszaállító funkcióval.
Az Achilles-sarkunk
A védelem szempontjából a fiók szempontjából az eddigiek nagyszerűek, azonban mindig emlékeznie kell arra, hogy a védett fiókot körülvevő ökoszisztémáról is gondoskodnia kell. Hadd hozzak egy példát:
Az ASafaWeb egy csodálatos szolgáltatás által hosztolt, amelyet az AppHarbor biztosít. A hosztolt fiók visszaállításának folyamata a következőképpen zajlik:
1. lépés:
2. lépés:
3. lépés:
4. lépés:
Az összes előző információ elolvasása után már könnyen megérthetjük, hogy az ideális világban mely szempontokat valósítanánk meg egy kicsit másképp. Ugyanakkor itt szeretném hangsúlyozni, hogy ha létrehozok egy ASafaWeb-hez hasonló weboldalt az AppHarbor szolgáltatásában, majd kitalálok nagyszerű titkos kérdéseket és válaszokat, hozzáadok egy második hitelesítési tényezőt, és mindent jól csinálok, az nem törli el azt a tényt, hogy a folyamat leggyengébb láncszeme képes mindezt összetörni. Ha valaki sikeresen hitelesít az AppHarborban a személyes adataimmal, akkor képes lesz bármely ASafaWeb fiók jelszavát az általa kívántra cserélni!
Az a lényeg, hogy a védelem megvalósíthatóságát összefüggő rendszerként kell értékelni: modellezni kell a rendszer minden belépési pontjának fenyegetéseit, még ha ez egy felszínes folyamat is, mint például az AppHarborba való bejelentkezés. Ennek jó képet kell adnia arról, hogy mennyi energiát kell befektetnem az ASafaWeb jelszóvisszaállítási folyamatába.
Összegzés
Ez a bejegyzés rengeteg információt tartalmaz, ezért szeretném ezt egy egyszerű vizuális ábrába sűríteni:
Ne feledje, hogy a lehető legrészletesebb naplózást kell végezni minden egyes lépésnél. Ennyi az egész, ez egyszerű!
Összegzés
A bejegyzésem átfogónak tűnik, azonban számos további anyag áll rendelkezésre, amelyet én tudnék beletérni, de úgy döntöttem, hogy a rövidség kedvéért eltekintünk ettől: az e-mail cím visszaállításának szerepe, olyan helyzet, amikor elveszíti a hozzáférést a fiókhoz kapcsolt e-mailhez (például, ha kilépett a munkájából) és így tovább. Ahogy korábban mondtam, a visszaállítási funkció nem olyan bonyolult, csak sokféle nézőpont létezik róla.
Bár a visszaállítás nem olyan nehéz, gyakran rosszul valósítják meg. Fent láttunk néhány példát, amikor a megvalósítás képes problémákhoz vezetett, és sok más precedens van, amikor a hibás visszaállítás valóban problémákat okozott. Nemrégiben kiderült, hogy Ez egy komoly negatív következmény!
Ezért legyél óvatos a visszaállító funkcióiddal, különböző pontokon, és a funkció tervezésekor ne vegyél le a fekete kalapodat, mert nagy a valószínűsége, hogy más is fel fogja venni!
Hirdetés
VDSina kedvező áron kínál napi díjjal, minden szerver 500 Megabit internetkapcsolatra csatlakozik, és ingyenesen védett a DDoS-támadások ellen!
Forrás: habr.com
