0

私のサイト（違いがあればRailsサイト）を実装する際の私の設計上の優先事項の1つは、ユーザーごとに便利な機能を提供しながら、ユーザーがさらに別のユーザー名とパスワードを作成する必要をなくすことです。

私がこれを行うことを計画している方法は次のとおりです。

  1. ユーザーがサイトに情報を入力します。情報は、サーバー側のセッションを介してユーザーに関連付けられます。
  2. ユーザーが情報の入力を完了すると、サーバーはアクセスURLを電子メールでユーザーに大まかに次の形式で送信します。http://siteurl/<user identifier>/<signature: HMAC(secret + salt + user identifier)>
  3. ユーザーがURLをクリックすると、サイトはユーザーIDとソルトを検索し、サーバーに保存されているシークレットを使用してHMACを計算し、計算されたHMACと署名が一致するかどうかを認証します。

私の質問は、これは私がやろうとしていることを達成するための合理的に安全な方法ですか？それを役に立たなくする一般的な攻撃はありますか？ユーザー名/パスワードを避けたいという私の願望を放棄するやむを得ない理由はありますか？このテーマに関する必読の本や記事はありますか？

私はクレジットカード番号や非常にプライベートなものを扱っていませんが、それでも情報を適度に安全に保ちたいと思います。

4

2 に答える 2

5

1 つの単語 (実際には 2 つ) -Refererヘッダー。ユーザーがあなたのサイトにアクセスした後に次にアクセスするサイトでは、このヘッダーにユーザーの資格情報が表示されます。さらに、ユーザーは資格情報が侵害された後、資格情報を変更できなくなります。

ユーザー名/パスワード認証の考え方は、既知のユーザー ID と、ユーザーごとに自由に変更できる未知のパスワードという 2 つの別個の情報が関係するというものです。あなたのシステムには (Referer のことは別として)、すべてに対して 1 つのパスワード、つまり「秘密」があります。また、署名を総当たり攻撃して (ユーザー ID を知っているため)、システム全体を役に立たなくして秘密を復元するのはかなり簡単だと思います。

于 2012-10-09T03:45:21.950 に答える
1

私は、iPhone アプリ用の同様のパスワードレス ログインを検討しました。Web アプリの最大の問題は、ログインが不必要に面倒になることです。

とはいえ、簡単な変更は次のとおりです。

  1. ユーザーが電子メール アドレスを入力します。
  2. サーバーは、ランダムな認証 (例: 128 ビットの /dev/urandom、base64 エンコード) トークンを生成H(authtoken)し、タイムスタンプと共に DB に保存してから、電子メールを送信します。https://example.com/login/userid?auth=authtoken
  3. ユーザーが URL をクリックすると、サーバーはトークンが DB にあり、有効期限が切れていないことを確認し、DBからトークンを削除して、セッション Cookie を設定します。

サーバーはもう少し状態を保存する必要がありますが、とにかく状態を保存する必要がありました。これは、優れたパスワード リセット フローとほぼ同じように機能するため、理論的には安全性が劣ることはないと思われます。ただし、実際には、「パスワード リセット」フローが通常のログイン フローになっているため、account-hijack-via-password-reset ほど明白な監査証跡は残りません。

MAC とタイムスタンプを使用して同様のことを行うこともできます(uid,timestamp,MAC_k(uid,timestamp))。基本的な問題は、MAC キー (データベースのバックアップなど) にアクセスできる人なら誰でも任意の認証トークンを生成でき、データベースが常に漏洩することです。

ハッシング/MAC するときは、「暗号スプライシング」攻撃に注意してください。

さらに、よくある間違いは、特定の電子メール アドレスにアカウントがあるかどうかを明らかにすることです (ログインでは「無効な電子メール/パスワード」と表示されることがよくありますが、パスワードのリセット フローではそれが表示されます。より良い方法は、常に電子メールを送信し、「この電子メールに関連付けられたアカウントはありません」という電子メールで、理想的には成功応答と同じバイト数で!)。

于 2012-10-09T04:50:23.317 に答える