[解決済み] CodeIgniterの認証ライブラリはどのように選べばよいのでしょうか？[クローズド］

質問

がありますね。 いくつか . 整備されていて使いやすいのはどれですか？その長所と短所は何ですか？

解決方法は？

更新情報（2010年5月14日）。

この記事を読んだロシアの開発者 Ilya Konyukhov が、DX Auth をベースとした CI 用の新しい認証ライブラリを、以下の推奨事項と要件に従って作成したことが判明しました。

そして出来上がったのが タンクAuth は、OPの質問に対する答えのように見えます。私はここで思い切って、Tank Authを現在入手可能なCodeIgniterのための最高の認証ライブラリと呼びたいと思います。必要な機能をすべて備え、無駄なものを一切排除した、揺るぎないライブラリです。

タンクAuth

<ブロッククオート

プロフェッショナル

• 充実した機能
• 機能セットを考慮したリーンフットプリント(20ファイル)
• 非常に優れたドキュメント
• シンプルで洗練されたデータベース設計（4つのDBテーブルのみ）
• ほとんどの機能はオプションで、簡単に設定可能
• 言語ファイル対応
• reCAPTCHA対応
• CI のバリデーションシステムにフックする
• アクティベーションメール
• 電子メール、ユーザー名、またはその両方によるログイン（設定可能）
• 未使用のアカウントは自動で失効
• シンプルで効果的なエラー処理
• ハッシュ化にはphpassを使用（DBの自動ログインコードもハッシュ化）。
• セキュリティ質問を使用しない
• ユーザーデータとプロファイルデータの分離は非常に素晴らしい
• ログインの失敗に関する非常に合理的なセキュリティモデル（ボットやDoS攻撃に対する優れた防御策）

(小)短所

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

Tank Authのダウンロードはこちら

---

オリジナルの回答です。

私も自分で実装してみました（数週間の作業で現在8割程度完成）。FreakAuth Light, DX Auth, Redux, SimpleLogin, SimpleLoginSecure, pc_user, Fresh Powered, and a few more.などなど。基本的な機能が欠けていたり、本質的に安全でなかったり、私の好みからすると肥大化しすぎていたりと、IMOではどれも同等レベルではありませんでした。

実は、CodeIgniterの認証ライブラリをテストしていた時（正月明け）に、全ライブラリを詳しくまとめたことがあります。参考までに、それをシェアしておきます。

DX Auth

<ブロッククオート

プロフェッショナル

• 非常に充実した機能
• 中程度のフットプリント（25ファイル以上）でありながら、非常にスリムな印象を与えることができる
• ドキュメントが充実している。ただし、一部、やや砕けた英語になっている。
• 言語ファイル対応
• reCAPTCHA対応
• CI のバリデーションシステムにフックする
• アクティベーションメール
• 未使用のアカウントは自動で失効
• 塩については grc.com を推奨 (PRNG としては悪くない)
• 保存された「理由」文字列による禁止
• シンプルで効果的なエラー処理

短所

• 紛失したパスワードの「リセット」のみ可能（再アクティブ化時に新しいパスワードを選択させるのではなく）。
• 自作の擬似イベントモデル - 良かれと思ってやったが、的外れだった
• ユーザーテーブルの2つのパスワードフィールド、悪いスタイル
• 2つの別々のユーザーテーブルを使用（1つは「一時的な」ユーザー用 - あいまいで重複している）
• 安全でない可能性のあるmd5ハッシュを使用しています。
• ログインに失敗した場合、ユーザー名ではなくIP名で保存されます。 安全ではありません！
• 自動ログインキーがデータベースでハッシュ化されていない - 実質的にパスワードを平文で保存するのと同じくらい安全ではありません
• ロールシステムは完全に混乱しています: ハードコードされたロール名を持つis_admin関数、is_roleは完全に混乱、check_uri_permissionsは混乱、全体の権限テーブルは悪い考えです（URIは変更可能でページを保護されていないレンダリング、権限は常に機密ロジックがある場所に正確に格納されるべきです）。パーミッションは常にセンシティブなロジックの場所に正確に保存されるべきです）。
• ネイティブの（貧弱な）CAPTCHAを含む
• reCAPTCHA関数のインターフェイスが汚い

FreakAuthライト

<ブロッククオート

プロフェッショナル

• 非常に充実した機能
• ほとんどの場合、非常によくドキュメント化されたコード
• ユーザーデータとプロファイルデータの分離はいい感じです
• CIのバリデーションシステムとの連携
• アクティベーションメール
• 言語ファイル対応
• 積極的な開発

短所

• 少し肥大化した感じがする（50ファイル以上）
• それなのに、Cookieの自動ログインがない（！）。
• ユーザー名とメールアドレスの両方を使ったログインに対応していない
• UTF-8文字に問題があるようです。
• 多くのオートローディングを必要とする（パフォーマンスを阻害する）
• 設定ファイルの管理が悪い
• ビューとコントローラの分離がひどく、多くのプログラムロジックがビューに、出力がコントローラにハードコードされています。これは致命的です。
• 含まれるビューのHTMLコードの貧弱さ
• 規格外のCAPTCHAが含まれています。
• コメント付きデバッグエコーが随所に
• 特定のフォルダ構造を強制的に作成
• 特定のAjaxライブラリを強制的に使用する（変更可能だが、そもそも存在してはならない）。
• ログイン試行回数に上限なし - 非常に危険! 危険です!
• フォームバリデーションを妨害する
• 安全でない可能性のあるmd5ハッシュを使用しています。

pc_user

<ブロッククオート

プロフェッショナル

• 小さなフットプリントのための優れた機能セット
• 軽量で無駄がない(3ファイル)
• エレガントなCookieの自動ログイン
• オプションでテスト実装が可能（いいとこ取り）

短所

• 古いCIデータベースの構文を使用（安全性が低い）
• CIのバリデーションシステムにフックしない
• ちょっと直感的でないステータス（ロール）システム（インデックスが逆さま - 実用的でない）。
• 安全でない可能性のあるsha1ハッシュを使用しています。

フレッシュパワード

プロフェッショナル

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

短所

• 必要な機能の多くが欠けている。これは致命的です。
• すべてがハードコーディングされている。致命的です。

Redux / Ion Auth

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

Ion Authは、重すぎず、高度すぎず、よく機能するライブラリです。ほとんどの場合、その機能セットはプロジェクトの要件に十二分に応えられるでしょう。

<ブロッククオート

長所

• 軽量で、CodeIgniterとの統合が簡単。
• ライブラリから直接メール送信をサポート
• オンラインドキュメントが充実しており、活発な開発者/ユーザーコミュニティがある
• プロジェクトへの導入が容易

短所

• DBスキーマが他より複雑
• ドキュメントの詳細が不足している部分がある

シンプルロジンセキュア（SimpleLoginSecure

<ブロッククオート

プロフェッショナル

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

短所

• ログイン、ログアウト、作成、削除のみ
• 多くの必須機能が欠けている。もうダメだ
• ライブラリというより、出発点

---

誤解のないようにお願いします。 私は、これらのライブラリの開発者が成し遂げたこと、そしてそれぞれがどれほど進歩してきたかに非常に感銘を受けていますし、私自身のライブラリを構築するために彼らのコードのいくつかを再利用することに抵抗はありません。私が言いたいのは、このようなプロジェクトでは、時々、本質的な「必要なもの」（例えばハードなセキュリティ対策）から、ソフトな「良いもの」へと焦点が移ってしまうことがあるということです。

だから、基本に立ち返る。

CodeIgniterの認証が完了 右

これが、私が認証ライブラリに要求する最小限の機能リストです。また、これは私自身のライブラリの機能リストのサブセットでもあります;)

<ブロッククオート

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

注：最後の数点は ではなく あなたのウェブアプリケーションには必要のない、超高セキュリティのやりすぎです。 もし、認証ライブラリがこれらのセキュリティ基準を100％満たしていない場合は、使用しないでください。

最近の有名な例では、無責任なプログラマーが自分のソフトウェアからこれらを省いてしまったことがあります。#17は、大統領選挙期間中にサラ・ペイリンのAOLメールがハッキングされた原因です。18と19は、ブリトニー・スピアーズ、バラク・オバマ、フォックス・ニュースなどのツイッターアカウントがハッキングされたときの犯人です。

これらの攻撃は脳外科手術ではありません。裏口のドアを大きく開けたままにしておくと、表側のドアをボルトで固定することで誤った安心感を抱いてしまうからです。さらに、もしあなたがCodeIgniterのようなベストプラクティスのフレームワークを選択するほどコーディングに真剣であるなら、少なくとも最も安全なものを手に入れる義務があります。 基本的な のセキュリティ対策は万全です。

---

<rant>

基本的には、こんな感じです。 どうでもいい 認証ライブラリが多くの機能、高度なロール管理、PHP4互換性、きれいなCAPTCHAフォント、国別テーブル、完全な管理パネル、ベルとホイッスルを提供するならば、ライブラリは実際に私のサイトが 安全性が低い ベストプラクティスに従わないことで それは 認証 パッケージは、1つのことを正しく行う必要があります。認証です。もしそれが あれ しかし、それは良いことよりも悪いことの方が多いのです。

</rant>

/イェンス・ローランド