文件传输服务的密码保护功能评测
评测各文件传输服务的密码保护功能,对比强度要求、加密集成和用户体验。
各文件传输服务的密码保护，从表面装饰到真正加密集成，实现方式差异显著。WeTransfer Pro 添加了密码门控，在服务器端校验后才允许下载，但文件仍可被 WeTransfer 本身解密。Smash、SwissTransfer 和 Dropbox Transfer 采用类似模型。而 Tresorit Send 和 HexaTransfer 则将密码（或其派生密钥）作为实际文件加密的输入，通过 PBKDF2 或 Argon2id 处理——不知道密码，密文在数学上无法读取，即便是服务提供商也无能为力。
服务器端门控与密码学密钥的本质区别
关键区别在于密码在哪里被验证。服务器端门控模式下，服务商存储密码哈希（理想情况下使用 bcrypt 或 Argon2），验证输入值后再提供文件。文件本身用服务商持有的密钥加密。若攻击者入侵数据库或法院强制要求，文件无论密码强弱都会以明文形式被获取。
密码学密钥模式下，密码经过密钥派生函数（KDF）处理——通常是迭代次数达60万次以上的 PBKDF2，或经过内存代价调优的 Argon2id——生成实际的文件加密密钥。没有密码就没有密钥，没有密钥就没有明文。服务商在物理上无法解密文件，即便接到法院传唤也无法做到。
WeTransfer Pro：便捷的门控，而非加密
WeTransfer 在 Pro 计划（约每月10欧元）中引入密码保护。上传时设置密码，通过其他渠道告知收件人，收件人在下载页面输入密码。底层实现是哈希比对——文件用 AWS KMS 管理的密钥进行 AES-256 静态加密，与用户密码无关。
这种设计足以防止链接被随意转发，但不满足不信任 WeTransfer 本身或其托管服务商的威胁模型。此外，若没有速率限制，还容易遭受在线暴力破解（WeTransfer 未公开其速率限制策略）。
Smash：密码加邮件验证双重校验
Smash 在所有付费计划中提供密码保护，并结合可选的收件人邮件验证功能。你可以要求收件人既要证明对特定邮箱的所有权（通过魔法链接），又要输入密码。这有效抵御了"转发链接加拦截密码"的常见攻击手法。
密码仍然是服务器端门控，而非派生输入，但这种双因素组合（你知道的加你能访问的）大幅提高了门槛。对于向特定方发送合同的场景，是实用性与安全性之间合理的折中。
SwissTransfer：简单可选的密码
SwissTransfer 的密码字段可选，以服务器端方式实现。服务免费，无需注册，完全托管在瑞士 Infomaniak 基础设施上。密码能防止链接被随意分享，不改变底层加密机制（文件以 AES-256 静态加密，密钥由服务商管理）。
用户体验简洁：一个复选框，一个密码字段，一个确认。没有密码强度提示，没有最低复杂度要求——输入"123"也会被接受，密码的强度完全取决于发件人的自觉性。
Dropbox Transfer：支持管理员策略的密码
Dropbox Transfer Standard 及以上版本支持管理员可配置最低复杂度的密码。团队管理员可强制要求至少8位字符、大小写混合、包含数字和符号。密码校验在服务器端完成，之后 Dropbox 从美国或欧盟区域流式传输文件。Dropbox Business 支持 SAML SSO 集成，以身份验证访问替代密码流程。
企业层面的价值在于审计日志：每次密码尝试均被记录，包括可能表明凭证填充攻击的失败尝试。对于 SOC 2 和 ISO 27001 取证，这条审计追踪至关重要。
Tresorit Send：密码派生加密密钥
Tresorit Send 采用密码学方案。设置密码时，Tresorit 通过 PBKDF2 在已加密文件之上再叠加一层额外加密。没有密码，文件就无法解密，即便是 Tresorit 本身也无法做到。公司总部位于瑞士，持有 ISO 27001 认证，并公开发布密码学白皮书。
用户可见的体验与 WeTransfer 类似：设置密码，分享出去。但底层数学完全不同。Tresorit 数据库泄露只会暴露密文和盐值，而非可还原的文件内容。
HexaTransfer：URL 片段密钥与可选密码封装
HexaTransfer 的基础模型将256位随机密钥嵌入 URL 片段（# 之后），浏览器永远不会将片段部分发送至服务器。该密钥在下载后于客户端解密 AES-256-GCM 密文。添加密码时，PBKDF2 以60万次迭代对随机密钥进行封装，必须提供密码才能解开并使用该密钥。
这种分层设计意味着解密需要三个要素同时具备：密文（来自服务器）、URL 片段（来自链接）以及密码（来自带外渠道）。单独截获其中任何一个都毫无用处。这一模型最初由 Firefox Send 探索，并经过现代注重隐私的服务持续优化。
功能对比矩阵
| 服务 | 密码类型 | KDF | 最低强度要求 | 速率限制 | |------|---------|-----|------------|---------| | WeTransfer Pro | 服务器端门控 | 无 | 无强制要求 | 未公开 | | Smash | 服务器端门控+邮件验证 | 无 | 可选策略 | 有 | | SwissTransfer | 服务器端门控 | 无 | 无强制要求 | 有 | | Dropbox Transfer | 服务器端门控+SSO | 无 | 管理员可配置 | 有 | | Tresorit Send | 密码学KDF | PBKDF2 | 8位以上 | 有 | | HexaTransfer | 密码学KDF | PBKDF2 60万次 | 强制要求 | 有 |
密码强度与熵值问题
文件传输的"强密码"应至少达到70位熵——从大型词典中随机选取四个词（Diceware 风格），或12位以上随机字符。60万次迭代的 PBKDF2 对离线攻击额外增加约20位有效熵，使中等强度密码真正难以破解。
薄弱环节通常在于传递方式。将密码通过短信发送至与链接相同的手机号，会让整个保护形同虚设。应使用独立渠道：通过 Signal 发送链接，通过电话告知密码，反之亦可。B2B 传输场景中，建议在现有视频通话中协商密码，而非新建渠道。
密码保护不够用的场景
对于真正敏感的传输——金融并购文件、源代码、医疗记录——应考虑将密码保护与收件人邮件验证、短有效期（24小时）和下载通知结合使用。更好的方案是使用支持魔法链接或 SSO 原生收件人身份验证的服务。
密码保护是有用的额外防线，而非完整的访问控制体系。配合符合你威胁模型的其他控制措施使用，不要以为字段上有密码就意味着服务商无法读取你的文件——通常它依然可以。
在 hexatransfer.com 上试试 — 免费、无需注册、最多 10 GB。