平时白天使用中国建设银行个人网上银行系统并不多，今天由于要做一笔转帐，在下午登录个人网银系统并输入正确的身份信息后，竟然显示这样一条比较有意思的错误信息：
＂超流量拒绝＂还真是个新词，不知道是建设银行发明的，还是网银系统的平台厂商 IBM 发明的，难道是 QoS ？
此外也觉得＂拒绝＂二字有点生硬，即使不是谦语，也难道不能有更人性一点的提示吗？
好消息：湖北告破熊猫烧香电脑病毒案，抓获8名疑犯
如此 Keywords
号称“国内最火热的IT 产业资讯站点太平洋产业资讯”（地址：http://www.pconline.com.cn/news）
看看其页面源码：
<title>|><| 国内最火热的IT产业资讯站点–太平洋产业资讯</title>
<META NAME=”description” CONTENT=”国内最火热的IT新闻频道，最多IT业界内幕的新闻频道，扎根市场深入渠道的IT新闻报道，全方位透视IT业界，联系消费者与业界人士的IT新闻频道。”>
<META NAME=”keywords” CONTENT=”google，CEO，网络，名人，财报，思科，SUN，微软，网络，三星，甲骨文，oracle，microsoft，office，riaa，盗版，色情，裸体，歌星，影星，排行，联想，苹果，宽带，资费，adsl，电影，音乐，破产，收购，liunx，开源，共享，网络，垃圾邮件，网站，itunes，cnnic，3721，百度，IBM，windows，p2p，黑客，破解，病毒，、为，小灵通，UT斯达康，3G“>
为了搜索结果，道德和脸面都不要了。
授权管理器（AzMan）中授权策略信息的存储方式的选择
授权管理器（AzMan）是 Windows Server （2000、2003、Longhorn Server…）中自带的、能够和AD紧密集成的、供应用程序使用的授权检查引擎，它实现了完整的基于角色的授权管理框架，利用它，可以在应用程序中大大简化与授权有关的代码编写与实现。
在目前版本中，授权策略信息有两种存储方式：
- XML
- 目录（如活动目录－AD或ADAM）
上述两类三种存储方式的适用场景分别如下：
- 简单的小型应用可以直接使用XML，在这种方式中，不用设置/扩展 AD/ADAM 的 Schema，非常方便
- 如果基础域环境不好（如应用程序不便访问DC、存在多个Domain）等情况时，可以使用 ADAM
- 如果基础域环境较好，且应用程序的身份完全与AD集成，最好使用AD
在 Vista 中，AzMan 又增加了一种存储方式：SQL Server，这样对于应用程序来说，又多了一种更实用的选择，而且即然能存在 SQL Server中，估计通过一些手段，这些信息也能存储到其他类型的数据库中，如Access、Oracle等，现在 ASP.NET 2.0中的一些 Provider 不也是公开源代码了，并且实现了其他数据库类型的 Provider 了嘛。
不过，AD/ADAM 具有复制功能，可以方便地实现多个实例之间的目录同步，而SQL Server 不具有此功能，另外 AD/ADAM 在查询方面具有性能优势（AzMan的绝大多数请求是查询），所以到底要使用哪一种存储方式，还是要综合评估。
关于 AzMan 的更多信息，可以参考 AzMan MSDN Blog。
网上银行安全事件的反思
今年以来，网上银行安全事件层出不群，闹得沸沸扬扬，据网易财经：网银危机（http://finance.163.com/special/002521GA/ebank.html）上公布的信息，受害者近千人，损失资金金额也近千万元。
如果你在银行的科技部门，就知道这些事件带来的波动效应有多大，几乎所有银行的网上银行都极大的关注这些案件，从上至下，进行安全自查，封闭可能漏洞，关闭风险等级较高的功能，以最大限度地提高系统的安全性，降低客户的资金风险，当然，我也被折腾的够呛。可以说，工行此次事件不但给工行的声誉和上市进程造成了严重影响，而且几乎给所有其它银行的电子银行业务都带来很大的冲击和负面影响，我身边的好多人在了解到这些情况后，有的直接关闭了网上银行的功能，有的则坚定了不相信网上银行系统安全、而且决不开通网上银行功能的想法。
就整个事件反思，个人认为：
1) 工行的对整个事件的态度确实存在问题
在网上银行出了安全事件后，不分青红皂白，一律推到受害人身上，按“工行网银受害者联盟”（www.ak.cn）网站上事件相关人的描述，工行把受害人“妖魔化为弱智群体，然后把我们一脚踢到公安机关；甚至工行还混淆其商业银行的企业身份，对我们肆意诬蔑和打压”。
可以说，工行的这种态度是很多大型国有企业（包括其他行业）的通病，丝毫不出人意外，大家在日常生活中碰到这样的店大欺店案例并不鲜见。在最新一期的《新金融》杂志上，仍看见工商银行电子银行部的主管领导在推脱责任，说问题全出在用户身上。
个人对此也深有感触，有一位同学在工行数据中心，我们在聊起此事时，他仍坚称：整个事件仍是“别有用心”的人在夸大其辞，即使其中真有受害人，那也是他自己太笨。个人以为目前在中国，没有人敢公开地对中国工商银行这样的大目标“别有用心”，所以我宁愿相信，www.ak.cn 上公布的受害人，不存在造假的可能。
态度决定一切，国家足球队原主主教练米卢这话说得没错，我相信，如果工行不是始终独善其身、推脱责任的态度，事件也不会闹到如此地步。
回过头来看看招行，能够在网站上开通论坛，专门收集网友的反馈，来不断地更改和升级系统，印证了其“因您而变”的企业口号，其他哪家银行能有些魄力开这样一个论坛？ 当然了，以现在这种系统的水平，最好还是不要开，会被口水淹没的。
2) 工行的系统确实存在问题
据我个人估计，这次大面积暴发的网上银行安全事件的主要原因就是出在工商银行网上银行系统登录页面的安全控件上，工行最早的网上银行系统使用的是普通的 HTML 控件，而且也没有使用验证码，后来，在系统升级时，加入了图片验证码，也加入了安全控件，但这个所谓“安全控件”的安全性并不高，不但不能防止大部分键盘记录软件（KeyLogger）的截获，也没有对数据进行加密（详见于2004年我对此进行的分析：网上银行“安全登录控件”分析），再后来，他们再次对安全控件进行了升级，对数据进行了加密，也能够防止大部分 KeyLogger 的截获，但据了解内情的人员透露，仍然存在漏洞，工行也在考虑进行进一步的升级。
有人也许会说，工行的系统管不了用户机器上的木马，但是，系统安全是一个整体的概念（信息安全领域的“木桶理论”），光做到银行端的安全是没有用的，黑客不会找最安全的地方来进攻的，即然网上银行系统的页面扩展到了用户端，那么银行就有责任地保护这部分应用（最薄弱的部分）的安全。
3）工行的安全事件响应机制存在问题
按照中国人民银行和银监会（它们在此次事件中也有监管缺失的问题）有关要求，商业银行在开办网上银行时，一定要建立安全事件响应机制。但就此次事件来看，没看出来他们的响应机制在哪里，首先是没有积极地帮助受害人锁定帐户，其次是没有积极与公安机关配合，尽早对所有事件统一分析，统一处理，而只是在事件闹得沸沸扬扬的时候，才“正面回应”，结果仍是“工行回应网银资金失窃案 称系统不存在漏洞”（http://news.tom.com/2006-08-18/000N/78413992.html）。
按说对于网上银行这种安全性要求非常高的系统来说，系统务必要记录访问客户端的所有细节，不但应包括最重要的客户端 IP 地址，还应该包括 HTTP 请求（Request）中的所有变量，如远程主机名、User_Agent、HTTP_REFERER、Accept-Language/Encoding等数据，这些数据将对追踪访问人、电子取证、案例侦破提供提供非常有力的证据，很多系统会记录 IP 地址，但往往会忽视其它一些特征数据的记录，而通过对这些数据的分析，有助于对那些通过代理来进行犯罪的黑客进行证据搜集。据个人分析，这些重要数据很可能被工行的网上银行系统所忽视，以至于影响了有效的响应过程。
其次，以工行的这样的大型企业来说，在事件发生时，完全有能力直接与最高级别的公安机关对话，对整个事件统一立案，集中力量统一侦破，相信很快会有结果，但是据了解，工行直到最近才把这事做起来，但这里，大好的时机都错过了。
4）客户所承担的安全成本太高
这不仅是工行的问题，几乎其他所有银行的网上银行系统都存在此问题，个人以为，在 USB-Key（工行称之为 U 盾）上赚客户的钱，纯属利令智昏之举，有的银行甚至以此来做为利润科目，实在是一大耻辱，这就和CCTV以送台大熊猫起名的时机敛财、欺骗全国人民感情的恶举如出一辙（年初起的名，现在还没有送过去），自己图名利，别人来买单。
既然是你系统提供的安全认证手段，费用就应该你自己负责，如果 USB-Key 收费，那是不是设置帐户/卡的口令也要收费？ 即使收费，收点成本成不？ 现在 1G 的U盘才多少钱，你那个 USB-Key 要收近百元？
除此之外，包括工行在内的多家银行收取所谓的“网上银行年费”，说的不客气，纯属脑子进水，想不明白确定收费的这些决策人员到底有没有了解网上银行业务对于网点/柜台减负所带来的成本节约？
我相信，USB-Key 的代价较高是绝大多数用户没有选择它的原因所在，工行现在推动态口令卡，依我看没必要，把 USB-Key 取消/少量收费即可。
还有一些小细节：大家现在访问一下工行网上银行系统，在登录页面上，仍然没有一些醒目的安全提示，登录页面那么大，就容不下一段关于防止身份盗用的说明？ 看看页面源码，很多数据检查/校验的机制仍光溜溜地用 JavaScript 显示在那里，在看看进入系统时的这个地址：http://www.icbc.com.cn/wangyin_xitong/alert.jsp（网银_系统），不能起一个好一点、专业一点的目录名吗？（此网站上诸多目录都是以中文拼音命名）
=========================================================
回顾这个尚未结束的事件，可以认为它是对工商银行在网上银行系统安全保护不够完善的一个教训，也是对其他银行的一个警示，未尝不是坏事，亡羊补牢未晚也。当然了，要说推脱，工行还是有些理由的，毕竟它的网银用户数量在国内是最大的，因此黑客会选择攻击它的用户（这和微软的软件最常被攻击的原因类似），但是，只要扎扎实实地、全面地、负责任地做好安全工作，不要老喊口号而未真正地付诸行动，相信前景还是美好的，网上银行业发展的大潮仍是浩浩荡荡不可挡。
个人以此事件为启发，就网上银行系统的安全性来说，提出一些以后需要关注的问题：
1）降低客户所承担的安全成本，如 USB-Key 费用的降低，大力推广数字证书的应用；
2）学习招商银行（这似乎让很多大银行很没有面子），发展基于浏览器的专用客户端，不但功能更为强大、操作更为快捷方便，而且能够有效避免假网站、木马型病毒的攻击。我们看看欧美地区，大多数的较大的银行都支持OFX（开放金融协议），通过 Microsoft Money 等专用客户端可以直接连接到它们的系统中，个人认为这也是国内网上银行系统的发展方向；
3）改变目前系统中这种通过用户+密码的传统认证方式，只要使用用户名/密码，就有可能受到键盘记录木马的威胁，要彻底的解决此问题，必须
使用全新的身份鉴别技术。例如在 .NET Framework 3.0 中新推出的 CardSpace 技术（内置在 Windows Vista 中，可以安装在 Windows XP 上），就可以彻底地避免键盘记录软件、通讯侦听软件对身份鉴别过程的威胁；
4）进一步加强应用的安全性，在事前、事中、事后各个环节提高可控性，例如：可疑交易的确认（类似于信用卡的可疑消费确认），用户可自行设置登录时段、登录位置（如只限于北京地区）、进行风险等级较高的操作时，能够及时发送短消息通知用户，能够快速定位交易对手（转出时的目标帐户）的相关信息，能够快速锁定可疑账户，能够更完全面的记录客户端的信息，能够进行行为分析；
5）继续有策略、有技巧、持之以恒地加强用户安全教育，这在目前中国的互联网界流氓软件满天飞、普通用户极端受害的情况下，是非常非常有必要的。
TechED 2006 参会印象
1、看起来参会人员似乎和去年差不多，可房间却十分紧张，最后挤在四人间，而且距离会场较远，TechED 渐有成为唯一的微软年度盛会之势，PDC 已经两三年不见了；
2、有幸见到一位厉害人物，VB 产品组的总经理潘正磊，从 Access 1.0 做起一直到现在 14 年，参与主持开发的产品很多，虽然自己现在 VB6, VB.NET 基本上用的 少了，但受到其个人魅力吸引，两堂课都听了，很受感慨，要是在中国，能找到这样一位14年编写代码，做产品规划和管理，还能在课上大讲 Debug 技巧与 Tricks/Tips 的人吗，一行一行调试代码的人吗？
3、Vista/Longhorn Server 的远程显示协议（RDP） 到 V6.0 ，支持 Gateway ，更安全（类似于 Outlook 的 RPC Over HTTPS），支持NAP（网络访问保护），可以直接支持远程应用程序，这个特性很 Cool，不过似乎很象 Citrix 的东西；
4、SharePoint 中的工作流基于 WF（为什么不叫 WWF 了？这和WPF、WCF不匹配呀）真不错，Kaneboy 演示的例子也非常好，看来也是精心准备的，可惜 kaneboy 问的问题没太有把握，没敢举手，没有拿到礼物，回头买一本支持一下，自己翻译过书，也知道写书、翻译书挺累的，要尊重作者劳动和知识 产权，呵呵，顺便夸奖一下 Kaneboy 的美女同事 TingLi ，技术、演讲能力都不错，同 Team 的其他成员都不错。回头再做开发的时候，要好好考虑一下能不能用 Infopath + SPS 2007 搞定，这样能避免大量无聊的代码了，开发生产力第一；
5、最近是国内各大银行网上银行的多事之秋，传统的“用户名+密码”的安全弱点已无法承担此重任，使用数字证书也仍然在端点上存在一些问题，Vista 的 CardSpace（InfoCard）技术来得正是时候，不过我估计给银行的决策人员介绍是可以，要用的话，估计还得段时间，要使用它，还是需要一些魄力与技术洞察力的；
6、今年听了一些 MOM 的课，东西是好东西，可如何说服领导花钱购买这个东西，提高管理水平，这似乎是个问题；
7、今年的动手试验室不错，但时间还是感觉紧张，脚本也没有翻译成中文，绝大多数人都做不完，不过能开放16个小时也不错，晚饭后还做了两个 Biztalk 2006 的试验，可惜没有带大硬盘，把这些虚拟机和资料 Copy 回家自己慢慢看；
8、今年的赞助商似乎不如去年，缺少去年 AMD 的那种气势；
9、今年的 MVP 活动感觉不如往年，没有很好的机会聚在一起好好聊聊，缺乏交流致使大家都不怎么互相认识，感觉比较陌生，而且把自己喜欢的一张 MVP 海报拉在房间里了，依旧感谢 MVP Lead 为我们申请的门票；
10、日程安排得挺紧张，有点累，得好好休息一下了，刚好凑够10条，呵呵。
Windows 的安全等级
最近在多处看到仍有人说 Windows 平台的安全等级是 C2 级，这里纠正一下。
正式获得 C2 级安全等级认证是 Windows NT 4.0 ，它是基于美国可信计算机系统评测标准 TCSEC（桔皮书，它把系统安全级别划分为 D、C1、C2、B1、B2、B3 和A级）上获得的，现在没有 TCSEC了，大家都遵循 CC（通用准则，它把系统划分为 EAL 1-7 级）了，Windows 2000、Windows XP SP2 和 Windows 2003 在 CC 上都是达到 EAL4+ 级。
TCSEC和CC 的考察维度和要求不太一样，因此两个标准的级别可比性不大，但有些人也对此对过比较，认为在保证性方面，CC 的 EAL4 相当于 TCSEC 的 B1，EAL4+ 比 EAL4 高，相当于原有的 B1 – B2 之间。
新名词 – Ransomware 勒索软件
先列出大家都了解的一些常见的与安全相关的名人堂：
- 病毒 － Virus
- 蠕虫 － Worm
- 木马 － Trojan Horse
- 假病毒 － Hoax
- 恶作剧 － Joke
- 后门 － Backdoor
- 间谍程序 － Spyware
- 规模传播的邮件病毒 － Mass Mailer
- 僵尸程序 － Bot
- 广告软件 － Adware
- 恶意代码/脚本/代码 － Malware/MalScript/MalCode
- 网络钓鱼 － Phishing
- 键盘记录软件 － KeyLogger
- 行为记录软件 － Track Ware
- 窃取程序 － Stealer
- 垃圾邮件 － Spam
- 拨号软件 － Dialer
- 逻辑炸弹 － Logic Bomb
- 漏洞利用代码 － Exploit Code
- 流氓软件
现在又有新成员Ransomware － 勒索软件加入了，大家鼓掌欢迎，这里简要介绍一下它的政治面貌：
勒索软件（RansomWare）是黑客用来劫持用户资产或资源并以此为条件向用户勒索钱财的一种恶意软件。勒索软件通常会将用户系统上多种类型的文件，如文档、邮件、数据库、源代码、图片、压缩文件等，进行某种类型的加密操作，使这些文件不可用。勒索软件还可能通过修改系统配置文件，干扰用户正常使用系统的方法使系统的可用性降低。然后，通过弹出窗口、对话框或生成文本文件等的方式向用户发出勒索通知，要求用户向指定帐户汇款来获得解密文件的密码或者获得恢复系统正常运行的方法。
查看：勒索软件详细介绍 | 全国首例传播电脑病毒敲诈案告破
新书预告：《数据库加密-最后的防线》
function act(no)
{
if(document.all.item(“x”+no).style.display==””) document.all.item(“x”+no).style.display=”none”;
else document.all.item(“x”+no).style.display=””;
}
前几天，思归提到数据库安全是个大问题，我深有同感，感觉现在大家在外围、应用安全上做的工作比较多，往往忽视了数据库的保护，而这部内容恰恰是最关键的信息资产，正好本人与同事最近刚翻译完成了一本这方面的著作，《数据库加密——最后的防线》近期将由电子工业出版社出版，本书中详细介绍了如何对数据库的数据进行加密，同时给出了 Java 样例代码。
译序节选>> (单击显示/隐藏)
安全性本身涉及的内容和范围非常广泛，从整体层次上来说，包括安全策略、安全管理、物理安全、网络安全、主机安全、应用安全、数据安全等许多领域，针对这些主题，业界已经提供了大量成熟的解决方案和最佳实践，从微观上来说，安全基础技术——密码学的发展也相当成熟。通过在以上各个层次中合理地使用密码技术，能够有效地满足绝大多数安全需求，关于这些内容的安全资料和书籍非常丰富，但是唯一令人遗憾的是，关于密码学在数据库中的应用这个领域，即数据库加密，却被很多安全专家和技术人员所忽视，很少有人去研究，因此也鲜有相关著作，其主要原因是大家一般寄希望于数据库管理系统来保护数据的安全性，但是在实际应用中，数据库管理系统所能提供的保护作用是有限的。
大多数情况下，应用系统中最有价值的资产就是商业数据，尤其对一些特定行业，如金融行业来说，数据的机密机至关重要，甚至事关企业的命运和发展。例如去年美国付款信息处理公司CardSystems遭受黑客入侵，造成了美国史上最大一起的数据泄露事件，此次泄密事件波及的信用卡用户多达4000万人，严重影响了全世界范围的数千万客户，甚至包括中国的数千名用户，这使得银行和信用卡公司不得不为所有客户重新换发所有信用卡，这不但带来了巨大的业务损失，更重要的是，对公司的声誉、客户的信心带来了沉重的打击。
由此可以看出，数据安全在整个系统安全中非常重要的一个环节，虽然应用程序和数据库管理系统可以为数据提供相当程度的安全保证，但是要看到，由于数据在物理上一般存储在单独的服务器上，攻击者可以很容易破解或绕过应用程序而直接访问数据库，另外，由于数据库管理系统使用不当或者攻击者绕过数据库管理系统来直接访问数据库所对应的原始文件，数据库管理系统所提供的安全保护也失效了，除此之外，那些合法的用户，如数据库管理员、应用开发人员都有可能轻易读取数据库中的内容，从而破坏数据的机密性。因此，如果不在数据库内部实施额外的安全措施，如数据库加密，就难以完全保证数据的安全性。
考虑到数据库系统的复杂性，因此保护数据库并对其进行加密也是一个非常错踪复杂的问题，如密码算法和模式的选择、密钥的管理等，如何才能有效地入手呢？《数据库加密——最后的防线》，这本来自业界领先的安全公司 Symantec IT应用与数据库安全项目主管的著作，将带给你这些问题的答案。
在本书中，作者Kevin Kenan全面地介绍了与数据库加密这个主题有关的方方面面的问题。包括了解保护数据的必要性，如何构建一个真正的数据库威胁模型，加强数据库安全的需求分析、对数据进行分类、如何编写与密码系统安全交互的数据库应用程序、避免常见的威胁数据库安全的漏洞和问题，以及如何在测试、部署、保护及终止过程中保护数据库应用的安全性等。
本书分为四大部分，第一部分首先介绍了安全性的基本含义及其在数据库中的具体体现，随后讲述了密码学和数据库的一些基础知识和密码学在数据库中的应用。在第二部分中，介绍了密码系统的基础架构和密码系统中的各个组件，如密钥库、密钥管理器、密码提供者、密码引擎等。
第三部分介绍了密码系统的项目管理，描述了一个项目开发生命周期的各个阶段应該注意的安全问题，如在需求阶段进行需求定义、确定策略、标准及算法，在设计阶段，提到了应該遵循的安全设计指南及最佳实践，并介绍了威胁建模及安全模式方面的内容。在开发阶段，介绍了应該注意的最主要的安全开发实践；在测试阶段，主要介绍了安全功能测试和穿透测试，前者是从正面的角度测试各种功能是否存在，而后者是从攻击者的角度来测试系统安全措施的有效性如何，是否存在任何漏洞。最后，介绍了应用程序在部署、运行及终止阶段应該注意的安全问题，这是一部分很容易被忽视的重要内容。
在第四部分中，作者针对之前描述的各种理论、技术与实践，给出了一个数据库加密系统的Java实现，这是本书中非常有价值的一部分内容，通过这部分代码，读者可以更准确、更深入地了解本书中的内容，最后，给出了这个示例系统的运行演示。这些代码可以在少量修改后，就可以应用到实际的项目中去。这部分代码可以从作者的网站（http://www.kevinkenan.com）上下载，其中包括了相关的使用说明，包括如何建立初始数据库等。
目录节选>> (单击显示/隐藏)
第一部分：数据库安全
1、数据库安全问题
1.1、数据库面临的攻击
1.2、保护数据库的外部需求
2、使用加密保护数据库
2.1、数据库知识的快速复习
2.2、密码学是什么
2.3、密码学应用
2.4、加密的风险
2.5、加密面临的攻击
2.6、混淆
2.7、传输加密
第二部分：加密基础设施
3、加密基础设施概述
3.1、应用程序架构
3.2、加密系统加构
3.3、加密密钥
4、加密引擎和算法
4.1、本地引擎
4.2、专用引擎
4.3、加密算法
5、密钥存储库、清单和管理组件
5.1、密钥存储库
5.2、密钥清单
5.3、密钥管理组件
6、加密提供者和使用者
6.1、提供者
6.2、使用者
第三部分：加密项目
7、加密项目的管理
7.1、安全意识
7.2、客户参与
7.3、项目范围
7.4、项目角色
8、增强需求的安全性
8.1、安全需求、策略和标准
8.2、一般需求
8.3、需求复查
8.4、确定加密标准
8.5、数据分类
9、提高设计的安全性
9.1、数据流图
9.2、设计指南
9.3、威胁建模
9.4、安全模式
9.5、设计密码系统
10、安全开发
10.1、安全开发指南
11、测试
11.1、安全功能测试
11.2、穿透测试
12、部署、保护与终止
12.1、部署
12.2、保护
12.3、终止
第四部分：示例代码
13、示例说明
13.1、工具和通用服务
13.2、引擎与密钥库示例
14、密钥库
14.1、本地密钥
14.2、本地密钥的存储
14.3、访问本地密钥
15、清单
15.1、密钥别名
16、密钥管理程序
16.1、密钥工具-KeyTool
17、引擎
17.1、本地引擎
18、票据与提供者
18.1、加密请求与解密结果
18.2、票据
18.3、提供者
19、使用者
19.1、客户信息
19.2、信用卡信息
19.3、客户管理对象
20、异常
21、示例系统运行演示
21.1、设置密钥
21.2、操作客户信息
21.3、替换密钥
21.4、替换加密密钥的密钥
查看：Amazon 原版信息
网银大盗的作案手法
之前提到的网银安全的事有结果了，大家了解一下网银大盗的作案手法，很有教育意义，希望大家可以举一反三，不，说错了，是很有警示意义，希望大家可以以此为戒，加强防范，呵呵。
某报讯，在互联网上兴风作浪将近一年的“新网银大盗”电脑病毒作者已经被捕。这位16岁的电脑高手通过在被害人电脑中“种植”电脑病毒的形式，盗窃工行网上银行用户密码账号，然后通过多次转账的形式提取现金。截至案发时，刘某已经窃取现金62500余元。
据悉，犯罪嫌疑人刘某系厦门市某中专校在校生，被捕时年仅16岁。刘某入侵了吉林搜狐网，将其中部分网页链接改造成可偷偷打开事先设定的恶意网页的“陷阱”链接，从而在点击者的电脑中“种植”电脑病毒。他制作的电脑病毒“新网银大盗”一旦发现用户登录工行个人网上银行的界面，就开始记录用户的键盘输入内容。如果卡号长度为19个字符，并以“95588”开头时，病毒就会将记录下的卡号、密码和验证数字等信息加密后自动传送给电脑病毒作者。通过这种形式，刘某盗窃工行网上银行用户密码账号，然后通过多次转账的形式提取现金。据警方介绍，仅仅通过侵入吉林搜狐网传播木马病毒，刘某就获取了124张银行卡的网上银行资料。网络警察在一个与他相关的网站上还发现了数百张银行卡资料，最终查明刘某前后一共盗走12名受害者银行卡内的钱款62500多元。
一位少年就可以对资产达几千亿的超大银行的系统造成威胁，这种不对称就来自于满山遍野的黑客工具和银行科技人员的不作为，要不是警察叔叔帮忙，真为这些银行的客户担心。
