前几天跟朋友一起讨论关于传输过程加密的问题，http本身的设计就是无状态。现在很多的网站都在传输过程中都没有进行加密，只是数据库进行了加密，而这样的话，别人通过嗅探的话，还是可以嗅探到你的明文密码。

    比如：你的一台机器ip是。 23.22.2.3另一台机器是23.22.2.4，在同一个网关下23.22.2.3的这是一个网站的服务器，而我就可以用23.22.2.4这个服务器来嗅弹，23.22.2.3 80端口的信息 登录的用户名，等等这些信息。并且嗅探到的还是明文，先前我测试了dz dz也在传输过程中没有加密，他不过就是数据库加密比较另类一点，难解密！也就是用md5+salt来加密的。

    也许有人会说，为何不用https加密呢？

    1、https的是收费的。

    2、https也可以突破嗅探 至于怎么样突破 这里的就不在多说。

    3、用https之后网页会很卡，现在我们讨论的并不是数据库加密，而是传输过程的加密， 先前我自己想到的方法是 在客户端js加密 而想到这个办法后 有出现了种种的问题 问题如下： js的方法别人在网上已经说过。

    1.js加密的问题是，不论单向双向，加密方式没办法隐藏，会被人家看到。

    2.例如我密码是 123abc,输入表单后发送，js给加密成了 乱码。 发给服务端再加密下和数据库比对。问题来了，如果入侵者截获到js加密后的乱码，他可以禁用js，然后直接把乱码输入表单后发送，效果和直接得到用户密码发生一。 js加密这里的作用除了黑客不知道密码是啥外，其他都没用，乱码也可以登录。

    js的加密的直接pass掉。这里根本行不通！

    跟朋友又讨论下 想到了其他的办法 捆绑验证码 从而进行加密。

    流程：用户输入密码->js提交服务器md5（md5（pass）+验证码）->服务器查询出pass然后md5（pass+验证码）『数据库里pass=md5（pass）』->删除验证码的session

    这个方法笔者也测试了，确实可行！发出捆绑验证码的，从而进行传输加密的代码，打包下载。

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。