保护好自己的数字资产,我的方法你也可以试试
2021-09-17 12:30:53 Author: sspai.com(查看原文) 阅读量:77 收藏

Matrix 首页推荐

Matrix 是少数派的写作社区,我们主张分享真实的产品体验,有实用价值的经验与思考。我们会不定期挑选 Matrix 最优质的文章,展示来自用户的最真实的体验和观点。

文章代表作者个人观点,少数派仅对标题和排版略作修改。


在如今的世界里,我们的生活重心越来越向数字世界中转移,我们每天要花那么多时间在各类电子设备上,这些设备本身没有那么吸引人,重要的是其作为网络和互联网的终端。我们的目光穿透屏幕之后,看到的是无时无刻不在壮大和发展的数字世界。而在这个世界中通行的唯一认证方式,是账号与密码。

但当世界发展成现在这样,人们偏好线上办理业务而不是线下办理;手机号实名制使得大部分公司的业务基于手机验证码来进行认证;所有的企业都想涉足金融行业,每个应用点开「我的」里都有一个「钱包」,「钱包」里最显眼的位置一定被「借钱」业务所占据,副标题则是「20 万」,以及一个字体更小的注释:「大约可借」。而为了相互竞争,企业将这个借钱的门槛和认证需求一降再降,这就为一些违法犯罪行为提供了机会。

这个机会基于这样一个现实:手机号因为成了数字世界的实际身份认证方式而变得极为重要,而大部分人没有意识到它有多重要。一个简单(且实际发生过)的例子是这样的:傍晚你的手机被偷,由于到了营业厅的下班时间,你只能等第二天去补办 SIM 卡,而犯罪分子取下你手机中的 SIM 卡,插在另一台手机上,就可以用来接收验证码。因为一些数据库的泄露,他们能从中查到这个手机号所有者的姓名、身份证、银行卡号等隐私信息,用这些信息和验证码,他们能够在各类金融服务中进行借款,这些借款会先转进你的银行卡,然后用来购买各种难以追踪路径的虚拟物品(在这个过程中,你有所察觉,并及时冻结了信用卡和常用的储蓄卡,这阻止了更大损失的发生,但对于各种借款行为仍然无能为力)。

当然,这起事件发生以后,其中的薄弱环节已经得到了加强,各类借钱操作也得到了撤销和赔付,但是没有人能够保证不会有其它的漏洞出现。归根结底,仍然是由于手机号码实际上的重要性和用户对这种重要性缺少认知引起的。

最重要的保障:手机号 PIN 码

对于手机号的保护,最好的方式就是开启 PIN 码。开启 PIN 码后,每次手机开机(或取下 SIM 卡插进别的手机)后,都需要输入这个 PIN 码才能解锁 SIM 卡,在此之前,SIM 卡不会接收任何信号。这种方式能够有效地防止「取出 SIM 卡在别的手机里接收验证码」这类事情的发生。

PIN 码(以及 PUK 码)通常能够在购买手机卡时的大卡(类似银行卡大小)的背面看到,默认的 SIM 卡的 PIN 码因运营商不同而有所不同,但通常为 1234 或 0000 这类密码,很容易被验证出来,无法进行有效保护,所以开启 PIN 码时,请记得进行修改。同时,为了安全起见,在修改前,请确保你能够获取 SIM 卡的 PUK 码,你可以在卡背或者运营商的应用中查询,或者打电话给运营商客服来获取(这显然又是一个安全上的漏洞)。如果在解锁 SIM 卡时,输入了 3 次错误的 PIN 码(这个次数限制无法通过重启手机来重置),就需要使用 PUK 码来解锁并设置新的 PIN 码,PIN 码可以被修改,而 PUK 码与 SIM 卡绑定,无法被修改。另外,通常的机制是,如果 PUK 码输入错误十次,就会触发 SIM 卡的安全机制,会导致芯片产生物理性的损坏,这时候只能去营业厅进行补卡。

 使用情境功能最多错误次数超出次数后果是否可更改
PIN 码重启手机或放入 SIM 卡时解锁 SIM 卡开始接收信号3 次需要使用 PUK 码解锁
PUK 码多次输入错误 PIN 码时重设 PIN 码10 次SIM 卡物理性损坏

所以,在开启和修改 PIN 码之前,请确保以下几点:

  1. 知道原来的 PIN 码和 PUK 码
  2. 记住修改后的 PIN 码
  3. 将 PUK 码进行安全留存
  4. 发现现有的 PUK 码无法解锁时,请勿进行重复尝试,而是前往营业厅进行解锁

PIN 码的初始长度通常为 4 位,但最长可以设置为 8 位。iPhone 可以在「设置 - 蜂窝网络 - SIM 卡 PIN 码」中开启和修改 PIN 码,而安卓手机取决于品牌和系统而有所不同,但通常可以在「设置」中的「安全」相关选项中找到。

设置了 PIN 码后造成的不便是,每次重启手机之后,都需要输入 PIN 码才能使用 SIM 卡。这是一个常用密码,但相比较于能不能记住来说,其安全性更加重要。所以我将这个密码存在密码管理器中,SIM 卡被锁定并不影响手机的功能,所以开机之后可以直接在密码管理器中复制 PIN 码来解锁 SIM 卡,现在的手机使用上已经没有了重启手机的习惯和必要了,所以这点不便是完全可以接受的。

上面提到,通过打电话给运营商客服可以得知 PUK 码,即使这算不上一种漏洞,也通常是薄弱的一环,容易遭到利用。根据我的了解,目前为止,当使用其它手机号拨打运营商客服索要另一个手机号的 PUK 码时,客服进行简单的一些资料验证之后,就会给出你的 PUK 码,通常为姓名,身份证号,手机号;而如果是拨打电话的手机号,则通常不需要任何资料验证(不同地区甚至不同的客服,要求可能都会有所差异,可能会更严格,也有可能会更宽松)。

我们无法对前一种情况进行任何防范,因为这些资料通常可能因为订票、住宿和金融行业的企业数据库漏洞而被泄露,当然,这种情况也需要先知道手机号,而手机被偷后通常会被第一时间关机,再次开机时,如果启用了 PIN 码,就无法通过任何形式获取手机号(一种未经证实的说法是,因为运营商的数据泄露,有些 SIM 卡可以通过卡上的一串数字编码查询到手机号)。而针对后一种情况,建议关闭「锁定时使用语音助手」和「通知预览」功能。因为(未关闭时)语音助手可以直接在锁屏状态下拨打电话,而即使客服下发 PUK 码时,通过短信发送这种更安全的方式,也会在锁屏界面直接展示出来。这两个设置同样有助于降低手机丢失时的潜在风险。

其它一些可能的漏洞包括借助一些系统和应用提供的短信云同步功能,如果此功能依赖的账号和密码泄露,造成损失时你甚至很难排查出这个问题。另一种情况是对于基于 2G 的 GSM 嗅探和劫持,这种情况与短信云同步的后果类似,所有短信会被犯罪分子所同步接收,一些建议(包括运营商给出的建议)是开启手机的 VoLTE 功能,不过目前仍然在使用 2G GSM 网络的只有中国移动(联通 2G 退网正在进行中,电信的 2G 使用的是不同的标准)。

PUK 码和初始 PIN 码通常也可以在运营商的 app 中看到,这点的问题倒不是太大,因为需要先解锁手机。而假如你手机中安装了运营商 app,但设置了一个简单的密码(为了在戴口罩无法使用面部识别解锁时更方便),又经常在公共场合输入密码,就会导致额外的风险。因为如果解锁密码泄露,就可以用解锁密码来解锁手机,然后在运营商 app 中查询到 PUK 码来重置 PIN 码。

所以,如果你的 PIN 码或 PUK 码存在手机中,那么要更好的保护手机号,需要为手机设置一个强设备密码

但在谈论设备密码之前,先来谈一谈另一个需要借助设备密码保护的功能——iCloud 账号。

对隐私的保护:iCloud+ 的「隐藏邮件地址」

即使你我对于隐私的看法也许不一致,但因为隐私泄露而导致损失的可能性是我们都要面对的问题。我们的姓名,身份证号,手机号等信息存在于各类企业的数据库中,外卖和购物网站则还会有地址这类信息留存。这些企业的信息泄露情况屡次发生,每次发生都会让社工库中的信息更加详细,而黑客和犯罪行为非常大一部分依赖社工库中的数据。

处在这个疫情时代,这些信息更是需要在任何地方被提供和记录,尽管这个系统的设计目的是为了更好的防控疫情,但设计得再完美的系统也是由人来执行的,在这种大规模和高频次的信息收集传递过程中,难免会有信息泄露情况,不论是有意的还是无意的。当然,相比较于疫情肆虐的局面来说,信息泄露是一种更加轻微的问题。但这个问题也许也没有我们想象得那么轻微,身份证号与个人绑定,而且无法更改,一旦泄露,就说明你永远会面临由此引发损失的可能性,而对于大部分人来说,手机号也并不会经常进行更改,所以一旦有了新的基于身份证号和手机号的漏洞出现,风险就会无法逃避地产生。

所以,不论你坚持「个人隐私不可侵犯」,还是「君子坦荡荡」,至少以降低风险性为目的来说,隐私是需要保护的。

而在我看来,隐私包括这些信息:姓名,手机号,身份证号,邮箱地址,用户名。通过这类信息的任何一条,进行交叉查询,就能大概率找到在其它网站上注册的账号,从而获取更多的信息,这就是一些「人肉搜索」常用的方法。在一些需要实名认证的服务中,姓名、身份证号和手机号这些信息是必不可少的,但在其它的使用情况中,iCloud+ 新推出的「隐藏邮件地址」让我对这个问题有了一些新的解决方式。

iCloud+ 是 Apple 在今年的 WWDC 上发布的新服务,其中的「隐藏邮件地址」能够生成不限数量的邮箱,这些邮箱可以用来日常使用(如注册账号,发送邮件等),所有发送给这个地址的邮件都会被转发给设定的地址(默认为 Apple ID 的邮箱,但可以手动设置为「联系方式」中的其它邮箱)。这种方式就提供了一种新的方法来管理个人账号,比如在每个服务中使用不同的邮箱。

相比较于之前的「Sign in with Apple」生成的隐藏邮箱,这项功能少了许多限制,同时增加了更多的功能。iCloud+ 的「隐藏邮件地址」生成的邮箱与任何其它邮箱的功能相同,使用 @icloud.com 结尾(而不是 @privaterelay.appleid.com),所以看起来它就是一个正常的邮箱地址,使用起来也就像一个正常的邮箱地址,但有这些需要注意的地方:

  • 无法手动设定邮箱的地址,只能从给出的三个备选项中选择一个,而且未选择的备选项在下次选择时仍然会出现
  • 使用「隐藏邮件地址」收发邮件时,邮件会经过 Apple 的中转服务,即其他人发送到「隐藏邮件地址」的邮箱的邮件,会被 Apple 用特定的邮件地址(同样以@icloud.com 结尾,通常格式为「原始邮箱地址字符串 + 随机字符串 + @icloud.com」)发送给你,而你回复邮件也可以发送到这个特定的中转邮件地址
  • 这个邮箱无法添加到 Apple ID 的「联系方式」中,所以不能用这个邮箱来作为 iMessage 的地址

目前,在 iOS 15 和 macOS 12 测试版本中,可以在设置中新建邮件地址。在 iOS 中位于「设置 - (位于最上方的)账号 - iCloud - 隐藏邮件地址 - 创建新地址」;在 macOS 中位于「系统偏好设置 - Apple ID - iCloud - 隐藏邮件地址 - 选项 - 添加(左下方的『+』 符号)」。

测试系统的 Safari 浏览器可以在注册账号时选择「隐藏邮件地址」来生成新的邮件地址(需要打开「自动填充 - 通讯录信息」的选项,在 iOS 中位于「设置 - Safari 浏览器 - 自动填充 - 使用联络信息」;macOS 中位于 Safari 的「偏好设置 - 自动填充 - 使用我的通讯录中的信息」)。

在 macOS 12 Monterey 中:

macOS 12 - 隐藏邮件地址

在 iOS 15 中:

iOS 15 - 隐藏邮件地址

但「邮件」中发送邮件时,发件人中还没有「隐藏邮件地址」选项(这一功能出现在了 WWDC 的视频展示中)。我猜想这项功能应该会在即将开始的秋季发布会后,iOS 和 macOS 的正式版本中上线。

在前一段时间,我尝试对自己过去多年来积累的账号进行一次清理,在看到 iCloud+ 的「隐藏邮件地址」功能之后,我有了一个更进一步的想法,使用这个功能来分离我的所有网络账号。 iCloud+ 的「隐藏邮件地址」功能需要开通 iCloud 付费订阅才能使用,最低的付费套餐为每月 6 元的 50G 套餐,我的照片和各类文档不多,不太需要这个容量,但即使只使用「隐藏邮件地址」这个功能,也非常值得付费。当然,一些其它的替代方案包括使用匿名邮件服务商,自建邮箱服务等,这些方法对于我而言都引入了新的复杂度,需要更高的使用门槛,但如果你对这些服务有(或者希望进行)深入的了解,也完全可以使用这些服务。这些服务的唯一目的是降低个人在多个网站账号上的交集。任何方式只要能够达到目的,并且足够的稳定和安全,都是可以使用的。

通过对我以往账号的回顾,我将我在使用的账号进行了这两个维度的分类:

  • 使用邮箱还是手机号登录
  • 属于重要账号还是一般账号

对于第二个维度「重要账号还是一般账号」,我通常有两个标准,满足这两个条件中的任意一个,我都将其视为重要账号。

  • 是否有实名需求(如微信,支付宝,各类政务网站等)
  • 账号本身很重要,经常使用(如 Microsoft 账号,Apple ID,主要使用的邮箱账号等)

除此之外,还有一些基本原则:

  • 邮箱的权重大于手机号的权重:即当同时拥有邮箱和手机号两种注册方式的时候,使用邮箱进行注册
  • 有实名认证需求时,手机号权重大于邮箱的权重
  • 仅使用一种认证方式:要么使用手机号,要么使用邮箱,但不要两者同时绑定
  • 只在重要账号上使用常用用户名:对于重要账号,不论是使用邮箱还是手机号注册,都使用主要用户名,这个用户名可以是与现实身份产生关联的 ID,我习惯于直接使用名字或名字的拼音。

总结下来,对于两个维度,每个维度两种可能性进行分类,总共有四种情况:

分类重要账号一般账号
手机号注册常用手机号 + 常用用户名小号 + 随机用户名
邮箱注册iCloud+ 随机邮箱 + 常用用户名iCloud+ 随机邮箱1 + 随机用户名2

使用「隐藏邮件地址」服务时,我建议除了那些非常有价值,实在无法割舍的账号以外,其它的账号都重新进行创建,以达到完全割离的目的,否则通过留存的记录,数据和广告公司可能仍然会将这些账号关联起来(并非针对个人,而是它们的大数据系统仍然有极大的可能性将这些账号视为同一个人)。

将账号进行隔离的好处是,在一个服务中的使用记录,不会导致在另一个服务中出现相关的广告推荐;任何企业的数据库泄露都无法对其它账号产生任何影响。当然,如果是基于手机号的账号,则无法享受到这种好处。

为了进一步降低复杂度,我将 Apple ID 更换成了 iCloud 邮箱,缺点是我无法再通过其它的邮箱来为这个 Apple ID 提供保障(比如在找回密码时接收验证码。但找回密码可以通过绑定的手机号码来完成,今年的 WWDC 还推出了基于「信任联系人」的验证码设计);优点则是我不需要考虑另外一个账号的安全性。在我完成了对账号的清理之后(包括删除或放弃不再使用的账号,抛弃一些不太重要的账号来重新注册,以及更换重要账号的邮箱),我的所有账号都只基于 iCloud 邮箱和手机号码。

所以剩下的唯一一件事情是,需要保证 iCloud 账号足够安全。显然,一个高强度的账号密码是必不可少的,而且由于这是一个不常用密码,所以我选择将其存储到密码管理器中。但除此之外,还要考虑在没有密码的情况下,如何找回这个账号的密码,这不仅可以更准确地判断此账号的安全性,也同时为如何防止别人通过这种方式得到此账号的访问权提供了思路。

修改 iCloud 的密码有两种方式(在开启了双重验证之后),一种是通过其绑定的手机号接受验证码来进行重新设置,另一种方式是通过信任设备的解锁密码(如果你有使用非 iCloud 邮箱的话,还可以通过邮箱来找回密码;恢复密钥也可以实现这个功能,但这两种方式都会引入新的复杂度)。也就是说,iCloud 账号的安全依赖于手机号和设备密码

如果施行了上面对手机号码的保护方式,正如其末尾提到的,手机号码的安全依赖强设备密码。先不考虑密码管理器的安全,那么就只需要一个强设备密码,就能够对手机号码和 iCloud 账号提供保护,同时也就意味着对我的所有数字账号提供了保障。

设备密码:证明你是你自己的方式

在 Apple 的设计中,「信任设备」是唯一能够证明用户身份的方式,所以如果是在「信任设备」上,用户可以凭借「设备解锁密码」来直接修改 iCloud 账号的密码,而不需要验证原来的 iCloud 密码。

也许你会认为这种方式存在安全隐患。如果你希望关闭这种通过「设备密码」来修改 iCloud 账号密码的方式,可以在「设置 - 屏幕使用时间 - 内容和隐私访问限制」中,开启「内容和隐私访问限制」,然后在同一位置的「允许更改 - 账户更改」中设置为「不允许」,当然,为了防止解锁手机后可以将其重新设置为允许,就需要在上一页的「屏幕使用时间」中设置「为屏幕使用时间设置密码」,这样就需要输入这个密码才能将其修改为「允许」。

这种方式会带来一些额外的限制,比如设置中最上面的「账号」就会变成了不可点击的灰色,即无法使用「账号」选项里的任何功能。而且这种方式同样引入了新的复杂度——「屏幕使用时间密码」。我认为设置一个更安全的设备密码才是更加简单的解决方法,而且即使设置了「内容和隐私访问限制」,也同样需要一个安全的设备密码。

总之,基础原则是,不要在非自身使用的设备中登录个人的 iCloud 账号,也不要在自身使用的设备上登录他人的 iCloud 账号。对于某些特定的情况,比如为家人的设备进行设置时,更好的方法是为他们注册单独的 Apple ID,同时将其加入家庭组中进行管理,对于这些内容,我没有什么研究,如果你希望使用这些功能,可以参考Apple官网提供的支持文档

对于设备密码的强度,我推荐这些标准:

  • 12~18 位长度:太短更容易在公共场合泄露,太长则难以记忆
  • 拥有字母和数字:引入符号当然会进一步加强安全性,但也会导致输入上的困难,在我看来使用字母和数字已经足够安全
  • 使用与个人信息无关的内容:不论是姓名、拼音、身份证号和出生日期等信息,都有可能已经在社工库中留存,所以存在一些风险

为了降低记忆的难度,一种较为推荐的方式是使用多个随机的无关英文单词,比如「floss-pie-wapiti-sweeten」,这种方式更加容易记忆,你需要记住的只有几个较短的单词,和它们之间的顺序,也拥有一定的容错性(模糊的单词或顺序可以通过多次尝试来回忆起来,但同时也不会让不知道密码的人能够尝试出来)。

一些密码管理器在其网页版上就提供了这种随机单词的生成器,我在 1 Password 和 Bitwarden 的网页中都找到了此功能。

1 Password: Password Generator:将类型从「Random Password」改为「Memorable Password」。

1 Password: Password Generator

Bitwarden: Password Generator:将「Type」设置为「Passphrase」。

Bitwarden: Password Generator

当然,在实际使用中,我建议去掉单词之间的「-」,这会让你输入起来更麻烦,且输入模式更明显。

对于不想去记一些不常用单词的人来说,一种可能的替代方法是使用拼音,但因为拼音的数量远远少于英文单词。不计算音调,拼音的音节数量只有410个(参考 维基百科:汉语拼音音节列表),而英文则有几万个单词,使用 4 个英文单词理论上存在至少 10000^4 = 1 亿亿种可能性,要用拼音来实现同等复杂的密码,则需要 6 个以上。另外,拼音的音节规律性较强,也有可能会稍微降低其安全性。不论采用哪一种方式,最重要的是使用随机生成,而不是由自己挑选,自己挑选出来的结果具有极强的主观判断,会极大降低其安全性。

密码管理器:所有通行的权利

现在,我们来谈一谈密码管理器。

密码管理器显然是一个老生常谈的话题,也通常是大部分用户安全配置中的重点和所有账号的依赖,但如果不能对密码管理器在整个安全体系中的位置产生正确的理解,也有可能会因此产生一些问题。

我认为安全体系中最重要的是保护手机号码的 PIN 码;保护隐私的服务(iCloud+);保护设备的设备密码。这三个部分已经在前面的内容中分别进行了表述。而密码管理器,则作为基础服务存在。在实践上,我目前使用 Elpass 作为密码管理器,通过 iCloud 进行同步(我同时也在思考是否有其它更好或更简单的选择,比如 iCloud 钥匙串,但还没有彻底得出结论)。

Elpass 可以通过 iCloud 和 Dropbox 来进行同步,在 macOS 和 iOS 上有原生客户端,在 Windows 上只有基于 Chrome 的扩展(要使用此扩展的话,只能通过 Dropbox 同步数据)。对我来说,这些功能已经足够使用,因为我个人更偏好简洁的原生开发应用。但重要的不是能够做什么,而是你用来做什么。如果选择 1 Password 和 Bitwarden 这类由企业或开源组织开发的工具,相比较于独立开发的 Elpass 来说,应该是更具保障和安全性的。

对于「用来做什么」这个问题,我的存储标准是:非必需密码。即只要不是必须记住的密码,我都选择保存到密码管理器中。在实践中,只有两种密码符合此标准:密码管理器的主密码,和常用设备解锁密码。这就是我需要记忆的 N+1 个密码。N 指的是常用设备个数,1 指的是密码管理器的主密码。

这种方式是我极力简化后的结果,你可能会一眼发现其中存在的一些相互依赖(比如通过 iCloud 同步 Elpass 的密码数据库,但又将 iCloud 密码存储在 Elpass 中),从而认为有造成死循环的可能。但如果对每个部分都进行充分的了解,就能够在尽量简化这个系统的同时,达到消除循环依赖的目的。简化系统的目的是消除复杂度,因为越多的部件存在,就会让系统越复杂,而复杂度不仅会导致混乱,同时也会很难发现其中的漏洞和问题。这就是我对待工具的「最简化原则」。

密码安全架构

我为自己设计的安全体系画了上面这张图,具体定义如下:

  • 箭头表示依赖,比如「密码管理器」依赖「主密码」。
  • 紫色的箭头表示可修改,比如在信任设备上,可以使用「设备解锁密码」来更改「iCloud 密码」。
  • 虚线箭头表示备份,这里只有一种情况,在未完成肌肉记忆以前,将「设备解锁密码」备份在「密码管理器」中。

如果有多个向内的箭头,则表示需要满足所有的依赖,才可以使用这项功能。在这张表中,只有「密码管理器」有两个向内的箭头,即需要「主密码」和「iCloud」才可以使用「密码管理器」。

这张图的起点为左下角,两个紫色模块即代表需要记忆的 N+1 个密码。密码管理器使用 iCloud 同步,而 iCloud 的密码存储在密码管理器中,但 iCloud 的密码可以使用「设备解锁密码」或者「短信验证码」进行更改,所以即使真的遇到了所有的设备都无法访问的情况,也可以通过手机验证码来获取 iCloud 的使用权限。这样看来,手机验证码需要最高的权限来进行保护。因为短信验证码不仅是 iCloud 的保障(也就间接是所有账号和密码的保障),同时由于实名制的存在,同时也作为所有支付手段的保障。所以我将 SIM 卡的 PIN 码设置为随机的八位数字,存储在密码管理器中。

相比较于 A 依赖 B,B 依赖 C……这样的路径,我更偏好这样一种方式:A 依赖 B,同时 B 依赖 A,但 A 或者 B 可以通过某种只与我本人身份绑定的认证来访问或者获得访问权,这种方式的好处是使得系统更加简单,为了保证 A 和 B 的安全,我不需要引入额外的 C 模块来做这件事情。

比如在我的设计中,密码管理器和 iCloud 相互依赖,而解决依赖的方式是可以通过信任设备或者手机验证码来修改 iCloud 密码从而获取其访问权。对于信任设备,其解锁密码只依赖于个人的记忆,这是一种与本人绑定的身份认证方式;对于手机验证码,通过 PIN 码来进行保护,同时 PIN 码存储在密码管理器中,这形成了一个大一些的相互依赖,而解决这个相互依赖的方式是在营业厅重置 PIN 码,这需要本人携带身份证件进行办理,同样是一种与本人绑定的身份认证方式。

最后,对于密码管理器的保护主体——账号,其保障在于手机号和邮箱。

账号安全架构

对于数字账号的安全,我的建议是:

  • 使用密码管理器生成的复杂密码
  • 开启两步验证

具体的情境假设:有备无患

在完成了架构设计之后,可以假设某个功能或者服务出现了问题,来检查是否有可行的解决方法,从而验证这个系统的有效性,也能够同时确定这个系统的最大风险承受能力。

企业数据库泄露导致某个账号密码暴露

直接修改这个账号的密码即可。当然,为了保护隐私,一种极端的方式是删除或弃用这个账号,然后重新注册新的账号。

单个设备丢失或无法访问

此时在其他设备上可以访问所有数据,在确认设备无法找回后,远程删除数据。

所有设备丢失或无法访问

此时密码管理器和 iCloud 均无法访问,可以通过手机验证码来修改 iCloud 密码,修改成功后即可访问密码管理器中的密码,然后在密码管理器中生成新的 iCloud 密码,因为一般手动修改的密码会较为简单,所以需要生成新的复杂密码来更新 iCloud 密码。

密码管理器出现问题

密码管理器的某些恶性问题会导致数据泄露或无法获取原有数据,比如开发者在应用中埋入了后门,收集账户和密码,或者程序的恶性 BUG(或开发者的恶意操作)删除了所有数据,虽然这种可能性非常小。在这种情况下,由于绝大多数的支付操作都需要验证身份(通常是基于手机验证码或者人脸识别),所以即使支付密码存储在密码管理器中,也不太会造成财物上的损失。使用手机验证码可以找回 iCloud 邮箱,通过手机验证码和 iCloud 邮箱可以找回所有的账户。所以在这种情况下,最有可能损失的只有一些数字内容,如云存储资料,我将这些资料存储在 iCloud 中,所以不会被泄露或删除。

iCloud 无法使用

可能性最小的情况之一是,Apple 的 iCloud 服务出现了问题,这时候除了作为云服务所存储的文件可能有丢失的风险之外,可以通过密码管理器的备份来找回绝大多数的账号。当然如果 iCloud 邮箱彻底不可用,这就意味着所有基于 iCloud 邮箱的账号都缺少保障,因为无法通过邮箱来接收验证邮件,从而无法转移账号到新的邮箱中。所以唯一的做法是通过备份还原的密码管理器数据,登录账号并下载所有可以下载的必要数据,然后注册新的账号使用。使用基于手机注册的账号则没有这个问题。

当然,这种情况的可能性非常小,考虑这种情况的原因是,确保在发生任何意外时,我都知道能够通过哪些方式来保全自己的数据和资产。

手机号安全出现问题

如果是营业厅的上班时间,尽快补办 SIM 卡,这样旧的 SIM 卡就会失效;如果是其它时间,拨打正在使用的银行和金融服务的客服请求冻结账号。也可以尝试拨打运营商的号码请求冻结号码,但是由于无法证明自己的身份,而如果犯罪分子解锁了 SIM 卡,那么即使号码被冻结,犯罪分子也可以重新解锁手机号,比如开头提到的例子中,就出现过这种情况。

终极情况,系统失效的条件:失去所有设备的所有权,同时失去手机号码的所有权。

这就是这个最简化的安全系统的最大风险承受能力,所有的信任设备都无法再使用,手机号也无法再被使用。这种事情发生的几率很小,但也许你能够想象出怎样的一场意外或者灾难能够构成这个局面。这里的「手机号码的所有权」指的是我永远无法再使用这个手机号码的情况,可能的情况包括但不限于:运营商的漏洞导致我的手机号被删除(也许这种情况有可能重新办理而找回来);我因为使用此手机号码进行一些违法行为而导致手机号被封禁等等。

但正如我所说,这是一个最简化的系统,为了增强这个系统的安全性,你可以对其进行一些改造,比如将密码数据库定期进行本地备份,存储在一个安全的硬盘中,然后将硬盘妥善保存;或者使用其它的云服务来存储这个数据库;或者记住 iCloud 的密码;或者为 iCloud 设置恢复密钥,将恢复密钥打印出来妥善保存等等。这些方法都能够更好的加强这个系统,但同时也引入了额外的复杂度,而复杂通常意味着有更大的几率出错。所以我的习惯是,首先构建出一个最简单的系统,然后再根据需要慢慢完善这个系统。

对于是否引入某些模块,我仍然在考虑当中,因为与我所遵循的「最简化原则」有一些冲突。也有可能其实没有冲突,只是我还没有彻底想清楚它们之间的关系,在此之前,我保持「最简化原则」的结果,暂不引入额外的变量。

而即使这种终极情况真的发生,我所损失的也只有在数字世界使用的所有服务和账号,而不会包括任何资产上的损失。我接受这种小概率事件发生时的结果,所以这同时也就作为了这个安全系统的最大风险承受能力。

最终总结:安全系统的设计

在我看来,我们只会越来越深地进入和融入数字世界,而在现在这个世界以及未来的世界中,不出意外的话,数字账号的安全性问题显然将会伴随我们一生,而且只会越来越重要。所以在最开始就投入一些时间和精力,构建出一个较高安全性的系统,这样可以在之后的时间里享受这个系统带来的安全保障,同时对于某些可能存在的漏洞和陷阱也会拥有更好的识别能力。所以即使你现在没有什么有价值的资产需要保护(比如我),也最好开始做这些事情,如果你对自己的未来充满希望的话(比如我)。

而我给出的对安全系统的最简化设计,并不是希望你完全照搬到自己身上,而是希望你能够从中进行一些参考,比如对于每个模块的安全性保障是如何实现的,比如你需要对哪些模块进行保护,而将这些模块放到一起,相互连接出「依赖、可修改,备份」等关系,就能够更加清晰的认识这个系统的安全性,从而发现其需要补足的薄弱点。

如果你希望设计自己的安全系统,以下是我认为这篇文章中值得参考的点,当然,也仅供参考。

  • 明确自己需要保护的模块有哪些
  • 确定模块之间的相互依赖
  • 通过假设来确定对于意外情况的处理方式
  • 确定自身愿意接受的最大风险承受能力
  • 画出模块之间的依赖图来帮助设计

此外,还有一些基础模块和保障方式:

  • 手机验证码:通过PIN码保护
  • 隐私:通过匿名邮箱 + 手机小号保护
  • 设备:通过强设备密码保护
  • 数字账号:通过密码管理器保护

我不推荐本文提到的任何具体的工具和服务,提到的唯一原因是这是我本人的使用环境。但我推荐使用「开启PIN码」、「手机小号」、「隐藏邮件地址」、「密码管理器」和「设置复杂密码」等方法、功能或服务。不论你使用的是什么设备和工具,在理清了自己需要的功能之后,我相信找到可用的工具将会更简单一些。

安全系统设计的主要思路当然是降低对于不够靠谱的模块的依赖,比如小公司的服务,对安全不够重视的公司的服务,以及自身的记忆力。从某种程度上来说,我们记住的东西才是我们唯一能够验证自身的方法,所以作为最重要同时也最不靠谱的依赖,方法就只有尽量降低需要记忆的数量,同时也不要考验自己的长期记忆能力,如果有什么长期不会使用的信息,就不要为难自己了,将其打印出来或者写在纸上妥善保存才是更好的处理方式。

安全系统的设计是为了应对那些意外情况,尽管这些情况发生的几率都比较小,毕竟现在的多数人也许仍然保持着注册所有账号使用同一个密码的方式,对手机和手机号码也缺少防护,也不会因此而经常性地遭遇财产上的损失。但使用可靠的方式来进行防护,养成良好的账号使用习惯仍然有助于提高在数字世界中的安全性。

写到这个地方,我已经感觉这篇文章有些过长和啰嗦了。尽管已经删改了多次,但仍然很难写得足够清晰和简洁,可能是因为我一方面想把个人化的系统作为例子展示,另一方面想推崇的又是通用的方法而不是特定的工具;对某些想得多一些的模块描述得过于啰嗦,对想得少一些的模块一笔带过甚至没有谈到。而我本人对安全领域并没有深入的研究,这个系统的设计也没有经过长时间的完善思考,只是这段时间进行重新设计后得到的结果,所以如果有发现任何错漏之处,欢迎指出。

篇幅既然已经过长,我想在最后谈一谈我对这个时代的看法。

时代带给我们什么

许多时候人们责怪受害人缺少安全意识:「手机验证码是不能随便给别人的」。现在的大部分企业的验证码里都会有这样「贴心」的提示:「请勿将验证码泄露给任何人」。但问题是,为什么所有的身份认证都基于手机号这个诞生之初的目的是提供通讯联络功能的主体上?运营商觉得他们没有加固手机号安全的义务和责任,因为他们负责的只是通讯业务,所以只要提供了可用的功能即可。互联网企业没有进行加强认证,因为这种认证会提高用户使用的门槛,而且他们没有义务为用户的手机号安全负责。即使在某些诈骗案件中,企业有了明确的不可推卸的责任,他们会作出的最佳决定也只是「全额赔付,坚决不改」,因为这种赔付相较于降低门槛所带来的收益来说不值一提。而且通常来说责任很难明确在企业身上,除非变成了公共事件。除此以外,对于那些无法明确责任的受害者来说,结果就是「受害者的风险防范意识不强,需要自行承担责任」。

当绝大多数人为了便利而放弃了安全性之后(因为安全性通常只在危险的时候才能够被直接感知到),这种趋势裹挟着其他不愿意牺牲安全和隐私换取便利性的小部分人,让他们难以享有这项权利。比如街头不再愿意接受现金付款,在超市排队结账的队伍中,如果有人掏出了现金,也许专业的收银员不会有什么反应,但在他身后排队的人都会产生颇为强烈的负面情绪(明面上或是暗地里),这时候身后可能就会有不耐烦的人「推荐」他用手机。在他的立场中,虽然这种劝说通常不会使结账者现场掏出手机注册支付宝(如果真的这样做,可能会更加耽误时间),但也许之后他就会开始使用手机,从而使以后的结账过程更迅速一些,世界上少了一位使用现金付款的人,也就变得更美好了一些,所以劝说的人有时候秉承着一种朴素的正义感(当然也不总是这样,不排除某些人真的是因为不耐烦而出言讥讽),这就是来自大环境的裹挟。

现在仍然在结账时使用现金的,通常都是不会(或不愿意)使用手机的老年人,真的为了安全性和隐私而使用现金的人并不多见。但这可能就是大环境裹挟的结果,他们本来坚持的做法变得不便利,同时处处受到环境的恶意(即使有时候出发点并非恶意),所以不得不放弃原来的做法,而选择顺从大环境。

当然,即使问题的来源是运营商对于手机号安全的轻视,互联网企业为了利润而简化认证,或者更直接的来源——犯罪分子的行为,但作为个人来说,这就是我们现在要面对的问题。正如不论是哪一种犯罪,我们更应该去责怪犯罪者的行为,而不是受害者的防范意识不强,但同时我们仍然要注意环境的安全性,或者至少通过一些措施来获得生存上的安全感。

当你的身体生存在物理世界,但意识绝大多数时间生存在数字世界里时,你的视角也会倾向于向数字世界转移,不仅是你所关注的创作者的创作内容,还包括你日常使用的工具,进行的消费,最终的结果是,你所拥有的财产——承载着货真价实的人名币的银行卡,从物理世界迁移到了数字世界之中。在现实世界当然也有基于银行卡的犯罪行为,而如今这类行为越来越少,一方面是因为相关制度的完善,另一方面也可能是因为,绝大多数用户的财产已经迁移到了数字世界(即消费习惯更多的产生在数字世界)。在物理世界的犯罪受到物理世界的限制,但在数字世界,不仅仅是制度没有达到物理世界那么完善,而且限制也少得多。在物理消费时代,你无法做到用一张银行卡在全世界多个地方(近乎)同时进行消费,即使有这种行为,也通常会被银行的风控系统所捕获,因为这在物理世界中是一种异常的消费行为,而在数字消费时代,这种事情当然有可能发生,并且经常发生,所以银行的风控系统显然会根据这类行为而作出调整,这也就给犯罪分子更大的空间,也就意味着可能给你带来更大的损失。

所以,构建一个完善的安全系统,来保障个人的数字资产,是一件有必要的事情。

> 下载少数派 客户端 、关注 少数派公众号 ,了解更妙的数字生活 🍃

> 想申请成为少数派作者?冲!

© 本文著作权归作者所有,并授权少数派独家使用,未经少数派许可,不得转载使用。


文章来源: https://sspai.com/post/68634
如有侵权请联系:admin#unsafe.sh