js的加密
『壹』 用JS方法加密URL
首先,很不推薦你使用get方式發送密碼,最好是使用post.
原因是,你通過一個連接把用戶名和密碼發送到後台,即便密碼不是明文,別人獲取不到密碼明文,但是,只要你這個連接成功登陸過,別人就可以拿這個連接到處登陸.密碼明文加密完全形同虛設.
如果非想使用get方式發送,我可以給你個思路,就是表單附帶發送令牌,這個令牌是表單內的隱藏域,後台里對每一個時刻都不同的字元串做單向加密然後保存SESSION會話,一般使用md5方式,然後表單頁面隱藏域寫出該SESSION的值.發送表單的時候,附帶令牌一起發送,(在url形式中就是多了一個參數),後台驗證令牌是否是保存過的SESSION值,如果是,執行登陸,如果不是,就報錯.
不管令牌是不是正確的,你都需要在每次生成頁面時重新更新一次令牌並輸出,這樣才能保證唯一性.
然後你可以使用js版的md5把密碼處理成加密字元串.
這樣可以躲過部分不熟悉html的,但是如果他懂html,只需查看html的令牌,然後自己去組成url,那麼照樣還是不行.
所以,這種形式仍是不可取的,正宗的方式就是post發送用戶名和密碼,或是ajax的get方式發送.
『貳』 如何將js加密
簡單的說: javascript是一種客戶端語言,即是在用戶的瀏覽器中被執行的,由於許可權不被伺服器控制,所以不可能加密.
多說一點: 雖然js不能加密,但是如果你不太想被別人太容易拿去使用,你可以使用一些工具對javascript的代碼進行壓縮和代碼混淆. 這種工具你搜一下就是一大堆的.
『叄』 怎麼隱藏JS中的加密代碼,怎麼讓別人看不出你的JS加過密
首先JS是客戶端(瀏覽器)運行的語言,和css html一樣是明文可見的,js目前只能做到使用eval混淆,網路搜索「JS壓縮」第一個應用就可以做到混淆和反混淆。另外還有一種方式,針對某些編譯器編程,在此就說編譯器吧,比如google的,其實只是一個優化器。這樣優化出來的代碼閱讀性很差,代碼冗餘量很低,性能也是相對來說比較好的。
但是強調一點,js是明文可見的,只能混淆,讓閱讀新降到最低,如果和密碼一樣加密傳輸的,瀏覽器獲得的是密文的話,就無法執行,直接報錯啦!
『肆』 如何對JS代碼加密
JS加密其實就是對字元進行編碼,也不是一定要用工具有兩個函數的document.write(escape("你好,這是測試!")+"<br>");
document.write(unescape("%u4F60%u597D%uFF0C%u8FD9%u662F%u6D4B%u8BD5%uFF01"));
『伍』 如何加密js
可以搜索js加密工具。
一般js是不用加密,只需要混淆壓縮就可以了。
真正可以加密的就是需要使用網上提供的php的加密方法。
『陸』 求助前端JS都是用什麼加密的
寫過 js混淆器,談一些淺顯的個人看法。
個人認為,js的不可讀化處理分為三個方面:壓縮(compression)、混淆(obfuscation) 和加密(encryption)。 (不可讀化處理,這是我自己發明的術語,一切會增加代碼不可讀性的代碼轉換, 都可以這么叫,「增加代碼不可讀性」可能是代碼轉換的結果或者目的).
1. 壓縮
這一操作的目的,是讓最終代碼傳輸量 (不代表代碼量, 也不代表文件體積)盡可能小。壓縮js的工具,常見的有:YUI Compressor、UglifyJS、Google Closure Compiler 等。
通常在代碼壓縮的過程中,只改變代碼的語法,代碼的語義和控制流不會有太大改變。
常見做法是把局部變數縮短化,把一些運算進行等價替換等。代碼壓縮對於代碼保護有一些幫助,但由於語義和控制流基本沒變,起不了太大作用。
在壓縮層面上,代碼不可讀只是一種附帶傷害,不是最終目的。
2. 混淆
這一操作的目的,是讓代碼盡可能地不可讀,主要用作代碼保護。
讓代碼不可讀,增加分析的難度,這是唯一目的。混淆過後文件體積變大一倍也沒關系,代碼量變多也沒關系,運算慢50% 也沒關系。
常見的做法有:分離常量、打亂控制流、增加無義代碼、檢查運行環境如果不對就罷工,等等。
在混淆層面上,代碼不可讀是最終目的。
值得一提的是,Google Closure Compiler 的 Advance Level Compression 會壓縮類和對象的成員,其壓縮結果很難分析,也可以認為是一種混淆,但兼容性不太好。
廣告時間:我寫的 js混淆器,中文名叫 「看起來很厲害的 JS 編譯器」, 英文名叫做 The Impressive JS.Segment.Compiler , 看起來很厲害的 JS 編譯器 。
3. 加密
說實話我很難對加密做一個定義,因為加密在Web界有太多歧義了。
有加密就有解密,意味著加密操作可逆,密文可以明文化。
就這樣看來,在Web界,可以稱之為加密的東西包括:HTTPS傳輸、JavaScript實現對稱加密或者不對稱加密等等。
這樣看來,不可逆的代碼壓縮和混淆就不能列入加密這個范疇了。
非要找一個可以稱之為加密,又經常被人誤解為壓縮和混淆的東西,Dean Edwards 的 Dean Packer/Unpacker 可以拿來做個例子。
比如我們把 var num=1;alert(num);
輸入 Dean Packer,pack 一下,得到這么一串東西,是不是看著非常像被壓縮和混淆過的代碼?
把上面那串意義不明物拿來 unpack 一下,得到了原文。
實際上 Dean Packer 只是對源碼進行了一個字元串變換,沒有深入到代碼語法層面,你可以拿 "Hello world, 你好師姐" 來試試。
用Online JavaScript beautifier 能輕松把這串東西還原為 「Hello world, 你好師姐」。
可以看出,代碼加密意味著:將代碼明文進行可逆的變換(加密),生成密文;將密文進行逆變換(解密),可以還原明文;最終運行環境運行的是解密代碼。
結語
實際上大家對壓縮、混淆、加密這三個概念還是挺不清晰的,我在這里說一些個人見解,希望有幫助。
在現實項目中,我是多種手段結合的:
對於不需要做代碼保護的項目,比如個人博客,做代碼壓縮,加快載入速度,這就夠了。
對於需要做一些代碼保護,防止抄襲的項目,可以在源碼中加入一些開發者的信息和防護代碼,然後混淆和壓縮。很不幸的是,我這方面總是做得不太好,防君子防不了小人啊哈哈。
對於需要嚴格加密的項目,可以用 混淆、壓縮、加密、簽名檢查 等多種手段,這我就不清楚了,等大嬸來補充。
『柒』 關於JS加密,這個是什麼加密方式如何進行加密和解密
7種加密方式:http://www.codesky.net/article/200911/165731.html
『捌』 如何在前端調用js對密碼進行加密
加密和解密原則上都應該在後台完成才合乎常理,如果在前端加密,就好比在眾目睽睽之下化妝易容,然後聲稱自己是另一個人一樣,沒意義啊。
如果一定要在前端加密,可以這樣:
<input type="submit" name="submit" value="注冊" onclick="var pwd=document.getElementsByName('password')[0];pwd.value=md5(pwd.value);"/>
『玖』 js有幾種加密方式
首先,MD5不是加密演算法,是簽名演算法,哎,到底是有多少國人被毒害了呀。
另外,只要是可以由軟體實現的加密演算法,js都能使用,只是有效率問題,
一般的
非對稱演算法,使用的資源都很龐大,所以js很少有。
而對稱的加密演算法……,由於js是對用戶可見的,所以……就和沒加密一樣。
這也就是為什麼真正的高安全網站都不會選擇用js做加密,而是選擇用https 協議這樣的手段。
再次重申,MD5不是加密演算法,所以不再上述范圍內
『拾』 js如何加密加密完之後如何使用
使用內置的三個函數就行,分別是escape(),encodeURI(),以及encodeURIComponent()。
escape() 方法:
採用ISO Latin字元集對指定的字元串進行編碼。所有的空格符、標點符號、特殊字元以及其他非ASCII字元都將被轉化成%xx格式的字元編碼(xx等於該字元在字元集表裡面的編碼的16進制數字)。比如,空格符對應的編碼是%20。
不會被此方法編碼的字元: @ * / +
encodeURI() 方法:
把URI字元串採用UTF-8編碼格式轉化成escape格式的字元串。
不會被此方法編碼的字元:! @ # $& * ( ) = : / ; ? + '
encodeURIComponent() 方法:
把URI字元串採用UTF-8編碼格式轉化成escape格式的字元串。與encodeURI()相比,這個方法將對更多的字元進行編碼,比如 / 等字元。所以如果字元串裡麵包含了URI的幾個部分的話,不能用這個方法來進行編碼,否則 / 字元被編碼之後URL將顯示錯誤。
不會被此方法編碼的字元:! * ( ) '
因此,對於中文字元串來說,如果不希望把字元串編碼格式轉化成UTF-8格式的(比如原頁面和目標頁面的charset是一致的時候),只需要使用
escape。如果你的頁面是GB2312或者其他的編碼,而接受參數的頁面是UTF-8編碼的,就要採用encodeURI或者
encodeURIComponent。
另外,encodeURI/encodeURIComponent是在javascript1.5之後引進的,escape則在javascript1.0版本就有。