CodeIgniter の認証ライブラリはどのように選択すればよいですか? [closed] 質問する

更新 (2010 年 5 月 14 日):

結局、ロシアの開発者 Ilya Konyukhov はこの記事を読んで挑戦し、以下の推奨事項と要件に従って、DX Auth に基づく CI 用の新しい認証ライブラリを作成しました。

そしてその結果タンク認証OP の質問に対する答えのように見えます。私はここで大胆に、Tank Auth を CodeIgniter で現在利用できる最高の認証ライブラリと呼びたいと思います。これは、必要な機能がすべて備わっており、不要な機能は一切ない、堅牢なライブラリです。

タンク認証

長所

• フル機能
• 機能セットを考慮した無駄のないフットプリント（20ファイル）
• 非常に良いドキュメント
• シンプルでエレガントなデータベース設計（DB テーブルは 4 つだけ）
• ほとんどの機能はオプションであり、簡単に設定できます
• 言語ファイルのサポート
• reCAPTCHAをサポート
• CIの検証システムへのフック
• アクティベーションメール
• メールアドレス、ユーザー名、またはその両方でログイン（設定可能）
• 未有効化のアカウントは自動的に期限切れになります
• シンプルだが効果的なエラー処理
• ハッシュ化には phpass を使用します (また、DB 内の自動ログイン コードもハッシュ化します)
• セキュリティ質問を使用しない
• ユーザーとプロフィールのデータを分離するのはとてもいいことだ
• ログイン失敗時の非常に合理的なセキュリティ モデル (ボットや DoS 攻撃に対する優れた保護)

（マイナー）欠点

• 紛失したパスワードコードはDBでハッシュ化されません
• ネイティブの（貧弱な）CAPTCHAが含まれています。これは、（Google所有の）reCAPTCHAサービスに依存したくない人にとっては便利ですが、実際には十分に安全ではありません。
• オンラインドキュメントが非常に少ない (コードは適切にドキュメント化されており直感的なので、ここでは小さな問題です)

Tank Authをここからダウンロード

元の回答:

私も独自のものを実装しました (数週間の作業を経て、現在約 80% 完了)。まず、FreakAuth Light、DX Auth、Redux、SimpleLogin、SimpleLoginSecure、pc_user、Fresh Powered など、他のものをすべて試しました。私の意見では、どれも標準に達していませんでした。基本的な機能が欠けていたり、本質的に安全でなかったり、私の好みには肥大化しすぎたりしていました。

実は、私は CodeIgniter の認証ライブラリをテストしていたときに (新年直後に) 詳細なまとめを作成しました。参考までに、それを皆さんと共有します。

DX認証

長所

• 非常に充実した機能
• フットプリントは中程度（25以上のファイル）ですが、かなりスリムに感じられます。
• 素晴らしいドキュメントですが、一部英語が少し壊れています
• 言語ファイルのサポート
• reCAPTCHAをサポート
• CIの検証システムへのフック
• アクティベーションメール
• 未有効化のアカウントは自動的に期限切れになります
• ソルトについては grc.com をお勧めします (PRNG としては悪くない)
• 保存された「理由」文字列による禁止
• シンプルだが効果的なエラー処理

短所

• ユーザーが忘れたパスワードを「リセット」することのみを許可します（再アクティベーション時に新しいパスワードを選択させるのではなく）
• 自作の疑似イベントモデル - 意図は良いが的を外している
• ユーザーテーブルにパスワードフィールドが 2 つある、不適切なスタイル
• 2 つの別々のユーザー テーブルを使用します (1 つは「一時」ユーザー用 - あいまいで冗長)
• 潜在的に安全でないmd5ハッシュを使用する
• 失敗したログイン試行はユーザー名ではなく IP によってのみ保存されるため、安全ではありません。
• 自動ログイン キーはデータベースでハッシュされません。実質的には、パスワードを平文で保存するのと同じくらい安全ではありません。
• ロール システムは完全に混乱しています。is_admin 関数にはロール名がハードコードされており、is_role は完全に混乱しており、check_uri_permissions は混乱しており、権限テーブル全体は悪いアイデアです (URI が変更され、ページが保護されていない状態になる可能性があります。権限は常に機密ロジックがある場所に正確に保存する必要があります)。これは致命的です。
• ネイティブ（低品質）CAPTCHA を含む
• reCAPTCHA機能のインターフェースが乱雑

フリークオーツライト

長所

• 非常に充実した機能
• ほとんどが非常によく文書化されたコード
• ユーザーとプロフィールデータを分離するのは良いことだ
• CIの検証システムへのフック
• アクティベーションメール
• 言語ファイルのサポート
• 積極的に開発

短所

• 少し肥大化した感じ（50以上のファイル）
• しかし、自動クッキーログインがありません（！）
• ユーザー名とメールアドレスの両方でのログインはサポートされていません
• UTF-8文字に問題があるようです
• 大量の自動読み込みが必要（パフォーマンスの低下）
• 適切に管理されていない設定ファイル
• ビューとコントローラーの分離がひどく、ビューには多くのプログラム ロジックがあり、出力はコントローラーにハードコードされています。これは致命的です。
• 含まれているビューの HTML コードが不十分
• 標準以下のCAPTCHAが含まれています
• コメントされたデバッグエコーがどこにでも
• 特定のフォルダ構造を強制する
• 特定の Ajax ライブラリを強制します (切り替えることはできますが、そもそもそこに存在すべきではありません)
• ログイン試行回数に上限なし - 非常に危険です! 絶対にやめて!
• フォーム検証をハイジャックする
• 潜在的に安全でないmd5ハッシュを使用する

pc_ユーザー

長所

• 小さなフットプリントに優れた機能セット
• 軽量、肥大化なし（3ファイル）
• エレガントな自動クッキーログイン
• オプションのテスト実装が付属（素晴らしい機能）

短所

• 古い CI データベース構文を使用します (安全性が低い)
• CIの検証システムに接続しない
• ちょっと直感に反するステータス（役割）システム（インデックスが逆さまなので実用的ではない）
• 潜在的に安全でない sha1 ハッシュを使用します

フレッシュパワー

長所

• 小さなフットプリント（6ファイル）

短所

• 重要な機能が多数欠けています。これは致命的です!
• すべてがハードコードされています。これは致命的です!

Redux / イオン認証

によるとCodeIgniter ウィキRedux は廃止されましたが、Ion Auth フォークは健在です。https://github.com/benedmunds/CodeIgniter-Ion-Auth

Ion Auth は、重すぎたり高度すぎたりすることなく、機能が充実したライブラリです。ほとんどの場合、その機能セットはプロジェクトの要件を十分に満たします。

長所

• 軽量でCodeIgniterとの統合が簡単
• ライブラリから直接メールを送信できます
• オンラインで十分に文書化されており、活発な開発者/ユーザーコミュニティがある
• プロジェクトへの導入が簡単

短所

• 他のDBスキーマよりも複雑なDBスキーマ
• ドキュメントにはいくつかの領域で詳細が欠けている

シンプルログインセキュア

長所

• 小さなフットプリント (4 ファイル)
• ミニマルで、無駄が一切ない
• ハッシュ化に phpass を使用する (優秀)

短所

• ログイン、ログアウト、作成、削除のみ
• 重要な機能が多数欠けています。これは致命的です!
• 図書館というよりは出発点

誤解しないでください。私は上記のライブラリを軽視するつもりはありません。それぞれの開発者が成し遂げたことや、それぞれのライブラリがどれだけ進歩したかに非常に感銘を受けており、自分のライブラリを構築するためにそれらのコードの一部を再利用することに抵抗はありません。私が言いたいのは、これらのプロジェクトでは、重要な「必要なもの」(厳格なセキュリティ対策など) から、よりソフトな「あったらいいもの」に焦点が移ってしまうことがあるということです。私はその点を改善したいと考えています。

したがって、基本に戻ります。

CodeIgniter の認証を正しく行う

認証ライブラリに必要な最小限の機能リストを以下に示します。これは、私自身のライブラリの機能リストのサブセットでもあります ;)

1. オプションのテスト実装を備えた小型フットプリント
2. 完全なドキュメント
3. 自動ロードは不要。パフォーマンス向上のためにライブラリをジャストインタイムでロード
4. 言語ファイルのサポート。ハードコードされた文字列はありません。
5. reCAPTCHAはサポートされていますがオプションです
6. 推奨される TRUE ランダム ソルト生成 (例: random.org または random.irb.hr を使用)
7. サードパーティのログインをサポートするオプションのアドオン（OpenID、Facebook Connect、Google アカウントなど）
8. ユーザー名またはメールアドレスを使用してログイン
9. ユーザーとプロフィールデータの分離
10. アクティベーションとパスワード紛失に関するメール
11. 自動クッキーログイン機能
12. ハッシュ用に設定可能な phpass (もちろん適切にソルトされています!)
13. パスワードのハッシュ化
14. 自動ログインコードのハッシュ化
15. 紛失したパスワードコードのハッシュ化
16. CIの検証システムへのフック
17. セキュリティの質問はありません!
18. サーバー側で強力なパスワード ポリシーを強制し、オプションでクライアント側 (Javascript) 検証機能も搭載
19. 辞書攻撃と DoS 攻撃の両方に対するベスト プラクティス対策により、失敗したログイン試行の最大回数を強制します。
20. すべてのデータベース アクセスは、準備された (バインドされた) ステートメントを通じて実行されます。

注: 最後のいくつかのポイントは、Web アプリケーションに必要のない超高度なセキュリティの過剰ではありません。認証ライブラリがこれらのセキュリティ標準を 100% 満たしていない場合は、使用しないでください。

最近、無責任なコード作成者がソフトウェアからこれらの要素を除外した有名な例がいくつかある。17 番目は、大統領選挙中にサラ・ペイリンの AOL メールがハッキングされたケースである。18 番目と 19 番目が、ブリトニー・スピアーズ、バラク・オバマ、Fox News などの Twitter アカウントが最近ハッキングされたときに犯人となった。20 番目だけでも、2008 年に中国のハッカーが 1 回の自動ハッキングで 70,000 を超える韓国の Web サイトから 900 万件の個人情報を盗み出したケースである。

これらの攻撃は脳外科手術ではありません。裏口を全開にしたままにしておくと、正面に鍵をかけて安全だと思い込んで誤った認識に陥ることがあります。さらに、CodeIgniter のようなベスト プラクティス フレームワークを選択するほどコーディングに真剣に取り組むのであれば、少なくとも最も基本的なセキュリティ対策を正しく実施する義務があります。

<愚痴>

基本的には、次のようになります。認証ライブラリが、高度なロール管理、PHP4 互換性、美しい CAPTCHA フォント、国別テーブル、完全な管理パネル、付加機能など、多くの機能を提供していても、ライブラリがベスト プラクティスに従わずにサイトのセキュリティを低下させるのであれば、私は気にしません。認証パッケージであるため、1 つのこと、つまり認証を正しく行う必要があります。認証ができない場合、実際にはメリットよりもデメリットの方が大きいことになります。

</rant>

/イェンス・ローランド