前端密码字体库加密

㈠ jsencrypt实现前端RSA非对称加密解密（vue项目）

最近一个vue项目要求所有密码数据需要使用RSA非对称加密传输，以为挺简单，结果开发过程中还是遇到了些问题，简单做个笔记。同时也希望可以帮助到遇到同样问题的道友门。

重点来了：使用jsencrypt实现RSA非对称加解密
因为这里直接在前端加解密，所以需要一对现成的密钥，我们通过 密钥在线生成器 得到：

然后在需要使用的文件中引入JSEncrypt，我是将所有工具函数都封装在一个js文件的，我就直接在该文件中引入，我看也有人是在main.js中引入的。

到这里我们的加密解密方法就完成了，在需要的地方直接拿过来用就好了！

大功告成！这样就完了？我以为这样就ok了。

当然，如果没有遇到这个bug，就可以忽略下面的内容了。
从上面截图可以看到，重启项目的时候报错： navigator is not defined
而且这个bug有点奇葩，先启动项目再引入jsencrypt就什么问题都没有，但是先引入jsencrypt再启动项目就报错。这也是我前面能顺利执行的原因所在。
通过好一通折腾，用了网上的各种方法，比如在main.js引入jsencrypt、引入jsdom之类的，都没能解决这个问题，最终还是在jsencrypt的git相关 issue 下找到了这个问题的解决方案。

到这里问题就算基本解决了，但是由于项目组不止我一个前端，我不能要求每个同事或者以后接手维护项目的同事都要在node_moles中去替换文件。
所以就采用了另外一种方案：将jsencrypt.js通过在线js压缩器压缩至jsencrypt.min.js中，然后把jsencrypt.min.js放到src/assets/jsencrypt文件夹中，就不用npm install的方式了。
换了种方式，jsencrypt的引用方式需要做出相应的调整：

参考链接： RSA非对称加密传输---前端加密&解密(VUE项目)
https://github.com/travist/jsencrypt/issues/144
PS：才疏学浅，如果有考虑不周之处或者有更好的解决方案，欢迎指正探讨！

㈡ Web前端密码加密是否有意义

密码在前端加密完全没有意义，对密码系统的安全性不会有任何提高，反而会引发不必要的麻烦。首先，做前端开发的人需要知道，前端系统的控制权是完全在用户手里的，也就是说，前端做什么事情，用户有完全的控制权。假设如同 @陈轩所说，前端做过了md5，后台就不用做了，这个做法会有什么后果？如果某一天，这个系统的数据库泄露了，黑客就直接拿到了每个用户的密码md5值，但此时，由于黑客知道密码是在前端进行哈希的，所以他不需要爆破出该md5对应的原文是什么，而是直接修改客户端向服务器发出的请求，把密码字段换成数据库中MD5就可以了，由于与数据库中记录一致，直接就会登录成功。这跟直接存储明文密码没有任何区别！！！所以不管前端是不是加密了密码，后台使用安全的哈希算法对内容再次转换是非常有必要的。（MD5可不行，要用bcrypt，我之前回答过一个类似的：随着显卡性能的高速发展，目前的快速Hash算法是否已经变得不够安全了？）这个回答还有一个人赞同，希望大家别被错误答案误导了。另外一个答案 @林鸿所说，在非安全HTTP连接上，可以防止原始密码被窃听。但问题在于由于你的登录系统接受的哈希过的密码，而不是原文，窃听者根本不需要原始密码，只要通过哈希结果就可以伪造请求登录系统。这样做只能防止被窃听到原文的密码被攻击者用在社会学攻击上，而不能改善该网站的安全性。所以不管前端是不是加密了密码，使用HTTPS安全连接进行登录都是非常有必要的。以上我说的两点，合起来看就是：不管前端是否加密了密码，都不能以此为假设，让后端设计的安全等级下降，否则就会有严重的安全问题。实际上，前端进行密码加密，可以看做帮助用户多进行了一次原文的转换，不管用了什么加密算法，算出来的结果都是密码原文，你该如何保护用户的原始密码，就该如何保护此处的加密结果，因为对你的登录系统来说，它们都是密码原文。以上这些，说明了密码加密是没有什么意义的，接下来，我要说明前端加密会带来什么问题。有些人会认为前端进行了加密，可以降低后台的安全性需求，这种错误的观念会造成系统的安全漏洞。实际上，你不能对前端做任何的假设，所有跟安全相关的技术，都必须应用在后台上。前端进行加密会造成页面需要js脚本才能运行，那么假设你的系统需要兼容不能运行js的客户端，就必须再设计一个使用原文的登录接口。由于前端是不是加密，所有安全机制都必须照常应用，所以为系统增加这样的复杂性是完全没必要的，即使传输明文密码，只要正确使用了HTTPS连接和服务器端安全的哈希算法，密码系统都可以是很安全的。

㈢ Web前端密码加密是否有意义

密码在前端加密完全没有意义，对密码系统的安全性不会有任何提高，反而会引发不必要的麻烦。

(1)加密了也无法解决重放的问题，你发给服务器端的虽然是加密后的数据，但是黑客拦截之后，把加密之后的数据重发一遍，依然是验证通过的。直接监听到你所谓的密文，然后用脚本发起一个http请求就可以登录上去了。

http在网络上是明文传输的，代理和网关都能够看到所有的数据，在同一局域网内也可以被嗅探到，你可以开个wireshark抓下局域网的包试试看。加密也没有提高什么攻击难度，因为攻击者就没必要去解密原始密码，能登录上去就表示目标已经实现了，所以，难度没有提高。

(2)既然是加密，那么加密用的密钥和算法肯定是保存在前端的，攻击者通过查看源码就能得到算法和密钥。除非你是通过做浏览器插件，将算法和密钥封装在插件中，然后加密的时候明文混淆上时间戳，这样即使黑客拦截到了请求数据，进行重放过程时，也会很快失效。

㈣ 前端加密、解密数据

首先，为了更好的加密，我们不能用简单的加密，因为很有可能会被轻松破解掉，我之前实现的加密只是简单的把数据加密，在测试过程中（安全性测试），通过一些技巧还是可以解密成功。

所以，对于一些重要的信息可能需要非对称加密。

所谓的非对称加密解密，在我的理解的，就是前端用一把钥匙解密/加密，而后台用另一把钥匙来做同样的操作。

也就是，前端加密用特定的钥匙，解密的钥匙只在后端那里。这样在传输过程中就不会把钥匙丢掉。

同样，后端加密数据用一把钥匙，解密的时候，前端自己有规定的钥匙，这样数据也不会在过程中解密截取。

1、我这里是用vue

所以，第一步 npm install jsencrypt

2、安装完之后，开始定义一个专门用来加密解密的文件，我放到utils文件里面。

引入JSEncrypt

3、重点来了加密解密

首先，我这里使用公钥加密（由后台来给你公钥）

全局引用，使用

这样加密就完成了。

通常由后台加密，前端负责加密

由后台生成私钥，然后前端用来解密。

引用和加密一样

㈤ Web前端密码加密是否有意义

没有意义

---

密码前端的加密根本没有意义，密码系统的安全性没有提高，但会造成不必要的麻烦。

首先，前端开发人员需要知道前端系统的控制完全掌握在用户手中，也就是说前端所做的事情和用户拥有完全的控制。据称，前端做了MD5，后台不必做，这种方法会有什么后果？如果有一天，系统数据库泄露，黑客直接获得每个用户的密码的MD5值，但这一次，因为黑客知道密码的哈希的前面，所以他不需要鼓风的MD5对应什么是原创，而是直接修改发送到服务器的客户端请求的在它的数据库密码字段MD5，符合数据库中的记录，你可以直接登录。这与直接存储明文密码没有区别！！！所以不管前端密码是否加密，后台使用哈希算法的安全内容转换都是必要的。（MD5不能使用BCrypt的，我以前回答类似：用图形表现，当前快速发展的快速哈希算法已成为不安全吗？）有一个人同意这个答案，我希望你不要被错误的答案误导。对方的回答，Linh说，是为了防止原始密码被利用在一个不安全的HTTP连接。但问题是，因为你的登录系统接受密码代替原来的，窃听者根本不需要原始密码，只要哈希结果可以伪造请求登录系统。这样做只会防止攻击者在社交攻击时使用原始密码，而不会提高网站的安全性。所以不管前面密码是不是加密的，使用HTTPS安全连接登录都是很有必要的。

㈥ 前端js 加密解密方式

一、base64加密
使用JS函数的window.btoa()和 window.atob()，分别是中腊编码和解码

二、编码和解码字符串

使用JS函巧羡数卖宽滑的escape()和unescape()，分别是编码和解码

三、AES加密解密
四、RSA加密解密

㈦ 如何在前端调用js对密码进行加密

加密和解密原则上都应该在后台完成才合乎常理，如果在前端加密，就好比在众目睽睽之下化妆易容，然后声称自己是另一个人一样，没意义啊。
如果一定要在前端加密，可以这样：
<input type="submit" name="submit" value="注册" onclick="var pwd=document.getElementsByName('password')[0];pwd.value=md5(pwd.value);"/>

㈧ Web前端密码加密是否有意义

在前端对密码做一次MD5，看起来是防止明文传输了，事实上只有一种情况下它可以提高用户的安全性，那就是用户在别的网站上也用和你的网站一样的密码。并且在任何情况下都提高不了你自己网站的安全性。前面说的传输过程、内存里、日志里……这些地方没有明文密码，其实都只能保护用户本身的利益，对于自身服务的安全性是没有提高的。因为，既然传输过程不是加密的，那么包随便发，至于发一个abc123，还是发一个，对你的程序没有任何的区别，这时候你的程序都是小绵羊。这个过程可以看做，你的用户都用了32位字符串的密码，如是而已。从事实意义上讲，在所有网站上用同样密码的用户非常多，所以可以勉勉强强的说，这是有一丁丁点的意义的。但即使在前端做了签名，因为hash暴露了，也还是很容易被撞库。但是，对安全性没有提高，就不做了吗？当然要做，因为要应付审计。

㈨ 记录一下前端使用CryptoJS的几种加密方式

自己太小白了，之前在PC端项目中使用的MD5加密，现在的小程序项目使用了 CryptoJS 里面的 enc-base64 和 hmac-sha1 ，之前没有用到过这两种，所以比较疑惑，为何在小程序不继续使用 MD5 呢？所以在这里记录一下自己解疑惑的一些知识点。

随着互联网的兴起，我们对信息的安全越来越受重视，这样就导致在web开发中，对用户密码等各种加密变得更加重要了。与服务器的交互中，为了确保数据传输的安全性，避免被黑客抓包篡改。

对于Base64编码的，我觉得看一篇文章能够解决你的疑惑，我在这里就不赘述了
🧐 Base64编码原理

如： 用户密码，请求参数，文件加密

如： 接口参数签名验证服务

支付数据、CA数字证书

前端的朋友可能会关注前端js加密，我们在做 WEB 的登录功能时一般是通过 Form 提交或 Ajax 方式提交到服务器进行验证的。为了防止抓包，登录密码肯定要先进行一次加密（RSA），再提交到服务器进行验证。一些大公司都在使用，比如淘宝、京东、新浪 等。

前端加密也有很多现成的js库，如：

JS-RSA： 用于执行OpenSSL RSA加密、解密和密钥生成的Javascript库， https://github.com/travist/jsencrypt

MD5： 单向散列加密md5 js库， https://github.com/blueimp/JavaScript-MD5

crypto-js： 对称加密AES js库， https://github.com/brix/crypto-js

-CryptoJS (crypto.js) 为 JavaScript 提供了各种各样的加密算法。

HMAC 系列是消息验证，用于验证一个消息是否被篡改——如网站上传递 email 和 hmac(email)，则接收时可以通过 hmac(email) 获知 email 是否是用户伪造的