Kezeljen egy titkos számlaszámot hitelesítő adatként: auditálja

A számlaszámként felcímkézett mező nem automatikusan nyilvános hivatkozás, és a címke nem a teszt. A teszt az, amit a birtoklás lehetővé tesz: ha a szám ismerete bejelentkeztet valakit, letölt egy kapcsolati profilt vagy engedélyez egy eszközt, akkor az a szám életciklussal rendelkező hitelesítő adat. Elvégzem az alábbi öt ellenőrzést valahányszor egy szolgáltatás numerikus identitást ad ki és ártalmatlannak nevezi. Mindegyik egy sort ad egy rövid feljegyzéshez, és a feljegyzés a szállítandó eredmény, nem ítélet a termékről.

Leltározza fel, mit is engedélyez a birtoklás

Írja fel külön azokat a műveleteket, amelyeket a szám megnyit. A portálba való bejelentkezés, a konfigurációs fájl letöltése, egy új eszköz engedélyezése és egy elfogadott alagút-bejelentkezés biztosítása különböző jogosultságok, és egy szolgáltatás megvalósíthat egyet a többi nélkül. Egy portál, amely a számot egyetlen mezőként fogadja el, semmit sem mond arról, hogyan hitelesíti az alagút a partnerét később, vagy hogyan származtatják a forgalmi kulcsokat.

Az általános modell könnyen megfogalmazható: a bearer hitelesítő adat olyan, amelyet a birtokos külön kriptográfiai kulcs birtoklásának bizonyítása nélkül használhat, és ez az a megkülönböztetés, amelyet RFC 6750 a tokeneknél húz. Ez összehasonlítás, nem állítás, hogy egy szám alapú szolgáltatás OAuth-t valósít meg. Ha a birtokosnak nincs szüksége másra, kezelje a számot bearer titokként, és ennek megfelelően osztályozza a design többi részét.

Védje titokként, ne hivatkozásként

A tárolás a besorolásból következik. A bejelentkeztető érték jelszókezelőbe való, nem képernyőképre, vágólap-előzménybe, csevegőüzenetbe vagy böngészőjegyzetbe. A képernyőképek a szokásos szivárgás: a szám rövid és ártalmatlannak tűnik, ezért olyan támogatási szálban végzi, amely túléli azt az eszközt, ahonnan jött.

Az adathalászat a másik hibaüzemmód, és nem érdekli, mennyire véletlenszerű a szám. A csaló, aki akarja az értéket, megkéri, hogy illessze be egy űrlapba, és az soha nem lejáró, második tényező nélküli hitelesítő adat megéri a fáradságot. A bejelentkezési útvonalat könyvjelzőből vagy ismert címről érje el, ne egy üzenet linkjéről, amely szintén kéri a számot.

A helyreállítási anyagot a titok részének tekintse. Ha az üzemeltető helyreállítási kódot, PIN-t vagy olyan e-mail-címet is kiadott, amellyel a fiók alaphelyzetbe állítható, ezek külön hitelesítő adatok, ugyanazzal a védelmi követelménnyel. Egy védtelen visszaállítási csatorna minden más ellenőrzést díszítéssé tesz.

A kitalálással szembeni ellenállást és a sebességkorlátot együtt ellenőrizze

A hossz csak a generálási módszer mellett bír jelentéssel. Egy kiszámítható sorozatból származó hosszú szám gyengébb, mint egy kriptográfiai generátorból származó rövid érték, és a lenyűgöző számjegyszám nem bizonyítja a kiszámíthatatlanságot. Kérdezze meg, hogyan generálják az értéket, mielőtt arról gondolkodna, milyen nehéz kitalálni.

A kitalálással szembeni ellenállás önmagában sem bír ki egy korlátlan próbálkozási rátát. Azok az ellenőrzések számítanak, amelyeket az üzemeltető megvalósít: sikertelen próbálkozások számlálói, zárolások, forrásonkénti korlátozás, és hogy a rossz szám megkülönböztethető-e a nem létezőtől. Ha a szolgáltatás támogatja, egy sikertelen próbálkozás megmutatja, milyen a hiba, és megjelenik-e újrapróbálkozás-számláló:

# one attempt, then read the response and any counter or delay
# do not script repeated guesses against a live account
curl -i -X POST https://portal.example.invalid/login -d "account=000000000000"

Jegyezze fel, mit árul el a válasz. Az ismeretlen fiókhoz tartozó külön hiba felsorolási orákulum akkor is, ha a szám kitalálhatatlan, és ez a megállapítás a feljegyzéshez tartozik, akár javítható kliensoldalról, akár nem.

Tervezze meg a rotációt és a visszavonást, mielőtt szükség lenne rájuk

Keresse meg a támogatott eljárást egy elveszett vagy felfedett számhoz, és írja le, amíg minden működik. Egyáltalán lecserélhető a fiók hitelesítő adata? A csere érvényteleníti a már regisztrált eszközöket, az aktív munkameneteket vagy a letöltött konfigurációt? Milyen helyreállítási anyagot igényel az eljárás? Az e-mail-függőség nélküli szolgáltatás több helyreállítási felelősséget ruházhat a felhasználóra, ami fontosabbá teszi az eljárást, nem kevésbé.

Válassza külön a fiók cseréjét a hitelesítő adat visszavonásától. Ha a szám kulcs, tanúsítvány vagy profil letöltését engedélyezi, a szám cseréje érvényben hagyhatja a letöltött anyagot, és a letöltött anyag visszavonása más tulajdonossal rendelkező más művelet lehet. Ne feltételezze, hogy egy megváltozott mező minden kapcsolatot megszüntet; ellenőrizze az üzemeltető tényleges modelljét, és jegyezze fel, hol igazolta.

Dokumentálja a döntést, és később ellenőrizze újra

Vezessen egyoldalas feljegyzést szolgáltatásonként: milyen jogosultságokat ad a szám, hol tárolják, ki állíthatja vissza, milyen használati bizonyítékok vannak, és mit tenne a közzétételt követő első órában. Ez a feljegyzés az, ami a terminológiáról szóló vitát valaki által auditálható döntéssé alakítja.

Az adatvédelmi állításoknak saját hatókör kell. Egy véletlenszerűen generált szám továbbra is lehet stabil azonosító, amely időben összekapcsolja a fiókeseményeket; a kiszámíthatatlanság nem összekapcsolhatatlanság, és egyik tulajdonság sem mond semmit a megőrzött hálózati metaadatokról. Teljes terveket hasonlítson össze, ne mezőket számoljon egy bejelentkezőképernyőn.

Mielőtt rögzíti:

• A szám által adott összes jogosultság fel van sorolva, beleértve a letöltéseket és az eszközengedélyezést.
• A tárolási és helyreállítási csatornák ugyanazon a szinten védettek, mint maga a szám.
• A generálási módszer és a sebességkorlátok ismertek, nem a hosszból feltételezettek.
• Létezik csereeljárás és visszavonási eljárás, és tudja, melyik melyiket szünteti meg.
• A feljegyzés megnevezi, ki állíthatja vissza az értéket, és milyen bizonyítékok maradnak használat után.