Nyilvános VPN-jelszó: miért nem lehet az az e-mail-jelszavunk

A nyilvános VPN-könyvtárak profiljai olyan szervert, felhasználónevet és jelszót sorolnak fel, amellyel több ezer más ember is rendelkezik, és a kísértés az, hogy valami emlékezeteset írjunk be. Pontosan ez az ösztön a probléma: az érték nem személyes titok, és bármi, amire újra felhasználjuk, szintén nyilvánossá válik. Kezeljük a közzétett bejelentkezést egy nyilvános szolgáltatás megosztott kulcsaként, és minden minket azonosító fiókot teljesen más kategóriaként. Az elkülönítést könnyű fenntartani addig a napig, amikor számít.

Mik is valójában a hitelesítő adatok

A nyilvános VPN-könyvtárban közzétett bejelentkezés hozzáférési megállapodás az üzemeltető és bárki között, aki elolvassa az oldalt. Azonosíthat megosztott szolgáltatásfiókot személy helyett, és az üzemeltető megfigyelheti a kapcsolatot az átjárónál.

Az utolsó pont külön hangsúlyt érdemel: aki lezár egy alagutat, látja a be- és kilépő forgalmat, és birtokolja a jelszót, amely megnyitotta. Egy érték újrafelhasználása egy levélfiókhoz olyasmit árul el az üzemeltetőnek egy fiókról, amit soha nem lett volna szabad kitalálnia. A megosztott jelszó semmilyen értelmes értelemben nem titok, mert sok ember birtokolja. A kategóriák különböznek: nyilvános hozzáférési titok, privát fiókjelszó, ügyféltanúsítvány és társ kulcs, mindegyik más kérdésre válaszol.

Az újrafelhasználás ismert érték, nem gyenge

A jelszóerősségre vonatkozó útmutatások általában a hosszra és az egyediségre összpontosítanak, és az egyediséget pontosan az újrafelhasználás rombolja le. Egy két helyen használt hosszú jelszó mindkettőben ismert érték, amint az egyik kiszivárog.

A credential stuffing ezen az átfedésen alapul, és a nyilvános könyvtárak a pár első felét bárki számára ingyenessé teszik. Szolgáltatásonként külön értéket generálva ez az előny eltűnik anélkül, hogy bármi emlékezetesebbre lenne szükség. A hossz soha nem kompenzál egy nyilvános oldalon már kinyomtatott értéket.

Ha a jelszót már újrahasználták

Módosítsuk a nem kapcsolódó fiókot annak ellenőrzött helyreállítási folyamatán keresztül, majd vizsgáljuk át az aktív munkameneteit és helyreállítási beállításait, mert egy régi munkamenetet életben hagyó visszaállítás nem végezte el a munkát. Ne küldjük el a jelszót a VPN-támogatásnak a hiba bemutatására. Ahol többtényezős hitelesítés érhető el, kapcsoljuk be, mert túléli a kiszivárgott jelszót.

Forgassuk a VPN-hitelesítő adatokat azon a folyamaton keresztül, amelyet az üzemeltető dokumentál, és jegyezzük meg, hogy ez külön művelet saját fiókunk módosításától. Tartsuk a két változtatást ugyanabban a jegyben, hogy senki ne feltételezze, hogy az egyik lefedte a másikat.

Ha jelszó helyett privát ügyfélkulcs került nyilvánosságra, a visszavonás a gyógymód. Az e-mail-jelszó módosítása nem távolít el egy másolt kulcsot.

Ellenőrizzük a hitelesítő adat típusát a forgatás előtt

Határozzuk meg, mit vár valójában a mező, mielőtt bármit generálnánk. Egy portál szobakód, egy társ kulcs és egy jelszó nem felcserélhető, és a rossz forgatása helyben hagyja a felfedést.

python3 -c 'import secrets; print(secrets.token_urlsafe(24))'
gpg --gen-random --armor 2 32
pass generate work/mail 24

Tároljuk a generált értékeket jelszókezelőben, ne jegyzetben, hogy a különálló bejegyzések használhatók maradjanak. Ezután erősítsük meg, hogy az új érték működik, mielőtt eldobjuk a régit, és tartsuk mindkét eseményt ugyanabban a jegyben.

Fejezzük be a mentett hitelesítő adatok tisztításával minden olyan megosztott telepítésen, amely a régi bejelentkezést használta. A szerverről eltávolított hitelesítő adat továbbra is szivárgás, ha egy eszköz gyorsítótárazott példánnyal újra csatlakozik.