慣性聚合 高效追蹤和閱讀你感興趣的部落格、新聞、科技資訊
閱讀原文 在慣性聚合中打開

推薦訂閱源

博客园 - 司徒正美
V
V2EX
T
Tailwind CSS Blog
有赞技术团队
有赞技术团队
aimingoo的专栏
aimingoo的专栏
Apple Machine Learning Research
Apple Machine Learning Research
IT之家
IT之家
Blog — PlanetScale
Blog — PlanetScale
A
About on SuperTechFans
月光博客
月光博客
T
The Blog of Author Tim Ferriss
宝玉的分享
宝玉的分享
Martin Fowler
Martin Fowler
博客园 - 聂微东
The GitHub Blog
The GitHub Blog
V
Visual Studio Blog
WordPress大学
WordPress大学
酷 壳 – CoolShell
酷 壳 – CoolShell
Engineering at Meta
Engineering at Meta
GbyAI
GbyAI

阮一峰的网络日志

科技爱好者周刊(第 396 期):互联网通信的替代方案 科技爱好者周刊(第 396 期):互联网通信的替代方案 - 阮一峰的网络日志 科技爱好者周刊(第 395 期):软件开发的第三种方式 科技爱好者周刊(第 395 期):软件开发的第三种方式 - 阮一峰的网络日志 科技爱好者周刊(第 393 期):脑腐状态 科技爱好者周刊(第 392 期):axios 投毒与好莱坞式骗术 科技爱好者周刊(第 391 期):AI 的贫富分化 科技爱好者周刊(第 390 期):没有语料,大模型就是智障 套壳中国大模型撑起500亿美元估值?扒一扒 Cursor 的"套壳"疑云 科技爱好者周刊(第 389 期):未来如何招聘程序员 科技爱好者周刊(第 388 期):测试是新的护城河 零安装的"云养虾":ArkClaw 使用指南 科技爱好者周刊(第 387 期):你是领先的 科技爱好者周刊(第 386 期):当外卖员接入 AI 字节全家桶 Seed 2.0 + TRAE 玩转 Skill 科技爱好者周刊(第 385 期):马斯克害怕中国车企吗? 智谱旗舰 GLM-5 实测:对比 Opus 4.6 和 GPT-5.3-Codex 科技爱好者周刊(第 384 期):为什么软件股下跌 科技爱好者周刊(第 383 期):你是第几级 AI 编程 Kimi 的一体化,Manus 的分层 科技爱好者周刊(第 382 期):独立软件的黄昏 AI native Workspace 也许是智能体的下一阶段 科技爱好者周刊(第 381 期):中国 AI 大模型领导者在想什么 科技爱好者周刊(第 380 期):为什么人们拥抱"不对称收益" 科技爱好者周刊(第 379 期):《硅谷钢铁侠》摘录 我如何用 AI 处理历史遗留代码:MiniMax M2.1 升级体验 科技爱好者周刊(第 378 期):预测是新的互联网热点 科技爱好者周刊(第 377 期):14万美元的贫困线 科技爱好者周刊(第 376 期):太空数据中心的争议 科技爱好者周刊(第 375 期):一扇门的 Bug 终于有人做了 Subagent,TRAE 国内版 SOLO 模式来了 科技爱好者周刊(第 374 期):6GHz 的问题 VS Code 使用国产大模型 MiniMax M2 教程 科技爱好者周刊(第 373 期):数据模型是新产品的核心 国产大模型接入 Claude Code 教程:以 Doubao-Seed-Code 为例 科技爱好者周刊(第 372 期):软件界面如何设计 大模型比拼:MiniMax M2 vs GLM 4.6 vs Claude Sonnet 4.5 科技爱好者周刊(第 371 期):一个乐观主义者的专访 科技爱好者周刊(第 370 期):正确的代码高亮 错误处理:异常好于状态码 科技爱好者周刊(第 369 期):Tim 与罗永浩的对谈 科技爱好者周刊(第 368 期):不要这样管理软件团队 一天之内,智谱和 Anthropic 都发了最强编程模型 科技爱好者周刊(第 367 期):Nano Banana 的几个妙用 科技爱好者周刊(第 366 期):旧金山疯狂的 AI 广告 科技爱好者周刊(第 365 期):流量变现正在崩塌 科技爱好者周刊(第 364 期):最难还原的魔方 科技爱好者周刊(第 363 期):最好懂的神经网络解释 科技爱好者周刊(第 362 期):GitHub 工程师谈系统设计 科技爱好者周刊(第 361 期):暗网 Tor 安全吗?
找回密碼的功能設計
阮一峰 · 2019-02-07 · via 阮一峰的网络日志

所有需要登錄的網站,都會提供"找回密碼"的功能,防止用戶忘記密碼。

正確設計這個功能,保證安全可靠,並不簡單。下面就是安全專家 Troy Hunt 給出的設計指南

一、如何保存密碼

一個網站要想保證密碼安全,第一步就是以正確的方法保存密碼。一般說來,密碼有三種保存方式。

(1)明文保存

"明文保存"就是用戶的密碼原文不動地寫入數據庫。這種方式最不安全,極易洩漏,應該嚴格禁用。

(2)加密保存

"加密保存"就是使用密鑰,將密碼加密後,以密文保存進數據庫。這種方式雖然有一定的安全性,但是終究還是可以用密鑰還原密碼。因此,還是存在洩漏的可能,也不推薦使用。

(3)哈希保存

"哈希保存"就是對密碼使用哈希算法,將哈希值保存進數據庫。為了增加隨機性,防止彩虹表這一類的工具,計算哈希的時候,每個用戶都有一個不一樣的鹽值(salt),也會同時保存進數據庫。

哈希是單向運算,無法還原,所以即使哈希值洩漏,一般來說,也不會暴露用戶的原始密碼。

第一條規則:密碼永遠都要哈希保存。

二、密碼重置

如果密碼是哈希保存,用戶一旦忘記密碼,網站也無法知道原始密碼是什麼,只能讓用戶重置密碼。

第二條規則:找回密碼就是讓用戶重置密碼。

重置密碼又有兩種做法。有的網站先自動改成一個隨機密碼,然後再讓用戶登錄後自己改掉。這樣做的風險在於,你必須把隨機密碼告知用戶,通過郵件或短信,這個過程中就有可能洩漏。

第三條規則:重置密碼的時候,要給出一個鏈接,讓用戶到網頁上自己修改密碼。

重置鏈接由於是明文傳播,而且直接修改密碼,所以必須有失效時間。一般來說,可以設成10分鐘失效。

三、用戶名還是郵件地址?

重置密碼之前,必須知道重置誰的密碼。這時需要用戶提供,註冊時的郵件地址。

第四條規則:重置密碼之前,如果用戶提供了錯誤的郵件地址,不要提示他。

這是因為如果提示了,數據庫不包含某個郵件地址,就可能像下圖那樣,洩露用戶的隱私,被釣魚者利用。

正確的做法是,不管用戶輸入什麼郵箱,都向該郵箱發郵件。在郵件裡說明,有人嘗試重置密碼,但是他輸入的郵箱不在數據庫裡面。

如果不是採用郵件地址,而是根據用戶名識別用戶,就沒有辦法不提示,某個用戶名是否存在。某些人的用戶名非常特殊,一旦知道該用戶名存在,就幾乎可以肯定是該人註冊的。

第五條規則:重置密碼的時候,識別用戶最好依靠郵件地址,而不是用戶名。

四、過濾用戶

為了防止機器人攻擊,進入重置密碼之前,最好加上 CAPTCHA 識別。

此外,還要防止一種情況:張三知道李四的郵箱,然後使用找回密碼功能,讓系統給李四發出重置密碼的郵件。

第六條規則:如果條件允許,重置密碼之前,最好請用戶回答一些個人問題,或者採用 2FA 驗證,比如短信驗證碼。

最後,不要忘了記錄 IP 地址,在郵件裡面告訴用戶,哪個 IP 地址在申請重置你的密碼。

(完)