SQL Server 的密码查 master 数据库里，syslogins 表存着所有登录账号的看器密码哈希。这事我最早是密码查在一次内部安全审计里撞见的——客户丢过来一个 .bak 备份文件，说怀疑有离职员工留了后门账号。看器我 restore 到本地实例，密码查打开 SSMS，看器一句 SELECT name,密码查 password FROM syslogins 下去，三十多个账号的看器哈希全列出来了。那一刻我就明白，密码查所谓“SQL密码查看器”根本不是看器什么神秘工具，它干的密码查事跟这条查询没本质区别。
很多人第一反应是看器去找现成软件。网上一搜，密码查确实有一堆标着“SQL密码查看器”的看器小工具，界面大同小异：让你选实例、密码查填账号、点连接，然后弹个框显示密码。但这些东西底层逻辑分两派。一派走的是 SQL 协议本身的漏洞——准确说不是漏洞，是设计遗留。SQL Server 2000 及更早版本，密码哈希算法是单轮 SHA1 加盐，盐值就是账号名本身。这种哈希在今天的显卡面前跟明文没区别。另一派工具干脆就是连上实例后跑我上面那条查询，把哈希拉出来，再调用本地字典或彩虹表去撞。
我见过一个挺典型的案例。某制造企业的 ERP 数据库用了 sa 账号，密码设成 Admin@123。他们的 IT 主管坚持说“密码很复杂，没人能猜出来”。我拿 SQL 密码查看器一跑，哈希值秒出，再丢进 hashcat 跑规则攻击，不到四秒就还原了。问题不在密码本身有多弱，而在于 SQL Server 2000 的哈希机制让任何中等复杂度的密码都变得可逆。后来他们升级到 SQL Server 2019，同样的密码，hashcat 跑了一整夜也没出来——因为 2012 之后的版本改用了 PBKDF2 迭代加盐，撞库成本直接翻了几个数量级。
那这类工具到底合不合法？我的看法是：工具本身中性，关键看你怎么用。企业自己的 DBA 在授权范围内做密码审计，跑查看器把弱密码筛出来强制改掉，这是正经安全运维。但如果是拿着别人的 .bak 文件或者趁人不备连上生产库，那就是另一回事了。我认识一个做渗透测试的朋友，他接单时必带一份授权书，上面明确写了“允许对目标 SQL Server 实例进行密码强度检测”。他说有一次客户内部审计部门自己用查看器扫了一遍，发现财务系统的 sa 密码居然是 sa，当场惊出一身冷汗。
技术细节上，如果你真想自己动手而不是下载来路不明的 exe，可以走这条路：先拿到 master.mdf 或者一个完整备份，restore 到隔离环境。然后连上去执行 SELECT name, password_hash FROM sys.sql_logins（2012 及以上版本）。注意看 password_hash 字段的格式，0x0200 开头的是 SHA512 加盐，0x0100 是 SHA1 加盐，没有前缀的裸 0x 就是 SQL 2000 的老古董。拿到哈希后，用 hashcat 的 1731 模式（MSSQL 2012）或 131 模式（MSSQL 2000）去跑。字典别用网上随便下的，自己根据企业命名习惯生成一份，命中率会高很多。
有个坑得提一下。不少“SQL密码查看器”在连远程实例时会尝试用 xp_cmdshell 或者 OLE Automation 去提权，这会触发 SQL Server 的审计日志，而且很多企业防火墙会直接阻断。所以真要做审计，最好还是拿备份文件在本地跑，别去碰生产环境。我自己习惯用 Docker 起一个干净的 SQL Server 容器，把备份 restore 进去，查完直接删容器，不留痕迹。
最后说个观察。这几年 SQL Server 的密码哈希强度上来了，但人的习惯没变。我统计过手上经手的二十多个案例，超过六成的弱密码集中在三类：带年份的 Company@2023 变体、键盘路径 1qaz2wsx、以及跟业务系统同名的账号密码。查看器能帮你把这些揪出来，但改密码这事，终究得靠制度和意识。工具再顺手，也架不住有人把密码写在便利贴上贴显示器边框。