web-dev-qa-db-ja.com

Webサイトとパスワードが安全であることをユーザーに保証する方法

信頼性の高いウェブサイトでは、「すべてのデータは暗号化されている」、「すべてのパスワードは128ビット暗号化を使用して暗号化されている」などの主張が常にあります。

私のWebサイトでは、ランダムなソルトでSHA-512(おそらく)ハッシュを使用した後、すべてのユーザーパスワードをデータベースに保存します。ユーザーにパスワードが安全であることを保証するスニペットを追加して、パスワードが必要なためにユーザーが私のウェブサイトの使用を妨害されないようにします。ユーザーに安全を感じてもらいたいのですが、ハッシングとは誰もが知っているとは思いません。

私の質問:「すべてのパスワードは暗号化されて安全です」というメッセージを提供しても大丈夫ですか?平均的なユーザーはハッシュと暗号化の違いが何であるかを知らないと思います。 「暗号化」という快適な言葉?または、私が提供すべき代替メッセージはありますか?

余談ですが、私は暗号化とパスワードハッシュを初めて使用するので、自分のサイトを立ち上げるときに、今のところこれで十分安全かどうか疑問に思っていました。安全でない場合は安全だとユーザーに伝えたくありません。どんな情報でも大歓迎です。ありがとう。

15
user2698818
  1. ユーザーは気にしません。

    彼らが気にするのは、誰かが自分の銀行口座からお金を引き出したときで、数日前にリンクがあり、誰かがあなたのデータベースに完全にアクセスできたようです。

  2. 私がそのようなメッセージを見たほとんどすべてのケースで、それらは誤解を招くものでした。最も陽気なものは、すべてのページに「ミリタリーグレードの安全な」スタイルのラベルが付いたウェブサイトでした。 HTTP証明書が無効であることを通知するアラートがありました。ログオンフォームにSQLインジェクションがありました。数週間後、ウェブサイトはハッキングされ、その後永久に姿を消しました。

    私は情報を安全に保つと主張するウェブサイトの数を数えるのをやめますが、実際に電子メールで元のパスワードを送信する「パスワードを回復する」フォームを持っています。

    「W3Cの有効なXHTML」ラベルに似ています。なぜ彼らは通常、ホームページにも少なくとも数十のエラーと<DIV COLOR='red'>

それでもユーザーを安心させたい場合は、次のようにします。

パスワードは安全に保管されます。私たちはあなたのパスワードを見ることができず、パスワードを提供するように求める電子メールを決して送信しないことを覚えておいてください。

しかし率直に言って、「パスワードを忘れた、メールで送信する」の代わりに「パスワードをリセット」フォームを使用すると、どんな言葉よりも安心です。

さまざまなコメントからのヒント:

  • 車輪を再発明しないでください:OpenIDを使用してください。この方法では、ハッシュを保存することすらありません。

    出典:Jan Hudecによるコメント

  • あなたは学生なので、プロジェクトをオープンソースにします。あなたの懸念は次のとおりです:「学校の一部の子供がパスワードを設計したため、ユーザーのパスワードが安全でないとユーザーに思われたくない」、ソースコードを読んで、セキュリティを気にする熟練した開発者によって書かれたことを確認します。

    出典:Jan Doggenによるコメント

22

最初にパスワードを保存しないでください!Stack Exchangeの例に従って、ユーザーが自分のIDを使用してログインできるようにします。 OpenID 。実装は、ほとんどの一般的なWebフレームワークで自由に利用できます。

またはおそらく他のプロトコル。ある機関の社内プロジェクトの場合(他の回答へのコメントが示唆するように)、ほぼ確実にLDAP、Kerberos(Windows Active Directoryもこれら2つに基づいています。Apacheはそれらに対するHTTP認証をサポートしています)またはコンピュータログインのためのそのようなサービス。それに接続するだけです。

これにより、機密情報を保存する必要がなくなります(おそらく権限を保存する必要がありますが、それは重要ではありません重要です)。ユーザーはさらに別のユーザー名とパスワードを覚える必要がありません。 、それで全体的に有利です。

12
Jan Hudec

言う:

「これは安全です。」

は、特定の技術的事実またはプロセスについて行う個人的な判断であり、この判断は、そのときのセキュリティについて自分が知っていることによって制限されます。しかし、あなたの暗号化、保存方法などが、あなたが知らない、またはまだ知らないものであっても、あらゆる種類の攻撃に耐えることを間違いなく保証できますか?

意味:このステートメントは、おそらくあなたが気づいていなくても、時代遅れになる危険があります。

したがって、@ JoachimSauerによる上記のコメントに同意する傾向があります。何をするか、どのようにユーザー情報を保存するかを説明し、これがどのように想定されているかをユーザーに伝えますサービスを安全にします。次に、ユーザーに自分で判断させます。

2
stakx

それは本当にあなたの特定のウェブサイトのコンテキストに依存します。

たとえば、これが消費者向けWebサイトである場合、それらのほとんどはパスワード(たぶん)、財務/健康情報(依存する)、および写真などの個人情報(笑)だけを気にすることになるでしょう。 。

これがビジネスアプリケーションの場合は、パスワードだけでなく、サイト全体のセキュリティレベルが関係します。同様に、それはあなたのターゲットユーザーが誰であるかに依存します-非常に技術的/それほど技術的でないなど.

このすべてのコンテキストは、通信する必要があるwhatと、必要な保証のレベルを大きく定義します。

たとえば、技術に詳しくない消費者の場合、次のような一般的で単純なコメントがあれば十分です。

このサイトは、最先端のセキュリティ技術を使用して構築されています。パスワードは常に暗号化されており、NSAに写真を送信することは決してありません。

(そして、他の人が言ったように、パスワードを持つことをまったく行わないほうがよいです。OpenIdやOAuthなどの標準を使用してください。)

高度に技術的なビジネスの場合、次のような技術および手順の詳細の全ページが必要になります。

開発と展開のプロセス全体で、完全なSDL(安全な開発ライフサイクル)を実装しました。
...
私たちのセキュリティアーキテクチャは...これは...
...などの安全なコーディングを保証します...これらのテストとこれらのテストを実行します。
私たちの暗号にはこれらのアルゴリズムが含まれています...そして...私たちはあなたが必要とする業界の規制に準拠し、認定されています...
私たちのセキュリティは、この独立したサードパーティのコンサルタントによって検証されています。
...
詳細について、およびポリシーを確認したり、独立した監査を手配したりするには、マーケティング部門に相談してください。

もちろん、あなたはtooはるかに詳細な情報を提供したくはありません、それはパスワード自体よりもプロセスに関するものでなければなりません...そしてもちろん、実際には、実際にcomply何を書いても、どのようなコンテキストを扱っていてもかまいません。

mostのユーザーが気にしなくても、あなたが言ったことを理解できず、とにかくサインアップしますNSAにユーザーデータを送信する場合は、.
これは彼らのためではありません。
パスワードがなくても同じように満足しています。リストからユーザー名を選択して、自動的にログインします。

明らかに、これはcareという小さなパーセンテージのためです-スマートユーザーが適切なことを実行できるようにし、必要な情報を提供し、付与する必要があります彼らは彼らが求めるかもしれない教育。
そうしないと、それがうまくいかない場合、残りの98%が突然目を覚まして怒ります。
(「確かに、自分の写真を見るのにパスワードが必要ないことは知っていましたが、elseができるとは思いませんでしたそれらも見てください!!」)

1
AviD

システムを安全にしたい場合、パスワードアルゴリズムの強度は無意味です。特に、選択したパスワードが小さい場合や、ハッカーがすでに「クラッキングして保存した」一般的な単語で構成されている場合、ほとんどのハッカーはすぐにパスワードをクラックできます。 "レインボーテーブルなどを使用しています。多くの洞察については、 パスワードクラックに関するArsTechnicaの記事 を参照してください。

あなたがする必要があるのは、悪者がそもそもハッシュに到達できないことをユーザーに保証することです。私が働いていたセキュリティ意識の高い会社の1つに、Webサーバーがデータベースサーバーに物理的に接続されていない3層のWebシステムがありました。上司が自分のWebサイトを配置してDBに直接アクセスしたいと思ったとき(設計が不十分なコードだとは言えない)、それは持てないと言われ、プッシュすると...間にワイヤーがないと言われました。中間層サービスを介してすべてのデータ要求を渡すように、彼はそれを設計する必要がありました。そして、これらのサービスはセキュリティで保護されているだけでなく、最小限の攻撃対象にさらされ、ロックダウンされていました。そして、DBはテーブルを読み取り用に公開することはなく、ストアドプロシージャのみがロックされ、ロックされたため、関連するサービスのみがアクセスできました。

想像するほどコード化するのは悪くありませんでした。アーキテクチャと各層の分離を知っていれば、コード化は非常に簡単でした。

0
gbjbaanb

地球上で最も安全なサイトを開発し、ユーザーエクスペリエンスを非常に低下させることができます。ユーザーはあなたのサイトが安全でないと想定します。

地球上で最も安全性の低いサイトを構築し、驚くべきユーザーエクスペリエンスを実現できます。ユーザーは、サイトが安全であると想定します。少なくとも夕方のニュースに出るまでは。

0
CodeART