Webアプリケーションの認証/セキュリティのベストプラクティス(任意のプラットフォーム)


12

今日、マネージャーから質問がありました。特に、一般的なユーザー名とパスワードのログインフィールドの「パスワードを記憶」する多くの一般的なブラウザーの性質に関して、Webフォームアプリケーションの認証に適したデザインとは何ですか。

受け入れられると思う答えを見つけるのに苦労しています。ソニーの恥ずかしいセキュリティ上の欠陥に照らして、人々に保存されているデータの感度は低くても、私は本当に注意したいです。社会保障番号や住所すら保存していませんが、電話番号、メールアドレス、訪問者の写真を保存しています。

彼は、ユーザーが単純にパブリック端末でパスワードを記憶でき、誰かがこの端末にジャンプして、不正な方法でデータの表示または変更を開始できることを心配しています。ただし、少なくともWindowsワークステーションでは、ブラウザーがWindowsユーザーアカウント間で「パスワードを記憶する」ことはありません。

これを超えて、サーバー側で一方向パスワード暗号化を実装しています(暗号化されたパスワードをデータベースに保存し、ユーザーが指定したパスワードをサーバーで暗号化し、データベースの暗号化された文字列と比較します)。SSL暗号化を組み込む直接的な計画はありませんが、これはまだオプションです。

このアプローチには重大なセキュリティ上の欠陥がありますか?より良い提案はありますか?


一方向暗号化(ハッシュ)パスワードを保存するときは、強力なハッシュ(MD5ではない)を使用するか、パスワードをソルトする(stackoverflow.com/questions/420843/…を参照)か、その両方を行ってください。
ジョーダンライター

OWASP Webサイト(owasp.org)をご覧ください。さまざまなプロトコルの「チートシート」など、非常に有用なセキュリティ情報が多数あります。
ラルフ

ここにフォームベースのウェブサイト認証に関するいくつかのガイドラインがありますstackoverflow.com/a/477578/463478
Only You

回答:


13

高度なヒント:

  1. 必要なデータのみを保存する
  2. 機密データ(SSN、パスワード、クレジットカード番号など)を保管するときは常に暗号化する
  3. 機密データを送受信するときは、常にSSLを使用してトラフィックを暗号化します
  4. 情報の機密性に疑問がある場合は、暗号化します
  5. ユーザー入力を信頼しないでください(誰かが何か悪い入力を試みます)
  6. データを信頼しないでください(誰かがデータベース内のデータを変更できます-悪意のあるスクリプトを挿入するなど)
  7. 独自の暗号化を行わないでください
  8. アプリケーション/データベースをホストするサーバーを保護する
  9. セキュリティのためにエンドユーザーの負担を増やします(パスワードの制限、パスワードを公開しない、URLを電子メールで送信しない、セッション時間を短縮するなど)

あなたへの私の提案は、Webアプリケーションの保護に関する本を入手することです。1つの回答/ブログ/記事で伝えるには情報が多すぎます。暗号化だけのトピックは重要です。


独自の暗号化を実行する代わりにSSLを使用する背後にある理由は何ですか?独自の暗号化をローリングするWS-Securityなどの使用を検討しますか?SSLのセットアップは面倒な場合があります。
ジェファーソン氏

これは良いチェックリストです。賛成票が増えていないことに驚いています。
クリストファーホッホ

2
@ Mr.Jefferson「あなた自身の暗号化を実行したくない」と思う時間の99.999999%と思います。
ザックレイトン

2

ブラウザの動作をオーバーライドすることができます-ここでいくつかの良いアドバイス:

/programming/32369/disable-browser-save-password-functionality


1
良いリンク。個人的には、そのようなユーザーの選択をオーバーライドするのは開発者としてのビジネスだとは思いませんが、それを要求したクライアントのためにサイトを作成したので、それを行う方法を知ることが重要です。
Carson63000

1

私はあなたが大丈夫でなければならないと思います。

ほとんどのユーザーは、パスワードを公共の端末に保存しない程度に明るくなり、パスワードはプロファイルごとに保存されます。付箋紙に簡単に書いたり、弱いパスワードを使用したりできることを忘れないでください。

ログインページがSSLで暗号化されていない場合、攻撃者がネットワーク上を移動するときにそのパスワードを盗聴することは難しくありません。ただし、データベース内のパスワードをハッシュ化することで、潜在的な攻撃者が全員のパスワードを見るのを防ぐことができます(電子メールアドレスを使用して、ユーザーが他のサイトにログインしようとする可能性があります)。

それでもやりたい場合は、Chadが指摘したように、ブラウザーの動作を無効にする方法があります。私は自分の銀行のWebサイトとMicrosoftのLiveシステムでこれを見ただけです。


素晴らしい投稿です。ユーザー名は電子メールアドレスではなく、ユーザーはシステムに電子メールアドレスを保存します。Facebookのような人気のあるサイトでさえ、電子メールのアドイやパスワードのパケットスニッフィングの影響を受けやすいため、これについて言及します。
maple_shaft

また、Facebookのセキュリティの欠陥を、必ずしもアプリケーションのセキュリティモデルが不十分であることの「言い訳」として指摘していないことも付け加えておきます。ジョーイのお母さんが評価の高いR映画を視聴させたからといって、それは正しくありません:)
maple_shaft

1

特定の時点で、ユーザーを自分自身から保護することはできません(法的に義務付けられていません)。「パスワードを記憶する」機能は危険な場合がありますが、ユーザーが想定するリスクです。同様に、ユーザーが複数のサービスにパスワードを再利用することに決めた場合、そのリスクも想定します。また、ユーザーがパスワードをメモに書き留めてモニターに貼り付けないように警告する必要もありません。

つまり、誰かが正常に訴訟を起こし、ルールを変更するまでです。「警告:コンテンツは高温になる場合があります」も参照してください。


0

ブラウザがパスワードを記憶するかどうかを確実に制御できるとは思わない。ブラウザがそれを行うかどうかに関係なく、単にあなたの手に負えません。それはあなたにとって必ずしも大きなセキュリティリスクではありません。有効なログインから攻撃が行われる可能性があることを常に想定する必要があります。誰かが有効なログインユーザー/パスを持っているので、彼らは役に立たないだろうと思い込まないでください。結局のところ、パスワードが間違った手に渡るには多くの方法があります。

あなたができることは、毎回ログインフォームのフィールド名をランダム化することだと思います。代わりに<input name="username"、のようなものを使用します<input name="user658667587"。それはキャッシュされたユーザー名をかなり役に立たなくするでしょう。しかし、オーバーヘッドがそれだけの価値があるかどうかはわかりません。公共のマシンでアレントするユーザーに迷惑をかけることは言うまでもありません。

セキュリティが非常に重要な状況(銀行、投資)にある場合は、ログオン時に人々にそのパブリックマシンかどうかを単純に尋ねることができます。ユーザーがログインするときに既知のIPアドレスをキャッシュすることもできます。また、別の場所からログインする場合は、通常のユーザー/パスに加えて入力できないピン番号(例:画像をクリック)が必要です。私の銀行はそれに似たようなことをしています。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.