安卓手势密码有多弱：389112种组合、暴力破解与锁屏防护

手势密码这个话题，我在过去几年里被问过不下五十次，问的人里有做移动端开发的同行，也有单纯担心手机丢了被翻开的普通用户。大家都隐约觉得九个点连来连去不太靠谱，但很少有人说得清“不靠谱”到什么程度、在什么条件下不靠谱、以及到底该怎么补救。这次我把自己这些年攒下来的笔记重新梳理一遍，从最底层的排列组合算起，聊到真实攻击面、系统演进、以及个人和开发者分别该做什么。核心关键词就三个：安卓手势密码、暴力破解、锁屏防护，全文围绕它们展开。适合移动端开发者、企业设备管理员，也适合只想把手机调得更安全一点的普通用户，不需要密码学背景，跟着看就行。

1. 先算清楚账：手势密码的安全上限到底在哪

在讨论“安全不安全”之前，我习惯先把密码空间算出来，因为所有关于强度的争论，最终都会落到这个数字上。九个点的九宫格，安卓系统只接受长度 4 到 9 的图案，这个约束是硬性的、写在系统里的。很多人凭直觉觉得“九宫格能连出几百万种”，实际算下来比想象中小一个数量级。这一节我们把数字摊开，顺便说清楚为什么“1 秒破解”这个说法在特定前提下并不夸张。

1.1 389112 这个数字是枚举出来的

手势图案不能跨过未使用的中间点，这是一条硬规则：从左上角直接划到右下角是不允许的，必须中间那个点已经被连过。这条规则让计数不能简单套用排列公式，得靠深度优先搜索把所有合法路径走一遍。我写了个几十行的枚举脚本，跑出来结果和公开资料一致：

# 枚举 3x3 九宫格上的全部合法手势（长度 4~9） pts = [(r, c) for r in range(3) for c in range(3)] def mid(a, b): """a、b 之间有中间点时返回该点，否则返回 None""" (r1, c1), (r2, c2) = a, b if (r1 + r2) % 2 == 0 and (c1 + c2) % 2 == 0: m = ((r1 + r2) // 2, (c1 + c2) // 2) if m != a and m != b: return m return None counts = {n: 0 for n in range(4, 10)} def dfs(cur, visited): n = len(visited) if 4 <= n <= 9: counts[n] += 1 if n == 9: return for nxt in pts: if nxt in visited: continue m = mid(cur, nxt) if m is not None and m not in visited: # 中间点没连过，非法 continue visited.add(nxt) dfs(nxt, visited) visited.remove(nxt) for start in pts: dfs(start, {start}) print(counts) print("总计:", sum(counts.values()))

跑完输出每个长度的数量，加起来是 389112。这个结构值得单独列个表看，因为它直接解释了用户习惯带来的危险性：

看到这里有个反直觉的结论：8 点和 9 点的图案数量是完全相同的，因为九宫格只有九个点，走满九个点就等于把所有点用光，路径总数固定。而现实里六点以下的短图案非常好记又好划，用的人特别多。也就是说，真正被大量使用的，是表格上半部分那不到 7% 的空间。

1.2 18.6 bit 的理论熵，实际有效熵可能只有一半

389112 取以 2 为底的对数，约等于 18.6 bit。作为对照，四位数 PIN 是 10000 种、13.3 bit，六位数 PIN 是 1000000 种、19.9 bit。换句话说，一个九点的手势密码，理论强度也就和六位数字 PIN 打个平手，而绝大多数人根本没画到九点。

更要命的是，用户选择严重不均。公开的图案使用习惯研究里反复出现几个现象：大约四成的人从左上角的点起手；绝大多数图案的终点落在四个角上；字母形状（比如照着一个字母的轮廓连）被大量复用；对称图案的出现频率远高于随机分布应有的比例。这些规律一旦被做成字典，就相当于把 389112 砍掉前面一大截。行业里比较保守的估计是，一个高频图案字典覆盖到几百到几千条，就能命中相当大比例的真实用户。

我个人的经验判断更悲观一点：如果把“字母形、Z 形、M 形、从左上起手、四角收尾”这几条规律叠加起来做剪枝，剩下的候选空间压缩到一万条量级是很正常的事情，对应熵不到 14 bit。这已经低于六位随机 PIN 的强度了。

注意：讨论熵的时候一定要区分“理论熵”和“用户分布下的有效熵”。厂商宣传的“三十多万种组合”是前者，攻击者利用的是后者。这两个数字能差出一整个数量级。

1.3 “1 秒”这个说法成立的前提

标题里那个“1 秒”并不是耸人听闻，但它有严格的适用条件，脱离条件谈这个数字就是耍流氓。我把常见场景分成两类：

第一类是离线场景，攻击者已经拿到了锁屏凭据的存储内容（文件、分区镜像、或者解锁后的哈希导出），破解发生在攻击者自己的机器上，没有任何次数限制。这种情况下，把候选空间压到几万条、配合现代 CPU 或显卡的并行能力，秒级出结果完全正常。老版本系统把手势图案经过一次简单散列后就落盘，没有加盐、没有慢哈希、没有硬件绑定，这种条件下“字典一遍过”确实是一秒钟的事。

第二类是在线场景，也就是在锁屏界面上一个一个试。这里系统有错误次数限制、有递增延迟、近年来的设备还把错误计数放在独立的安全环境里，试错成本随次数指数上升。这种场景下想在一秒内试完几万种，完全不可能。

所以准确的说法是：“1 秒”描述的是离线恢复锁屏凭据的速度，而不是在别人手机上现场试的速度。而离线场景能不能成立，取决于你能不能绕过磁盘加密、能不能绕过硬件的密钥派生，这恰恰是近十年安卓安全体系进步最大的地方。后面的章节会详细拆开。

2. 四类真实攻击面拆解：攻击者到底从哪儿进来

光讲数学不够，因为现实中没人会坐在那儿穷举三十八万种图案。真正被用到的手法就那么几类，每一类的门槛、前提、取证难度都不同。我把它们归成四条线：离线恢复、物理侧信道、观测类攻击、以及可信计算链被打破。这一节按“成本从低到高”排，方便你对号入座地评估风险。

2.1 离线恢复：拿到凭据文件之后发生了什么

这是学术界和取证圈讨论最多的一条线。早期安卓版本的做法非常朴素：用户画完图案，系统把它编码成一个数字串，做一次 SHA-1 散列，然后把散列值写进系统分区的固定路径下。这条路径在社区里被反复讨论过，几乎成了常识。整个设计有三个致命问题：没有盐，意味着通用彩虹表可以直接复用；用的是快速哈希，意味着单机每秒能算几百万次；文件权限管理依赖 root，一旦拿到 root 或者能物理读取分区，文件就落到攻击者手里了。

后来的演进路线很清晰，我按代际列一下：

这个表格里最关键的一行是最后一行。现在主流设备默认开启文件级加密，锁屏凭据参与派生解密密钥。这意味着即使有人把你的存储芯片吹下来读出原始数据，拿到的也是一堆密文——没有正确凭据就派不出密钥，读出来也没意义。这条防线把“物理接触就能破解”这个假设彻底打破了。

注意：这里说的是主流新设备。老设备、低价白牌机、以及被刷过第三方系统镜像的设备，很可能还停留在表格第一、二行。判断自己设备处在哪一档，比记一堆操作步骤有用得多。

2.2 物理侧信道：屏幕上的油渍比你想的更诚实

这一条不需要任何技术手段，需要的是光线角度。手指划过屏幕会留下油脂痕迹，用特定角度的斜射光一照，最近的滑动轨迹会非常明显地显现出来。学术上把这类攻击叫“污渍攻击”，十几年前就有完整论文，实验条件下识别率能到六成以上，如果配合多角度拍摄和图像增强，还能更高。

为什么它比暴力枚举可怕？因为它把 389112 的搜索空间直接压缩到“痕迹重叠的几条候选路径”。更麻烦的是，用户往往有固定的起手点，痕迹会一层层叠加，反复使用的图案反而更容易被辨认出来——用得越久，越清晰。

对应的防护手段其实很朴素，但很少有人认真做：

• 用完手势后顺手在屏幕上抹一把，尤其是屏幕边缘和经常起手的左上区域
• 贴一层哑光膜，油脂痕迹的可见度会显著下降
• 关闭“显示图案轨迹”这类动画（很多定制系统默认开启）
• 如果设备支持随机化键盘布局的 PIN 输入，优先用 PIN 而不是图案

我个人现在的习惯是彻底不用图案了，改成六位 PIN 加指纹。理由很简单：PIN 的键盘可以随机化，指纹不存在污渍问题，图案则两头不占。

2.3 肩窥与录制：成本最低、成功率最高的一类

在地铁、电梯、排队的时候，从侧后方斜上方看过去，图案轨迹几乎是完全暴露的。九宫格的可视面积大、动作幅度大、轨迹连贯，比输 PIN 好观察太多。输 PIN 你还能用身体挡一下键盘，画图案根本挡不住，整个手掌在屏幕上划过的路径本身就是信息。

这一类的变种还包括：公共场所的监控摄像头、桌面上的网络摄像头、以及别人手机随手录的一段视频。一旦轨迹被录下来，回放逐帧看，起手点、转折点、终点全都清楚。这类攻击不需要任何技术能力，也因此最难防。

防御思路只有两条，都很土但有效：一是换掉图案，二是画的时候用手掌或者身体遮挡。我见过一些安全意识强的同事，会在输入前先把手机往身体内侧倾斜三十度，这个动作几乎成了肌肉记忆。

2.4 调试通道与可信启动链被打破

这一条是技术含量最高的，也是普通用户最容易误解的。很多人以为“开了 USB 调试就完蛋了”，其实没这么简单，但也没那么安全。

先说要满足什么条件。想通过调试通道访问锁屏凭据，通常需要同时满足：设备处于已解锁的引导状态（引导加载器可解锁）、系统镜像可以被替换或挂载、磁盘加密没有把凭据绑死在硬件上。三者缺一，这条路基本走不通。现代设备在这三处都设了关卡：引导加载器解锁会触发数据擦除、启动过程有完整性校验、加密密钥与芯片内的密钥派生逻辑绑定。

再说真正的风险点在哪。我在实际排查中遇到的真实问题，往往不是“高手远程攻破”，而是用户自己把设备搞成了低防护状态：

• 为了装某个需要特殊权限的工具，把引导加载器解锁了，之后一直没锁回去
• 刷了来路不明的第三方系统镜像，完整性校验链条从根上就断了
• 在开发者选项里长期开着调试授权，还给某台不常用的电脑授了权
• 用了来源不明的“一键优化”类工具，把系统的安全策略改掉了

这几种状态下，前面几节讲的所有硬件级防护都可能失效。我个人的判断标准很粗暴：只要引导加载器处于解锁状态，这台设备在安全意义上就不该存放任何敏感数据。

3. 分层加固：从个人设置到应用代码再到设备策略

知道了攻击面在哪，接下来就是怎么补。我一直反对那种“列二十条安全建议让你自己挑”的写法，因为绝大多数人执行不完。所以我按角色分成三层：普通用户做减法和换锁，应用开发者做隔离和加密，设备管理员做策略强制。三层各自独立生效，任何一层做到位都能显著抬高风险门槛。

3.1 个人用户：十分钟能做完的六件事

这一节的每一条我都实测过，改动成本都很低，按性价比排序：

第一，把图案换成六位以上 PIN。这一条的收益最大。六位 PIN 的空间是 100 万，比九点图案还大，而且不存在污渍泄露轨迹的问题。设置路径在“设置 → 安全 → 屏幕锁定”里，选 PIN，尽量别用生日和连续数字。

第二，开启随机化键盘布局。很多定制系统在 PIN 输入界面提供这个选项，开启后数字键每次随机排列，肩窥者看到的按键位置下一次就失效了。这个功能存在感很低，但对抗录制类攻击非常有效。

第三，把自动锁定时间压到 15 秒。默认往往是 30 秒甚至更长。手机放桌上转身接杯水的工夫，15 秒和 30 秒的差别就是“锁上了”和“没锁上”。

第四，关掉锁屏通知的内容预览。验证码、聊天内容、邮件标题全都直接显示在锁屏上，这跟锁屏密码防的东西是矛盾的。设置路径在“设置 → 通知 → 锁屏通知”，选“不显示内容”。

第五，清理智能解锁的信任项。信任设备、信任位置、可信人脸这几项，只要有一项成立，锁屏就等于形同虚设。我把信任位置全关了，信任设备只留了一个蓝牙耳机——而且这个决定我后来又反悔了，原因见下一节。

第六，清空调试授权列表，用完就关调试开关。开发者选项里的“撤销 USB 调试授权”是个好东西，建议每次连完电脑都点一下。

注意：智能解锁里的“信任设备”有个隐患——如果那个蓝牙设备本身没有锁，任何人捡到它靠近你的手机就能解锁。我关掉耳机信任项就是这个原因，便利性和安全性在这里的兑换比不划算。

3.2 应用开发者：别把 App 的安全押在锁屏上

这是我这些年最想对同行说的一句话。我见过太多应用把“用户有锁屏密码”当成安全前提，然后在本地明文存 token、存身份证号、存聊天记录。问题是锁屏只是设备的一道门，门后面的东西该锁还是得锁。

第一层，敏感数据必须用硬件密钥库里的密钥加密。安卓的密钥库支持把密钥生成在硬件安全环境里，密钥本身永远不出芯片边界。下面这段是生成一个“必须用户认证才能使用”的 AES 密钥的骨架：

val keyStore = KeyStore.getInstance("AndroidKeyStore").apply { load(null) } if (!keyStore.containsAlias("app_secret_key")) { val spec = KeyGenParameterSpec.Builder( "app_secret_key", KeyProperties.PURPOSE_ENCRYPT or KeyProperties.PURPOSE_DECRYPT ) .setBlockModes(KeyProperties.BLOCK_MODE_GCM) .setEncryptionPaddings(KeyProperties.ENCRYPTION_PADDING_NONE) .setKeySize(256) // 关键：每次使用都要求用户先通过设备凭据或生物识别 .setUserAuthenticationRequired(true) .setInvalidatedByBiometricEnrollment(true) // 新增指纹即失效，防止被冒用录入 .build() KeyGenerator.getInstance( KeyProperties.KEY_ALGORITHM_AES, "AndroidKeyStore" ).apply { init(spec) }.generateKey() }

这里有两个参数值得单独说。setUserAuthenticationRequired(true)让密钥的使用和用户认证绑定，攻击者就算拿到应用沙盒里的密文，没有用户认证也解不开。setInvalidatedByBiometricEnrollment(true)是个容易被忽略的细节：它的作用是新增生物特征录入后旧密钥直接失效，防止有人偷偷录入自己的指纹然后慢慢解数据。这个参数在取证场景里价值极高。

第二层，认证要用带密码学对象的生物识别。只调一个“认证成功”的回调是不够的，因为那个回调可以被 hook。正确的做法是把CryptoObject传进去，让认证结果和一次具体的加解密操作绑定：

val prompt = BiometricPrompt(activity, executor, object : BiometricPrompt.AuthenticationCallback() { override fun onAuthenticationSucceeded(result: BiometricPrompt.AuthenticationResult) { // 只有带上 CryptoObject，这里的 cipher 才是可信的 val cipher = result.cryptoObject?.cipher ?: return val plain = cipher.doFinal(cipherText) } }) val promptInfo = BiometricPrompt.PromptInfo.Builder() .setTitle("验证身份") .setAllowedAuthenticators( BiometricManager.Authenticators.BIOMETRIC_STRONG or BiometricManager.Authenticators.DEVICE_CREDENTIAL // 生物识别不可用时回落到 PIN ) .build()

第三层，把 root 检测和调试检测当成风控信号，而不是安全防线。这是我踩过的坑：早期版本我把 root 检测当成“检测到就退出”，结果用户一投诉就改，改成“检测到就警告”，最后干脆只上报日志。原因很简单，root 检测永远是猫鼠游戏，绕过的成本极低。正确的定位是：它只影响风控评分和部分功能降级，绝不应该成为“数据是否解密”的判定条件。数据解密只认硬件密钥。

第四层，别在本地存长期有效的凭据。access token 有效期压到小时级，refresh token 存进加密存储并且绑定设备指纹，敏感操作强制二次认证。这些是服务端和客户端配合的事，单靠客户端做不到，但客户端能决定自己存多少。

3.3 设备管理者：策略层直接把图案登录关掉

如果是企业配发的设备，那就别指望用户自觉了，直接在策略层强制。安卓的企业管理接口里，密码策略这一块能力挺全的。核心思路是：把密码质量要求提到“数字 PIN 及以上”，图案自然就被禁用了——因为图案属于最低的质量档位。

val dpm = context.getSystemService(Context.DEVICE_POLICY_SERVICE) as DevicePolicyManager val admin = ComponentName(context, MyDeviceAdminReceiver::class.java) // PASSWORD_QUALITY_NUMERIC 要求至少是数字密码，图案不满足，等于禁用了图案登录 dpm.setPasswordQuality(admin, DevicePolicyManager.PASSWORD_QUALITY_NUMERIC) dpm.setPasswordMinimumLength(admin, 6) dpm.setPasswordMinimumLetters(admin, 0) dpm.setPasswordHistoryLength(admin, 5) // 禁止复用最近 5 次密码 dpm.setMaximumFailedPasswordsForWipe(admin, 10) // 连续失败 10 次触发擦除 dpm.setMaximumTimeToLock(admin, 30_000) // 30 秒自动锁屏 dpm.setRequiredPasswordComplexity( // 较新版本上的等效接口 DevicePolicyManager.PASSWORD_COMPLEXITY_MEDIUM )

几个参数的选择理由，我说明一下：

• PASSWORD_QUALITY_NUMERIC而不是PASSWORD_QUALITY_SOMETHING。后者允许图案，前者不允许。这个区别很多人搞混。
• setPasswordMinimumLength(6)起步。四位 PIN 只有 13.3 bit，在离线场景下几乎等于没有。
• setPasswordHistoryLength(5)防止员工在几个常用密码之间来回切，这个比想象中重要。
• setMaximumFailedPasswordsForWipe(10)是个双刃剑。设太小，员工误操作会丢数据；设太大，等于没有。10 次是我在多个项目里试出来的平衡点，前提是必须配合服务端数据同步，本地擦除不能导致业务数据丢失。

还有一条不在密码策略里但同样关键：关掉不必要的调试能力，并强制开启存储加密校验。后一项在新设备上是默认的，但在设备管理场景下建议显式检查和上报，因为总会有那么几台老设备混在采购清单里。

4. 常见误区与自查实录

这一节是我这几年被问得最多的问题合集，加上一些我自己踩过的坑。有些误区流传太广，以至于成了“常识”，纠正起来特别费劲。

4.1 六个流传很广的错误认知

误区一：“贴了防窥膜就安全了”。防窥膜管的是左右视角，管不了正上方和斜上方，更管不了屏幕表面的油脂痕迹。它降低的是肩窥成功率，不是污渍攻击的成功率。两件事别混为一谈。

误区二：“开了指纹就不用管锁屏密码了”。恰恰相反，指纹只是快捷入口，底层凭据还是那个 PIN 或者图案。而且指纹有个 PIN 没有的问题：你没法拒绝，也没法在胁迫下“输错”。很多设备的锁屏界面提供“禁用生物识别”的快捷方式，我建议把它记住。

误区三：“密码够长就万事大吉”。长度只在离线场景里对抗穷举有用。在肩窥和污渍攻击面前，一个十二位的复杂密码和一个四位的 PIN 没有本质区别——都是被看着输进去的。

误区四：“恢复出厂设置就彻底干净了”。现代设备开了文件级加密之后，恢复出厂会把密钥销毁，数据确实不可恢复，这一点比早期好太多。但如果加密没开，或者设备是老系统，残留数据是有可能被恢复的。转卖二手设备前，我的做法是先恢复出厂，再随便写满一遍大文件，再恢复一次。

误区五：“刷了第三方系统更自由更安全”。自由是真的，安全基本相反。完整性校验链条断了，系统更新滞后，预置组件来源不明，这三条加起来比原厂系统风险高得多。测试机随便刷，日常机别碰。

误区六：“锁屏密码忘了就只能刷机”。现在主流设备都提供了账号验证的恢复路径，包括网页端的查找设备功能、账号密码验证后重设锁屏凭据。这些是官方支持的合法路径，走这条路比找路边店铺“解锁”安全一万倍——后者往往要你交出账号密码，或者直接给你装一堆东西。

4.2 五分钟自查：你的设备处在哪个风险档位

与其记一堆建议，不如做一次体检。下面这些命令走的是调试通道，属于自查用途，需要你在开发者选项里临时开启调试并授权自己的电脑：

# 1. 系统是否处于可调试状态（日常应为 0） adb shell getprop ro.debuggable # 2. 引导加载器是否可解锁（日常应为 0 或 false） adb shell getprop ro.oem_unlock_supported adb shell getprop sys.oem_unlock_allowed # 3. 存储加密状态（应为 encrypted） adb shell getprop ro.crypto.state adb shell getprop ro.crypto.type # 4. 系统版本与安全补丁级别（补丁太旧就是高风险） adb shell getprop ro.build.version.release adb shell getprop ro.build.version.security_patch

判读标准我整理成表：

跑完这几条，心里基本就有数了。我最常看到的问题是补丁级别停留在两年前，尤其是在“能用就行”的备用机上。备用机往往绑着支付账号，这个组合风险很高。

4.3 忘记手势之后的合法恢复路径

顺便说一下这个高频问题，因为很多人第一反应是找第三方工具，那才是真正的坑。官方支持的路径无非三条：账号验证后重设锁屏凭据、通过网页端查找设备功能远程重设、以及最后的恢复出厂。前两条不丢数据，第三条丢数据但干净。

我特别想提醒的是：任何声称“不丢数据解锁”的第三方服务，都要先问它凭什么能做到。能绕过锁屏读到数据的，只有两种可能——要么它利用了一个尚未公开的漏洞（那它不会拿来给你解锁手机），要么它在骗你（收了钱给你恢复出厂，或者顺手装点东西）。这个逻辑很简单，但在着急的时候特别容易忘。

5. 踩坑之后的几点个人体会

最后说几个偏主观的判断，都是被现实教育出来的。

第一个体会是，安全的瓶颈从来不是技术，而是“最后一公里的摩擦”。我给不少人配过六位随机 PIN，两周后再问，一半人改回了四位。原因很统一：每天解锁几十次，多按两位的烦躁感累积起来受不了。所以现在我的建议顺序变了，先推“随机化键盘 + 15 秒自动锁”这种一次性设置、长期零成本的改动，再谈密码长度。能坚持下来的弱方案，胜过坚持不下来的强方案。

第二个体会是，看一台设备安不安全，先看它的引导状态，而不是看它装了什么安全软件。我见过装了三个“安全卫士”却把引导加载器解锁着当日常机的，也见过什么防护软件都没装但原厂系统、补丁最新的。后者的实际风险低得多。这个判断标准比任何检测工具都准。

第三个体会是关于开发者的。我参与过一个项目，早期把用户凭证明文存在偏好设置里，理由冠冕堂皇——“设备有锁屏密码，本地数据是安全的”。后来做安全评审，我们花了整整两周做迁移，还要处理存量数据的兼容。这笔账如果在设计阶段算，成本不到一天。所以每次有人问我“本地存点东西要不要加密”，我的回答都是：先问这个数据泄露了谁受损，再问加密要写几行代码。答案通常是“用户受损”和“不到二十行”。

第四个是关于评估方法论的。标题里那种“一秒破解”的说法，传播力强但容易误导。我现在的习惯是，看到任何安全结论都先问三件事：攻击者需要什么前提？这个前提在现实中有多容易满足？满足之后影响多少用户？把这三问答完，绝大多数耸动的结论都会落地成一个具体的、有边界的事实。手势密码确实弱，但它的弱是有条件的弱；把它换掉不难，难的是搞清楚为什么换。