自黑，如何窃取账号密码？

时间：2022-04-09 17:42:02 | 来源：行业动态

时间：2022-04-09 17:42:02 来源：行业动态

首先，我们先来个比较简单比较低级的方式。使用的工具是Wireshark，这是一个网络封包分析软件，用于撷取网络封包，并尽可能显示出最为详细的网络封包资料，类似于电工手中的万用表。这个软件一般只能监测本机的流量数据，因此通常被用作自检，但是如果配合ARP欺骗技术，就能够监控整个局域网的流量！

我们这次测试的是在本机。首先，你需要知道本机的IP以及即将访问网站的IP。以IT门户数字尾巴为例，通过Ping地址，我们得到数字尾巴的IP为203.195.146.235，而本机的IP为10.72.12.143。接下来就是打开Wireshark，然后开启监听。

这时候我们开始在数字尾巴的登陆界面输入账号密码，登陆后，关闭监听。我们来看看监听到了什么？



使用简单的工具就能够获得用户账号密码

细心的读者或许已经看到，在监听的数据中明确写着如下几行代码：

username=17686******（这是笔者手机，做模糊处理哈）

password=Sj******（登录密码）

也就是说，数字尾巴的登陆没有做加密处理，只要能够你登录，你的账号密码就会以明文的形式在网络传播！如果你的其它账号使用了同样的账号密码（事实上，笔者的确如此。。），一旦被窃取，其他网站的账户也就容易被攻破。

然后又测试了几个网站，发现可以直接获取明文账号密码的网站已经不是太多了。即使同样的Http登陆，也做了一些加密处理，比如通过session计算出一个常数，储存在服务器。在提交password的时候，在前端通过js将这个常数与用户输入的密码进行md5运算，运算结果POST给服务器。这样黑客们不需要知道你的明文密码，监听到你所谓的密文，然后用脚本发起一个Http请求就可以登录上去了。并且，既然服务器端需要验证，也就需要还原原始密码，既然有方法，这对于黑客来说就完全可以破解了。

或许，你又会说，那就设置更复杂的加密传输，比如非对称加密。但是，这不是Https提供的功能么？而且Https提供的安全保障还可以应对其他的攻击。所以，目前来看Https是解决账号安全的靠谱方案。

Https真能解决问题？

先说结论：真能！这就要先说说Https的核心--非对称加密。Https在HTTP下加入SSL层（安全套接层）/TLS(TLS是SSL的升级协议)，HTTPS在传输数据之前需要客户端（浏览器）与服务端（网站）之间进行数次握手，在握手过程中将确立双方加密传输数据的密码信息，这样，Https就能保障数据在传输过程中不被非法篡改和利用。而Https握手加密使用的是非对称加密。

对称加密算法是指加密和解密时使用的是同一个秘钥；而非对称加密算法需要两个密钥来进行加密和解密，这两个秘钥是公开密钥（public key）和私有密钥（private key）。以最常用的RSA为例，它的原理是：

1. 随意选择两个大的质数p和q，p不等于q，计算N=pq。

2. 根据欧拉函数，求得r = (p-1)(q-1)

3. 选择一个小于 r 的整数 e，求得 e 关于模 r 的模反元素，命名为d。（模反元素存在，当且仅当e与r互质）

4. 将 p 和 q 的记录销毁。

这其中(N,e)就是公钥，(N,d)是私钥。传输过程中，只发送公钥(N,e)，私钥(N,d)则不在传输中体现。

这种加密其实就是利用了一个数学难题：当p和q是一个大素数的时候，从它们的积pq去分解因子p和q是很难的

举个例子： 3233可以进行因数分解为6153，但是你可以试试如下数字的因数分解：　1230186684530117755130494958384962720772853569595334792197322452151726400507263657518745202199786469389956474942774063845925192557326303453731548268507917026122142913461670429214311602221240479274737794080665351419597459856902143413

而这只是一个232个十进制位（768个二进制位）的数字哦，目前主流的加密会使用1024位甚至更高。事实上这是目前人类能分解的最大整数，1024位的破解尚未被报道（但估计也用不太久的时间，所以还是推荐使用更高位的加密）。

因此，目前采用RSA1024或者更高加密方法的Https是安全的，暂时还不用担心会被破解。但是越来越高的质数分解，导致服务器端的加密和解密计算量大增，这也导致用户在访问Https网站时候可能导致一定的延迟。



SSL造成的延迟到底有多少？

下面我们来实际测试下SSL将会造成大少的延迟。命令行工具curl有一个w参数，可以用来测量TCP握手和SSL握手的具体耗时。

curl -w "TCP handshake: %{time_connect}, SSL handshake: %{time_appconnect}/n" -so /dev/null Https://www.zhihu.com

在Macos下可以在命令行下直接输入（以知乎为例），得到的结果如下：

SSL握手将会造成较大的网络延迟

TCP handshake耗时在23-54ms，而SSL handshake在88-145ms之前。延迟跟网络有关系（内网环境下，网络延迟较高），但一般SSL造成的延迟是TCP握手的3-4倍。

这部分延迟除了网络问题，最重要的还有加密和解密所造成的延迟，因为后台服务器在验证大数字密钥时候需要耗费大量的计算资源。有数据显示，在同等硬件条件下，2048bit Https比Http并发性能要弱5-10倍，甚至更多。而据小米公司实测，正常情况下，一个16核的CPU能够达到300OPS（每秒3000次RSA操作）就算不错的成绩了。但是，每个网站不仅包括一个页面，比如主页面、登录页面、子页面等等，这些都需要通过SSL进行加密传输数据，因此通用x86服务器做SSL加解密会造成较高的延时，并且在高并发访问时容易造成服务器宕机。

有方法！浪潮SSL加解密解决方案

那么，面对如此严峻的网络安全环境和不断提升的加解密计算性能消耗，如何更高效的进行SSL加解密？答案是采用更有的计算解决方案，比如浪潮SSL加解密解决方案。

既然依靠CPU的通用计算不能很好地进行SSL加解密的高速运算，那么是不是能够通过专用的加速卡来实现?就像用GPU来实现图像运算那样，答案是肯定的。SSL专用加速卡，相比x86架构的CPU，虽然不能胜任通用计算应用需求，但是经过专门的算法和架构优化，在进行RSA加密计算时的性能大大优于传统架构。

浪潮基于SA5212M4的、专门面向SSL加解密加速的软硬一体化解决方案，支持2块SSL加速卡，支持IPsec、SSL 加速和压缩功能，可提供高达 50 Gbps 的加密速度和高达 24 Gbps 的压缩性能。在单卡情况下即可实现在RSA1024操作中190K OPS（每秒运算次数），而在RSA2048时也能达到35K的速度，与通用服务器相比能够有10倍以上的性能提升。

在网络安全问题频发的今天，为了自身网站的正常运转以及用户的隐私安全，越来越多的网站启用Https。浪潮SSL加解密解决方案则通过高效的计算加速技术，让Https的延迟更低，用户体验更优。