安全指南
密码、MFA、设备、公共 Wi-Fi、服务器、依赖、Git、暴露在外的环境——围绕目标展开的实操指南，让你今天就能动手加固。
如何安全存储密码 —— 哈希与加盐的正确做法
面向服务端的密码安全存储实战指南。先理解明文、加密、裸哈希为什么都不行，再收敛到『为每个用户加盐＋故意放慢的专用哈希（首选 Argon2id，其次 bcrypt/scrypt）』。不要自己造轮子，直接用标准函数；成本参数要定期复核；既有的弱哈希在用户登录时重新哈希以完成迁移。
AI 时代的安全防护｜个人开发者现在就该夯实的基本功（按优先级排序的清单）
AI 强化的不是『新弱点』，而是『自动、大规模地利用既有弱点』那一侧。所以比起特别的新对策，按正确的顺序夯实基本功才是最好的准备。CVE 立即打补丁＋依赖监控、杜绝复用＋MFA、清除暴露的机密、最小权限、收缩公开面、日志/IOC 的准备、备份——全都用一份按优先级排序的清单讲清楚。
AI 时代真正有效的安全对策与「无效」的那些｜小站为何也会被盯上
纠正 AI 时代的 4 个神话。①太小不会被盯上→自动化抹掉了『人来挑目标』这一步②需要特别的新对策→基本功才最强③装个产品就安心→比起检测，先做到『不让它发生』的设计④AI 生成代码又快又安全→连漏洞一起出货、上线前必须复查。真正有效的，是按正确顺序把不起眼的基本功做扎实。
收到了『冒充自己域名』的邮件——它和被入侵的区别，以及如何止住
即使收到自称来自自己域名的可疑邮件，多数也不是『服务器被入侵』，而是『发件人(From)被伪造』。因为 SMTP 允许任意填写 From。读懂邮件头里的 Authentication-Results、Received、Reply-To，就能分辨是入侵还是冒充。它能进到收件箱的主因是没有配置 DMARC。用 SPF→DKIM→DMARC(p=none→reject) 的分阶段引入来止住它。
备份基础：3-2-1 规则与抵御 ransomware 的恢复计划
备份只是「有做」还不够，只有「已确认可以恢复」才算数。基础＝3-2-1 规则（3 份副本、2 种介质、1 份异地）。要防 ransomware，还需要至少 1 份不是长期连接的「离线/不可变（immutable）」副本——长期连着的备份会连同本体一起被加密。云同步不是备份（误删和加密也会被同步）。多版本管理和定期恢复测试才算完整的运维。
用 gitleaks 在提交前拦下密钥：在 push 之前堵住 API 密钥泄露
密钥『泄露后再删』就晚了。一旦被提交，密钥就会留在 Git 历史里，被 push 后就要按已泄露处理、吊销并轮换密钥。gitleaks 是一款免费工具，用正则/熵对整个仓库和提交历史进行扫描，检出 API 密钥、私钥、token。防守的关键是两道拦截点＝①用 pre-commit 钩子在本地 push 前拦住②用 CI/cron 定期抓住漏网之鱼。.gitignore 只能阻止新的追踪、无法检出＝还需要单独的检测器。
双因素认证(MFA)如何正确选择：比 SMS 更强的「抗钓鱼」是什么
MFA 是『即使密码泄露也进不来』的双重锁，但你配了什么会让强度差三档。SMS／邮件会被钓鱼中继、SIM 交换攻破，属于弱方式；验证器 App(TOTP)居中；passkey／物理密钥(FIDO2)因为『无法对假站点出示』的抗钓鱼特性而属另一档。最优先的是给王国之钥（邮箱、域名、支付）配上抗钓鱼 MFA。再加上妥善保管恢复码、准备好备用手段，才算正确的运维。
还在用 Windows 10 的人请注意：支持终止后的安全风险
Windows 10 已于 2025 年 10 月 14 日终止支持。继续使用的最大风险是『被发现却永远不再修复的漏洞（forever-day）』不断堆积，从而更容易被攻击者盯上。面向个人的 ESU 延长只到 2026 年 10 月 13 日的一年、且只有安全修复的拖延手段（有免费的登记途径，但 EEA 首年免费不包含日本）。正路是迁移到 Windows 11 或更新设备，ESU 只作为完成迁移之前的『桥』来用。
BitLocker 与「设备加密」的区别 —— 同一技术的完整版与自动·简易版
BitLocker 和设备加密用的是同一套加密引擎。设备加密＝Home 也能用的自动·简易版（用微软账户自动开启、恢复密钥也自动备份、设置项极少）。BitLocker＝Pro 及以上的完整版（启动 PIN、外接加密(To Go)、精细管理）。对个人而言，做到自动加密＋知道恢复密钥在哪，往往就够了。比起产品名，『处于已加密状态』才是本质。
漏洞（CVE）处置实务：彻底修复，并持续监控复发
漏洞处置不是『修了』就完事。完成＝①扫描②修复③隔离/移交④监控四点齐备才算数。尤其在加上监控（每日变化检测）之前都算未完成——因为依赖明天又可能变得脆弱。修复内容哪怕100分，只要下一次部署就被覆盖，也等于0分。越是小团队，越能靠自动变化检测和『local→push→deploy』的纪律守得出奇地稳。
携带笔记本电脑外出时的安全防护 — 应对失窃、丢失与窥屏
携带笔记本外出的前提是『总有一天会丢、会被偷』。重点在于“即使丢了内容也不泄露”的设计＝①磁盘加密(BitLocker/FileVault) ②强登录+短自动锁定 ③远程擦除/位置追踪。随着HTTPS普及，公共Wi-Fi被窃听的风险下降，真正的威胁是伪AP、窥屏、离座。不要过度依赖VPN，优先做好加密与锁定。
osv-scanner 的安装与使用：用机器找出依赖包里的 CVE
osv-scanner 是一款免费工具，扫描锁文件或容器以排查依赖中的 CVE。本文把安装、运行、CI 集成做成步骤，并理清它与 npm/pnpm audit、Dependabot 的取舍。本站的观点＝选工具的正确答案由『你的架构』决定。多语言混用或不依赖 GitHub 就用 osv-scanner，单一 npm 用自带的 pnpm audit 就够了。
密码管理器安全吗？工作原理与云端、本地的区别，以及如何选择
密码管理器比重复使用、明文保存更确实地安全。关键在于零知识加密＝凭主密码只有端侧能解密，提供方只持有密文，所以提供方被攻破内容也不会泄露。真正的单点故障是主密码和金库的 MFA。云端型(Bitwarden/1Password)与本地型(KeePass)按用途选择。
公共Wi-Fi的危险 — 真正可怕的不是『窃听』，而是连上假AP和无视证书警告
公共Wi-Fi的『窃听』在HTTPS普及后大多已被加密，优先级下降。真正的风险是：①自己主动连上假AP（evil twin）②无视证书警告③把设备暴露在同一网络里。最强的对策出乎意料地简单＝用手机热点、相信HTTPS和证书警告、不自动连接陌生SSID。VPN是其次的追加手段。
是否把密钥文件遗忘在了公开目录里：webroot 盘点
放进 webroot（公开目录）的文件，只要访问 URL 任何人都能取走。令牌或认证凭据的 JSON、.env、备份一旦遗忘在那里，立刻造成实害。再加上若源自共用模板，同一个洞会横向扩散到所有站点。对策＝公开目录只放可以公开的东西，密钥放在 webroot 之外＋权限 600，并且盘点自己的服务器、一处发现就全机排查。
个人开发 / 小规模运营的安全底线：把行业标准的对策一次配齐
最低限度的对策并非『全都一样重』。本站的优先级 ＝ ①王国之钥（多因素认证 / 域名 / 邮箱）②密钥与代码 ③应用本体 ④补丁 / 检测 / 恢复。资源有限的个人，按这个顺序从上往下填才是正解。多数事故并非新型攻击，而是这块地基的缺口造成的。
中型到大型组织的安全底线：团队共同守护的标准基础
规模上来后，底线会从『检查清单』变成『有负责人的项目』。优先级与个人版一致＝①身份②机密与供应链③应用与基础设施④检测与响应＋贯穿全局的人与治理。最大的变化是：事故主因从『一时疏忽』转向『人、流程、离职者权限、第三方』。
安全资产盘点 —— 个人运维多台服务器时最易忽略的 7 项检查
个人运维多台服务器的事故，往往源于「没掌握的状态」而非「缺少防护」。要守的边界是放置密钥的电脑。2FA 按信任链分级，SSH 密钥矩阵化以清除重复・未使用・孤儿，明文密码从云端清除，整改要可逆且逐项进行，台账里不写机密。比起花哨的新工具，盘点更优先。
自建 Git 服务器和 GitHub，从安全角度看哪个更安全
自建 Git 不是『变安全』，而是『转移风险』。误公开这一类事故确实会消失，但服务器补丁、备份、提交前密钥检测的责任会转移到你身上。满足条件就是好选择，放任不管则比 GitHub 更危险。本站视角＝自建运营必须连同代价一起，否则无法成立。
安全使用手机的基础 —— 要守护的是把『钥匙串、保险箱、身份证』装进一台设备的终端
手机是把二要素、邮件、银行、身份证集中到一台设备上的单点故障。防守的重点不是安全 app，而是①强锁屏＋短自动锁屏（密码就是加密的钥匙）②OS／app 自动更新 ③官方商店＋权限复查 ④事先设好丢失时的远程锁定／擦除 ⑤二要素的“备份”（纸质备份码）。OS 默认已做加密与沙箱隔离。
不要把 root 密钥交给可能被入侵的环境：SSH 密钥的最小权限
从临时且可能被入侵的环境（GPU pod、CI runner、一次性 VM）向生产登记 root 密钥，那个环境一旦被入侵，生产就会连带被人以 root 权限抽走。对策＝不在临时环境放 root 密钥／不用了就删掉／再次需要时用非 root 用户＋command 限制密钥（command=「...」 restrict）把操作限定为一个。复用密钥是最重要资产，别搭出『漏一把就全完』的结构。
把密码存到 Google Drive 安全吗？正确的保管方法
把密码以明文形式集中保存在 Google 文档/电子表格里很危险。原因＝一个 Google 账号会成为全部密码的单点故障，账号被盗、恶意关联应用、钓鱼都能让全部密码一次性泄露。正确答案是专用密码管理器（即使在设备间同步，内容也保持加密）。如果非要用 Drive，那只能放加密过的管理文件＋为账号开启抗钓鱼的 MFA。
OpenAI 账户被封的原因与应对——被盗的 API key 为何会被判定为「蒸馏」违规
被盗的 API key 一旦被用于『蒸馏』滥用，连受害者的账户都可能被自动冻结。本文隐去具体个案信息，梳理其机制、预防与申诉路径。
X-Forwarded-For（XFF）伪造是什么 — 信任代理配置的陷阱与防御
XFF 是客户端可以伪造的头。在伪造 XFF 里夹带注入探测的无差别扫描是典型手法，而『信任全部代理（通配符）』很危险。对症处理＝对 IP 头做净化，根本＝把信任代理收敛到合适范围。即便没有实际损害，也有该修复的配置。
用 AI 写的代码泄露了 API key，被人盗刷——真正的祸根是放着不管的 CVSS 10.0
账单暴涨只是冰山一角。真正的祸根是放任不管、公开已久的 CVSS 10.0 RCE。本文从隐去专有名词的案例中，提炼出防御的教训。
安全超入门：.env 和 API key 到底危险在哪、又该怎么守
第一步。先理解 .env 和 API key 泄露后会发生什么（配出来的钥匙→冒名顶替→被盗刷），再从今天起做好这 4 件事：『不公开、不提交、泄露就全部更换、定期自查』。
Laravel 应用的 .env 被暴露给全世界——共享虚拟主机上最常见的部署错误
根本原因是『把应用本体放到了 public_html 目录正下方』。本该只暴露 public/。按应急处置→密钥轮换→结构改造三个阶段修复，并用机制防止再次发生。
安全运维 Next.js：建立不在已公开CVE上掉队的机制
框架的最大风险是放任已公开的CVE。以生产实际版本判定，用 Dependabot/osv-scanner 做机器监控，迅速更新，并以最小权限防守，构成四根支柱。本站的视角＝个人开发者输掉的不是知识，而是『运维的可持续性』。靠不漏看的机制取胜，而非速度。
在虚拟主机上避免 .env 被公开的目录布局与配置
核心是『把应用主体放在 docroot 之外，只公开 public/』。先用 .htaccess 止血，再做结构改造实现长期防护，最后自我检查。本站的视角＝这不是个人的疏忽，而是行业层面把『坏做法标准化』了。所以要靠机制而不是靠注意力来防御。bootstrap-redirect 比 symlink 更牢靠。