Twitter的双因素验证系统：更安全但却不一定更好

就在本周早些时候，Twiiter公布了自家最新双因素身份认证系统。通常情况下，每当听说这类系统时，我总是好奇他们是否会使用基于时间的一次性密码算法（简称TOMP）。

TOMP目前已经被多家企业奉为标准化方案，其中包括Amazon、Dropbox、Linode、Evernote以及微软。使用这套算法的重要作用在于，大家所有的安全令牌机制都可被囊括于同一款应用程序当中。不过Twitter决定放弃这套方案；事实上，他们表示自己开发的安全机制效果更为理想。

事实的确如此。

简而言之，Twitter利用公钥/私钥加密为设备创建一套密钥对，同时通知Twitter的服务器当前公钥设置的具体内容。秘密的私钥永远不会被公开，并与由公钥验证的签名一道用于标记由设备发出的请求。
这套系统的出色之处在于，即使Twitter的服务器被攻陷，攻击者也只能获取到一大堆公钥。缺少私钥的配合，犯罪分子将无法冒充用户进行操作。

但这套方案的定制特性意味着任何使用双因素认证机制的用户都必须首先安装Twitter应用程序。为了鼓励人们积极使用其应用，Twitter仅将API调用权限提供给少数开发人员用于编写自己的平台，这相当于以“爱用用、不用滚”的恶劣态度摆了用户一道。此举实际上相当于强迫用户只使用Twitter提供的社交服务。
不过就我目前观察到的结果，开发人员对Twitter提出的方案并不买账——事实上，眼下还没有哪家第三方客户端厂商能顺利接手这套新型验证机制。由于不想安装根本用不上的应用客户端，用户本身也选择了离开或者压根不理这套双因素验证方案。当然，Twitter的如意算盘也许是希望能借此挤垮与自己竞争的第三方客户端。

即使Twitter真的遭遇安全违规，他们也更可能直接重置密钥对而非以审慎的态度处理问题。这种简单粗暴的方式与我们经常听说的Hash及Salt密码被盗状况非常相似，对于密码保护而言并无益处。在这样的背景下，就算是双因素安全机制也会变得于事无补。

如果要对上述争论做个总结，那么一切都应该被归结到保持一致性方面。尽管Twitter的一键式系统确实相当便捷，用户能够在使用多种安全令牌系统的同时继续在不同客户端中保持一致的使用体验；然而如果大家对于安全问题的关注已经严谨到开始使用双因素认证机制，那么对基于TOMP的安全系统也应该完全能够应付得来。

所谓安全性，其核心在于对风险进行管理，而只有合理的保护强度（既不过弱也不必过强）才能真正实现安全效果。我们不可能为了小概率事件而在入睡时把移动设备放在防爆掩体当中。Twitter带来的双因素系统到底是不是更安全？没错。但我们真的有必要花这么大力气为每位普通用户降低安全风险吗？答案显然是否定的。

还有很多其它能帮助大家制定安全决策的服务企业可供选择，如果他们掌握的信息足够全面——例如了解我们如何使用自己的设备、习惯于将哪些数据保存在其中以及这部分数据的实际价值——就会发现每个人对安全性的需求都不一样。不少用户也正是出于这样的考虑才会使用非常愚蠢的密码内容。

Twitter的所作所为给我留下了深刻印象——一套更加封闭的专有系统，巧妙地在宣传安全卖点的同时给了开发人员一记狠狠的耳光。出发点的正确并不能扭曲现实，这种危害开发人员利益的做法完全不能接受。
很多用户对目前Twitter所采用的基于TOMP系统的安全机制表示满意，即使其实际安全效果相对较差。我们根本找不到足够的理由来替代现有方案。与密码这种油尽灯枯、必须迎来替代方案的机制不同，目前我们还看不到强行推广双因素验证的必要性与合理性。

在理想状态下，我们也许应该同时拥有两套方案可供选择；一者关注安全性而在便捷性方面做出妥协、另一者则强调便捷性而采取相对较弱的保护机制。不过商家显然还没有做好为用户量身定制安全方案的准备。