给文章平台造一个加密后台
上一篇文章里我写了如何用大模型给静态文章平台手搓一个本地发布工具。那个 admin.html 解决了"写文章"和"推到线上"这两件事的麻烦，但仅限于在我这台 Mac 上。出门在外、坐高铁、咖啡馆里，想改一个错字都得回家开机。
我想要的是：任何一台设备打开浏览器，输个密码，就能写文章、改文章、一键发布。
这个想法听起来很 SaaS。但我又不想为它额外起一个服务器、多搭一个数据库、再续一份月费。我的文章平台托管在 GitHub Pages 上，纯静态，不依赖任何后端——这是我从 WordPress 推倒重来时定下的原则，不能为了一个后台破功。
过去这周，AI 帮我把这件事做完了。整个后台就是一个加密的 HTML 文件，它公开放在 hiwd.com 上谁都能下载，但只有我能解开。
1、一开始走了一段错路
第一版很朴素：把 admin 的 HTML 内容用 AES 加密，把密文塞进一个 manage.html，套一层密码锁。访问时输密码就能解开。
看起来挺安全的：密文公开也没事，没有密码就读不出来。我设了一个简单的密码，就把它丢上线了。用了几天，得意。
直到我让 AI 做一次完整的安全审计。它把这个方案撕得稀烂。
核心问题是：密文在 GitHub Pages 上是公开的，攻击者可以把它下载到自己电脑，然后在自己的 GPU 上离线慢慢爆破密码。这种破解不会触发任何登录限制，攻击者有无限时间。我那个简单密码，一秒钟就能被穷举完。更糟的是，我用的加密库默认是"密码 hash 一次就拿来解密"，这跟在线登录服务标准的"hash 几十万次"差了上百万倍。
这是个典型的"看着加密，其实没加密"的方案。
2、推倒重来
我和 AI 重新设计了一遍。这一次，每个决策都先问一句"如果攻击者把这个文件下载走了，能干什么？"
密钥派生从默认的 1 次迭代提到 600,000 次（这是 OWASP 2023 的推荐值）。意思是攻击者每试一个密码，都要 GPU 算几秒钟。原来的"一秒爆破完所有密码"，变成"一万年算不完"。
加密算法换成 AES-GCM 256，它自带认证标签——密码错的话解密会直接抛异常，不会泄漏任何"是不是接近答案"的特征。原来的版本还有一个判断"解密结果是否包含 DOCTYPE"，那是给攻击者的明确信号，删掉。
密码本身换成 16 位随机字符，存进 macOS 钥匙串。配合上面的 600k 迭代，理论上整个银河系所有计算机一起算到宇宙热寂也破不了。
文件名加了 8 位随机后缀，从 manage.html 变成 manage-4dfaf82d.html。这不是"安全"，是"隐蔽"——不让爬虫顺手扫到，多挡一层好奇路人。成本几乎为零，收益可观。
3、token 怎么交给浏览器
真正麻烦的是 GitHub Token。每次发布都要调用 GitHub API，所以浏览器里必须有个 token。但 token 怎么进来？
方案 A：用户每次输一遍。安全但烦。
方案 B：把 token 也一起加密在 manage 里，密码解开就拿到。方便但风险高——密码若破，仓库失守。
我选了 B，但前提是密码足够强（见上一节）。这是权衡，不是免费的。
但问题来了：怎么把 token 安全地塞进密文？我不想让任何人——包括帮我写代码的 AI——经手这个 token。
解决办法是写一个独立的工具页 build-cipher.html。它本身在 .gitignore 里，永远不会上线。我在自己的浏览器里打开它，输入密码、token，加载 admin 模板，它在我本地完成加密，下载一个新的 manage-XXXXXXXX.html 给我。整个过程，token 不离开我电脑。
这个设计让我很满意。它把"敏感信息处理"这件事彻底本地化，工具本身也是一个 HTML 文件——和这个文章平台的风格一致。
4、最终的工作流
现在它跑起来是这样：
在任何设备上，浏览器打开那个加密 URL。输入密码，等 1-2 秒（PBKDF2 算密钥要这么久，这是安全的代价）。
进入 admin 界面：写新文章、改老文章、改 words，都和我那台 Mac 上的体验一致。
点"一键发布到 GitHub"。后台调用 GitHub API，提交文件，触发 Pages 重新部署。1-2 分钟后，hiwd.com 上线。
解锁后 24 小时内，浏览器记住一个派生密钥（不是密码本身，密码学上不可逆推），免输密码。第二天再访问就要重新输。
整个链路：零服务器、零依赖、零月费。
5、写到这里的感想
独立文章平台有一种"原教旨"倾向——纯文本、纯 HTML、不搞花活。我也是这个流派的。但这一次的折腾让我意识到，"极简"不等于"原始"，它是有结构的。
我没有引入服务器、数据库、CMS 框架、用户系统。我只是写了几个 HTML 文件，一个负责锁屏解密，一个负责编辑发布，一个负责本地构建。每个文件做一件事，都不超过两千行代码。
它们彼此协作，最终给了我一个"任何设备都能用、自主可控、安全的"文章后台。在这个连文章都被各种平台收编的年代，能在自己仓库里跑通这套，挺有意思的。
第一版那个不安全的方案我也不后悔。如果不是先做了一个错的，我也没机会去理解 PBKDF2 迭代次数到底意味着什么、AES-GCM 的认证标签为什么重要、攻击模型该怎么建立。AI 在这个过程里既是协作者，也是审计者——这个双重角色挺关键的，自己一个人闷头写代码很难发现自己的盲区。
下一步可能会加图片上传，或者把 words 同步做得更自动。但目前这个版本已经够用了。能在 iPad 上写一篇文章直接发布，对我来说就是一个完整的循环。
Andrew, May 2026