問題タブ [passwords]

私はLAMP（erl）スタックで開発しており、隠されたパスワードを保存するいくつかの方法を知っています。MySQL4.1.1とPerl5.8を考えると、ベストプラクティスがあると感じている人たちと、それがベストである理由を聞きたいと思います。

MySQL ENCODE（）およびDECODE（）関数を使用して私が読んだ1つのオプションは、私にはかなり良いように聞こえます...あなたの考えは？

この質問に対する現在のトップ投票は次のように述べています。

もう 1 つの問題は、セキュリティに関連するものではありますが、パスワードのハッシュ化と暗号化の違いを完全に理解できていないことです。プログラマーが安全でない「パスワードを通知する」機能を提供しようとしているコードで最もよく見られます。

この違いは一体何なのでしょうか？ハッシングは暗号化の一形態であるという印象を常に持っていました。投稿者が言及している危険な機能は何ですか?

HTML でログイン送信フォームを作成しましたが、何らかの理由でユーザー/パスワードのオートコンプリートが、Firefox で期待どおりに機能しません。

Firefox では次のようになります。

• ユーザー名とパスワードを入力し、ログインボタンをクリックします
• Firefox は、パスワードを覚えておきたいかどうかを尋ねてきます。「記憶」を押すと、ログインが機能します。(このテストを実行する前に、覚えているすべてのパスワードを削除したことを確認しました)
• ログアウトしてログインページに戻ります。ユーザー名とパスワードのフィールドが事前に入力されていることを期待しますが、そうではありません (FF が特定の URL に対して 1 つのユーザー/パスワードの組み合わせのみを保存している場合、この組み合わせはフォームに自動的に事前入力されます)。

Cookie を使用しない (したくない) ことに注意してください。ユーザー名とパスワードが実際に保存されていることをFFパスワードマネージャーで確認しました（保存されていました）

このページのコードは次のとおりです。

コードの何が問題になっていますか? 私のコードでオートコンプリートを FF で動作させるにはどうすればよいですか?

オートコンプリートは、たとえば gmail で正しく機能します。gmail のログイン ページにアクセスするたびに、メール アドレスとパスワードのフィールドが正しく事前入力されています。「このコンピューターで私を記憶する」チェックボックスを使用しないため、Cookie は使用されません。

どうぞよろしくお願いいたします。碧玉

アップデート
オートコンプリートは、Firefox で有効になっています。IE互換を維持したい。

銀行の Web サイトなどで、自分のユーザー ID が保存されておらず (他の一般的に入力されるもののようにドロップダウンに表示されません)、パスワードを記憶するためのプロンプトも表示されないことに気付きました。これはどのように行われますか？サイトが「特別」または例外であることをブラウザにどのように通知しますか? ちょっと興味があるんだけど。

私のmysqlデータベースには、パスワード列を持つユーザーテーブルがあります。現在、MD5 アルゴリズムを使用してユーザーのパスワードをハッシュし、データベースに保存しています。今、私は自分が安全意識の高い人だと思いたいです。MySQL のドキュメントを読んでいるときに、MD5 や SHA/SHA1 ハッシュ メソッドは推奨されていませんが、代替手段は提供されていないことに気付きました。

MySQL でパスワードをハッシュする最良の方法は何ですか? PHP と MySQL の両方でネイティブにサポートされている関数は理想的であり、現在の実装では必要です。

ありがとう！

興味があり、それが私を激怒させるので、ここの誰かがたまたま銀行で働いているか、そうでなければこれに対する答えを知っているのではないかと思っていました.

私はいくつかのオンライン バンキング サイト (英国と北米) を使用しましたが、それらは普遍的に次のパスワード パターンを強制し/[\w\d]{6,8}/て/.{6,20}/います。ほぼすべての !banking サイトにアクセスできます。

これはストレージ スペースに関係していると言われていますが、数学ではそれがサポートされていないようです。銀行がパスワード レコード用にシャドー テーブルを保持していると仮定して、1 アカウントあたり平均 10 と寛大に言いましょう。パスワードの許容長を 2 倍にし、8 文字 8 ビットの既存の形式に基づいて文字セットのビット幅を 2 ​​倍にすると、余分な11*を意味します。 2*8 = アカウントあたり 176 バイトなので、1M アカウントあたり ~168Mb です。1 億の口座をサポートする巨大な銀行だとしましょう - それでも 16Gb しかありません!

そんな単純なことじゃないですよね？確かに私の数字は根拠がありません。

または、銀行は銀行であり、恐竜をうろついているよりも良い理由はないというのがここでの答えです。

www.random.com/forum のパスワードが銀行のパスワードよりも強力な技術的な理由を知っている人はいますか?

リポジトリアクセス用のSubversionユーザー名とパスワードをフォルダ内のテキストファイルに保存しているconf場合、使用できるパスワードの最大長はどれくらいですか？つまり、次のファイルの秘密はどのくらいの期間である可能性がありますか？

シナリオ: PHP で作成された Web アプリケーションは、Amazon Web サービスを利用しており、機能するためにアクセス キー ID とシークレット アクセス キーを手元に置いておく必要があります。このデータを安全に保存するための現在の推奨事項や API はありますか?

私の考えは、ローカルサーバー変数から作成されたキーに基づいて、ファイルに対称的に暗号化することです。そうすれば、誰かが FTP 経由でファイルのコピーを取得したり、ファイルがコピーされたラップトップを紛失したりした場合、[うまくいけば] 意味不明になります。私が懸念しているのは、熟練した攻撃者が独自のスクリプトをアップロードして復号化できることです。

これは一般的な状況のように思えますが、快適な解決策を見つけたことはありません。AWS に送信する HMAC を作成するには元のデータが必要なため、明らかに一方向ハッシュは使用できません。関連する SO の質問へのリンクは大歓迎です。

保存する前にパスワードを 2 回ハッシュすることは、1 回ハッシュすることよりも多かれ少なかれ安全ですか?

私が話しているのは、これを行うことです：

これだけの代わりに：

安全性が低い場合は、適切な説明 (またはリンク) を提供できますか?

また、使用するハッシュ関数によって違いはありますか? 同じハッシュ関数を繰り返す代わりに、(たとえば) md5 と sha1 を混ぜても違いはありますか?

注 1: 「ダブル ハッシュ」と言うときは、パスワードをよりわかりにくくするために、パスワードを 2 回ハッシュすることを指しています。衝突を解決するテクニックについて話しているのではありません。

注 2: 本当に安全にするには、ランダムなソルトを追加する必要があることはわかっています。問題は、同じアルゴリズムで 2 回ハッシュすることがハッシュに役立つか、それとも損なわれるかです。

2 つの異なるドメインを持つ 2 つの異なるサーバーで 2 つの異なるサイトを実行しています。一方のサイトでは Joomla を実行し、もう一方のサイトでは Moodle を実行しています。Joomla サイトのユーザー テーブルに基づいて認証を行うように Moodle サーバーを構成したので、ユーザー情報の信頼できる情報源が得られます。

私がやりたいことは次のとおりです: 誰かが Joomla サイトにサインインした後、Moodle サイトへのリンクを提供します。Moodle サイトは黙ってログインし、シングル サインオン ソリューションを偽装します。Joomla のパスワードは MD5 化されており、それぞれに独自のシークレット ソルトがあります。

これに対処する方法として最初に考えたのは、パスワードがプレーンテキストで保存されていることを Moodle に伝え、リンクをクリックしたときに非表示のフォーム入力を介して暗号化されたパスワードを送信することでした。それに関する明らかなセキュリティ上の問題は別として、Moodle インターフェイス経由でログインしようとすると、巨大な MD5 文字列を入力する必要があることも意味していました。

Moodle の認証モジュールを変更して、送信されたパスワードが特定の基準 (例: 16 進数の 32 文字) に一致する場合、Joomla バージョンと比較する前に MD5 を実行しないようにすることを検討してきました。 （暗号化されたパスワードを発見したら）それを使用してログインします。必要なのは、暗号化されたパスワードをJoomlaからMoodleに送信し、そのログイン要求を別の方法で処理するようにMoodleに通知する特別な方法です。

何かご意見は？