Web上にユーザーログイン機能を実装する方法をご存知ですか？

Web 上のユーザー ログイン機能は最も基本的な機能のはずですが、いくつかのサイトのユーザー ログイン機能を見て、ユーザー ログイン機能の実装方法を皆さんに教える記事を書く必要があると感じました。この機能はユーザーのセキュリティに関わる機能であることが、次の記事からわかります。どのような方法が良いユーザー ログイン機能なのかを知っていただければ幸いです。以下の内容を転載する場合は、原文との整合性を保ち、作成者と出典を明記してください。

ユーザー名とパスワード

まず、ユーザー名とパスワードについて説明します。このサイトがこの問題について取り上げたのはこれが初めてではない。自分のパスワードを管理する方法を参照すると、自分のパスワードを管理する方法がわかります。また、パスワードを解析すると、最新のコンピューティング速度を使用すると、徹底的な方法を使用してパスワードを解析するのが非常に簡単になる可能性があることがわかります。ここでは、開発者の観点からこのユーザー名とパスワードを設計する方法を説明したいと思います。ここにいくつかのルールがあります:

ユーザーが非常に簡単に解読されるパスワードを入力することを制限します。たとえば、qwert、123456、password など、Twitter がユーザーのパスワードを制限しているのと同じように、パスワードのブラックリストを作成します。さらに、ユーザーのパスワードの長さ、大文字と小文字を区別するかどうか、および数字を含むかどうかを制限することができ、プログラムを使用してパスワードを確認できます。もちろん、これはユーザーを非常に不快にさせる可能性があるため、現在、多くの Web サイトがユーザーにパスワードの強度を知らせる UX を提供しています (この興味深い UX など)。これによりユーザーが選択できるようになり、その目的はユーザーに伝えることです。安全を確保したい場合は、まずパスワードを適切に設定してください。

ユーザーのパスワードをクリアテキストで保存しないでください。自分のパスワードの管理方法で述べたように、ユーザーは多くの Web サイトに同じ ID とパスワードを使用してログインすることがよくあります。したがって、Web サイトが平文で保存されている場合、データが悪意のある従業員によって漏洩された場合、ユーザーにとっては悲惨な結果になります。したがって、ユーザーのパスワードは、できればハッシュ アルゴリズムを備えた不可逆的な MD5 や SHA1 などの不可逆的な暗号化を使用して暗号化して保存する必要があります。 CSDN はかつてユーザーのパスワードを平文で保存していました。 （また、国内企業の行動や関連部門の管理方法については、国内のウェブサイトがパスワードを暗号化して保存するかどうかは保証できません。良心的な人間として、ユーザーのパスワードは暗号化して保存するべきだと思います）

ブラウザにパスワードを保存させるかどうか。ブラウザーがユーザー名とパスワードを保存しないようにするには、さまざまな方法があります。しかし、これはユーザーにとってイライラする可能性があります。なぜなら、現実世界ではこれほど多くのパスワードを覚えている人はいないからです。多くのユーザーはパスワードを保存するためにいくつかのパスワード管理ツールを使用している可能性があり、ブラウザもその 1 つにすぎません。重要なのは、システムのセキュリティ レベルが比較的高いかどうかを確認し、ブラウザにパスワードを保存させず、ユーザーにわかりやすく伝えることです。 Web サイトに保存します - パスワードを保存するのが最も安全な場所です。

インターネット上でのパスワード送信。 HTTP はクリア テキスト プロトコルであるため、ユーザー名とパスワードもオンラインでクリア テキストで送信されますが、これは非常に安全ではありません。この記事を読めば理解できます。暗号化された送信を実現するには、HTTPS プロトコルを使用する必要があります。ただし、中国には依然として Web ログイン方法に ActiveX コントロールを使用している Web サイトが多数あり、それが IE6 が依然として多数存在する理由である可能性があります。通常、これらの ActiveX コントロールはキーロガー対策用であると理解しています。 ただし、ActiveX コントロールはセキュリティが重要な海外のサイトではほとんど見られないため、ActiveX コントロールは存在すべきではないと今でも感じています。

ユーザーのログイン状態

まず最初にお伝えしたいのは、HTTP はステートレス プロトコルであるため、各リクエストは独立しており、トランザクションごとにユーザーのアクセス ステータスを記録することはできません。当社の Web サイトは複数のページで設計されており、ページジャンプのプロセス中に、ユーザーのステータス、特にユーザーのログインステータスを知る必要があります。この方法では、ユーザーがページにアクセスする権限を持っているかどうかがわかります。いくつかの機能を使用したり、データを表示したりできます。

したがって、各ページではユーザーの身元を認証する必要があります。もちろん、すべてのページでユーザーにユーザー名とパスワードを入力させることは不可能であり、ユーザーに当社の Web サイトが非常に SB であると感じさせることになります。この機能を実現するために、最も一般的に使用されるテクノロジーは、ユーザーのログイン情報をクライアントの Cookie に保存することにより、当社の各ページがこの Cookie からユーザーのログイン情報を取得することです。ステータスを記録し、ユーザーを確認する目的。しかし、本当に Cookie を使用しますか? Cookie の使用に関するいくつかの原則を次に示します。

ユーザーのパスワードを Cookie に保存しないでください。暗号化されたパスワードは機能しません。このパスワードはオフラインで取得して枯渇を試みることができるためです。したがって、ユーザーのパスワードを Cookie に保存しないでください。これを行っているサイトが多すぎます。

「パスワードを記憶する」を正しく設計してください。この機能は単にセキュリティ上のリスクであり、すべてのプログラマーがこれを設計する方法を知っているわけではないと思います。一般的な設計は、ユーザーがこの機能をチェックすると、システムがユーザー名と固定ハッシュ値を含む Cookie を生成することです。この固定ハッシュ値は常に使用されます。この方法により、すべてのデバイスとクライアントにログインでき、複数のユーザーを同時にログインさせることができます。これはあまり安全ではありません。参考までに、より安全な方法をいくつか紹介します:

(——2011/08/26追記、原文に若干の誤りがあり、わかりにくい部分があったので再調整しました——)

1) Cookie に、ユーザー名、ログイン シーケンス、ログイン トークンの 3 つを保存します。

ユーザー名: クリアテキストで保存されます。

ログイン シーケンス: MD5 によってハッシュされた乱数。ユーザーがパスワードの入力を強制された場合 (例: ユーザーがパスワードを変更する場合) にのみ更新されます。

ログイン トークン: MD5 によってハッシュされた乱数。1 つのログイン セッション内でのみ有効です。新しいログイン セッションで更新されます。

2) 上記 3 つがサーバーに保存されます。サーバーの認証されたユーザーは、クライアント Cookie でこれら 3 つを確認する必要があります。

3) このようなデザインにはどのような効果がありますか?

a) ログイン トークンは単一インスタンスのログインです。これは、ユーザーが持つことができるログイン インスタンスは 1 つだけであることを意味します。

b) ログイン シーケンスは盗難検出に使用されます。ユーザーの Cookie が盗まれ、窃盗犯がこの Cookie を使用して Web サイトにアクセスすると、システムはそのユーザーが正規のユーザーであると判断し、「ログイン トークン」を更新します。ただし、実際のユーザーが再び訪問すると、システムは「ログイン トークン」を更新します。 「ユーザー名」と「ログイン シーケンス」は同じですが、「ログイン トークン」が間違っていることがわかります。この場合、システムは、このユーザーが盗まれた可能性があることを認識します。そのため、システムはクリアして変更できます。ログイン シーケンスとログイン トークンを無効にし、ユーザーにパスワードの入力を求めます。また、システムのセキュリティについてユーザーに警告します。

4) もちろん、上記の設計には、同じユーザーが異なるデバイスからログインしたり、同じデバイスにログインするのに異なるブラウザを使用したりするなど、依然としていくつかの問題があります。あるデバイスが別のデバイスのログイン トークンとログイン シーケンスを無効にすることで、他のデバイスやブラウザが再度ログインする必要が生じ、Cookie が盗まれたかのような錯覚が生じます。したがって、サーバーサーバーの IP アドレス

も考慮する必要があります。

a) パスワードを使用してログインする場合、サーバーの「ログイン シーケンス」と「ログイン トークン」を更新する必要はありません (ただし、Cookie を更新する必要があります)。それは、実際のユーザーだけがパスワードを知っていると信じているからです。

b) IP が同じ場合、サーバーの「ログイン シーケンス」と「ログイン トークン」を更新する必要はありません (ただし、Cookie は更新する必要があります)。同じユーザーは同じ IP を持っていると考えるからです (もちろん、同じ LAN も同じ IP を持ちますが、この LAN はユーザーによって制御可能であると考えられます。この機能はインターネット カフェでは推奨されません)。

c) (IP が異なり、ログインにパスワードが使用されていない場合)、「ログイン トークン」は複数の IP 間で変更されます (ログイン トークンは、2 つ以上の IP 間で前後に変更されます)。一定期間内に一定回数以上アクセスすると、システムは盗難の可能性が非常に高いと判断し、バックグラウンドで「ログインシーケンス」と「ログイントークン」をクリアし、無効化します。 Cookie を使用し、複数のデバイスで一貫した Cookie を確保するために、ユーザーにパスワードの入力を強制します (またはユーザーにパスワードの変更を要求します)。

Cookie がすべての操作にアクセスできるようにしないでください。それ以外の場合は XSS 攻撃です。この機能については、新浪微博の XSS 攻撃を参照してください。次の機能では、ユーザーはパスワードを入力する必要があります:

1) パスワードを変更します。

2) メールを変更します。 (ユーザーのパスワードを取得するために使用される電子メール)

3) ユーザーの個人情報。

4) ユーザー消費機能。

Cookie の有効期限を測定します。 有効期限が切れなければ、ユーザー エクスペリエンスは非常に優れていますが、ユーザーがログイン パスワードをすぐに忘れてしまいます。 2 週間や 1 か月などの有効期限を設定すると良いかもしれませんが、2 週間や 1 か月を過ぎても、ユーザーはパスワードを忘れてしまいます。特に、ユーザーが公共のコンピューターに永続的な Cookie を保存した場合、それはアカウントの漏洩に相当します。したがって、Cookie の有効期限を考慮する必要があります。

パスワード検索機能

パスワードを取得する機能を提供する必要があります。しかし、多くの友人はこの関数を設計する方法を知りません。パスワード検索用のデザインは多数ありますので、以下で 1 つずつ説明します。

セキュリティ Q&A は決して使用しないでください。結局のところ、この手順は煩わしく、ユーザーはセキュリティ Q&A の設定方法を十分に理解していません。なんだ、自分の誕生日とか、母の誕生日とか。今日のインターネットは以前とは異なり、SNS のおかげで、Facebook、Kaixin、Renren、LinkedIn にアクセスして、多くのリアルな情報を見つけることができます。この情報があれば、セキュリティの質問を使用してパスワードをリセットできます。 ここでは Facebook について話さなければなりません。Facebook のセキュリティ Q&A は非常に強力で、写真を通じて個人を特定する必要もあります (笑)。

ユーザーのパスワードをリセットしないでください。これにより、ユーザーのパスワードが悪意のある攻撃にさらされる可能性があるためです。もちろん、確認のためにユーザーに電子メールを送信し、ユーザーが電子メール内のリンクをクリックしてからリセットする必要があります。通常、ユーザーはこの覚えにくいパスワードをメモしてシステムにログインするため、この方法はお勧めしません。システムにログインするときに「パスワードを記憶する」機能が使用されるため、ユーザーはパスワードを変更しません。 , したがって、書き留めたパスワードが盗まれたか、パスワードを忘れたかのいずれかです。

より良いアプローチは、電子メールで自分自身をリセットすることです。ユーザーがパスワード取得機能を申請すると、システムは一意の MD5 ランダム文字列 (UID+IP+タイムスタンプ+乱数を渡すことができる) を生成し、データベースに入れてから、上限時間 (たとえば 1 秒以内など) を設定します。時間）、MD5 文字列へのリンクが含まれた電子メールがユーザーに送信され、そのリンクをクリックすると新しいパスワードをリセットできます。

より良いアプローチ - 多要素認証。例: ユーザーが携帯電話と電子メールを介して確認コードを入力できるようにします。携帯電話 + 電子メールについては、よくわからないかもしれません。なぜなら、携帯電話が機能する場合、携帯電話は紛失してしまい、携帯電話はメールボックスにアクセスできるからです。したがって、USB シールド、SecureID (変化する 6 桁のトークン) を使用するか、手動でユーザーの身元を確認してください。もちろん、これは主にシステムのセキュリティ レベルによって異なります。

パスワード検出防御

確認コードを使用します。検証コードは、バックグラウンドでランダムに生成される有効期間の短い検証コードであり、通常はコンピューターが認識するのが難しい画像です。これにより、プログラムによるユーザーのパスワードの試行が防止されます。これが最も簡単で効果的な方法であることがわかりました。もちろん、目に見えない確認コードの入力を常にユーザーに求めるユーザー エクスペリエンスは良くないため、妥協することはできます。たとえば、Google は、ある IP アドレスから大量の検索が送信されていることが判明した場合、確認コードの入力を求めます。同じ IP で 3 つ以上の Gmail メールが登録されていることが判明した場合、テキスト メッセージまたは電話で確認コードを送信する必要があります。

失敗したユーザーパスワードの数。パスワードの失敗の上限を設定します。パスワードの失敗が多すぎると、アカウントがロックされ、ユーザーはアカウントを再アクティブ化するためにパスワードを取得する必要があります。ただし、この機能は悪意のある人によって使用される可能性があります。最善の方法は、試行の時間コストを増やすことです (この前の記事では、時間コストを増やす復号化アルゴリズムについて説明しました)。たとえば、パスワードを 2 回試行する間隔は 5 秒です。エラーが 3 つ以上ある場合、アカウントは 30 秒間ロックされます。エラーが 5 つ以上ある場合、アカウントは 1 分間ロックされます。何時間...

システムのグローバル防御。上記の防御策は個々のユーザーのみを対象としています。悪意のある攻撃者はこのことをよく知っているため、通常は「ボットネット」を使用して多数のユーザーのパスワードを順番に試行するため、上記の方法は十分ではない可能性があります。システムのグローバル ドメインでのパスワード失敗の数を監視する必要があります。もちろん、これは攻撃を受けていないときのデータによって裏付けられる必要があります。たとえば、システムで毎日平均 5,000 件のパスワード エラーが発生する場合、パスワード エラーの数がこの数を大幅に超え、時間が比較的集中している場合は、ハッカー攻撃が存在することを意味すると考えることができます。このとき何をすべきでしょうか? 最も一般的な方法は、すべてのユーザーが間違ったパスワードを入力した後に再試行するための時間コストを増やすことです。

最後に、ユーザー ログインについて説明します。サードパーティの OAuth と OpenID を使用することも非常に良い選択です。