タグ付けされた質問 「password-protection」

10
PHPでパスワードをハッシュするためにbcryptをどのように使用しますか?
「PHPにパスワードを保存するためにbcryptを使用する、bcryptルール」というアドバイスを時々聞いています。 しかし、何bcryptですか?PHPはそのような機能を提供していません。Wikipediaはファイル暗号化ユーティリティについて混乱しています。Web検索では、異なる言語でのBlowfishの実装がいくつか明らかになっています。現在、Blowfishはを介してPHPでも利用できますが、mcryptパスワードの保存にどのように役立ちますか?Blowfishは汎用の暗号であり、2つの方法で機能します。暗号化できた場合は、復号化できます。パスワードには一方向ハッシュ関数が必要です。 説明は何ですか?

17
PHP経由のHTTP認証ログアウト
HTTP認証保護フォルダーからログアウトする正しい方法は何ですか? これを実現できる回避策はありますが、バグが発生したり、特定の状況やブラウザで機能しない可能性があるため、潜在的に危険です。それが私が正確でクリーンな解決策を探している理由です。

8
暗号化/パスワード保護を備えたSQLite
私はSQLiteの使い方を学んでいるだけで、それが可能かどうか知りたいと思っていました。 データベースファイルの暗号化? データベースのオープンをパスワードで保護しますか? PS。この "SQLite暗号化拡張(SEE)"があることは知っていますが、ドキュメントによると、 "SEEはライセンスソフトウェアです..."および "SEEの永続的なソースコードライセンスのコストは2000ドルです。"


6
サブディレクトリから.htaccessパスワード保護を削除する方法
パスワードを使用して自分のWebサイト全体をパスワードで保護しています.htaccessが、サブディレクトリの1つを公開して、パスワードなしで表示できるようにしたいと考えています。 サブディレクトリのhtaccessパスワード保護を無効にするにはどうすればよいですか?具体的には、.htaccess構文は何ですか。 これ.htaccessが私のFTPのルートに置かれた私のファイルです。 AuthName "Site Administratrion" AuthUserFile /dir/.htpasswd AuthGroupFile / dev / null 安全なAuthName AuthType Basic ユーザーusername1が必要 注文を許可、拒否 すべてから許可

7
HTTPSを介したプレーンテキストパスワード
私は現在、HTTPS(したがってSSL暗号化)で動作するPHP OpenIDプロバイダーに取り組んでいます。 それは間違っている私は、プレーンテキストとしてパスワードを送信するために?理論的にはHTTPSはインターセプトできないため、何も問題はありません。または、これはあるレベルで安全ではなく、私はこれを見逃していますか?

9
パスワードハッシュのランダムでないソルト
更新:私は最近この質問から、以下の全体の議論で私(そして他の人もそうだったと確信しています)は少し混乱していることを学びました:私がレインボーテーブルと呼んでいるものは実際にはハッシュテーブルと呼ばれます。レインボーテーブルは、より複雑な生き物であり、実際にはヘルマンハッシュチェーンのバリアントです。解答は同じであると私は信じていますが(解読には至らないため)、一部の議論は少し歪んでいる可能性があります。 質問:「レインボーテーブルとは何ですか。どのように使用されますか?」 通常、Rainbow Tableの攻撃から保護するなど、ハッシュ関数(パスワードなど)と共に使用するために、暗号として強力なランダム値をソルトとして使用することを常にお勧めします。 しかし、実際にはソルトがランダムであることは暗号的に必要ですか?これに関して、一意の値(userIdなどのユーザーごとに一意)で十分でしょうか?実際には、単一のRainbow Tableを使用してシステムのすべて(またはほとんど)のパスワードをクラックする ことはできません... しかし、エントロピーの欠如は、ハッシュ関数の暗号強度を本当に弱めるのでしょうか? ソルトを使用する理由、それを保護する方法(保護する必要はない)、単一の定数ハッシュを使用する(しない)、または使用するハッシュ関数の種類については尋ねていません。 塩がエントロピーを必要とするかどうかだけです。 これまでの回答に感謝しますが、私が(少し)あまり慣れていない領域に焦点を当てたいと思います。主に暗号解読への影響-誰かが暗号数学PoVから何らかの入力を持っている場合、私は最も感謝します。 また、考慮されていなかった追加のベクトルがある場合、それも素晴らしい入力です(複数のシステムでの@Dave Sherohmanポイントを参照)。 それ以上に、理論、アイデア、またはベストプラクティスがある場合は、証明、攻撃シナリオ、または経験的証拠のいずれかでこれをバックアップしてください。または、許容できるトレードオフについての有効な考慮事項...私はこのテーマのベストプラクティス(大文字のBの大文字P)に精通しています。これが実際に提供する価値を証明したいと思います。 編集:ここでいくつかの本当に良い答えがありますが、@ Daveが言うように、それは一般的なユーザー名のレインボーテーブルに帰着します...そしてあまり一般的ではない名前も考えられます。ただし、ユーザー名がグローバルに一意である場合はどうなりますか?必ずしも私のシステムで一意である必要はありませんが、ユーザーごとに-たとえば、電子メールアドレス。 (@Daveが強調しているように、saltは秘密にされていないため)シングルユーザー用のRTを作成するインセンティブはなく、これはクラスタリングを妨げます。唯一の問題は、別のサイトで同じメールアドレスとパスワードを使用している可能性があることです。 それで、それは暗号解読に帰着します-エントロピーは必要ですか、それとも不要ですか?(私の現在の考えでは、暗号解読の観点からは必要ではありませんが、他の実際的な理由からです。)
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.