З боку кліента гэта выглядае як выпадковае адключэнне праз гадзіну пасля працоўнай сесіі. Значок у трэі знікае, тунель будаецца нанова, а журнал паказвае памылку аўтэнтыфікацыі, а не сеткавую памылку. Насамрэч сесія перагледзела параметры, і другому рукапаціканню спатрэбіліся ўліковыя даныя, сапраўднай копіі якіх у кліента ўжо не было. Аднаразовы код, які спрацаваў пры ўваходзе, не можа спрацаваць зноў, таму перазапыт ключа правальваецца менавіта так, як задумана.

Выпраўленне — гэта рашэнне пра тое, што павінна прад'явіць другое рукапаціканне, а не даўжэйшы таймер паўтору.

Прасочвайце абмен з пункту гледжання кліента

Пры ўваходзе кліент дасылае імя карыстальніка, пароль і код з токен-прылады, і сервер прымае гэтую камбінацыю. Затым сесія працуе, пакуль не спрацуе трыгер перагляду, які пачынае новае рукапаціканне TLS унутры існуючага тунеля. Гэта рукапаціканне зноў патрабуе аўтэнтыфікацыі. Калі шлях аўтэнтыфікацыі на серверы чакае пароль плюс актуальны аднаразовы код, у кліента няма новага кода, калі толькі карыстальнік не прысутнічае, каб яго ўвесці.

Большасць кліентаў не адкрываюць запыт пасярэдзіне сесіі, таму рукапаціканне выходзіць па тайм-ауце і тунель падае. Карыстальнік бачыць перападключэнне, а не запыт аўтэнтыфікацыі, і менавіта таму першая справаздача звычайна вінаваціць сетку.

auth-gen-token змяняе таго, хто адказвае на другое пытанне

auth-gen-token — гэта опцыя, якая дазваляе серверу выдаваць токен пасля паспяховага ўваходу, а наступныя перагляды прад'яўляюць гэты токен замест паўтору паролю і кода. Кіраўніцтва апісвае яго тэрмін дзеяння і паводзіны пры абнаўленні, і да токена трэба ставіцца як да ўліковых даных з уласным тэрмінам дзеяння. У прадвызначаным шляху сервер сам правярае токен, а не выклікае знешні аўтэнтыфікатар паролю зноў.

Са знешняй інтэграцыяй аўтэнтыфікацыі гэты падзел змяняецца. Плагін павінен разумець стан токена і прымяняць уласныя праверкі, бо сервер ужо не адзіны кампанент, які вырашае, ці працягваецца сесія. Стаўленне да токена як да чарговага лікавага аднаразовага кода не з'яўляецца рэалізацыяй гэтай функцыі.

Вырашыце, што адбываецца са статусам уліковага запісу

Токен, які перажывае доступ да ўліковага запісу, — гэта дзірка ў палітыцы. Вырашыце, як адключаны ўліковы запіс, выдаленае членства ў групе або адкліканая прылада набываюць моц, пакуль токен яшчэ сапраўдны. Кароткія тэрміны дзеяння токенаў памяньшаюць акно; яўны шлях адклікання робіць гэта наўмысным. Запішыце адказ перад уключэннем опцыі, бо прадвызначаны шлях не звяртаецца да знешняга аўтэнтыфікатара пры кожным пераглядзе.

У разгортванні з некалькімі серверамі сакрэт подпісу токенаў павінен быць агульным, інакш кліента могуць адправіць на вузел, які не можа праверыць яго токен.

Тэстуйце заканчэнне тэрміну і перападключэнне, а не толькі ўваход

Паменшыце інтэрвал перагляду ў тэставым профілі, каб другое рукапаціканне адбылося, пакуль вы назіраеце, затым сачыце за абодвума журналамі. Пераканайцеся, што токен выдаецца пры ўваходзе, прад'яўляецца пры перазапыце ключа і абнаўляецца або выдаецца нанова згодна з наладжаным тэрмінам. Затым прымусова выклічце заканчэнне тэрміну токена і поўнае перападключэнне, бо кліент, які чыста перападключаецца, можа ўсё роўна пацярпець няўдачу на шляху перазапыту ключа.

Тэстуйце выдаленне ўліковага запісу апошнім. Гэты выпадак паказвае, ці ваша палітыка выконваецца, ці проста апісана.

Не выпраўляйце гэта адключэннем абнаўлення

Усталяванне інтэрвалу перагляду на нуль на абодвух баках прыбірае сімптом разам з ратацыяй ключоў. Гэта хавае праблему паўторнага выкарыстання ўліковых даных за зменай палітыкі, якую ніхто не разгледзеў. Пакіньце абнаўленне і выбірайце паміж токенам ад сервера і свежым інтэрактыўным запытам у залежнасці ад таго, ці прысутнічае карыстальнік.

Даўжэйшы таймер паўтору не робіць выкарыстаны код сапраўдным зноў. Ён толькі адтэрміноўвае адключэнне і робіць журнал цяжэйшым для чытання.

Падобныя артыкулы