[技巧]你會作Web上的用戶登陸功能嗎？

時間 2019-11-20

標籤技巧 web 用戶登陸功能欄目 HTML 简体版

原文原文鏈接

Web上的用戶登陸功能應該是最基本的功能了，但是在我看過一些站點的用戶登陸功能後，我以爲頗有必要寫一篇文章教你們怎麼來作用戶登陸功能。下面的文章告訴你們這個功能可能並無你所想像的那麼簡單，這是一個關係到用戶安全的功能，但願你們能從下面的文章中能知道什麼樣的方法纔是一個好的用戶登陸功能。php

用戶名和口令html

首先，咱們先來講說用戶名和口令的事。這並非本站第一次談論這個事了。如何管理本身的口令讓你知道怎麼管理本身的口令，破解你的口令讓你知道在現代這樣速度的計算速度下，用窮舉法破解你的口令可能會是一件很輕鬆的事。在這裏我想告訴從開發者的角度上來作設計這個用戶名和口令的事。下面一幾件規則：java

限用戶輸入一些很是容易被破解的口令。如什麼qwert，123456,password之類，就像twitter限制用戶的口令同樣作一個口令的黑名單。另外，你能夠限制用戶口令的長度，是否有大小寫，是否有數字，你能夠用你的程序作一下校驗。固然，這可能會讓用戶感到很不爽，因此，如今不少網站都提供了UX讓用戶知道他的口令強度是什麼樣的（好比這個有趣的UX），這樣可讓用戶有一個選擇，目的就是告訴用戶——要想安全，先把口令設得好一點。程序員

千萬不要明文保存用戶的口令。正如如何管理本身的口令所說的同樣，不少時候，用戶都會用相同的ID相同的口令來登陸不少網站。因此，若是你的網站明文保存的話，那麼，若是你的數據被你的不良員工流傳出去那對用戶是災難性的。因此，用戶的口令必定要加密保存，最好是用不可逆的加密，如MD5或是SHA1之類的有hash算法的不可逆的加密算法。CSDN曾明文保存過用戶的口令。（另，對於國內公司的品行以及有關部門的管理方式，我不敢保證國內網站以加密的方式保存你的口令。我以爲，作爲一個有良知的人，咱們應該加密保存用戶的口令）web

是否讓瀏覽器保存口令。咱們有N多的方法能夠不讓瀏覽器保存用戶名和口令。可是這可能對用戶來講很不爽。由於在真實世界裏誰也記得不住那麼多的口令。不少用戶可能會使用一些密碼管理工具來保存密碼，瀏覽器只是其中一種。是否讓瀏覽器保存這個須要你作決定，重點是看一下你的系統的安全級別是否要求比較高，若是是的話，則不要讓瀏覽器保存密碼，並在網站明顯的位置告訴用戶——保存口令最安全的地方只有你的大腦。算法

口令在網上的傳輸。由於HTTP是明文協議，因此，用戶名和口令在網上也是明文發送的，這個很不安全。你能夠看看這篇文章你就明白了。要作到加密傳輸就必需使用HTTPS協議。可是，在中國仍是有不少網站的Web登陸方式還在使用ActiveX控件，這可能成爲IE6還大量存在的緣由。我一般理解爲這些ActiveX控件是爲了反鍵盤記錄程序的。不過，我依然覺ActiveX控件不該該存在，由於在國外的衆多安全很重要的站點上都看不到ActiveX的控件的身影。shell

用戶登陸狀態數據庫

首先，我想告訴你們的是，由於HTTP是無狀態的協議，也就是說，這個協議是沒法記錄用戶訪問狀態的，其每次請求都是獨立的無關聯的，一筆是一筆。而咱們的網站都是設計成多個頁面的，所在頁面跳轉過程當中咱們須要知道用戶的狀態，尤爲是用戶登陸的狀態，這樣咱們在頁面跳轉後咱們才知道是否可讓用戶有權限來操做一些功能或是查看一些數據。瀏覽器

因此，咱們每一個頁面都須要對用戶的身份進行認證。固然，咱們不可讓用戶在每一個頁面上輸入用戶名和口令，這會讓用戶以爲咱們的網站想當的SB。爲了實現這一功能，用得最多的技術就是瀏覽器的cookie，咱們會把用戶登陸的信息存放在客戶端的cookie裏，這樣，咱們每一個頁面都從這個cookie裏得到用戶是否登陸的信息，從而達到記錄狀態，驗證用戶的目的。可是，你真的會用cookie嗎？下面是使用cookie的一些原則。安全

千萬不要在cookie中存放用戶的密碼。加密的密碼都不行。由於這個密碼能夠被人獲取並嘗試離線窮舉。因此，你必定不能把用戶的密碼保存在cookie中。我看到太多的站點這麼幹了。

正確設計「記住密碼」。這個功能簡直就是一個安全隱患，我以爲並非全部的程序員都知道怎麼設計這個事。下面是一些方法供你參考。

1）在cookie中，保存三個東西——用戶名，登陸序列，登陸token。

用戶名：明文存放。

登陸序列：一個被MD5加密過的隨機數，每次以輸入口令的方式登陸後更新。

登陸token：一個被MD5加密過的隨機數，僅一個登陸session內有效，新的登陸session會更新它。

2）上述三個東西會存在服務器上，服務器的驗證用戶須要驗證客戶端cookie裏的這三個事。

3）爲何要設計這個樣子？由於，

a）登陸token是單實例登陸。意思就是一個用戶只能有一個實例。

b）登陸序列是用來作盜用行爲檢測的。若是用戶的cookie被盜後，盜用者使用這個cookie訪問網站時，咱們的系統是覺得是合法用戶，而後更新「登陸token」，而真正的用戶訪問時系統發現，只有「用戶名」和「登陸序列」相同，可是「登陸token」不對，這樣的話，系統就知道，這個用戶出現了被盜用的狀況，因而，系統能夠清除登陸序列和 登陸token，這樣就能夠令全部的cookie失效，並要求用戶輸入口令。並給警告用戶系統安全。

不要讓cookie有權限訪問全部的操做。不然就是XSS攻擊，這個功能請參看新浪微博的XSS攻擊。下面的這些功能必定要用戶輸入口令：

1）修改口令。

2）修改電子郵件。（電子郵件經過用來找回用戶密碼）

3）用戶的隱私信息。

4）用戶消費功能。

找回口令的功能

找回口令的功能必定要提供。可是不少朋友並不知道怎麼來設計這個功能。咱們有不少找回口令的設計，下面我逐個點評一下。

千萬不要使用安全問答。事實證實，這個環節很煩人，並且用戶並不能很好的設置安全問答。什麼，個人生日啊，我母親的生日，等等。由於今天的互聯網和之前不同了，由於SNS，今天的互聯比之前更真實了，我能夠上facebook，開心，人人網，LinkedIn 查到你的不少的真實的信息。經過這些信息我可使用安全問答來重設你的口令。Facebook的安全問答很強大，還要你經過照片認人。

不要重置用戶的密碼。由於這有可能讓用戶的密碼遭到惡意攻擊。固然，你要發個郵件給用戶讓其確認，用戶點擊郵件中的一個連接，你再重置。我並不推薦這樣的方法，由於用戶通常都會用筆記下來這個很記的口令，而後登陸系統，由於登陸系統時使用了「記住密碼」的功能，因此致使用戶不會去修改密碼，從而要麼導到被寫下來的密碼被人盜取，要麼又忘記了密碼。

好一點的作法——經過郵件自行重置。當用戶申請找回口令功能的時候，系統生成一個MD5惟一的隨機字串（可經過UID+IP+timestamp+隨機數），放在數據庫中，而後設置上時限（好比1小時內），給用戶發一個郵件，這個鏈接中包含那個MD5的字串的連接，用戶經過點擊那個連接來本身從新設置新的口令。

更好一點的作法——多重認證。好比：經過手機+郵件的方式讓用戶輸入驗證碼。手機+郵件可能還不把握，由於手機要能會丟了，而個人手機能夠訪問個人郵箱。因此，使用U盾，SecureID，或是經過人工的方式覈實用戶身份。固然，這主要看你的系統的安全級別了。

口令探測防守

使用驗證碼。驗證碼是後臺隨機產生的一個短暫的驗證碼，這個驗證碼通常是一個計算機很難識別的圖片。這樣就能夠防止以程序的方式來嘗試用戶的口令。事實證實，這是最簡單也最有效的方式。固然，老是讓用戶輸入那些肉眼都看不清的驗證碼的用戶體驗很差，因此，能夠折中一下。好比Google，當他發現一個IP地址發出大量的搜索後，其會要求你輸入驗證碼。當他發現同一個IP註冊了3個以上的gmail郵箱後，他須要給你發短信方式或是電話方式的驗證碼。

用戶口令失敗次數。調置口令失敗的上限，若是失敗過多，則把賬號鎖了，須要用戶以找回口令的方式來從新激活賬號。可是，這個功能可能會被惡意人使用。最好的方法是，增長其嘗試的時間成本（之前的這篇文章說過一個增長時間成本的解密算法）。如，兩次口令嘗試的間隔是5秒鐘。三次以上錯誤，賬號被臨時鎖上30秒，5次以上賬號被鎖1分鐘，10次以上錯誤賬號被鎖4小時……

系統全局防守。上述的防守只針對某一個別用戶。惡意者們深知這一點，因此，他們通常會動用「僵屍網絡」輪着嘗試一堆用戶的口令，因此上述的那種方法可能還不夠好。咱們須要在系統全局域上監控全部的口令失敗的次數。固然，這個須要咱們平時沒有受到攻擊時的數據作爲支持。好比你的系統，平均天天有5000次的口令錯誤的事件，那麼你能夠認爲，當口令錯誤大幅超過這個數後，並且時間相對集中，就說明有黑客攻擊。這個時候你怎麼辦？通常最多見使用的方法是讓全部的用戶輸錯口令後再次嘗試的時間成本增長。

參考文章