タグ付けされた質問 「passwords」

Webサービスがあります。現在、サーバー上のMySQLテーブルにプレーンテキストでパスワードを保存しています。私はこれがベストプラクティスではないことを知っています。それが私がそれに取り組んでいる理由です。 セキュリティで保護されたデータベースに保存されているパスワードを暗号化する必要があるのはなぜですか？誰かが私のデータベースにハッキングすると、全員のパスワードを取得することに気付きます。しかし、誰かが私のデータベースに入った場合、たとえばデータの削除など、他の問題があります。 私が考えることができるシナリオは、あなたがハッキングされているということです。数時間前からデータベースを復元すると、すべてが順調です。ただし、パスワードがプレーンテキストの場合...泥棒はすべてのパスワードを持っているため、すべてリセットする必要があります。ユーザーの面倒。 パスワードが暗号化されている場合は、以前のデータベースに復元するだけで済みます。これは正しい考えですか？

78 mysql  encryption  passwords 

パスワードを許可する長さを制限したり、特定の文字を禁止したりするサイトを数多く目にしました。パスワードの検索スペースを広げて長くしたいので、それは私に制限されています。また、それらがハッシュされていないかもしれないという不快な感覚を私に与えます。 そこにあるの良いアッパー長さを設定したり、パスワードの文字を除くいずれかの理由は？

39 security  passwords 

現在、職場でアプリケーションを継承していますが、残念なことに、データベースに保存されているユーザーパスワードは社内暗号化機能を使用して暗号化されており、暗号化解除機能も含まれています。 したがって、誰かが本当にする必要があるのは、ユーザーテーブルをコピーし、暗号化アセンブリ（データベースの実稼働アクセス権を持つユーザー）をコピーするだけです。そうすれば、100,000の電子メールアドレスと潜在的なパスワードにアクセスできます。 なぜこれが良いアイデアではないのかをビジネスに説明しようとしていますが、セキュリティの概念は技術的にあまり気になっていないので頭に浮かぶようです（政府向けです）。さらに、管理者ユーザーがユーザーのパスワードを取得してログインし、作業を行うために必要な機能を実行するための、アプリケーション内に実際に存在する機能があります。 そのため、彼らはセキュリティへの影響を理解していません。また、強力なセキュリティポリシー（パスワードを簡単に取得できないようにハッシュする）を実装するには、既存の機能を削除する必要があります。 私は何をすべきか？そもそもパスワードシステムを構築していなかったので、何か問題が発生しても非難できるわけではありません。一方、私はそれについて気分が悪く、また、100,000の潜在的な電子メールログオンにアクセスしたくありません。

34 security  client-relations  passwords 

確立されたユーザーベースで既存のアプリケーションを保守します。時間が経つにつれて、現在のパスワードハッシュ手法は時代遅れであり、アップグレードする必要があると判断されています。さらに、UXの理由により、既存のユーザーにパスワードの更新を強制することは望ましくありません。パスワードハッシュ更新全体は、画面の背後で行われる必要があります。 以下を含むユーザー用の「単純な」データベースモデルを想定します。 ID Eメール パスワード このような要件を解決するにはどうすればいいですか？ 私の現在の考えは次のとおりです。 適切なクラスに新しいハッシュメソッドを作成します データベース内のユーザーテーブルを更新して、追加のパスワードフィールドを保持する ユーザーが古いパスワードハッシュを使用して正常にログインしたら、2番目のパスワードフィールドに更新されたハッシュを入力します これにより、パスワードハッシュを持っているユーザーとパスワードハッシュを更新していないユーザーを合理的に区別できないため、両方のチェックを強制されるという問題が残ります。これは恐ろしく欠陥があるようです。 さらに、これは基本的に、すべてのユーザーがパスワードを更新するまで、古いハッシュ手法を無期限に保持することを意味します。その時点でのみ、古いハッシュチェックの削除を開始し、不要なデータベースフィールドを削除できました。 私の現在の「ソリューション」は汚れていて不完全であり、そうではないので、ここでいくつかのデザインのヒントを探していますが、可能なソリューションを記述するために実際のコードが必要な場合は、自由に言語を使用してください。

32 security  language-agnostic  passwords 

パスワードの設定/リセットにも使用されるREST APIがあるとします。また、これがHTTPS接続で機能すると仮定します。そのパスワードを呼び出しパスに入れない正当な理由はありますか、BASE64でエンコードすることもできますか？ 例として、次のようなパスワードをリセットします。 http://www.example.com/user/joe/resetpassword/OLDPASSWD/NEWPASSWD BASE64は暗号化ではないことを理解していますが、この場合はショルダーサーフィンのパスワードを保護したいだけです。

31 rest  passwords 

セキュリティ上の理由から、パスワードはプレーンテキストで保存しないでください。ハッシュを保存する必要があります。また、レインボーテーブル攻撃を防ぐために、ハッシュを慎重に生成する必要があります。 ただし、通常、最後のn個のパスワードを保存し、最小限の複雑さと異なるパスワード間の最小限の変更を強制する必要があります（ユーザーがPassword_1、Password_2、...、Password_ nのようなシーケンスを使用できないようにします）。これはプレーンテキストパスワードでは簡単ですが、ハッシュのみを保存することでどのようにできますか？ つまり、安全なパスワード履歴メカニズムをどのように実装できるのでしょうか？

23 security  passwords 

システムのユーザー識別/認証プロセスについて誰か（クライアント）と意見の相違があります。それの要点は、各ユーザーにグローバルに一意のパスワードを持たせることです（つまり、2人のユーザーが同じパスワードを持つことはできません）。私はこれに対する明白な議論をすべて排除しました（セキュリティの脆弱性であり、認証と認証を混同します、それは無意味です）。 私はこれについて権威のある（または半権威の、または独立した）意見を探してさまざまなGoogle検索を行ってきましたが、何も見つけることができません私が知る限り）。誰も私にそのような独立した意見を指摘できますか？ [編集] すべての回答に感謝しますが、この提案されたアプローチ/要件の問題をすでに理解しており、クライアントに説明することさえできますが、クライアントはそれらを受け入れません。 。 私はまた、デイリーWTFの記事を見つけたと思いますが、それはジョン・ホプキンスが指摘しているという問題がある-これは、それは価値が説明するように見えるしないように自明WTFであることを理由。 そして、はい、パスワードはソルトおよびハッシュされます。その場合、グローバルな一意性を確保するのは難しいかもしれませんが、それは私の問題を解決しません-それは単にクライアントが先に進まないという要件があることを意味します。実装します。そして、「塩漬けやハッシュに悩まされていません」と言う立場にいたら、「グローバルに一意のパスワードを実装していない」と言う立場になります。 なぜこれが悪い考えであるかについての独立したおよび/または権威ある情報源へのポインタは、まだ感謝して受け取られています... [/編集]

20 security  passwords 

セキュリティリスクが中〜低のアプリ（つまり、バンキングアプリなどではない）のログインを作成する場合、ユーザーが入力したパスワードを次のように入力するだけで検証できますか。 if(enteredPassword == verifiedPassword) SendToRestrictedArea(); else DisplayPasswordUnknownMessage(); 効果的であるように簡単に思えますが、それが必要なすべてであるかどうか私は確かに気にしません。ユーザー名とパスワードのコンボを簡単にチェックするだけで十分ですか？ 更新：特定のプロジェクトはたまたまWebサービスであり、検証は完全にサーバー側であり、オープンソースではありません。ドメインは、これに対処する方法を変更しますか？

20 security  passwords  validation 

私はこの答えを読んで、パスワードをメールで送信しないことを主張するコメントを見つけました： パスワードをメールで取得できないようにする必要があります。これは、パスワードがどこかにプレーンテキストで保存されていることを意味します。リセットのみが必要です。 これにより、[パスワードを忘れた場合]オプションを処理する問題が生じます。 ユーザーがそれを読むことができるように、どんなUIでも生のパスワードを表示する必要があります。「パスワードを忘れた」を処理する方法は何でしょうか

18 programming-practices  security  email  passwords 

私は最近、数年前からアカウントを持っていた政府のサービスを使用しました。サービスのパスワードを思い出せなかったので、「パスワードを忘れた」リンクを使用し、この政府のWebサイトが私のメールアドレスにプレーンテキストでパスワードを送信したことに驚いた。 私はユーザーパスワードの処理方法を個人的に認識しており、フィードバックフォーム（これは政府のWebサイトです。ほとんどの人は、すべてに同じパスワードまたは少数のパスワードを使用します（私は知っています）。彼らは単に、「省はパスワード情報を保護するために必要な措置を講じており、適切な暗号化を行ってパスワード情報を保存している」と安心させました。 「私にパスワードをメールで送ることができれば、明らかに必要な措置を講じていません」と言いたいのですが、失礼になろうとはしていません。とにかく私が何を意味するかを知っている誰かに連絡してください。 だから、「（公式のセキュリティ標準）に従って必要な措置が講じられていない」と述べたいと思います。OWASPをすばやく検索しましたが、プレーンテキストストレージに関する記事しか見つかりませんでした。 取得可能なパスワード情報の保存を禁止する（おそらくそう思うと思われる）ユーザーのパスワード処理に関するセキュリティ標準はありますか？さらに良いことには、銀行や政府のWebサービスなどの機密情報を扱うWebサイトが従わなければならない標準がありますか？ おそらく何も変わらないことは知っていますが、IMOを一撃する価値はあります。

17 security  standards  passwords 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 4年前に閉鎖されました。 信頼できるWebサイトでは、「すべてのデータは暗号化されています」または「すべてのパスワードは128ビット暗号化を使用して暗号化されています」などのクレームが常に表示されます。 私のウェブサイトでは、SHA-512（ほとんどの場合）ハッシュをランダムソルトで使用した後、すべてのユーザーパスワードをデータベースに保存します。パスワードが必要であるためにWebサイトの使用を妨げないように、パスワードが安全であることをユーザーに保証するスニペットを追加します。ユーザーに安全を感じてもらいたいのですが、ハッシュとは誰もが知っているとは思いません。 私の質問：「すべてのパスワードは暗号化され安全です」というメッセージを提供しても大丈夫ですか？平均的なユーザーはハッシュと暗号化の違いを知っているとは思わないので、見ているだけで安全だと感じる可能性が高い慰めの言葉「暗号化」？または、提供する必要がある代替メッセージはありますか？ ちなみに、私は暗号化とパスワードハッシュが初めてであり、サイトを立ち上げた時点でこれで十分であるかどうか疑問に思っていました。安全でない場合は安全だとユーザーに伝えたくありません。どんな情報でも大歓迎です。ありがとう。

15 security  ethics  encryption  passwords  hashing 

パスワードの強度に関するさまざまなリソースを読んで、パスワードのエントロピーの大まかな推定値を提供するアルゴリズムを作成しようとしています。 できるだけ包括的なアルゴリズムを作成しようとしています。この時点では、擬似コードしかありませんが、アルゴリズムは次のことをカバーしています。 パスワードの長さ 繰り返されるキャラクター パターン（論理） 異なる文字スペース（LC、UC、数値、特殊、拡張） 辞書攻撃 以下をカバーしておらず、完全にカバーすべきではありません： 順序付け（このアルゴリズムの出力により、パスワードを厳密に順序付けることができます） パターン（空間） 誰でもこのアルゴリズムの弱点についての洞察を提供できますか？具体的には、アルゴリズムにパスワードを入力するとその強度が過大評価される状況を誰もが考えられますか？過小評価は問題ではありません。 アルゴリズム： // the password to test password = ? length = length(password) // unique character counts from password (duplicates discarded) uqlca = number of unique lowercase alphabetic characters in password uquca = number of uppercase alphabetic characters uqd = …

14 algorithms  passwords 

現在のところ、この質問はQ＆A形式には適していません。回答は事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は議論、議論、世論調査、または広範な議論を求める可能性があります。この質問を改善し、場合によっては再開できると思われる場合は、ヘルプセンターをご覧ください。 6年前に閉鎖されました。 安全でないパスワードを選択するユーザーの権利を制限することを考えています（長さによって決定されるパスワードの安全性、使用される文字の種類（大文字/小文字、数字、記号など）、および使用できるかどうか）レインボーテーブルにあります）、侵害された場合にアカウントが受ける損害を制限します。 このアイデアのアプリケーションはまだありませんが、フォーラムなどを書いています：1234をパスワードとして使用するユーザーは、投稿する前にキャプチャを入力するか、厳格なスパム対策の対象となる場合がありますコンテンツを拒否するタイムアウトまたはベイジアンフィルターとして。このフォーラムが非常に階層的であり、モデレーターまたは何らかの手段による「昇格」を許可する場合、これは、それらが特権を獲得するのを阻止するか、特権を持っていることを伝えますが、より安全なものに変更せずにそれらを行使させませんパスワード。 もちろん、これはセキュリティの唯一の尺度となることはできませんが、それ以外の場合は適切なセキュリティプラクティスの次にうまくいくかもしれません。 どう思いますか？これは無理をして、より重要なセキュリティ慣行からフォーカスを奪い取っているのでしょうか、それともリスクを制限し、ユーザーに安全なパスワードの使用を促す良い方法ですか？

13 security  passwords  authorization  risk  permissions 

パスワードがハッシュされて保存されている場合、パスワードをリセットしようとすると、パスワードが最後のパスワードと似ていることをコンピューターはどのように知るでしょうか？1つはハッシュ化され、元に戻すことはできないため、2つのパスワードはまったく異なりませんか？

11 database  security  hashing  passwords 

この質問は、私たちが取り組んでいるウェブサイトの「アカウントの作成」ページについて同僚と話し合っているときに今日出てきました。 私の同僚の意見では、登録をできるだけ迅速かつシームレスに行う必要があるため、ユーザーにメールを尋ねて残りを処理するだけです。 私はその意図に同意しますが、いくつかの懸念があります。 我々はパスワードを生成するので、我々は持っているパスワードが強い十分であることを確認する責任を 私の経験では、わかりにくいパスワードに直面したとき、ユーザーはそれを投稿に書き留める可能性が高い パスワードを書き留めていないユーザーは、パスワードを忘れる可能性が高いです。つまり、定期的に新しいパスワードを要求する必要があり、誰にとっても面白くない ただし、ユーザーが作成したパスワードの一般的な品質と、多くの人がすべて（「震え」）に同じパスワードを使用する傾向があるという事実を考えると、強力なパスワードを生成することが理にかなっていることがわかります。 私はまだそれについて不安を感じています。ユーザーがクレジットカードの詳細を保存するオプションを持つ商人のウェブサイトに取り組んでいるので、最も安全なアプローチを使用することが明らかに非常に重要です。

11 security  passwords