sqlserver数据库里密码破译

SQL Server的据库密码从来不是“破译”出来的，多数时候是码破猜出来的。我见过太多人把sa密码设成123456，据库或者干脆用公司名字加年份。码破去年帮一个客户做安全评估，据库扫了三百多台数据库，码破四十七台用同一个密码：Admin@2023。据库这不是码破破译，这是据库撞大运。

真正要聊的码破是那些稍微有点技术含量的路子。SQL Server的据库密码存储分两种，SQL Server认证的码破登录名，密码哈希存在master数据库的据库sys.sql_logins里，2005以后是码破SHA-512加盐，2012以后还加了PBKDF2的据库迭代。想直接逆推？理论上可行，但成本高到不如直接买通DBA。

但有个东西经常被忽略：SQL Server允许你导出登录名的哈希。如果你已经拿到sysadmin权限，跑一句SELECT name, password_hash FROM sys.sql_logins，所有SQL认证账号的哈希就到手了。然后呢？拿hashcat跑字典。我实测过，一台2080Ti的机器，针对SHA-512的哈希，每秒能试大概三百万次。八位纯数字密码，三分钟出结果。八位大小写加数字，得跑三天。

更有意思的是那些老版本。SQL Server 2000的密码哈希是单轮SHA-1，没盐。有个客户还在跑2000，我导出一看，sa的哈希直接丢进在线彩虹表，两秒钟就弹回明文：sa123。这密码用了十五年，没人改过。

还有一种情况是连接字符串泄露。很多应用把数据库密码硬编码在配置文件里，或者更糟——写在源码里。GitHub上搜“connectionString”加“Password=”，能翻出几万个结果。我见过一个项目，web.config里明文写着sa密码，而那个网站有文件上传漏洞。攻击者不需要破译任何东西，读一下配置文件就行。

SQL Server有个功能叫“包含数据库”，Contained Database，允许在用户数据库里直接做认证。这个设计本身没问题，但很多人不知道，包含数据库的密码哈希存在用户数据库的sys.database_principals里。如果你备份了一个包含数据库，然后恢复到自己的实例上，就能拿到哈希。这算是个合法的“破译”路径——不用攻击任何东西，只要拿到备份文件。

再说说暴力破解。SQL Server默认没有登录失败锁定策略。你可以无限次尝试sa密码。写个脚本，用sqlcmd或者ODBC，每秒能试几十次。我做过测试，针对一个八位小写字母密码，本地网络能跑到每秒两百次尝试，四小时就破了。如果密码是字典词加数字，比如“password1”，三十秒的事。

防御方法其实很直接。禁用sa账号，用Windows认证，如果非要用SQL认证，密码至少十二位，混合大小写、数字、符号。开启登录审计，失败超过五次就锁。别用包含数据库，除非你真的需要。还有，别把连接字符串放在源码里，用Windows认证或者至少加密配置节。

最后说个真事。有个开发跟我说他的数据库密码是“!QAZ2wsx”，觉得够复杂了。我看了眼键盘，这是键盘左上到右下的斜线序列。hashcat的键盘模式规则，三分钟就出来了。密码强度不是看字符集，是看熵。人脑能记住的“复杂”密码，在规则引擎面前跟“123456”没区别。

所以别想着破译，想想怎么让破译变得不划算。密码长度比复杂度重要，随机性比记忆性重要。至于那些还在用sa/123456的，不是技术问题，是态度问题。

很赞哦!（61）