Nemrég volt időm újra átgondolni, hogyan kell működnie egy biztonságos jelszó-visszaállítási funkciónak, először amikor ezt a funkciót beépítettem , majd amikor segített egy másik embernek valami hasonlót csinálni. A második esetben linket akartam adni neki egy kanonikus forráshoz, amely tartalmazza a visszaállítási funkció biztonságos megvalósításának minden részletét. A probléma azonban az, hogy ilyen forrás nem létezik, legalábbis nem olyan, amely mindent leírna, ami számomra fontosnak tűnik. Ezért úgy döntöttem, hogy magam írom meg.
Látod, az elfelejtett jelszavak világa valójában meglehetősen titokzatos. Sok különböző, teljesen elfogadható nézőpont létezik, és sok egészen veszélyes is. Valószínűleg sokszor találkozott mindegyikkel végfelhasználóként; ezért megpróbálom ezeket a példákat felhasználni annak bemutatására, hogy ki csinálja jól, ki nem, és mire kell összpontosítania, hogy a funkció megfelelő legyen az alkalmazásban.
Jelszótárolás: kivonatolás, titkosítás és (gap!) sima szöveg
Nem beszélhetünk arról, hogy mit tegyünk az elfelejtett jelszavakkal, mielőtt megbeszélnénk, hogyan tároljuk őket. A jelszavak az adatbázisban három fő típus egyikében tárolódnak:
- Egyszerű szöveg. Van egy jelszó oszlop, amely egyszerű szöveges formában kerül tárolásra.
- Titkosított. Jellemzően szimmetrikus titkosítást használnak (egy kulcsot használnak a titkosításhoz és a visszafejtéshez is), és a titkosított jelszavakat is ugyanabban az oszlopban tárolják.
- Hashed. Egyirányú folyamat (a jelszó kivonatozható, de nem törölhető); Jelszó, szeretném remélni, amelyet egy só követ, és mindegyik a saját oszlopában található.
Térjünk rá a legegyszerűbb kérdésre: Soha ne tároljon jelszavakat egyszerű szövegben! Soha. Egyetlen sebezhetőség , egy gondatlan biztonsági mentés, vagy egy tucatnyi más egyszerű hiba közül – és ennyi, gameover, az összes jelszavad – vagyis elnézést, minden ügyfele jelszava közkinccsé válik. Természetesen ez óriási valószínűséggel járna más rendszerekben lévő összes fiókjukból. És ez a te hibád lesz.
A titkosítás jobb, de vannak gyengeségei. A titkosítás problémája a visszafejtés; Fogjuk ezeket az őrülten kinéző rejtjeleket, és visszakonvertáljuk őket egyszerű szöveggé, és amikor ez megtörténik, visszatérünk az ember által olvasható jelszóhelyzethez. Hogyan történik ez? Egy kis hiba van a kódban, amely dekódolja a jelszót, és így nyilvánosan elérhetővé válik - ez az egyik módja. A hackerek hozzáférnek ahhoz a géphez, amelyen titkosított adatokat tárolnak – ez a második módszer. Egy másik módszer ismét az, hogy ellopják az adatbázis biztonsági másolatát, és valaki megkapja a titkosítási kulcsot is, amelyet gyakran nagyon nem biztonságosan tárolnak.
Ez pedig elvezet minket a hash-hez. A hashelés mögött az az elképzelés áll, hogy egyirányú; A felhasználó által beírt jelszó és a kivonatolt verzió összehasonlításának egyetlen módja a bevitel kivonatolása és összehasonlítása. Az olyan eszközök támadásainak megelőzése érdekében, mint a szivárványtáblák, a folyamatot véletlenszerűen sózzuk (olvasd el a kriptográfiai tárolásról). Végső soron, ha helyesen implementáljuk, biztosak lehetünk benne, hogy a kivonatolt jelszavak soha többé nem lesznek egyszerű szövegek (a különböző kivonatoló algoritmusok előnyeiről egy másik bejegyzésben fogok beszélni).
Egy gyors érv a kivonatolásról a titkosítással kapcsolatban: az egyetlen ok, amiért valaha is titkosítania kell a jelszó kivonatolása helyett, az az, ha a jelszót egyszerű szövegben kell látnia, és ezt soha nem szabad akarnod, legalábbis egy szokásos webhelyhelyzetben. Ha erre van szüksége, akkor valószínűleg valamit rosszul csinál!
Figyelem!
A bejegyzés szövege alatt az AlotPorn pornográf weboldal képernyőképének egy része látható. Szépen ki van vágva, így nincs semmi, amit ne látnál a parton, de ha még mindig gondot okoz, akkor ne görgess lejjebb.
Mindig állítsa vissza jelszavát soha ne emlékeztesd rá
Felkérték valaha, hogy hozzon létre egy függvényt? emlékeztetőket Jelszó? Tegyen egy lépést hátra, és gondolja át ezt a kérést fordítva: miért van szükség erre az „emlékeztetőre”? Mert a felhasználó elfelejtette a jelszavát. Mit akarunk valójában csinálni? Segíts neki újra bejelentkezni.
Tudom, hogy az „emlékeztető” szót (gyakran) köznyelvi értelemben használjuk, de valójában az a biztonságosan segíti a felhasználót, hogy újra online legyen. Mivel biztonságra van szükségünk, két oka van annak, hogy az emlékeztető (azaz a jelszó elküldése a felhasználónak) nem megfelelő:
- Az e-mail egy nem biztonságos csatorna. Ahogyan HTTP-n keresztül nem küldenénk érzékeny üzenetet (HTTPS-t használnánk), úgy e-mailben sem kellene érzékeny üzenetet küldenünk, mert a szállítási rétege nem biztonságos. Valójában ez sokkal rosszabb, mint egyszerűen egy nem biztonságos átviteli protokollon keresztül küldeni az információkat, mivel a leveleket gyakran egy tárolóeszközön tárolják, a rendszergazdák hozzáférhetnek, továbbítják és szétosztják, hozzáférhetők a rosszindulatú programok számára stb. A titkosítatlan e-mail rendkívül nem biztonságos csatorna.
- Amúgy nem szabad hozzáférnie a jelszóhoz. Olvassa el újra az előző, tárolásról szóló részt - legyen a jelszó hash-je (jó erős sóval), ami azt jelenti, hogy semmilyen módon nem lehet kimásolni a jelszót és elküldeni postai úton.
Hadd demonstráljam a problémát egy példával : Íme egy tipikus bejelentkezési oldal:
Nyilvánvalóan az első probléma az, hogy a bejelentkezési oldal nem töltődik be HTTPS-en keresztül, hanem az oldal jelszó küldését is kéri („Send Password”). Ez lehet egy példa a fent említett kifejezés köznyelvi használatára, ezért lépjünk tovább, és nézzük meg, mi történik:
Sajnos nem néz ki sokkal jobban; és egy e-mail megerősíti, hogy probléma van:
Ez elmondja nekünk az usoutdoor.com két fontos vonatkozását:
- Az oldal nem hash jelszavakat. Legjobb esetben is titkosítva vannak, de valószínű, hogy egyszerű szövegként tárolják őket; Nem látunk bizonyítékot az ellenkezőjére.
- Az oldal hosszú távú jelszót küld (újra és újra visszamehet és használhatjuk) egy nem biztonságos csatornán.
Ha ez nincs útban, ellenőriznünk kell, hogy a visszaállítási folyamat biztonságos módon történik-e. Ennek első lépéseként meg kell győződni arról, hogy a kérelmező jogosult-e a visszaállítás végrehajtására. Más szóval, ezt megelőzően személyazonosság-ellenőrzésre van szükségünk; vessünk egy pillantást arra, hogy mi történik, ha egy személyazonosságot ellenőriznek anélkül, hogy először ellenőriznénk, hogy a kérelmező valóban a fiók tulajdonosa.
A felhasználónevek listázása és hatása az anonimitásra
Ezt a problémát a legjobban vizuálisan illusztrálni. Probléma:
Látod? Ügyeljen a „Nincs felhasználó regisztrálva ezzel az e-mail címmel” üzenetre. A probléma nyilvánvalóan akkor merül fel, ha egy ilyen webhely megerősíti elérhetőség ilyen e-mail címmel regisztrált felhasználó. Bingo – most fedezted fel a férjed/főnököd/szomszéd pornófétisét!
Természetesen a pornó meglehetősen ikonikus példája a magánélet fontosságának, de az identitás egy adott webhelyhez való társításának veszélyei sokkal szélesebbek, mint a fent leírt, esetlegesen kínos helyzet. Az egyik veszély a társadalmi tervezés; Ha a támadó össze tud találni egy személyt a szolgáltatással, akkor olyan információkkal rendelkezik, amelyeket elkezdhet használni. Például kapcsolatba léphet egy személlyel, aki egy webhely képviselőjének adja ki magát, és további információkat kérhet, hogy megkísérelje elkövetni. .
Az ilyen gyakorlatok felvetik a „felhasználónevek felsorolásának” veszélyét is, amely során egyszerűen csoportos lekérdezések lebonyolításával és az azokra adott válaszok megvizsgálásával ellenőrizhető a felhasználónevek vagy e-mail címek teljes gyűjteménye egy webhelyen. Van egy listája az összes alkalmazott e-mail címeiről, és van néhány perce egy forgatókönyv megírására? Aztán meglátod mi a probléma!
Mi az alternatíva? Valójában nagyon egyszerű, és csodálatosan van megvalósítva :
Itt az Entropay semmit sem árul el arról, hogy a rendszerében létezik-e e-mail cím valakinek, akinek nem ez a címe... Ha te saját ez a cím és nem létezik a rendszerben, akkor egy ehhez hasonló e-mailt fog kapni:
Persze lehetnek elfogadható helyzetek, amikor valaki hiszihogy regisztrált a weboldalon. de ez nem így van, vagy másik email címről csináltam. A fenti példa mindkét helyzetet jól kezeli. Nyilvánvaló, hogy ha a cím megegyezik, e-mailt fog kapni, amely megkönnyíti a jelszó visszaállítását.
Az Entropay által választott megoldás finomsága abban rejlik, hogy az azonosítás ellenőrzése ennek megfelelően történik email bármilyen online ellenőrzés előtt. Egyes webhelyek választ kérnek a felhasználóktól egy biztonsági kérdésre (erről lentebb olvashat bővebben) a hogyan kezdődhet a visszaállítás; Ezzel azonban az a probléma, hogy meg kell válaszolnia a kérdést, miközben valamilyen azonosítási formát (e-mail vagy felhasználónév) ad meg, ami szinte lehetetlenné teszi az intuitív válaszadást anélkül, hogy felfedné a névtelen felhasználó fiókjának létezését.
Ezzel a megközelítéssel van kicsi csökkent a használhatóság, mert ha nem létező fiókot próbálsz visszaállítani, akkor nincs azonnali visszajelzés. Természetesen ez az e-mail küldésének lényege, de valódi végfelhasználói szemszögből nézve, ha rossz címet adnak meg, először csak az e-mail kézhezvételekor tudják meg. Ez némi feszültséget okozhat a részéről, de ez csekély ár egy ilyen ritka folyamatért.
Egy másik megjegyzés, kissé eltér a témától: a bejelentkezést segítő funkciókkal, amelyek feltárják, hogy a felhasználónév vagy az e-mail cím helyes-e, ugyanez a probléma. Mindig válaszoljon a felhasználónak egy „Ön felhasználónév és jelszó kombináció érvénytelen” üzenettel, ahelyett, hogy kifejezetten megerősítené a hitelesítő adatok meglétét (például „a felhasználónév helyes, de a jelszó helytelen”).
Jelszó visszaállítása és visszaállítási URL küldése
A következő koncepció, amelyet meg kell vitatni, az a jelszó visszaállítása. Két népszerű megoldás létezik:
- Új jelszó generálása a szerveren és elküldése e-mailben
- A visszaállítási folyamat megkönnyítése érdekében küldjön egy e-mailt egyedi URL-lel
Ellenére , az első pontot soha nem szabad használni. Ezzel az a probléma, hogy ez azt jelenti, hogy van tárolt jelszó, amelyhez bármikor visszatérhet és újra felhasználhatja; nem biztonságos csatornán küldték, és a beérkező levelek között marad. Valószínű, hogy a beérkező levelek szinkronizálva vannak a mobileszközök és az e-mail kliens között, valamint nagyon hosszú ideig online tárolhatók a webes e-mail szolgáltatásban. A lényeg az a postafiók nem tekinthető a hosszú távú tárolás megbízható eszközének.
De ezen kívül az első pontnak van még egy komoly problémája – ez amennyire csak lehetséges leegyszerűsíti fiók blokkolása rosszindulatú szándékkal. Ha ismerem valakinek az e-mail címét, akinek fiókja van egy webhelyen, akkor bármikor letilthatom a jelszavának visszaállításával; Ez egy szolgáltatásmegtagadási támadás, amelyet ezüsttálcán szolgálnak fel! Éppen ezért a visszaállítást csak a kérelmező jogosultságának sikeres ellenőrzése után szabad végrehajtani.
Amikor egy visszaállított URL-ről beszélünk, akkor egy olyan webhely címét értjük alatta egyedi az alaphelyzetbe állítási folyamat ezen esetére. Természetesen véletlenszerűnek kell lennie, nem lehet könnyen kitalálható, és nem tartalmazhat semmilyen külső hivatkozást a fiókhoz, amely megkönnyíti a visszaállítást. Például a visszaállítási URL nem lehet egyszerűen egy elérési út, mint például: „Reset/?felhasználónév=JohnSmith”.
Egyedi tokent akarunk létrehozni, amely visszaállítási URL-ként küldhető el, majd összevethető a felhasználó fiókjának szerverrekordjával, így megerősítve, hogy a fiók tulajdonosa valójában ugyanaz a személy, aki megpróbálja visszaállítani a jelszót . Például egy token lehet "3ce7854015cd38c862cb9e14a1ae552b", és egy táblázatban tárolható a visszaállítást végrehajtó felhasználó azonosítójával és a token létrehozásának idejével együtt (erről lentebb olvashat bővebben). Az e-mail elküldésekor egy URL-t tartalmaz, például „Reset/?id=3ce7854015cd38c862cb9e14a1ae552b”, és amikor a felhasználó letölti, az oldal megkérdezi a token meglétét, majd megerősíti a felhasználó adatait, és lehetővé teszi a Jelszó.
Természetesen, mivel a fenti folyamat (remélhetőleg) lehetővé teszi a felhasználó számára, hogy új jelszót hozzon létre, gondoskodnunk kell arról, hogy az URL HTTPS-en keresztül legyen betöltve. Nem, , ennek a token URL-nek szállítási rétegbeli biztonságot kell használnia, hogy az új jelszóűrlapot ne lehessen megtámadni és a felhasználó által létrehozott jelszót biztonságos kapcsolaton keresztül továbbították.
A visszaállítási URL-hez is hozzá kell adni egy token időkorlátot, hogy a visszaállítási folyamat egy bizonyos időközön belül, mondjuk egy órán belül, befejeződhessen. Ez biztosítja, hogy az alaphelyzetbe állítási időablak minimálisra csökkenjen, így a visszaállítási URL címzettje csak ezen a nagyon kis időtartamon belül tud cselekedni. Természetesen a támadó újraindíthatja a visszaállítási folyamatot, de egy másik egyedi visszaállítási URL-t kell szereznie.
Végül biztosítanunk kell, hogy ez az eljárás eldobható legyen. A visszaállítási folyamat befejezése után a tokent el kell távolítani, hogy a visszaállítási URL többé ne működjön. Az előző pont annak biztosítása érdekében szükséges, hogy a támadónak legyen egy nagyon kicsi ablaka, amely alatt manipulálhatja a visszaállított URL-t. Ráadásul természetesen, ha a visszaállítás sikeres, a tokenre már nincs szükség.
Ezen lépések egy része túlságosan feleslegesnek tűnhet, de nem zavarja a használhatóságot és tulajdonképpen javítani a biztonságot, bár olyan helyzetekben, amelyek reményeink szerint ritkák lesznek. Az esetek 99%-ában a felhasználó nagyon rövid időn belül engedélyezi a visszaállítást, és a közeljövőben nem állítja vissza újra a jelszót.
A CAPTCHA szerepe
Ó, CAPTCHA, a biztonsági funkció, amelyet mindannyian szeretünk utálni! Valójában a CAPTCHA nem annyira védelmi eszköz, mint inkább azonosítási eszköz – legyen szó akár személyről, akár robotról (vagy automatizált szkriptről). Célja az automatikus űrlapbeküldés elkerülése, ami természetesen képes a biztonság feltörésének kísérleteként használható. A jelszavak visszaállításával összefüggésben a CAPTCHA azt jelenti, hogy az alaphelyzetbe állítás funkciót nem lehet brutálisan rákényszeríteni sem a felhasználó kéretlen levelére, sem a fiókok meglétének meghatározására (ami természetesen nem lesz lehetséges, ha követi a személyazonosságok ellenőrzése).
Természetesen maga a CAPTCHA nem tökéletes; Számos precedens van a szoftver „hackelésére” és a megfelelő sikerarány (60-70%) elérésére. Ezen kívül van egy megoldás, amely a következő bejegyzésemben látható , ahol egy cent töredékét fizetheti az embereknek minden egyes CAPTCHA megoldásáért, és 94%-os sikerarányt érhet el. Azaz sérülékeny, de (kissé) megemeli a belépési gátat.
Nézzük a PayPal példáját:
Ebben az esetben a visszaállítási folyamat egyszerűen nem indulhat el, amíg a CAPTCHA meg nem oldódik, tehát elméletileg lehetetlen automatizálni a folyamatot. Elméletben.
A legtöbb webalkalmazás esetében azonban ez túlzás és teljesen igaza van a használhatóság csökkenését jelenti – az emberek egyszerűen nem szeretik a CAPTCHA-t! Ezenkívül a CAPTCHA-hoz könnyen visszatérhet, ha szükséges. Ha a szolgáltatást kezdik támadni (itt jön jól a naplózás, de erről később), akkor a CAPTCHA hozzáadása nem is lehetne egyszerűbb.
Titkos kérdések és válaszok
Az általunk megfontolt összes módszerrel vissza tudtuk állítani a jelszót az e-mail fiókhoz való hozzáféréssel. Azt mondom, hogy „csak”, de természetesen illegális hozzáférni valaki más e-mail fiókjához. kell összetett folyamat legyen. azonban .
Valójában a fenti link Sarah Palin Yahoo! két célt szolgál; egyrészt azt szemlélteti, hogy milyen egyszerű (egyes) e-mail fiókokat feltörni, másrészt pedig azt, hogy milyen rossz biztonsági kérdéseket lehet rosszindulatú szándékkal felhasználni. De erre később még visszatérünk.
A XNUMX%-ban e-mail alapú jelszó-visszaállítással az a probléma, hogy a visszaállítani kívánt webhely fiókjának integritása XNUMX%-ban az e-mail fiók integritásától függ. Bárki, aki hozzáfér az e-mailjeihez minden olyan fiókhoz hozzáférhet, amely egyszerűen e-mail fogadásával visszaállítható. Az ilyen fiókok esetében az e-mail az online élet „minden ajtó kulcsa”.
A kockázat csökkentésének egyik módja a biztonsági kérdés-válasz minta alkalmazása. Kétségtelen, hogy már láttad őket: válassz olyan kérdést, amelyre csak te tudsz válaszolni must tudja a választ, majd amikor visszaállítja a jelszavát, a rendszer kérni fogja. Ez növeli a bizalmat abban, hogy a visszaállítást megkísérlő személy valóban a fiók tulajdonosa.
Visszatérve Sarah Palinhoz: a hiba az volt, hogy a biztonsági kérdéseire/kérdéseire könnyen meg lehetett találni a választ. Különösen akkor, ha Ön olyan jelentős közéleti személyiség, az anyja leánykori nevére, iskolai végzettségére vagy arra vonatkozó információk nem annyira titkosak. Valójában a legtöbbet szinte bárki megtalálhatja. Ez történt Sarah-val:
David Kernell hacker úgy férhetett hozzá Palin fiókjához, hogy részleteket talált a hátteréről, például az egyeteméről és a születési dátumáról, majd a Yahoo! elfelejtett jelszó-helyreállítási funkcióját használta.
Először is ez egy tervezési hiba a Yahoo! – ilyen egyszerű kérdések megfogalmazásával a cég lényegében szabotálta a biztonsági kérdés értékét, ezáltal rendszerének védelmét. Természetesen az e-mail fiók jelszavának visszaállítása mindig nehezebb, mivel a tulajdonosnak nem tud e-mailt küldeni (második cím nélkül), de szerencsére ma már nemigen lehet ilyen rendszert létrehozni.
Térjünk vissza a biztonsági kérdésekhez – lehetőség van arra, hogy a felhasználó saját kérdéseket készítsen. A probléma az, hogy ez borzasztóan nyilvánvaló kérdéseket fog eredményezni:
Milyen színű az ég?
Olyan kérdések, amelyek kényelmetlenséget okoznak az embereknek, ha biztonsági kérdést használnak az azonosításra emberek (például egy call centerben):
Kivel feküdtem le karácsonykor?
Vagy őszintén hülye kérdések:
Hogyan írják a "jelszót"?
Ha biztonsági kérdésekről van szó, a felhasználókat meg kell menteni önmaguktól! Más szóval, a biztonsági kérdést magának az oldalnak kell meghatároznia, vagy ami még jobb, ha felteszi sorozat biztonsági kérdések, amelyek közül a felhasználó választhat. És nem könnyű választani egy; ideális esetben a felhasználónak két vagy több biztonsági kérdést kell kiválasztania számla regisztrációkor, amely ezután második azonosító csatornaként lesz használva. A több kérdés növeli az ellenőrzési folyamatba vetett bizalmat, és lehetőséget ad a véletlenszerűség hozzáadására (nem mindig ugyanazt a kérdést mutatja), plusz egy kis redundanciát is biztosít arra az esetre, ha a tényleges felhasználó elfelejtette a jelszavát.
Mi a jó biztonsági kérdés? Ezt több tényező befolyásolja:
- Kellene lennie rövid – a kérdésnek világosnak és egyértelműnek kell lennie.
- A válasznak az kell lennie különleges - nincs szükségünk olyan kérdésre, amelyre egy ember másképp válaszolhat
- Lehetséges válaszok kellenek különböző - ha megkérdezzük valakinek a kedvenc színét, akkor a lehetséges válaszok egy nagyon kis halmaza adódik
- Keresés a válasznak összetettnek kell lennie – ha a válasz könnyen megtalálható bármilyen (emlékezz a magas beosztású emberekre), akkor ő rossz
- A válasznak az kell lennie állandó időben - ha megkérdezi valaki kedvenc filmjét, akkor egy évvel később a válasz más lehet
Amint ez megtörténik, van egy weboldal, amely jó kérdéseket tesz fel . A kérdések egy része egészen jónak tűnik, mások nem felelnek meg a fent leírt tesztek egy részénél, különösen a „keresés egyszerűsége” teszten.
Hadd mutassam be, hogyan valósítja meg a PayPal a biztonsági kérdéseket, és különösen azt, hogy a webhely milyen erőfeszítéseket tesz a hitelesítés érdekében. Fent láttuk az oldalt a folyamat elindításához (CAPTCHA-val), és itt megmutatjuk, mi történik az e-mail cím megadása és a CAPTCHA megoldása után:
Ennek eredményeként a felhasználó a következő levelet kapja:
Eddig minden teljesen normális, de itt van, ami a visszaállítási URL mögött rejtőzik:
Tehát a biztonsági kérdések kerülnek szóba. Valójában a PayPal azt is lehetővé teszi, hogy hitelkártyaszáma ellenőrzésével visszaállítsa jelszavát, így van egy további csatorna, amelyhez sok webhely nem fér hozzá. Egyszerűen nem tudom megváltoztatni a jelszavamat válasz nélkül mindkét biztonsági kérdés (vagy a kártyaszám nem ismerete). Még ha valaki eltérítené is az e-mailjeimet, nem tudná visszaállítani a PayPal-fiókom jelszavát, hacsak nem tud rólam egy kicsit több személyes információt. Milyen információkat? Íme a PayPal által kínált biztonsági kérdések:
Lehet, hogy az iskola és a kórház kérdése kissé nehézkes a keresés egyszerűsége szempontjából, de a többi nem túl rossz. A biztonság fokozása érdekében azonban a PayPal további azonosítást igényel változások válaszok a biztonsági kérdésekre:
A PayPal egy elég utópisztikus példa a biztonságos jelszó-visszaállításra: CAPTCHA-t valósít meg, hogy csökkentse a brute force támadások veszélyét, két biztonsági kérdésre van szükség, majd egy másik, teljesen más azonosítást igényel, csak a válaszok megváltoztatásához – és ezt a felhasználó után. már bejelentkezett. Természetesen nálunk pontosan ez a helyzet várt a PayPal-ról; egy pénzintézet, amely nagy pénzösszegekkel foglalkozik. Ez nem jelenti azt, hogy minden jelszó-visszaállításnál követnie kell ezeket a lépéseket – ez legtöbbször túlzás –, de jó példa azokra az esetekre, amikor a biztonság komoly ügy.
A biztonsági kérdésrendszer kényelme, hogy ha nem telepítette azonnal, akkor később is hozzáadhatja, ha az erőforrás-védelem szintje ezt megkívánja. Jó példa erre az Apple, amely csak nemrég vezette be ezt a mechanizmust [a cikk 2012-ben íródott]. Miután elkezdtem frissíteni az alkalmazást az iPademen, a következő kérést láttam:
Aztán láttam egy képernyőt, ahol kiválaszthattam több pár biztonsági kérdést és választ, valamint egy mentési e-mail címet:
Ami a PayPal-t illeti, a kérdések előre kiválasztottak, és néhányuk valójában nagyon jó:
A három kérdés/válasz pár mindegyike a lehetséges kérdések különböző halmazát képviseli, így rengeteg módja van a fiók konfigurálásának.
Egy másik szempont, amelyet figyelembe kell venni a biztonsági kérdés megválaszolásakor, a tárolás. Ha egy egyszerű szöveges adatbázis van az adatbázisban, az majdnem ugyanazokat a fenyegetéseket fenyegeti, mint egy jelszó, nevezetesen, hogy az adatbázis feltárása azonnal feltárja az értéket, és nem csak az alkalmazást kockáztatja, hanem potenciálisan teljesen más alkalmazásokat is, amelyek ugyanazokat a biztonsági kérdéseket használják (ismét ). Az egyik lehetőség a biztonságos kivonatolás (erős algoritmus és kriptográfiailag véletlenszerű só), de a legtöbb jelszótárolási esettől eltérően jó oka lehet annak, hogy a válasz egyszerű szövegként jelenik meg. Egy tipikus forgatókönyv a személyazonosság-ellenőrzés egy élő telefonszolgáltató által. Természetesen ebben az esetben is alkalmazható a hash (az operátor egyszerűen beírhatja a kliens által megnevezett választ), de a legrosszabb esetben a titkos válasznak a kriptográfiai tároló valamilyen szintjén kell elhelyezkednie, még akkor is, ha szimmetrikus titkosításról van szó. . Összesít: kezeld a titkokat titkokként!
A biztonsági kérdések és válaszok egyik utolsó aspektusa az, hogy sebezhetőbbek a társadalmi manipulációval szemben. Az egy dolog, hogy megpróbáljuk közvetlenül kinyerni a jelszót valaki más fiókjából, de a létrehozásáról szóló beszélgetést (egy népszerű biztonsági kérdés) teljesen más. Valójában nagyon jól kommunikálhat valakivel az életének számos olyan területéről, amely titkos kérdést vethet fel anélkül, hogy gyanút kelt. Persze a biztonsági kérdésnek éppen az a lényege, hogy valakinek az élettapasztalatára vonatkozik, tehát emlékezetes, és itt van a probléma – az emberek szeretnek beszélni az élettapasztalataikról! Ez ellen keveset tehetsz, csak akkor, ha olyan biztonsági kérdés-lehetőségeket választasz, hogy azok legyenek kevesebb valószínűleg szociális tervezéssel húzható ki.
[Folytatjuk.]A Reklám Jogairól
VDSina megbízhatót kínál , minden szerver egy 500 megabites Internet csatornához csatlakozik és ingyenesen védett a DDoS támadásokkal szemben!
Forrás: will.com