自動ログインを安全に実装する方法

私は多くの、多くの、読んだ多くの「あなたはおそらく間違ったパスワードを保存している」方法についての記事を。これらは常に、ユーザーがログインしているサーバーにパスワードを保存することを指します。基本的に、パスワードなどを確実にソルトするなど、ユビキタスなアドバイスを再ハッシュします（ただし、クライアントがログインする必要がないように、パスワードをクライアントに保存するためのベストプラクティスに関する記事を見たことはありません）ログインするたびに手動で。「私を記憶する」機能。

ブラウザからDropboxなどのプログラムまで、多くのソフトウェアにこの機能があります。

最近、DropboxがコンピューターにIDを保存する方法に関する古い記事を読みました。別のコンピューターにコピーして貼り付けてDropboxを起動し、IDを取得したデバイスとしてログインできます。ログインもなし、Dropboxアカウントへのフルアクセスもありません。これは本当にばかげたデザインのように思えますが、それを行うより良い方法は考えられません。

クッキーのようなものをプレーンテキストで保存しないようにする方法すらわからない。暗号化する場合、暗号化を解除するためのキーはどこに保存しますか？

セキュリティの脆弱性を導入しない唯一の方法は、自動ログイン機能を削除し、ユーザーがサービスを使用するたびにパスワードを入力するようにすることですが、それは使い勝手が悪く、ユーザーはそうする必要がないことを期待して甘やかされています。

自動ログイン機能を実装するために、資格情報を安全にローカルに保存することについて何を読むことができますか？原則が記事全体に対して単純すぎる場合、それらは何ですか？問題のソフトウェアは、すべてのプラットフォームに存在しない機能（一部のLinuxディストリビューションにある「キーチェーン」など）に依存すべきではありません。

1つの方法は次のとおりです。

• ユーザーがログインしたら、セッションIDをクライアントのコンピューターのCookieに保存します（ユーザー名やパスワードではありません）。
• セッションをIPアドレスに結び付けるため、個々のセッションIDは、開始されたコンピューターでのみ機能します。

サイトの開発に使用しているフレームワークによっては、この動作は組み込み機能として利用できる場合があります。

HTTPプロトコルはとにかくステートレスであるため、Webサイトを使用する1回のセッション中に誰かをログインさせたままにすることと、次回サイトを使用するときに「自動ログイン」することに機能的な違いはありません。セッションの有効期限が切れるまでにどれだけの時間を許可するかだけです。

更新：また、明らかにセキュリティを強化するためにHTTPSを使用します。

更新2：このアプローチには制限があり、IPアドレスを大幅に変更するユーザーにはうまく機能しないことに注意してください。ただし、セキュリティのレベルは向上し、状況によっては役立つ場合があります。

Amazon（および他の多く）はハイブリッドアプローチを使用しています。閲覧、カートへのアイテムの追加、および以前に使用したクレジットカード/配送先住所の組み合わせを使用した注文のための自動ログインを提供します。ただし、クレジットカードの追加、配送先住所の追加/変更、パスワードの更新、過去の注文（オプションでユーザーに対して）の表示、その他の多くのアカウント設定など、多くのアクションのためにパスワードを入力する必要があります。

そう、あなたのコンピューターにアクセスする人々はあなたのセッションをハイジャックできますが、あなたはまだ彼らが注文したものを手に入れます！（さらに重要なことに、セッションをハイジャックするインセンティブはほとんど無効になっています。）しかし、誰かが私のコンピューターにアクセスできる場合、平均的なサイトセッションを盗む人々よりも大きな問題があります。

セキュリティがそれほど必要ないアプリケーションの部分がある場合、セッションID（ハッシュまたは必要に応じて）を格納するハイブリッドモデルを選択して、サイトのセキュリティの低い部分にユーザーを自動ログインできます。 、ただし、より高いセキュリティエリアに入るときにパスワードを入力し、セッションの終了時に高いセキュリティトークンを削除するように要求します。

もちろん、これが銀行レベルのサイトの場合、自動ログインはオプションではありません。繰り返しますが、これらの種類のセキュリティを使用するサイトは、保護しているデータの価値を想定しており、ハイジャックされたセッションの潜在的なリスクを考慮してユーザーの利便性を高めています。アプリケーションに当てはまらない場合は、自動ログインを実装しないでください。ユースケースに適したセキュリティ/有用性のトレードオフのレベルにアクセスする必要があります。

実際にはそれほど難しくはありません。最初に次の形式でCookieを保存します。

userID.token

トークンにsha1ハッシュを使用できます。その後、remember_me_tokensデータベーステーブルストアのuserID、トークンのbcryptハッシュ、およびトークンが生成された時刻。

次に、誰かがあなたのサイトにアクセスしたら、Cookieが設定されているかどうかを確認します。Cookieが設定されている場合、過去7日以内にデータベース内に有効な行があるかどうかを確認します。データベースにCookieの有効な行がある場合、ユーザーがログインしていることを示すセッションを設定し、一致するCookie /データベース行も削除して、新しいCookie /トークン/データベース行を生成します。

ログアウトしたら、Cookieを削除します。

cronジョブを実行して、たとえば7日以上経過したremember_me_tokenを削除します。

保管先のデバイスを信頼している場合のみ可能です。（デバイスに影響を与えられない場合）ユーザーの責任です。それは単にあなたの手の外にあります。

コメントに記載されているとおり：

それはあなたが信頼するものについてです。マシンがIDを保存することを信頼できない場合、それが問題です。キーチェーンを信頼する場合、それが最大のセキュリティになります。もちろん、デバイスのハードウェアなどを検出するようなカスタムの安全性を追加することもできますが、それはすべて偽物であるため、最終的にはわかりません。それはあなたのコントロールの外です。