：TOTP多因素認證、風(fēng)控攔截與Redis會話一致性)
前陣子接手一個老 PHP 電商項目老板讓我把登錄安全做扎實。當時我對多因素認證、風(fēng)控攔截、會話一致性這三塊也只是有個大概認知網(wǎng)上現(xiàn)成的庫又不敢直接塞進生產(chǎn)環(huán)境干脆從零開始寫一套。正好手上有個 PHP 8.3 的空閑服務(wù)配合 Redis 直接把整條認證鏈路捋了一遍。這篇文章就用“庖丁解牛”的方式把登錄體系拆成三塊骨頭——多因素認證怎么做、風(fēng)控攔截怎么評分、會話一致性怎么保證——每一塊我都會給代碼、給思路、給踩坑記錄。內(nèi)容偏實操適合那些有 PHP 基礎(chǔ)、但還沒完整構(gòu)建過認證體系的開發(fā)者看完可以直接照著落地也能理解每個設(shè)計決策背后的原因。1. 項目解牛三個模塊為什么必須放一起做很多人會把“多因素認證”“風(fēng)控攔截”“會話一致性”當成三個獨立需求分開做這是非常容易踩坑的地方。用戶的登錄行為是一條完整鏈路三者的關(guān)系是前后串聯(lián)的請求先進入風(fēng)控引擎風(fēng)控決定你要不要做二次認證二次認證通過之后再建立會話。拆開做最終聯(lián)調(diào)時一定會出現(xiàn)接口對不齊、狀態(tài)不同步的問題。所以從設(shè)計第一天起就要把它們當成一個閉環(huán)看。1.1 先捋清楚需求的三條主線多因素認證解決的是“密碼泄露”問題。就算用戶的賬號密碼被釣魚、撞庫撞出來了沒有第二個因素攻擊者依然進不來。我這邊選了 TOTP基于時間的一次性密碼作為主認證方式因為在沒有服務(wù)商依賴的前提下它完全離線可用客戶不用等短信也不會被通道延遲坑。風(fēng)控攔截解決的是“碰撞與自動化攻擊”問題。密碼錯誤 100 次和密碼錯誤 1 次兩者風(fēng)險完全不一樣。風(fēng)控引擎就是在正式認證前給這次請求打分分數(shù)決定走什么處置策略。它的價值不僅在于防黑客還能防止正常用戶被暴力破解影響。會話一致性解決的是“登錄態(tài)在多機、多端下的漂移”問題。生產(chǎn)環(huán)境至少兩臺 Web 服務(wù)器如果 Session 存在本地文件里負載均衡一轉(zhuǎn)發(fā)用戶就被“強制下線”了。把 Session 搬到 Redis 之后不管請求打到哪臺機器都能讀到同一份登錄數(shù)據(jù)。1.2 技術(shù)選型與目錄結(jié)構(gòu)我全程用的是 PHP 8.3 Redis 7 nginx路由自己寫不依賴重型框架。核心邏輯全部用原生 PHP 實現(xiàn)二維碼生成用endroid/qr-code其他的能省則省。為什么要刻意去掉框架因為框架的封裝會把很多關(guān)鍵機制藏起來比如 Session 生命周期、Cookie 屬性、序列化方式這些恰恰是登錄體系最容易出問題的地方。用原生實現(xiàn)一遍你能清楚看到每一步發(fā)生了什么。項目目錄結(jié)構(gòu)大致長這樣auth-system/ ├─ public/ │ └─ index.php ├─ app/ │ ├─ Auth/ │ │ ├─ Totp.php │ │ ├─ OneTimeCode.php │ │ ├─ RiskEngine.php │ │ └─ SessionManager.php │ ├─ Support/ │ │ ├─ Base32.php │ │ └─ RedisClient.php │ └─ Config.php ├─ composer.json └─ .env每個類的職責很純粹Totp處理時間同步驗證碼OneTimeCode負責短信/郵件驗證碼和備份碼RiskEngine做信號采集和風(fēng)險評分SessionManager統(tǒng)一接管 Redis 里的會話讀寫。這種職責劃分也方便以后替換實現(xiàn)比如風(fēng)控規(guī)則想升級成機器學(xué)習(xí)打分只需要改RiskEngine內(nèi)部邏輯。1.3 一次登錄請求的完整生命周期把流程在腦子里過一遍后面所有代碼都是給這個流程服務(wù)的用戶提交賬號密碼服務(wù)端先校驗賬號是否存在、密碼哈希是否匹配。密碼校驗通過后立刻進入風(fēng)控引擎。風(fēng)控會采集當前設(shè)備的指紋、IP 地理位置、User-Agent、歷史失敗次數(shù)等信號。風(fēng)控引擎輸出風(fēng)險評分。0 到 35 分直接放行35 到 70 分要求二次認證70 分以上直接拒絕。如果需要二次認證就觸發(fā) TOTP 或短信驗證碼流程用戶提交一次性驗證碼。認證通過后調(diào)用session_regenerate_id(true)重建會話把用戶身份和登錄時間寫入 Redis并下發(fā) Cookie。用戶后續(xù)請求會帶著 Session IDRedis 里讀出來校驗是否過期、是否被強制下線然后做滑動續(xù)期。這個鏈路里風(fēng)控在認證之前認證在會話建立之前。順序不能反——如果先建會話再做風(fēng)控風(fēng)控一旦把用戶攔截會話狀態(tài)就會出現(xiàn)半登錄半匿名的尷尬局面。2. 多因素認證從 TOTP 到驗證碼的完整鏈路多因素認證這塊我推薦優(yōu)先做 TOTP。它不依賴短信通道用戶裝一個 Google Authenticator、Microsoft Authenticator 或者 1Password 就能用。TOTP 的完整落地包含四個部分核心算法、密鑰綁定、校驗邏輯、兜底方案。下面逐個拆。2.1 TOTP 的核心算法HMAC 與時間窗口TOTP 的本質(zhì)不是加密而是“用時間和密鑰計算一個動態(tài)短碼”。它的底層是 HOTPHMAC-Based One-Time Password區(qū)別只在于 HOTP 把計數(shù)器傳進去TOTP 把當前時間戳整除 30 得到的結(jié)果當作計數(shù)器。為什么是 30 秒這是 RFC 6238 推薦的默認時間步長太長用戶等得煩躁太短用戶輸入時間不夠。核心計算代碼我用 PHP 實現(xiàn)關(guān)鍵點都注釋了final class Totp { public const STEP 30; public function __construct( private readonly string $secret, // base32 解碼后的原始密鑰字節(jié) private readonly int $digits 6, private readonly int $window 1, ) {} public function codeAt(float $timestamp): string { // 當前時間步長 $counter intdiv((int) floor($timestamp), self::STEP); // 計數(shù)器必須是 8 字節(jié)大端序RFC 4226 里高位補零 $bin pack(N2, 0, $counter); // HMAC-SHA1輸出 20 字節(jié) $hash hash_hmac(sha1, $bin, $this-secret, true); // 動態(tài)截斷取 hash 最后一個字節(jié)的低 4 位作為偏移量 $offset ord($hash[19]) 0x0f; // 從偏移量開始取 4 字節(jié)最高位強制為 0避免符號位干擾 $value ((ord($hash[$offset]) 0x7f) 24) | ((ord($hash[$offset 1]) 0xff) 16) | ((ord($hash[$offset 2]) 0xff) 8) | (ord($hash[$offset 3]) 0xff); // 取模得到 6 位數(shù)字不夠前面補零 return str_pad((string) ($value % 10 ** $this-digits), $this-digits, 0, STR_PAD_LEFT); } }有兩點我想特別說明。第一pack(N2, 0, $counter)這種寫法專門兼容 32 位 PHP把高 32 位置零低 32 位存計數(shù)器不會因為$counter超出整型范圍而飄移。第二動態(tài)截斷是 HOTP 規(guī)范里的固定套路不是隨便取的 4 字節(jié)它保證了就算 HMAC 的某些位被翻轉(zhuǎn)取到的偏移也不會跑出哈希邊界。2.2 密鑰生成、Base32 與掃碼綁定TOTP 的種子密鑰必須是服務(wù)端為每個用戶獨立生成的不能用固定的字符串。我用random_bytes(20)生成 160 位隨機數(shù)這個強度已經(jīng)超過大多數(shù)需要。生成的字節(jié)沒法直接給用戶看Google Authenticator 的掃碼解析要求密鑰必須 Base32 編碼。Base32 編碼算法不復(fù)雜只是把任意字節(jié)流按 5 位一組重新映射到 A-Z 2-7 這 32 個字符上。我提供一個可直接復(fù)用的編碼函數(shù)function base32_encode(string $data): string { $alphabet ABCDEFGHIJKLMNOPQRSTUVWXYZ234567; $binary ; foreach (str_split($data) as $char) { $binary . sprintf(%08b, ord($char)); } $result ; foreach (str_split($binary, 5) as $chunk) { $result . $alphabet[bindec(str_pad($chunk, 5, 0))]; } return $result; }同樣的校驗的時候需要 Base32 解碼把用戶掃碼得到的字符串轉(zhuǎn)回原始密鑰字節(jié)我這里給出的解碼函數(shù)要跟編碼函數(shù)配對使用function base32_decode(string $data): string { $alphabet ABCDEFGHIJKLMNOPQRSTUVWXYZ234567; $map []; for ($i 0; $i 32; $i) { $map[$alphabet[$i]] $i; } $data strtoupper(rtrim($data, )); $binary ; foreach (str_split($data) as $char) { $binary . str_pad(decbin($map[$char] ?? 0), 5, 0, STR_PAD_LEFT); } $result ; foreach (str_split($binary, 8) as $byte) { if (strlen($byte) 8) { $result . chr(bindec($byte)); } } return $result; }綁定階段的核心是生成 otpauth URI。這個 URI 是一串標準的配置文本認證器 App 看到它就知道往哪個 App 生成二維碼$secretBytes random_bytes(20); $secret base32_encode($secretBytes); $issuer MyApp; $account userexample.com; $uri sprintf( otpauth://totp/%s:%s?secret%sissuer%sdigits%dperiod%d, rawurlencode($issuer), rawurlencode($account), $secret, rawurlencode($issuer), 6, 30, ); // 然后用 endroid/qr-code 把這個 $uri 生成二維碼渲染到前端配套composer require endroid/qr-code把$uri傳給二維碼庫輸出 base64 圖片。這里有一個非常容易忽略的步驟綁定只是把密鑰存進數(shù)據(jù)庫還不夠一定要讓用戶立刻提交一次當前驗證碼服務(wù)端驗證通過才算綁定完成。這個“綁定即驗證”的設(shè)計可以防止二維碼在傳遞過程中被劫持或者用戶掃錯碼綁定成別人的種子。2.3 校驗邏輯容錯、防重放與防時序攻擊校驗的核心代碼是verify它做的事情很簡單算出當前時間窗口的驗證碼和用戶提交的比對如果不一致就往前、往后各滑動一個窗口再比對。為什么要有滑動窗口因為用戶掃碼、打開認證器、手動輸入這幾個動作會消耗時間等提交到服務(wù)端時30 秒的時間窗口可能已經(jīng)翻篇了。public function verify(string $code, float $timestamp): bool { if (!preg_match(/^\d{ . $this-digits . }$/, $code)) { return false; } $current intdiv((int) floor($timestamp), self::STEP); for ($i -$this-window; $i $this-window; $i) { $candidate $this-codeAt(($current $i) * self::STEP); if (hash_equals($candidate, $code)) { return true; } } return false; }hash_equals不是可選項不能用替代。原因很簡單比較字符串時只要發(fā)現(xiàn)第一個不同字符就立刻返回 false攻擊者可以通過測量響應(yīng)時間反推驗證碼的字符hash_equals會固定比較完所有字節(jié)時序上不給攻擊者留縫隙。校驗通過之后還有一道防線防重放。同一個驗證碼在同一個時間窗口內(nèi)只能使用一次否則只是一個被動截獲的驗證碼也能反復(fù)登錄。實現(xiàn)方式是驗證成功后把當前時間窗口記為“已使用”寫入 Redis$replayKey mfa:totp:replay:{$userId}:{$current}; $ok $redis-set($replayKey, 1, [NX, EX self::STEP * ($this-window 1)]); if (!$ok) { throw new RuntimeException(該驗證碼已使用請刷新后重試); }set命令帶上NX參數(shù)表示只有 key 不存在時才寫入。第二次使用相同窗口的驗證碼set會返回 false說明被重放了。EX的過期時間設(shè)為窗口前后可接受的范圍避免 Redis key 堆積。2.4 短信郵件驗證碼與備份碼的兜底方案TOTP 雖然穩(wěn)但用戶一旦換手機就會遇到“新手機還沒綁定、舊手機不在身邊”的尷尬。所以必須提供兜底方案。第一種兜底是短信或郵件驗證碼。它的實現(xiàn)比 TOTP 簡單很多生成一個 6 位隨機數(shù)字存進 Redis 并設(shè)置 5 分鐘過期然后調(diào)用短信或郵件服務(wù)商接口發(fā)送。這里有兩個關(guān)鍵細節(jié)發(fā)送限流和一次性使用。$code (string) random_int(100000, 999999); // 60 秒內(nèi)同一賬號只能發(fā)一次 $limitKey mfa:sms:limit:{$userId}; if (!$redis-set($limitKey, 1, [NX, EX 60])) { throw new RuntimeException(發(fā)送太頻繁請稍后再試); } $redis-setex(mfa:sms:code:{$userId}, 300, password_hash($code, PASSWORD_BCRYPT)); // $smsProvider-send($user-phone, $code);為什么要對同一個賬號限制發(fā)送頻率因為短信通道要花錢攻擊者可以利用接口無限轟炸既浪費成本又可能把運營商的通道封掉。為什么要用password_hash存驗證碼而不是明文因為 Redis 里可能有過期數(shù)據(jù)被 dump 的風(fēng)險任何時候都不要把明文驗證碼留在存儲層。第二種兜底是備份碼。備份碼的生成邏輯是生成 10 到 20 個隨機碼展示給用戶一次數(shù)據(jù)庫里只存每個備份碼的哈希。為什么不能存明文備份碼的殺傷力和密碼等同數(shù)據(jù)庫一旦泄露明文備份碼就直接白給。驗證的時候把用戶輸入的備份碼哈希之后比對匹配成功就從庫里刪除這條記錄保證只能用一次。3. 風(fēng)控攔截采集信號、計算風(fēng)險、分級處置風(fēng)控引擎的定位是“認證之前的一道閘門”。它不關(guān)心用戶密碼對不對它只判斷這次請求本身是否可疑。我從三個層面來拆信號怎么采集、分數(shù)怎么算、觸發(fā)之后怎么處置。3.1 信號采集設(shè)備指紋、IP 情報與行為數(shù)據(jù)設(shè)備指紋是風(fēng)控最基礎(chǔ)的數(shù)據(jù)源。前端頁面加載時采集瀏覽器信息包括 User-Agent、語言、時區(qū)、屏幕分辨率、canvas 渲染結(jié)果、已安裝字體等然后用 SHA-256 把這些信息拼起來做一次哈希得到一個設(shè)備指紋。代碼示意如下// 前端采集后通過接口上報 $deviceSignals [ ua $_SERVER[HTTP_USER_AGENT] ?? , lang $_SERVER[HTTP_ACCEPT_LANGUAGE] ?? , screen 1920x1080, timezone -480, canvas hash-string-from-canvas, ]; $fingerprint hash(sha256, json_encode($deviceSignals));但要注意這個 fingerprint 是客戶端算出來傳給服務(wù)端的理論上可以被偽造。所以不能直接把這個哈希當成身份憑證。更嚴謹?shù)淖龇ㄊ欠?wù)端用 HMAC 密鑰對它簽發(fā)一個設(shè)備 ID后續(xù)請求都帶著這個簽名后的設(shè)備 ID 關(guān)聯(lián)用戶。IP 側(cè)的情報可以通過 GeoIP 庫拿到國家、城市、經(jīng)緯度。比如 GeoLite2 離線庫就可以。為什么不在這里拋具體服務(wù)商因為生產(chǎn)環(huán)境可能用云廠商的安全產(chǎn)品也可能內(nèi)網(wǎng)部署離線庫只要最終能給一個 0 到 100 的 IP 風(fēng)險分就行。行為數(shù)據(jù)是最容易獲得也最誠實的。密碼錯誤次數(shù)、驗證碼錯誤次數(shù)、同一 IP 的登錄頻率、請求路徑異常程度這些數(shù)據(jù)通過 Redis 計數(shù)指標就能拿到。它們的價值在于反映“趨勢”單個錯誤可能是手滑短時間內(nèi) 20 次錯誤就是自動化腳本在跑。3.2 風(fēng)險評分模型規(guī)則加權(quán)而不是玄學(xué)第一版風(fēng)控不需要上機器學(xué)習(xí)規(guī)則加權(quán)就夠了。原因有兩條一是新業(yè)務(wù)根本沒有歷史標注數(shù)據(jù)供模型訓(xùn)練二是規(guī)則引擎可解釋、可調(diào)試客戶投訴“為什么被攔截”時你能立刻給出原因。我這里擬定了一套評分規(guī)則信號評分區(qū)間說明IP 基礎(chǔ)風(fēng)險0-30GeoIP 識別為 IDC、代理則高分設(shè)備新度0-25該賬號歷史從未出現(xiàn)過此設(shè)備指紋失敗次數(shù)0-25最近 10 分鐘密碼失敗次數(shù)每次 5上限 25地理位置跳躍0-20上次登錄城市與本次距離超過 500 公里訪問軌跡異常0-15UA 異常、請求路徑不符合登錄流程黑名單100命中已知黑名單直接攔截需要聲明的是這個權(quán)重表是“基于常見實踐的配置范例”你可以按照業(yè)務(wù)特征調(diào)整但調(diào)的時候要關(guān)注每種規(guī)則誤傷多少正常用戶。核心代碼就非常直白final class RiskEngine { public function evaluate(array $signals): RiskResult { $score 0; $score $signals[ip]-score(); $score $signals[device_new] ? 25 : 0; $score min(25, $signals[fail_count] * 5); $score $this-geoJumpScore($signals[geo_before], $signals[geo_now]); if ($signals[ip]-isBlacklisted()) { return RiskResult::blocked(blacklist ip); } return RiskResult::scored($score); } }地理位置跳躍的計算用 Haversine 公式就可以。不要看經(jīng)緯度差大就拍大腿決定用戶很可能坐飛機出差這個信號要配合“IP 是否 IDC、本次登錄是否新設(shè)備”一起看。單獨一個維度超過 500 公里就加分是很粗的規(guī)則比較靠譜的寫法是距離大于閾值并且設(shè)備是新設(shè)備才給較高的權(quán)重。3.3 三種處置方式觀察、驗證、阻斷評分出來后處置策略分成三檔0 到 35 分直接放行但把這次請求打上低風(fēng)險標簽寫日志。35 到 70 分進入二次認證流程要求 TOTP 或短信驗證碼通過了再放行。70 分以上拒絕登錄提示環(huán)境異?；蚵?lián)系客服人工處理。第二檔里有一個值得注意的細節(jié)如果用戶本來就要做多因素認證那風(fēng)控評分高時不應(yīng)該“再讓他做一次認證”而是應(yīng)該在同一個認證流程里提升挑戰(zhàn)難度。比如低風(fēng)險時只要 TOTP中高風(fēng)險時強制 TOTP 加備份碼確認。這樣才能真正形成兩重防線而不是做兩遍無用功。同樣重要的是“后臺日志先行”。我給風(fēng)控引擎加了一個影子模式所有評分結(jié)果都記錄到日志表但初期不實際攔截。上線跑兩周之后把誤報和漏報的案例抽出來調(diào)權(quán)重再逐步開啟攔截。風(fēng)控系統(tǒng)翻車的重災(zāi)區(qū)不是技術(shù)不夠而是規(guī)則直接拍死了正常用戶還渾然不覺。3.4 用 Redis 做滑動窗口計數(shù)滑動窗口計數(shù)的核心是“統(tǒng)計最近 N 秒內(nèi)的事件數(shù)量”。我舉個密碼失敗次數(shù)的例子。初始密碼校驗失敗時執(zhí)行$failKey risk:fail:{$userId}:{$ip}; $count $redis-incr($failKey); // 注意只有第一次累加時才設(shè)置過期時間 if ($count 1) { $redis-expire($failKey, 600); }關(guān)鍵坑就在if ($count 1)這一句。如果我在每次累加之后都無腦執(zhí)行expire($failKey, 600)那么持續(xù) 10 分鐘內(nèi)每產(chǎn)生一次失敗key 的過期時間都會往后順延 10 分鐘這個“滑動窗口”就永遠滑不到頭了。只有當 key 是新建的時候設(shè)置過期才能保證 10 分鐘不動之后窗口自動清零。另一個常用場景是 IP 登錄頻率限流每分鐘最多 20 次登錄嘗試$loginKey risk:login:{$ip}; $count $redis-incr($loginKey); if ($count 1) { $redis-expire($loginKey, 60); } if ($count 20) { throw new RuntimeException(嘗試過于頻繁請稍后再試); }這種計數(shù)方式很簡單但也有并發(fā)問題兩個請求同時incr可能出現(xiàn)一個進程看到$count 1而另一個看到$count 2的競態(tài)。好在 Redis 的INCR是原子操作設(shè)置過期時以“第一個拿到 1 的進程”為準基本夠用。如果想更嚴謹可以用 Lua 腳本把“累加、設(shè)置過期、判斷閾值”打包成一個原子操作執(zhí)行。4. 會話一致性登錄態(tài)在多機環(huán)境不漂移會話一致性是這一套系統(tǒng)能不能在生產(chǎn)環(huán)境扛住的關(guān)鍵。你把認證和風(fēng)控都做好了結(jié)果用戶一刷新就掉線體驗同樣廢掉。這一章解決的核心問題是怎么讓所有請求都讀到同一個登錄態(tài)以及登錄態(tài)什么時候失效。4.1 為什么不能用默認 SessionPHP 默認的 Session 是把數(shù)據(jù)序列化后寫到本地文件里的。單機開發(fā)沒問題一旦上了負載均衡請求被轉(zhuǎn)發(fā)到另一臺機器那邊讀不到你的 Session 文件用戶就被判定為未登錄。表現(xiàn)就是用戶明明才登錄成功下一頁又跳回登錄頁。解決辦法是把 Session 數(shù)據(jù)統(tǒng)一存到 Redis。最簡單的做法是在php.ini里改配置session.save_handler redis session.save_path tcp://127.0.0.1:6379?database2這個辦法快但不夠靈活。我更喜歡在代碼里實現(xiàn)一個SessionHandlerInterface這樣能統(tǒng)一控制 key 前綴、過期時間并且方便在強制下線時精準刪除指定會話。實現(xiàn)見下一節(jié)。4.2 自定義 Redis 會話處理器先看代碼這一段是整個會話一致性的地基final class RedisSessionHandler implements SessionHandlerInterface { public function __construct( private readonly Redis $redis, private readonly int $ttl 7200, private readonly string $prefix PHPSESSID:, ) {} public function open(string $path, string $name): bool { return true; } public function close(): bool { return true; } public function read(string $id): string|false { return $this-redis-get($this-prefix . $id) ?: ; } public function write(string $id, string $data): bool { return (bool) $this-redis-setex($this-prefix . $id, $this-ttl, $data); } public function destroy(string $id): bool { return $this-redis-del($this-prefix . $id) 0; } public function gc(int $max_lifetime): int { return 0; } }注冊方式也很簡單$redis new Redis(); $redis-connect(127.0.0.1, 6379); $redis-select(2); session_set_save_handler(new RedisSessionHandler($redis, 7200), true); session_start();這里我把 TTL 設(shè)為 7200 秒也就是 2 小時。但每個會話應(yīng)該有一個“最后活躍時間”的概念不能簡單地 2 小時一刀切。下一節(jié)會講滑動續(xù)期。寫入時用setex設(shè)置過期時間Redis 會在到達 TTL 后自動刪除 key這就是絕對超時的基礎(chǔ)框架。4.3 登錄成功后的 session 重建與會話數(shù)據(jù)模型登錄成功那一刻一定要調(diào)用session_regenerate_id(true)。這個方法會生成一個新的 Session ID并把舊的 Session 內(nèi)容遷移過來同時刪掉舊 ID。這么做的目的是防 Session 固定攻擊——攻擊者把固定 Session ID 種給用戶用戶登錄成功后攻擊者就可能復(fù)用同一個 ID。重建 ID 之后攻擊者手里的舊 ID 直接失效。然后是會話數(shù)據(jù)模型。很多新手會把用戶對象整個塞進$_SESSION這是錯的。序列化整個用戶對象不僅體積大還有可能出現(xiàn)類屬性被篡改的風(fēng)險。我的做法是把最小必要數(shù)據(jù)放進去$_SESSION[user_id] 101; $_SESSION[auth_level] mfa_verified; $_SESSION[risk] [ score 20, device_id f3a9b8..., ]; $_SESSION[login_at] time(); $_SESSION[last_seen] time();為什么last_seen要單拎出來因為滑動續(xù)期邏輯要用到它。注意auth_level在這里非常有用它區(qū)分“已經(jīng)通過 MFA”和“還沒通過 MFA”的會話。如果風(fēng)控評分中途升高你可以只把auth_level改成pending讓用戶在下次操作時重新認證而不是直接銷毀整個會話。4.4 會話續(xù)期、超時與主動踢人續(xù)期要解決兩個矛盾用戶希望長時間不重登安全團隊希望空閑會話盡快過期。我的方案是“絕對超時 2 小時 空閑超時 15 分鐘”。每次請求進來判斷l(xiāng)ast_seen距離當前時間是否超過 900 秒if (time() - $_SESSION[last_seen] 900) { // 有活動續(xù)期重置 session 的 TTL $_SESSION[last_seen] time(); $handler new RedisSessionHandler($redis, 7200); $handler-write(session_id(), session_encode()); }這里千萬注意不能每次請求都重置 TTL否則一個掛著不動的瀏覽器也會因為 15 分鐘內(nèi)恰好有自動請求而無限續(xù)期。續(xù)期的觸發(fā)條件必須是“用戶確實在做有效操作”比如點了菜單、打開了新頁面而不是后臺定時器發(fā)的心跳。主動踢人的實現(xiàn)要靠會話索引。登錄成功后把當前 Session ID 加入該用戶的會話集合$activeSessionsKey session:user:{$userId}; $redis-sAdd($activeSessionsKey, session_id());強制下線時遍歷集合逐個刪除 Redis 里的 Session keyforeach ($redis-sMembers($activeSessionsKey) as $sid) { $redis-del(PHPSESSID:{$sid}); } $redis-del($activeSessionsKey);這種設(shè)計同時支持“踢所有設(shè)備”和“只踢某臺設(shè)備”。如果業(yè)務(wù)要求同一賬號只能一個會話在線登錄成功時刪掉集合里除當前 Session ID 之外的所有 ID 就行。要注意的是刪除 Redis 里的 Session 只是單向的攻擊者手里的 Cookie 并不會立刻消失但因為 Session 讀取不到任何數(shù)據(jù)下一次請求就會被判定為未登錄安全性不會受影響。5. 常見問題與避坑清單這章內(nèi)容是我實際跑這套系統(tǒng)時遇到的真問題一個一個列出來省得你再踩一遍。5.1 TOTP 時間漂移與容錯窗口TOTP 完全不依賴網(wǎng)絡(luò)但它依賴時間。如果服務(wù)器時鐘不準驗證永遠過不了。生產(chǎn)環(huán)境一定要配 NTP 同步排查時可以用timedatectl status看當前時間偏差。用戶設(shè)備時間偏差大時我通過把window參數(shù)調(diào)到 2 解決也就是前后各允許 2 個窗口共 2.5 分鐘容錯。但這個窗口越大重放風(fēng)險越高我實際生產(chǎn)只開 1超過 1 的讓用戶重新同步設(shè)備時間。5.2 session.save_path 與多機同步Redis 存 Session 之后多機同步最大的坑不是 Redis 本身而是 PHP 序列化格式。如果一臺服務(wù)器session.serialize_handler是php另一臺是php_binary它們寫入 Session 數(shù)據(jù)的格式就不一樣Redis 里的同一份數(shù)據(jù)可能被另一臺機器解析失敗。統(tǒng)一在每臺機器的 php.ini 里配置session.serialize_handler php session.save_handler redis然后再啟動服務(wù)。注意 Redis key 前綴我用PHPSESSID:就是為了和默認文件 Session 的 key 命名區(qū)分開也方便排查時直接redis-cli查看。5.3 風(fēng)控誤殺與規(guī)則調(diào)優(yōu)風(fēng)控引擎上線頭一個月業(yè)務(wù)方天天來找我“為什么這個客服賬號登錄被擋了”。查下來基本都是誤殺。誤殺最常見的原因有三個代理 IP 走辦公網(wǎng)絡(luò)、用戶出差更換城市、新設(shè)備首次登錄。我的調(diào)優(yōu)方法是給規(guī)則加“影響系數(shù)”比如“設(shè)備新度”這一條只對密碼風(fēng)險等級較高的賬號加成對普通用戶即使新設(shè)備也最多加 10 分而不是 25 分。早期寧可漏一點也不要一開始就大殺四方。5.4 PHP 環(huán)境相關(guān)的幾個真實報錯裝 PHP 8.3 時如果編譯 zip 擴展容易碰到no package libzip found這通常不是 PHP 的問題而是系統(tǒng)缺少 libzip 開發(fā)包。CentOS 上執(zhí)行yum install libzip-develDebian 上執(zhí)行apt install libzip-dev再重新編譯就能過。Windows 下則是另一個畫風(fēng)啟動時報vcruntime140.dll 14.0 is not compatible with PHP 8.3原因是 VC 運行庫版本太老去微軟官網(wǎng)裝 VC 2015-2022 Redistributable 就能解決。這類環(huán)境問題看似和認證邏輯無關(guān)但排查起來能浪費一整天提前寫在清單里免得大家走彎路。5.5 Cookie 和 HttpOnly 等安全屬性Session 就算放進了 Redis如果 Cookie 能被 JS 偷偷讀走登錄態(tài)照樣不安全。我在項目里固定設(shè)置這幾項ini_set(session.use_strict_mode, 1); ini_set(session.use_only_cookies, 1); ini_set(session.cookie_httponly, 1); ini_set(session.cookie_samesite, Lax); // 線上確認 HTTPS 之后才會開啟 ini_set(session.cookie_secure, $isHttps ? 1 : 0);use_strict_mode的作用是拒絕用戶提交的未知名 Session ID從源頭減少固定會話偽造的可能。cookie_httponly則禁止 JavaScript 讀取 CookieXSS 就算打進來也偷不走登錄態(tài)。cookie_samesiteLax能在跨站請求時把 Cookie 擋在門外對 CSRF 有不錯的抑制效果。最后一條要特別小心開發(fā)環(huán)境沒有 HTTPS 時千萬不要把cookie_secure開成 1否則 Cookie 根本種不進去你會看到“登錄成功然后立刻掉線”的詭異現(xiàn)象。把這三塊從零到一完整實現(xiàn)一遍之后最值錢的東西不是哪段代碼而是你終于知道一次登錄背后到底發(fā)生了什么風(fēng)控打分、TOTP 校驗、會話重建、Redis 里 key 的增刪改查每一步都有明確的存在理由。以后再看任何現(xiàn)成的登錄 SDK 或者框架內(nèi)置的 auth 模塊你不會再有一層黑盒恐懼反而能一眼判斷出它設(shè)計的優(yōu)劣。最后再分享一個小技巧這套系統(tǒng)的調(diào)試階段一定要在 Redis 里給 session、風(fēng)控計數(shù)、MFA 狀態(tài)分別指定不同的 database 或 key 前綴比如PHPSESSID:、risk:、mfa:。這樣線上出了故障你能直接redis-cli看一個 key 的 TTL 和內(nèi)容不需要在 PHP 代碼里打斷點翻哪臺機器的日志。我自己這回就是這么救回一次線上大事故的。 PHP登錄安全實戰(zhàn)：TOTP多因素認證、風(fēng)控攔截與Redis會話一致性
前陣子接手一個老 PHP 電商項目老板讓我把登錄安全做扎實。當時我對多因素認證、風(fēng)控攔截、會話一致性這三塊也只是有個大概認知網(wǎng)上現(xiàn)成的庫又不敢直接塞進生產(chǎn)環(huán)境干脆從零開始寫一套。正好手上有個 PHP 8.3 的空閑服務(wù)配合 Redis 直接把整條認證鏈路捋了一遍。這篇文章就用“庖丁解牛”的方式把登錄體系拆成三塊骨頭——多因素認證怎么做、風(fēng)控攔截怎么評分、會話一致性怎么保證——每一塊我都會給代碼、給思路、給踩坑記錄。內(nèi)容偏實操適合那些有 PHP 基礎(chǔ)、但還沒完整構(gòu)建過認證體系的開發(fā)者看完可以直接照著落地也能理解每個設(shè)計決策背后的原因。1. 項目解牛三個模塊為什么必須放一起做很多人會把“多因素認證”“風(fēng)控攔截”“會話一致性”當成三個獨立需求分開做這是非常容易踩坑的地方。用戶的登錄行為是一條完整鏈路三者的關(guān)系是前后串聯(lián)的請求先進入風(fēng)控引擎風(fēng)控決定你要不要做二次認證二次認證通過之后再建立會話。拆開做最終聯(lián)調(diào)時一定會出現(xiàn)接口對不齊、狀態(tài)不同步的問題。所以從設(shè)計第一天起就要把它們當成一個閉環(huán)看。1.1 先捋清楚需求的三條主線多因素認證解決的是“密碼泄露”問題。就算用戶的賬號密碼被釣魚、撞庫撞出來了沒有第二個因素攻擊者依然進不來。我這邊選了 TOTP基于時間的一次性密碼作為主認證方式因為在沒有服務(wù)商依賴的前提下它完全離線可用客戶不用等短信也不會被通道延遲坑。風(fēng)控攔截解決的是“碰撞與自動化攻擊”問題。密碼錯誤 100 次和密碼錯誤 1 次兩者風(fēng)險完全不一樣。風(fēng)控引擎就是在正式認證前給這次請求打分分數(shù)決定走什么處置策略。它的價值不僅在于防黑客還能防止正常用戶被暴力破解影響。會話一致性解決的是“登錄態(tài)在多機、多端下的漂移”問題。生產(chǎn)環(huán)境至少兩臺 Web 服務(wù)器如果 Session 存在本地文件里負載均衡一轉(zhuǎn)發(fā)用戶就被“強制下線”了。把 Session 搬到 Redis 之后不管請求打到哪臺機器都能讀到同一份登錄數(shù)據(jù)。1.2 技術(shù)選型與目錄結(jié)構(gòu)我全程用的是 PHP 8.3 Redis 7 nginx路由自己寫不依賴重型框架。核心邏輯全部用原生 PHP 實現(xiàn)二維碼生成用endroid/qr-code其他的能省則省。為什么要刻意去掉框架因為框架的封裝會把很多關(guān)鍵機制藏起來比如 Session 生命周期、Cookie 屬性、序列化方式這些恰恰是登錄體系最容易出問題的地方。用原生實現(xiàn)一遍你能清楚看到每一步發(fā)生了什么。項目目錄結(jié)構(gòu)大致長這樣auth-system/ ├─ public/ │ └─ index.php ├─ app/ │ ├─ Auth/ │ │ ├─ Totp.php │ │ ├─ OneTimeCode.php │ │ ├─ RiskEngine.php │ │ └─ SessionManager.php │ ├─ Support/ │ │ ├─ Base32.php │ │ └─ RedisClient.php │ └─ Config.php ├─ composer.json └─ .env每個類的職責很純粹Totp處理時間同步驗證碼OneTimeCode負責短信/郵件驗證碼和備份碼RiskEngine做信號采集和風(fēng)險評分SessionManager統(tǒng)一接管 Redis 里的會話讀寫。這種職責劃分也方便以后替換實現(xiàn)比如風(fēng)控規(guī)則想升級成機器學(xué)習(xí)打分只需要改RiskEngine內(nèi)部邏輯。1.3 一次登錄請求的完整生命周期把流程在腦子里過一遍后面所有代碼都是給這個流程服務(wù)的用戶提交賬號密碼服務(wù)端先校驗賬號是否存在、密碼哈希是否匹配。密碼校驗通過后立刻進入風(fēng)控引擎。風(fēng)控會采集當前設(shè)備的指紋、IP 地理位置、User-Agent、歷史失敗次數(shù)等信號。風(fēng)控引擎輸出風(fēng)險評分。0 到 35 分直接放行35 到 70 分要求二次認證70 分以上直接拒絕。如果需要二次認證就觸發(fā) TOTP 或短信驗證碼流程用戶提交一次性驗證碼。認證通過后調(diào)用session_regenerate_id(true)重建會話把用戶身份和登錄時間寫入 Redis并下發(fā) Cookie。用戶后續(xù)請求會帶著 Session IDRedis 里讀出來校驗是否過期、是否被強制下線然后做滑動續(xù)期。這個鏈路里風(fēng)控在認證之前認證在會話建立之前。順序不能反——如果先建會話再做風(fēng)控風(fēng)控一旦把用戶攔截會話狀態(tài)就會出現(xiàn)半登錄半匿名的尷尬局面。2. 多因素認證從 TOTP 到驗證碼的完整鏈路多因素認證這塊我推薦優(yōu)先做 TOTP。它不依賴短信通道用戶裝一個 Google Authenticator、Microsoft Authenticator 或者 1Password 就能用。TOTP 的完整落地包含四個部分核心算法、密鑰綁定、校驗邏輯、兜底方案。下面逐個拆。2.1 TOTP 的核心算法HMAC 與時間窗口TOTP 的本質(zhì)不是加密而是“用時間和密鑰計算一個動態(tài)短碼”。它的底層是 HOTPHMAC-Based One-Time Password區(qū)別只在于 HOTP 把計數(shù)器傳進去TOTP 把當前時間戳整除 30 得到的結(jié)果當作計數(shù)器。為什么是 30 秒這是 RFC 6238 推薦的默認時間步長太長用戶等得煩躁太短用戶輸入時間不夠。核心計算代碼我用 PHP 實現(xiàn)關(guān)鍵點都注釋了final class Totp { public const STEP 30; public function __construct( private readonly string $secret, // base32 解碼后的原始密鑰字節(jié) private readonly int $digits 6, private readonly int $window 1, ) {} public function codeAt(float $timestamp): string { // 當前時間步長 $counter intdiv((int) floor($timestamp), self::STEP); // 計數(shù)器必須是 8 字節(jié)大端序RFC 4226 里高位補零 $bin pack(N2, 0, $counter); // HMAC-SHA1輸出 20 字節(jié) $hash hash_hmac(sha1, $bin, $this-secret, true); // 動態(tài)截斷取 hash 最后一個字節(jié)的低 4 位作為偏移量 $offset ord($hash[19]) 0x0f; // 從偏移量開始取 4 字節(jié)最高位強制為 0避免符號位干擾 $value ((ord($hash[$offset]) 0x7f) 24) | ((ord($hash[$offset 1]) 0xff) 16) | ((ord($hash[$offset 2]) 0xff) 8) | (ord($hash[$offset 3]) 0xff); // 取模得到 6 位數(shù)字不夠前面補零 return str_pad((string) ($value % 10 ** $this-digits), $this-digits, 0, STR_PAD_LEFT); } }有兩點我想特別說明。第一pack(N2, 0, $counter)這種寫法專門兼容 32 位 PHP把高 32 位置零低 32 位存計數(shù)器不會因為$counter超出整型范圍而飄移。第二動態(tài)截斷是 HOTP 規(guī)范里的固定套路不是隨便取的 4 字節(jié)它保證了就算 HMAC 的某些位被翻轉(zhuǎn)取到的偏移也不會跑出哈希邊界。2.2 密鑰生成、Base32 與掃碼綁定TOTP 的種子密鑰必須是服務(wù)端為每個用戶獨立生成的不能用固定的字符串。我用random_bytes(20)生成 160 位隨機數(shù)這個強度已經(jīng)超過大多數(shù)需要。生成的字節(jié)沒法直接給用戶看Google Authenticator 的掃碼解析要求密鑰必須 Base32 編碼。Base32 編碼算法不復(fù)雜只是把任意字節(jié)流按 5 位一組重新映射到 A-Z 2-7 這 32 個字符上。我提供一個可直接復(fù)用的編碼函數(shù)function base32_encode(string $data): string { $alphabet ABCDEFGHIJKLMNOPQRSTUVWXYZ234567; $binary ; foreach (str_split($data) as $char) { $binary . sprintf(%08b, ord($char)); } $result ; foreach (str_split($binary, 5) as $chunk) { $result . $alphabet[bindec(str_pad($chunk, 5, 0))]; } return $result; }同樣的校驗的時候需要 Base32 解碼把用戶掃碼得到的字符串轉(zhuǎn)回原始密鑰字節(jié)我這里給出的解碼函數(shù)要跟編碼函數(shù)配對使用function base32_decode(string $data): string { $alphabet ABCDEFGHIJKLMNOPQRSTUVWXYZ234567; $map []; for ($i 0; $i 32; $i) { $map[$alphabet[$i]] $i; } $data strtoupper(rtrim($data, )); $binary ; foreach (str_split($data) as $char) { $binary . str_pad(decbin($map[$char] ?? 0), 5, 0, STR_PAD_LEFT); } $result ; foreach (str_split($binary, 8) as $byte) { if (strlen($byte) 8) { $result . chr(bindec($byte)); } } return $result; }綁定階段的核心是生成 otpauth URI。這個 URI 是一串標準的配置文本認證器 App 看到它就知道往哪個 App 生成二維碼$secretBytes random_bytes(20); $secret base32_encode($secretBytes); $issuer MyApp; $account userexample.com; $uri sprintf( otpauth://totp/%s:%s?secret%sissuer%sdigits%dperiod%d, rawurlencode($issuer), rawurlencode($account), $secret, rawurlencode($issuer), 6, 30, ); // 然后用 endroid/qr-code 把這個 $uri 生成二維碼渲染到前端配套composer require endroid/qr-code把$uri傳給二維碼庫輸出 base64 圖片。這里有一個非常容易忽略的步驟綁定只是把密鑰存進數(shù)據(jù)庫還不夠一定要讓用戶立刻提交一次當前驗證碼服務(wù)端驗證通過才算綁定完成。這個“綁定即驗證”的設(shè)計可以防止二維碼在傳遞過程中被劫持或者用戶掃錯碼綁定成別人的種子。2.3 校驗邏輯容錯、防重放與防時序攻擊校驗的核心代碼是verify它做的事情很簡單算出當前時間窗口的驗證碼和用戶提交的比對如果不一致就往前、往后各滑動一個窗口再比對。為什么要有滑動窗口因為用戶掃碼、打開認證器、手動輸入這幾個動作會消耗時間等提交到服務(wù)端時30 秒的時間窗口可能已經(jīng)翻篇了。public function verify(string $code, float $timestamp): bool { if (!preg_match(/^\d{ . $this-digits . }$/, $code)) { return false; } $current intdiv((int) floor($timestamp), self::STEP); for ($i -$this-window; $i $this-window; $i) { $candidate $this-codeAt(($current $i) * self::STEP); if (hash_equals($candidate, $code)) { return true; } } return false; }hash_equals不是可選項不能用替代。原因很簡單比較字符串時只要發(fā)現(xiàn)第一個不同字符就立刻返回 false攻擊者可以通過測量響應(yīng)時間反推驗證碼的字符hash_equals會固定比較完所有字節(jié)時序上不給攻擊者留縫隙。校驗通過之后還有一道防線防重放。同一個驗證碼在同一個時間窗口內(nèi)只能使用一次否則只是一個被動截獲的驗證碼也能反復(fù)登錄。實現(xiàn)方式是驗證成功后把當前時間窗口記為“已使用”寫入 Redis$replayKey mfa:totp:replay:{$userId}:{$current}; $ok $redis-set($replayKey, 1, [NX, EX self::STEP * ($this-window 1)]); if (!$ok) { throw new RuntimeException(該驗證碼已使用請刷新后重試); }set命令帶上NX參數(shù)表示只有 key 不存在時才寫入。第二次使用相同窗口的驗證碼set會返回 false說明被重放了。EX的過期時間設(shè)為窗口前后可接受的范圍避免 Redis key 堆積。2.4 短信郵件驗證碼與備份碼的兜底方案TOTP 雖然穩(wěn)但用戶一旦換手機就會遇到“新手機還沒綁定、舊手機不在身邊”的尷尬。所以必須提供兜底方案。第一種兜底是短信或郵件驗證碼。它的實現(xiàn)比 TOTP 簡單很多生成一個 6 位隨機數(shù)字存進 Redis 并設(shè)置 5 分鐘過期然后調(diào)用短信或郵件服務(wù)商接口發(fā)送。這里有兩個關(guān)鍵細節(jié)發(fā)送限流和一次性使用。$code (string) random_int(100000, 999999); // 60 秒內(nèi)同一賬號只能發(fā)一次 $limitKey mfa:sms:limit:{$userId}; if (!$redis-set($limitKey, 1, [NX, EX 60])) { throw new RuntimeException(發(fā)送太頻繁請稍后再試); } $redis-setex(mfa:sms:code:{$userId}, 300, password_hash($code, PASSWORD_BCRYPT)); // $smsProvider-send($user-phone, $code);為什么要對同一個賬號限制發(fā)送頻率因為短信通道要花錢攻擊者可以利用接口無限轟炸既浪費成本又可能把運營商的通道封掉。為什么要用password_hash存驗證碼而不是明文因為 Redis 里可能有過期數(shù)據(jù)被 dump 的風(fēng)險任何時候都不要把明文驗證碼留在存儲層。第二種兜底是備份碼。備份碼的生成邏輯是生成 10 到 20 個隨機碼展示給用戶一次數(shù)據(jù)庫里只存每個備份碼的哈希。為什么不能存明文備份碼的殺傷力和密碼等同數(shù)據(jù)庫一旦泄露明文備份碼就直接白給。驗證的時候把用戶輸入的備份碼哈希之后比對匹配成功就從庫里刪除這條記錄保證只能用一次。3. 風(fēng)控攔截采集信號、計算風(fēng)險、分級處置風(fēng)控引擎的定位是“認證之前的一道閘門”。它不關(guān)心用戶密碼對不對它只判斷這次請求本身是否可疑。我從三個層面來拆信號怎么采集、分數(shù)怎么算、觸發(fā)之后怎么處置。3.1 信號采集設(shè)備指紋、IP 情報與行為數(shù)據(jù)設(shè)備指紋是風(fēng)控最基礎(chǔ)的數(shù)據(jù)源。前端頁面加載時采集瀏覽器信息包括 User-Agent、語言、時區(qū)、屏幕分辨率、canvas 渲染結(jié)果、已安裝字體等然后用 SHA-256 把這些信息拼起來做一次哈希得到一個設(shè)備指紋。代碼示意如下// 前端采集后通過接口上報 $deviceSignals [ ua $_SERVER[HTTP_USER_AGENT] ?? , lang $_SERVER[HTTP_ACCEPT_LANGUAGE] ?? , screen 1920x1080, timezone -480, canvas hash-string-from-canvas, ]; $fingerprint hash(sha256, json_encode($deviceSignals));但要注意這個 fingerprint 是客戶端算出來傳給服務(wù)端的理論上可以被偽造。所以不能直接把這個哈希當成身份憑證。更嚴謹?shù)淖龇ㄊ欠?wù)端用 HMAC 密鑰對它簽發(fā)一個設(shè)備 ID后續(xù)請求都帶著這個簽名后的設(shè)備 ID 關(guān)聯(lián)用戶。IP 側(cè)的情報可以通過 GeoIP 庫拿到國家、城市、經(jīng)緯度。比如 GeoLite2 離線庫就可以。為什么不在這里拋具體服務(wù)商因為生產(chǎn)環(huán)境可能用云廠商的安全產(chǎn)品也可能內(nèi)網(wǎng)部署離線庫只要最終能給一個 0 到 100 的 IP 風(fēng)險分就行。行為數(shù)據(jù)是最容易獲得也最誠實的。密碼錯誤次數(shù)、驗證碼錯誤次數(shù)、同一 IP 的登錄頻率、請求路徑異常程度這些數(shù)據(jù)通過 Redis 計數(shù)指標就能拿到。它們的價值在于反映“趨勢”單個錯誤可能是手滑短時間內(nèi) 20 次錯誤就是自動化腳本在跑。3.2 風(fēng)險評分模型規(guī)則加權(quán)而不是玄學(xué)第一版風(fēng)控不需要上機器學(xué)習(xí)規(guī)則加權(quán)就夠了。原因有兩條一是新業(yè)務(wù)根本沒有歷史標注數(shù)據(jù)供模型訓(xùn)練二是規(guī)則引擎可解釋、可調(diào)試客戶投訴“為什么被攔截”時你能立刻給出原因。我這里擬定了一套評分規(guī)則信號評分區(qū)間說明IP 基礎(chǔ)風(fēng)險0-30GeoIP 識別為 IDC、代理則高分設(shè)備新度0-25該賬號歷史從未出現(xiàn)過此設(shè)備指紋失敗次數(shù)0-25最近 10 分鐘密碼失敗次數(shù)每次 5上限 25地理位置跳躍0-20上次登錄城市與本次距離超過 500 公里訪問軌跡異常0-15UA 異常、請求路徑不符合登錄流程黑名單100命中已知黑名單直接攔截需要聲明的是這個權(quán)重表是“基于常見實踐的配置范例”你可以按照業(yè)務(wù)特征調(diào)整但調(diào)的時候要關(guān)注每種規(guī)則誤傷多少正常用戶。核心代碼就非常直白final class RiskEngine { public function evaluate(array $signals): RiskResult { $score 0; $score $signals[ip]-score(); $score $signals[device_new] ? 25 : 0; $score min(25, $signals[fail_count] * 5); $score $this-geoJumpScore($signals[geo_before], $signals[geo_now]); if ($signals[ip]-isBlacklisted()) { return RiskResult::blocked(blacklist ip); } return RiskResult::scored($score); } }地理位置跳躍的計算用 Haversine 公式就可以。不要看經(jīng)緯度差大就拍大腿決定用戶很可能坐飛機出差這個信號要配合“IP 是否 IDC、本次登錄是否新設(shè)備”一起看。單獨一個維度超過 500 公里就加分是很粗的規(guī)則比較靠譜的寫法是距離大于閾值并且設(shè)備是新設(shè)備才給較高的權(quán)重。3.3 三種處置方式觀察、驗證、阻斷評分出來后處置策略分成三檔0 到 35 分直接放行但把這次請求打上低風(fēng)險標簽寫日志。35 到 70 分進入二次認證流程要求 TOTP 或短信驗證碼通過了再放行。70 分以上拒絕登錄提示環(huán)境異?；蚵?lián)系客服人工處理。第二檔里有一個值得注意的細節(jié)如果用戶本來就要做多因素認證那風(fēng)控評分高時不應(yīng)該“再讓他做一次認證”而是應(yīng)該在同一個認證流程里提升挑戰(zhàn)難度。比如低風(fēng)險時只要 TOTP中高風(fēng)險時強制 TOTP 加備份碼確認。這樣才能真正形成兩重防線而不是做兩遍無用功。同樣重要的是“后臺日志先行”。我給風(fēng)控引擎加了一個影子模式所有評分結(jié)果都記錄到日志表但初期不實際攔截。上線跑兩周之后把誤報和漏報的案例抽出來調(diào)權(quán)重再逐步開啟攔截。風(fēng)控系統(tǒng)翻車的重災(zāi)區(qū)不是技術(shù)不夠而是規(guī)則直接拍死了正常用戶還渾然不覺。3.4 用 Redis 做滑動窗口計數(shù)滑動窗口計數(shù)的核心是“統(tǒng)計最近 N 秒內(nèi)的事件數(shù)量”。我舉個密碼失敗次數(shù)的例子。初始密碼校驗失敗時執(zhí)行$failKey risk:fail:{$userId}:{$ip}; $count $redis-incr($failKey); // 注意只有第一次累加時才設(shè)置過期時間 if ($count 1) { $redis-expire($failKey, 600); }關(guān)鍵坑就在if ($count 1)這一句。如果我在每次累加之后都無腦執(zhí)行expire($failKey, 600)那么持續(xù) 10 分鐘內(nèi)每產(chǎn)生一次失敗key 的過期時間都會往后順延 10 分鐘這個“滑動窗口”就永遠滑不到頭了。只有當 key 是新建的時候設(shè)置過期才能保證 10 分鐘不動之后窗口自動清零。另一個常用場景是 IP 登錄頻率限流每分鐘最多 20 次登錄嘗試$loginKey risk:login:{$ip}; $count $redis-incr($loginKey); if ($count 1) { $redis-expire($loginKey, 60); } if ($count 20) { throw new RuntimeException(嘗試過于頻繁請稍后再試); }這種計數(shù)方式很簡單但也有并發(fā)問題兩個請求同時incr可能出現(xiàn)一個進程看到$count 1而另一個看到$count 2的競態(tài)。好在 Redis 的INCR是原子操作設(shè)置過期時以“第一個拿到 1 的進程”為準基本夠用。如果想更嚴謹可以用 Lua 腳本把“累加、設(shè)置過期、判斷閾值”打包成一個原子操作執(zhí)行。4. 會話一致性登錄態(tài)在多機環(huán)境不漂移會話一致性是這一套系統(tǒng)能不能在生產(chǎn)環(huán)境扛住的關(guān)鍵。你把認證和風(fēng)控都做好了結(jié)果用戶一刷新就掉線體驗同樣廢掉。這一章解決的核心問題是怎么讓所有請求都讀到同一個登錄態(tài)以及登錄態(tài)什么時候失效。4.1 為什么不能用默認 SessionPHP 默認的 Session 是把數(shù)據(jù)序列化后寫到本地文件里的。單機開發(fā)沒問題一旦上了負載均衡請求被轉(zhuǎn)發(fā)到另一臺機器那邊讀不到你的 Session 文件用戶就被判定為未登錄。表現(xiàn)就是用戶明明才登錄成功下一頁又跳回登錄頁。解決辦法是把 Session 數(shù)據(jù)統(tǒng)一存到 Redis。最簡單的做法是在php.ini里改配置session.save_handler redis session.save_path tcp://127.0.0.1:6379?database2這個辦法快但不夠靈活。我更喜歡在代碼里實現(xiàn)一個SessionHandlerInterface這樣能統(tǒng)一控制 key 前綴、過期時間并且方便在強制下線時精準刪除指定會話。實現(xiàn)見下一節(jié)。4.2 自定義 Redis 會話處理器先看代碼這一段是整個會話一致性的地基final class RedisSessionHandler implements SessionHandlerInterface { public function __construct( private readonly Redis $redis, private readonly int $ttl 7200, private readonly string $prefix PHPSESSID:, ) {} public function open(string $path, string $name): bool { return true; } public function close(): bool { return true; } public function read(string $id): string|false { return $this-redis-get($this-prefix . $id) ?: ; } public function write(string $id, string $data): bool { return (bool) $this-redis-setex($this-prefix . $id, $this-ttl, $data); } public function destroy(string $id): bool { return $this-redis-del($this-prefix . $id) 0; } public function gc(int $max_lifetime): int { return 0; } }注冊方式也很簡單$redis new Redis(); $redis-connect(127.0.0.1, 6379); $redis-select(2); session_set_save_handler(new RedisSessionHandler($redis, 7200), true); session_start();這里我把 TTL 設(shè)為 7200 秒也就是 2 小時。但每個會話應(yīng)該有一個“最后活躍時間”的概念不能簡單地 2 小時一刀切。下一節(jié)會講滑動續(xù)期。寫入時用setex設(shè)置過期時間Redis 會在到達 TTL 后自動刪除 key這就是絕對超時的基礎(chǔ)框架。4.3 登錄成功后的 session 重建與會話數(shù)據(jù)模型登錄成功那一刻一定要調(diào)用session_regenerate_id(true)。這個方法會生成一個新的 Session ID并把舊的 Session 內(nèi)容遷移過來同時刪掉舊 ID。這么做的目的是防 Session 固定攻擊——攻擊者把固定 Session ID 種給用戶用戶登錄成功后攻擊者就可能復(fù)用同一個 ID。重建 ID 之后攻擊者手里的舊 ID 直接失效。然后是會話數(shù)據(jù)模型。很多新手會把用戶對象整個塞進$_SESSION這是錯的。序列化整個用戶對象不僅體積大還有可能出現(xiàn)類屬性被篡改的風(fēng)險。我的做法是把最小必要數(shù)據(jù)放進去$_SESSION[user_id] 101; $_SESSION[auth_level] mfa_verified; $_SESSION[risk] [ score 20, device_id f3a9b8..., ]; $_SESSION[login_at] time(); $_SESSION[last_seen] time();為什么last_seen要單拎出來因為滑動續(xù)期邏輯要用到它。注意auth_level在這里非常有用它區(qū)分“已經(jīng)通過 MFA”和“還沒通過 MFA”的會話。如果風(fēng)控評分中途升高你可以只把auth_level改成pending讓用戶在下次操作時重新認證而不是直接銷毀整個會話。4.4 會話續(xù)期、超時與主動踢人續(xù)期要解決兩個矛盾用戶希望長時間不重登安全團隊希望空閑會話盡快過期。我的方案是“絕對超時 2 小時 空閑超時 15 分鐘”。每次請求進來判斷l(xiāng)ast_seen距離當前時間是否超過 900 秒if (time() - $_SESSION[last_seen] 900) { // 有活動續(xù)期重置 session 的 TTL $_SESSION[last_seen] time(); $handler new RedisSessionHandler($redis, 7200); $handler-write(session_id(), session_encode()); }這里千萬注意不能每次請求都重置 TTL否則一個掛著不動的瀏覽器也會因為 15 分鐘內(nèi)恰好有自動請求而無限續(xù)期。續(xù)期的觸發(fā)條件必須是“用戶確實在做有效操作”比如點了菜單、打開了新頁面而不是后臺定時器發(fā)的心跳。主動踢人的實現(xiàn)要靠會話索引。登錄成功后把當前 Session ID 加入該用戶的會話集合$activeSessionsKey session:user:{$userId}; $redis-sAdd($activeSessionsKey, session_id());強制下線時遍歷集合逐個刪除 Redis 里的 Session keyforeach ($redis-sMembers($activeSessionsKey) as $sid) { $redis-del(PHPSESSID:{$sid}); } $redis-del($activeSessionsKey);這種設(shè)計同時支持“踢所有設(shè)備”和“只踢某臺設(shè)備”。如果業(yè)務(wù)要求同一賬號只能一個會話在線登錄成功時刪掉集合里除當前 Session ID 之外的所有 ID 就行。要注意的是刪除 Redis 里的 Session 只是單向的攻擊者手里的 Cookie 并不會立刻消失但因為 Session 讀取不到任何數(shù)據(jù)下一次請求就會被判定為未登錄安全性不會受影響。5. 常見問題與避坑清單這章內(nèi)容是我實際跑這套系統(tǒng)時遇到的真問題一個一個列出來省得你再踩一遍。5.1 TOTP 時間漂移與容錯窗口TOTP 完全不依賴網(wǎng)絡(luò)但它依賴時間。如果服務(wù)器時鐘不準驗證永遠過不了。生產(chǎn)環(huán)境一定要配 NTP 同步排查時可以用timedatectl status看當前時間偏差。用戶設(shè)備時間偏差大時我通過把window參數(shù)調(diào)到 2 解決也就是前后各允許 2 個窗口共 2.5 分鐘容錯。但這個窗口越大重放風(fēng)險越高我實際生產(chǎn)只開 1超過 1 的讓用戶重新同步設(shè)備時間。5.2 session.save_path 與多機同步Redis 存 Session 之后多機同步最大的坑不是 Redis 本身而是 PHP 序列化格式。如果一臺服務(wù)器session.serialize_handler是php另一臺是php_binary它們寫入 Session 數(shù)據(jù)的格式就不一樣Redis 里的同一份數(shù)據(jù)可能被另一臺機器解析失敗。統(tǒng)一在每臺機器的 php.ini 里配置session.serialize_handler php session.save_handler redis然后再啟動服務(wù)。注意 Redis key 前綴我用PHPSESSID:就是為了和默認文件 Session 的 key 命名區(qū)分開也方便排查時直接redis-cli查看。5.3 風(fēng)控誤殺與規(guī)則調(diào)優(yōu)風(fēng)控引擎上線頭一個月業(yè)務(wù)方天天來找我“為什么這個客服賬號登錄被擋了”。查下來基本都是誤殺。誤殺最常見的原因有三個代理 IP 走辦公網(wǎng)絡(luò)、用戶出差更換城市、新設(shè)備首次登錄。我的調(diào)優(yōu)方法是給規(guī)則加“影響系數(shù)”比如“設(shè)備新度”這一條只對密碼風(fēng)險等級較高的賬號加成對普通用戶即使新設(shè)備也最多加 10 分而不是 25 分。早期寧可漏一點也不要一開始就大殺四方。5.4 PHP 環(huán)境相關(guān)的幾個真實報錯裝 PHP 8.3 時如果編譯 zip 擴展容易碰到no package libzip found這通常不是 PHP 的問題而是系統(tǒng)缺少 libzip 開發(fā)包。CentOS 上執(zhí)行yum install libzip-develDebian 上執(zhí)行apt install libzip-dev再重新編譯就能過。Windows 下則是另一個畫風(fēng)啟動時報vcruntime140.dll 14.0 is not compatible with PHP 8.3原因是 VC 運行庫版本太老去微軟官網(wǎng)裝 VC 2015-2022 Redistributable 就能解決。這類環(huán)境問題看似和認證邏輯無關(guān)但排查起來能浪費一整天提前寫在清單里免得大家走彎路。5.5 Cookie 和 HttpOnly 等安全屬性Session 就算放進了 Redis如果 Cookie 能被 JS 偷偷讀走登錄態(tài)照樣不安全。我在項目里固定設(shè)置這幾項ini_set(session.use_strict_mode, 1); ini_set(session.use_only_cookies, 1); ini_set(session.cookie_httponly, 1); ini_set(session.cookie_samesite, Lax); // 線上確認 HTTPS 之后才會開啟 ini_set(session.cookie_secure, $isHttps ? 1 : 0);use_strict_mode的作用是拒絕用戶提交的未知名 Session ID從源頭減少固定會話偽造的可能。cookie_httponly則禁止 JavaScript 讀取 CookieXSS 就算打進來也偷不走登錄態(tài)。cookie_samesiteLax能在跨站請求時把 Cookie 擋在門外對 CSRF 有不錯的抑制效果。最后一條要特別小心開發(fā)環(huán)境沒有 HTTPS 時千萬不要把cookie_secure開成 1否則 Cookie 根本種不進去你會看到“登錄成功然后立刻掉線”的詭異現(xiàn)象。把這三塊從零到一完整實現(xiàn)一遍之后最值錢的東西不是哪段代碼而是你終于知道一次登錄背后到底發(fā)生了什么風(fēng)控打分、TOTP 校驗、會話重建、Redis 里 key 的增刪改查每一步都有明確的存在理由。以后再看任何現(xiàn)成的登錄 SDK 或者框架內(nèi)置的 auth 模塊你不會再有一層黑盒恐懼反而能一眼判斷出它設(shè)計的優(yōu)劣。最后再分享一個小技巧這套系統(tǒng)的調(diào)試階段一定要在 Redis 里給 session、風(fēng)控計數(shù)、MFA 狀態(tài)分別指定不同的 database 或 key 前綴比如PHPSESSID:、risk:、mfa:。這樣線上出了故障你能直接redis-cli看一個 key 的 TTL 和內(nèi)容不需要在 PHP 代碼里打斷點翻哪臺機器的日志。我自己這回就是這么救回一次線上大事故的。