逐步停止 Google Sync 和“低安全性应用”支持

原文 ↗ Hacker News 讨论 ↗

Google 正在为 Workspace 账户退役 Google Sync 和“低安全性应用”的密码访问，推动组织转向基于 OAuth 的认证，或使用应用专用密码访问 IMAP、POP 和 SMTP。评论者既欢迎这种对抗凭据填充和钓鱼的更强保护，也担心会破坏旧客户端、打印机和脚本，担心 OAuth 对小项目过于复杂且成本高，并认为这会进一步推动用户使用 Google 自家应用并加深生态锁定。许多人把应用密码和第三方邮件服务商视为实际可行的替代方案，同时质疑 Google 会让这些替代方案维持多久。

变更范围

  • 许多人指出 HN 标题具有误导性：Google 关闭的是 Workspace 的“低安全性应用”（用户名 + 主密码）和 Google Sync（ActiveSync），而不是 IMAP/SMTP/POP 本身。
  • 应用专用密码和 OAuth 仍受支持；几位用户确认 Workspace 支持明确表示，应用密码可用于 IMAP、POP 和 SMTP。
  • 个人 Gmail 更早就已经失去 LSAs；这次是对 Workspace 的收尾。

应用密码和旧设备

  • 大量担忧来自打印机、扫描仪和旧客户端（例如 Outlook 2007、通过 Exchange 的 iOS Mail）。
  • 线程共识是：这些设备仍可通过应用密码，或在某些情况下通过 SMTP 中继继续工作。
  • 一些管理员表示应用密码运行稳定；另一些则觉得它们令人困惑或不可靠，并担心普通用户/IT 会难以应对。

OAuth 的复杂性和摩擦

  • 许多人抱怨 OAuth2 令人困惑、不透明且容易出错，尤其对于无头服务器和脚本。
  • 提到的问题包括：错误信息不清晰、令牌行为变化、刷新令牌的怪癖，以及 Google 对获得经过验证的生产客户端所设的很高门槛（以及成本）。
  • 文中提到了一些工具和变通方案（OAuth 代理、CLI 辅助工具、rclone 等），但它们通常需要手动设置 OAuth 客户端。

安全论点与密码强度

  • 支持变更的一方认为：LSAs 会助长凭据填充，而且没有 2FA；OAuth 和应用密码能缩小影响范围并降低钓鱼风险。
  • 另一些人则认为，强且唯一的密码 + TLS + 可选 2FA 已经足够，称这只是“安全表演”，而且对用户不友好。
  • 关于应用密码熵的争论（16 个随机小写字符）。多数人得出的结论是 65–75 位已经绰绰有余，尤其是在有在线速率限制的情况下。

锁定、体验与竞争担忧

  • 一些人认为这是在推动用户放弃第三方客户端，转而使用 Gmail 应用，尤其是在 iOS Mail 失去 Exchange 推送，以及 Google 抵制 JMAP 等协议的背景下。
  • 一些机构已经限制使用带 Exchange/O365 的 IMAP，这加剧了人们对更广泛地转向专有生态系统的担忧。
  • 许多用户讨论或推荐替代方案（自托管、Fastmail、Proton、Tuta），理由是互操作性更好或垃圾邮件处理更好。

不确定性

  • 应用密码的未来被视为不稳定：Google 文档不鼓励使用它们，而且一些组织报告曾收到过此前的弃用警告。
  • 通过应用密码实现的非 OAuth IMAP/SMTP 的长期支持程度被看作是“目前如此”，并非有保证。