前端密碼字體庫加密

㈠ 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 是否是用戶偽造的