更新（2010年5月14日）：
結局のところ、ロシアの開発者Ilya Konyukhovがこれを読んだ後、ガントレットを手に取り、以下の推奨事項と要件に従って、DX Authに基づいてCI用の新しい認証ライブラリを作成しました。
結果のTank Authは、OPの質問に対する答えのように見えます。ここから外に出て、Tank Authを、今日利用可能なCodeIgniterに最適な認証ライブラリと呼びます。これは、必要なすべての機能を備え、必要のない機能をすべて備えた堅実なライブラリです。
タンク認証
長所
- フル機能
- 機能セットを考慮した無駄のないフットプリント（20ファイル）
- 非常に良いドキュメント
- シンプルでエレガントなデータベース設計（4つのDBテーブルのみ）
- ほとんどの機能はオプションであり、簡単に設定できます
- 言語ファイルのサポート
- サポートされるreCAPTCHA
- CIの検証システムにフック
- アクティベーションメール
- 電子メール、ユーザー名、またはその両方でログイン（構成可能）
- 非アクティブ化されたアカウントは自動的に期限切れになります
- シンプルで効果的なエラー処理
- ハッシュにphpassを使用します（DBの自動ログインコードもハッシュします）。
- 秘密の質問を使用しない
- ユーザーとプロファイルデータの分離は非常に便利です
- ログイン試行の失敗に関する非常に合理的なセキュリティモデル（ボットおよびDoS攻撃に対する優れた保護）
（マイナー）短所
- 紛失したパスワードコードはDBでハッシュされません
- （Googleが所有する）reCAPTCHAサービスに依存したくない人には便利なネイティブ（貧弱な）CAPTCHAが含まれていますが、実際には十分に安全ではありません
- 非常にまばらなオンラインドキュメント（コードは適切に文書化されており、直感的であるため、ここでは小さな問題）
ここでタンク認証をダウンロード
元の答え：
私も自分で実装しました（現在、約80％は数週間の作業で完了しました）。最初に他のすべてを試しました。FreakAuth Light、DX Auth、Redux、SimpleLogin、SimpleLoginSecure、pc_user、Fresh Powered、その他いくつか。それらのどれも、基本的にIMOに欠けていたり、本質的に安全ではなかったり、私の好みでは肥大化していなかったり、IMOに達していませんでした。
実際、CodeIgniterのすべての認証ライブラリを詳細にまとめました（新年の直後に）。FWIW、私はあなたとそれを共有します：
DX Auth
長所
- 非常にフル機能
- 中程度のフットプリント（25以上のファイル）ですが、かなりスリムに感じることができます
- 優れたドキュメント。ただし、一部はわずかに英語が壊れている
- 言語ファイルのサポート
- サポートされるreCAPTCHA
- CIの検証システムにフック
- アクティベーションメール
- 非アクティブ化されたアカウントは自動的に期限切れになります
- 塩のgrc.comを提案します（PRNGに悪いことではありません）
- 保存された「理由」文字列による禁止
- シンプルで効果的なエラー処理
短所
- ユーザーに失われたパスワードの「リセット」のみを許可する（再アクティベーション時に新しいパスワードを選択させるのではなく）
- 自作の疑似イベントモデル-意図は正しいが、目標を達成できていない
- ユーザーテーブルの2つのパスワードフィールド、不適切なスタイル
- 2つの個別のユーザーテーブルを使用（1つは「temp」ユーザー用-あいまいで冗長）
- 安全でない可能性のあるmd5ハッシュを使用する
- 失敗したログイン試行は、ユーザー名ではなくIPによってのみ保存されます-安全ではありません！
- データベースでハッシュされていない自動ログインキー-パスワードをクリアテキストで保存するのと同じくらい安全ではありません！
- 役割システムは完全な混乱です：is_admin関数はハードコードされた役割名、is_roleは完全な混乱、check_uri_permissionsは混乱です、権限テーブル全体は悪い考えです（URIは変更されてページが保護されないことがあります;権限は常に正確に保存されるべきですデリケートなロジックがある場所）。合意を壊すもの！
- ネイティブ（貧しい）CAPTCHAを含む
- reCAPTCHA関数のインターフェイスが乱雑である
FreakAuth Light
長所
- 非常にフル機能
- ほとんどが十分に文書化されたコード
- ユーザーデータとプロファイルデータを分離するのは便利です
- CIの検証システムにフック
- アクティベーションメール
- 言語ファイルのサポート
- 積極的に開発
短所
- 少し膨らんだ感じ（50以上のファイル）
- それでも、自動Cookieログイン（！）
- ユーザー名とメールアドレスの両方でのログインはサポートしていません
- UTF-8文字に問題があるようです
- 大量のオートローディングが必要（パフォーマンスを妨げる）
- 正しく管理されていない構成ファイル
- ビューとプログラムの出力に多数のプログラムロジックがあり、コントローラーにハードコード化された、ひどいビューコントローラー分離。合意を壊すもの！
- 含まれているビューのHTMLコードが不十分
- 規格外のCAPTCHAが含まれています
- コメント付きデバッグはどこにでもエコーします
- 特定のフォルダ構造を強制します
- 特定のAjaxライブラリーを強制します（切り替え可能ですが、そもそもそこにあるべきではありません）。
- ログイン試行の上限なし-非常に危険です！合意を壊すもの！
- フォーム検証のハイジャック
- 安全でない可能性のあるmd5ハッシュを使用する
pc_user
長所
- 小さな設置面積のための優れた機能セット
- 軽量、膨らみなし（3ファイル）
- エレガントな自動Cookieログイン
- オプションのテスト実装が付属しています（素敵なタッチ）
短所
- 古いCIデータベース構文を使用（安全性が低い）
- CIの検証システムにフックしない
- ちょっと直感的ではないステータス（役割）システム（インデックスの上下が逆-非実用的）
- 安全でない可能性のあるsha1ハッシュを使用
フレッシュパワード
長所
短所
- 重要な機能がたくさんありません。合意を壊すもの！
- すべてがハードコーディングされています。合意を壊すもの！
Redux / Ion Auth
CodeIgniter wikiによると、Reduxは廃止されましたが、Ion Authフォークは強力になっています：https : //github.com/benedmunds/CodeIgniter-Ion-Auth
Ion Authは、過度に重くなったり、高度になったりすることのない、優れた機能を備えたライブラリです。ほとんどの場合、その機能セットはプロジェクトの要件を満たすだけではありません。
長所
- 軽量でCodeIgniterとの統合が簡単
- ライブラリから直接メールを送信することをサポート
- 十分に文書化されたオンラインで優れたアクティブな開発者/ユーザーコミュニティ
- プロジェクトへの実装が簡単
短所
- 他よりも複雑なDBスキーマ
- ドキュメントの一部の領域に詳細がない
SimpleLoginSecure
長所
- 小さなフットプリント（4ファイル）
- ミニマル、膨らみなし
- ハッシュにphpassを使用します（優れています）
短所
- ログイン、ログアウト、作成、削除のみ
- 重要な機能がたくさんありません。合意を壊すもの！
- ライブラリよりも出発点の詳細
誤解しないでください。上記のライブラリを軽視するつもりはありません。私は彼らの開発者が何を達成したか、そしてそれぞれの開発者がどれだけ進んでいるかに非常に感銘を受けており、自分のコードを構築するためにそれらのコードの一部を再利用することはしません。私が言っていることは、これらのプロジェクトでは、重要な「必要なもの」（ハードセキュリティの実践など）から、やわらかな「必要なもの」に焦点が移り、それを改善したいと考えていることです。 。
したがって、基本に戻ります。
正しく行われたCodeIgniterの認証
これは、認証ライブラリからの機能の最低限必要なリストです。それはたまたま私のライブラリの機能リストのサブセットです;）
- オプションのテスト実装による小さな設置面積
- 完全なドキュメント
- 自動読み込みは必要ありません。パフォーマンスのためのライブラリのジャストインタイムのロード
- 言語ファイルのサポート。ハードコードされた文字列はありません
- reCAPTCHAはサポートされていますがオプションです
- 推奨されるTRUEランダムソルト生成（例：random.orgまたはrandom.irb.hrを使用）
- サードパーティのログインをサポートするオプションのアドオン（OpenID、Facebook Connect、Googleアカウントなど）
- ユーザー名またはメールを使用してログイン
- ユーザーデータとプロファイルデータの分離
- アクティベーションおよび紛失したパスワードのメール
- 自動Cookieログイン機能
- ハッシュ用の構成可能なphpass（もちろん正しくソルトされています！）
- パスワードのハッシュ
- 自動ログインコードのハッシュ
- 失われたパスワードコードのハッシュ
- CIの検証システムにフック
- セキュリティの質問はありません！
- オプションのクライアント側（Javascript）バリデーターを使用した、強力なパスワードポリシーのサーバー側の適用
- ログイン試行失敗の最大数を強制し、辞書攻撃とDoS攻撃の両方に対するベストプラクティスの対策を講じました。
- すべてのデータベースアクセスは準備された（バインドされた）ステートメントを介して行われます！
注：これらの最後の数点は、Webアプリケーションに必要のない超高セキュリティの過剰ではありません。認証ライブラリがこれらのセキュリティ基準を100％満たしていない場合は、使用しないでください。
彼らをソフトウェアから除外した無責任なコーダーの最近の注目度の高い例：＃17は、大統領キャンペーン中にサラペイリンのAOLメールがハッキングされた方法です。最近、18番と19番の厄介な組み合わせが犯人であり、ブリトニースピアーズ、バラックオバマ、フォックスニュースなどのTwitterアカウントがハッキングされました。そして、＃20だけでも、中国のハッカーが2008年に1回の自動ハッキングで70.000以上の韓国のWebサイトから900万個の個人情報を盗むことができました。
これらの攻撃は脳の手術ではありません。バックドアを大きく開いたままにしておく場合は、フロントをボルトで固定することによって、誤った安心感に騙されないようにしてください。さらに、CodeIgniterのようなベストプラクティスフレームワークを選択するコーディングに真剣に取り組んでいる場合は、少なくとも最も基本的なセキュリティ対策を正しく実行する必要があります。
<暴言>
基本的には、次のとおりです。認証ライブラリが一連の機能、高度なロール管理、PHP4互換性、かなりのCAPTCHAフォント、国テーブル、完全な管理パネル、ベルとホイッスルを提供するかどうかは気にしません -ライブラリが実際に作成するかどうかベストプラクティスに従わないため、サイトの安全性が低下します。これは認証パッケージです。認証という1つのことを正しく行う必要があります。それができない場合は、実際には良いことよりも多くの害を及ぼしています。
</ rant>
/イェンス・ローランド