MYSQL网页编程之SQL SERVER数据库口令的懦弱性
对于现有业务，可以轻松移植到MySQL。当你需要替换掉老的硬件，当你需要削减历史遗留下的老系统的时候，选用MySQL对于财务部门来说更具吸引力。跟踪了一下SQLSERVER数据库服务器的登录历程，发明口令盘算长短常懦弱的，SQLSERVER数据库的口令懦弱表现两方面：1、收集上岸时分的口令加密算法
2、数据库存储的口令加密算法。
上面就分离报告：
1、收集上岸时分的口令加密算法
SQLSERVER收集加密的口令一向都十分懦弱，网上有良多写出来的对比表，可是都没有详细的算法处置，实践上跟踪一下SQL
SERVER的上岸历程,就很简单猎取其解密的算法：好吧，我们仍是演示一下汇编流程：
登录范例的TDS包跳转到4126a4处实行：
004DE72E：依据吸收到的巨细字段天生对应巨细的缓冲区举行下一步的拷贝
004DE748从吸收到的TDSBUF偏移8处拷贝出LOGIN的信息
004DE762：callsub_54E4D0：将新拷贝的缓冲压进举行参数反省的处置
顺次处置TDS包中的信息，各个字段天气都应当有各个域的长度，偏移0X24处与长度举行对照。
上面这段汇编代码就是完成对收集加密暗码解密的算法：
.text:0065C880movcl,.text:0065C882movdl,cl.text:0065C884xorcl,5.text:0065C887xordl,0AFh.text:0065C88Ashrdl,4.text:0065C88Dshlcl,4.text:0065C890ordl,cl.text:0065C892mov,dl.text:0065C894incedi.text:0065C895deceax.text:0065C896jnzshortloc_65C880.text:0065C898jmploc_4DE7E6
很简单就将其换成为C代码，能够看出其加密及其复杂,和明文没甚么区分，呵呵，人人能够在SNIFFER中嵌进这段代码对嗅叹到的TDS上岸包举行解密，实在0XA5不是特定的SQLSERVER暗码字段的分界标记，只是因为加密算法会主动把ASC的双字节暗示的0x0加密成0xa5罢了，可是假如同意双字节口令，这个就不是判别其分界的次要缘故原由了。
voidsqlpasswd(char*enp,char*dnp){inti;unsignedchara1;unsignedchara2;for(i=0;i<128;i++){if(enp==0)break;a1=enp^5;a1=a1<<4;a2=enp^0xaf;a2=a2>>4;dnp=a1|a2;}dnp=0;dnp=0;wprintf(L"passwd:%s
",(constwchar_t*)dnp);}
2、数据库存储的口令加密算法
SQLSERVER的口令到数据库存储的加密办法，也是让人奇异的。其历程以下：
在取得收集解密暗码的口令今后在005F9D5A处callSQLSORT_14，完成一个转换为年夜写口令缓冲举行保留。
然后在004def6d处挪用一个函数掏出数据库中的加密的PASSWORD，其情势以下：
2个字节的头0x0100(流动）4个字节的HASH加秘KEY20个字节的HASH120个字节的HASH2
如我掏出的一个例子：
fx:0x01001751857FDFDEC4FB618D8D18EBA5A27F615639F607CD46BEDFDEC4FB618D8D18EBA5A27F615639F607CD46BE流动增补KEYHASH1HASH2口令是：123456
SQL起首用4个字节的HASH加秘KEY补上其两处口令的缓冲，一个为年夜写，一个为小写。然后其加密历程以下C函数:
CryptAcquireContextW(&hProv,NULL,L("MicrosoftBaseCryptographicProviderv1.0"),1,0xf0000000);CryptCreateHash(hProv,0x8004,NULL,NULL,&hhash);CryptCreateHash(hProv,0x8004,NULL,NULL,&hHash);005F9DFE：CryptHashData(hhash,passwdbuf,0x12,NULL);passwdbuf是小写的passwd缓冲区,然后附加一个KEY，如上例子就是对{1,23456,0x17,0x51,0x85,0x7F}如许的一个字串举行HASH加密CryptHashData(hHash,PASSWDBUF,0x12,NULL);PASSWDBUF是年夜写的passwd缓冲区,然后附加一个KEY005F9E3E：CryptGetHashParam(hhash,2,&passwdout,&outlen,0);掏出passwdbuf是小写的passwd的加密值CryptGetHashParam(hHash,2,&PASSWDOUT,&OUTLEN,0);
掏出passwdbuf是年夜写的passwd的加密值这两个相加就是真实的数据库中的PASSWORD加密字段.
为何说以上办法是懦弱的呢？实在其真实的加密长度天生只要20个字节。
小写口令的HASH1+年夜写口令的HASH1拼接的40位HASH值的平安度还不如一个间接20位的HASH值来得平安。由于人人都晓得这两个值的因果干系，
供应给懂得密者更多的信息。
如由于其算法一样，假如HASH1=HASH2，就能够判别口令一定是未利用字母，只利用了数字和标记的口令，如上掏出的123456口令的HASH，两个HASH完整相称。
就是利用了字母，其晓得增补的KEY，算法，两个加密字串的干系，其解应当也是年夜年夜的简化了。下面我将描述五个不使用MySQL的响亮理由。 我们学到了什么？思考问题的时候从表的角度来思考问 同样会为索引视图等应用带来麻烦。看看行级和事务级的快照数据放在tempdb中，就能感觉到目前架构的尴尬。 这一点很好的加强了profiler的功能。但是提到profiler提醒大家注意一点。windows2003要安装sp1补丁才能启动profiler。否则点击没有反应。 一直以来个人感觉SQLServer的优化器要比Oracle的聪明。SQL2005的更是比2k聪明了不少。（有次作试验发现有的语句在200万级时还比50万级的相同语句要快show_text的一些提示没有找到解释。一直在奇怪。） 也可谈一下你是怎么优化存储过程的? 备份方面可能还是一个老大难的问题。不能单独备份几个表总是感觉不爽。灵活备份的问题不知道什么时候才能解决。 而SQLServer如果能像Oracle一样可以为登陆分配如：5%的cpu，10%的内存。就可以解决这个漏洞。 连做梦都在想页面结构是怎么样的，绝非虚言
页:
[1]