I see there are a few. Which ones are best maintained and easy to use? Or should I just write my own?
I've tried both FreakAuth and Erkana. I found FreakAuth was overkill for my needs (a simple login form + user add/edit/delete). I evaluated Erkana, but decided not to use, although I no longer remember exactly why. I may also have tried Sentry.
In the end I wrote my own, based on the CodeIgniter Filters System.
Jim.
Maybe you'd find Redux suiting your needs. It's no overkill and comes packed solely with bare features most of us would require. The dev and contributors were very strict on what code was contributed.
This is the official page
I use a customized version of DX Auth. I found it simple to use, extremely easy to modify and it has a user guide (with great examples) that is very similar to Code Igniter's.
Also take a look at BackendPro
Ultimately you will probably end up writing something custom, but there's nothing wrong with borrowing concepts from DX Auth, Freak Auth, BackendPro, etc.
My experiences with the packaged apps is they are specific to certain structures and I have had problems integrating them into my own applications without requiring hacks, then if the pre-package has an update, I have to migrate them in.
I also use Smarty and ADOdb in my CI code, so no matter what I would always end up making major code changes.
I tried Redux. Wasn't a fan. In the end, I ended up making a CI wrapper for Zend_Auth, which works like a charm.
Update (May 14, 2010):
It turns out, the russian developer Ilya Konyukhov picked up the gauntlet after reading this and created a new auth library for CI based on DX Auth, following the recommendations and requirements below.
And the resulting Tank Auth is looking like the answer to the OP's question. I'm going to go out on a limb here and call Tank Auth the best authentication library for CodeIgniter available today. It's a rock-solid library that has all the features you need and none of the bloat you don't:
Tank Auth
Pros
- Full featured
- Lean footprint (20 files) considering the feature set
- Very good documentation
- Simple and elegant database design (just 4 DB tables)
- Most features are optional and easily configured
- Language file support
- reCAPTCHA supported
- Hooks into CI's validation system
- Activation emails
- Login with email, username or both (configurable)
- Unactivated accounts auto-expire
- Simple yet effective error handling
- Uses phpass for hashing (and also hashes autologin codes in the DB)
- Does not use security questions
- Separation of user and profile data is very nice
- Very reasonable security model around failed login attempts (good protection against bots and DoS attacks)
(Minor) Cons
- Lost password codes are not hashed in DB
- Includes a native (poor) CAPTCHA, which is nice for those who don't want to depend on the (Google-owned) reCAPTCHA service, but it really isn't secure enough
- Very sparse online documentation (minor issue here, since the code is nicely documented and intuitive)
Original answer:
I've implemented my own as well (currently about 80% done after a few weeks of work). I tried all of the others first; FreakAuth Light, DX Auth, Redux, SimpleLogin, SimpleLoginSecure, pc_user, Fresh Powered, and a few more. None of them were up to par, IMO, either they were lacking basic features, inherently INsecure, or too bloated for my taste.
Actually, I did a detailed roundup of all the authentication libraries for CodeIgniter when I was testing them out (just after New Year's). FWIW, I'll share it with you:
DX Auth
Pros
- Very full featured
- Medium footprint (25+ files), but manages to feel quite slim
- Excellent documentation, although some is in slightly broken English
- Language file support
- reCAPTCHA supported
- Hooks into CI's validation system
- Activation emails
- Unactivated accounts auto-expire
- Suggests grc.com for salts (not bad for a PRNG)
- Banning with stored 'reason' strings
- Simple yet effective error handling
Cons
- Only lets users 'reset' a lost password (rather than letting them pick a new one upon reactivation)
- Homebrew pseudo-event model - good intention, but misses the mark
- Two password fields in the user table, bad style
- Uses two separate user tables (one for 'temp' users - ambiguous and redundant)
- Uses potentially unsafe md5 hashing
- Failed login attempts only stored by IP, not by username - unsafe!
- Autologin key not hashed in the database - practically as unsafe as storing passwords in cleartext!
- Role system is a complete mess: is_admin function with hard-coded role names, is_role a complete mess, check_uri_permissions is a mess, the whole permissions table is a bad idea (a URI can change and render pages unprotected; permissions should always be stored exactly where the sensitive logic is). Dealbreaker!
- Includes a native (poor) CAPTCHA
- reCAPTCHA function interface is messy
FreakAuth Light
Pros
- Very full featured
- Mostly quite well documented code
- Separation of user and profile data is a nice touch
- Hooks into CI's validation system
- Activation emails
- Language file support
- Actively developed
Cons
- Feels a bit bloated (50+ files)
- And yet it lacks automatic cookie login (!)
- Doesn't support logins with both username and email
- Seems to have issues with UTF-8 characters
- Requires a lot of autoloading (impeding performance)
- Badly micromanaged config file
- Terrible View-Controller separation, with lots of program logic in views and output hard-coded into controllers. Dealbreaker!
- Poor HTML code in the included views
- Includes substandard CAPTCHA
- Commented debug echoes everywhere
- Forces a specific folder structure
- Forces a specific Ajax library (can be switched, but shouldn't be there in the first place)
- No max limit on login attempts - VERY unsafe! Dealbreaker!
- Hijacks form validation
- Uses potentially unsafe md5 hashing
pc_user
Pros
- Good feature set for its tiny footprint
- Lightweight, no bloat (3 files)
- Elegant automatic cookie login
- Comes with optional test implementation (nice touch)
Cons
- Uses the old CI database syntax (less safe)
- Doesn't hook into CI's validation system
- Kinda unintuitive status (role) system (indexes upside down - impractical)
- Uses potentially unsafe sha1 hashing
Fresh Powered
Pros
- Small footprint (6 files)
Cons
- Lacks a lot of essential features. Dealbreaker!
- Everything is hard-coded. Dealbreaker!
Redux
Pros
- Tiny footprint, no bloat (3 files)
- Excellent documentation
- Database normalized to 3rd normal form (nice touch)
- Activation emails
- Sleek coding style
- Suggests grc.com for salts (not bad for a PRNG)
Cons
- Requires autoloading (impeding performance)
- Uses the inherently unsafe concept of 'security questions'. Dealbreaker!
- Return types are a bit of a hodgepodge of true, false, error and success codes
- Doesn't hook into CI's validation system
- Doesn't allow a user to resend a 'lost password' code
EDIT: Mathew Davies, who develops Redux Auth, says a bunch of the cons in my list (including the security questions dealbreaker) have been fixed in the latest beta, so that should definitely be worth checking out
SimpleLoginSecure
Pros
- Tiny footprint (4 files)
- Minimalistic, absolutely no bloat
- Uses phpass for hashing (excellent)
Cons
- Only login, logout, create and delete
- Lacks a lot of essential features. Dealbreaker!
- More of a starting point than a library
Don't get me wrong: I don't mean to disrespect any of the above libraries; I am very impressed with what their developers have accomplished and how far each of them have come, and I'm not above reusing some of their code to build my own. What I'm saying is, sometimes in these projects, the focus shifts from the essential 'need-to-haves' (such as hard security practices) over to softer 'nice-to-haves', and that's what I hope to remedy.
Therefore: back to basics.
Authentication for CodeIgniter done right
Here's my MINIMAL required list of features from an authentication library. It also happens to be a subset of my own library's feature list ;)
- Tiny footprint with optional test implementation
- Full documentation
- No autoloading required. Just-in-time loading of libraries for performance
- Language file support; no hard-coded strings
- reCAPTCHA supported but optional
- Recommended TRUE random salt generation (e.g. using random.org or random.irb.hr)
- Optional add-ons to support 3rd party login (OpenID, Facebook Connect, Google Account, etc.)
- Login using either username or email
- Separation of user and profile data
- Emails for activation and lost passwords
- Automatic cookie login feature
- Configurable phpass for hashing (properly salted of course!)
- Hashing of passwords
- Hashing of autologin codes
- Hashing of lost password codes
- Hooks into CI's validation system
- NO security questions!
- Enforced strong password policy server-side, with optional client-side (Javascript) validator
- Enforced maximum number of failed login attempts with BEST PRACTICES countermeasures against both dictionary and DoS attacks!
- All database access done through prepared (bound) statements!
Note: those last few points are not super-high-security overkill that you don't need for your web application. If an authentication library doesn't meet these security standards 100%, DO NOT USE IT!
Recent high-profile examples of irresponsible coders who left them out of their software: #17 is how Sarah Palin's AOL email was hacked during the Presidential campaign; a nasty combination of #18 and #19 were the culprit recently when the Twitter accounts of Britney Spears, Barack Obama, Fox News and others were hacked; and #20 alone is how Chinese hackers managed to steal 9 million items of personal information from more than 70.000 Korean web sites in one automated hack in 2008.
These attacks are not brain surgery. If you leave your back doors wide open, you shouldn't delude yourself into a false sense of security by bolting the front. Moreover, if you're serious enough about coding to choose a best-practices framework like CodeIgniter, you owe it to yourself to at least get the most basic security measures done right.
<rant>
Basically, here's how it is: I don't care if an auth library offers a bunch of features, advanced role management, PHP4 compatibility, pretty CAPTCHA fonts, country tables, complete admin panels, bells and whistles -- if the library actually makes my site less secure by not following best practices. It's an authentication package; it needs to do ONE thing right: Authentication. If it fails to do that, it's actually doing more harm than good.
</rant>
/Jens Roland
Hi Jens Roland.
I'm the developer of Redux Auth and some of the issues you mentioned have been fixed in the version 2 beta. You can download this off the offcial website with a sample application too.
- Requires autoloading (impeding performance)
- Uses the inherently unsafe concept of 'security questions'. Dealbreaker!
Security questions are now not used and a simpler forgotten password system has been put in place.
- Return types are a bit of a hodgepodge of true, false, error and success codes
This was fixed in version 2 and returns boolean values. I hated the hodgepodge as much as you.
- Doesn't hook into CI's validation system
The sample application uses the CI's validation system.
- Doesn't allow a user to resend a 'lost password' code
Work in progress
I also implemented some other features such as email views, this gives you the choice of being able to use the CodeIgniter helpers in your emails.
It's still a work in progress so if have any more suggestions please keep them coming.
-Popcorn
Ps : Thanks for recommending Redux.
I like your 20-step program. I've been frustrated with Redux, but it seems like the best-featured, best-documented solution out there. Don't understand why the skeleton of some standard auth wasn't build into CI. Their explanation that it "would look different for every app" seems like a copout.
Uses potentially unsafe sha1 hashing
actually sha1 is more secure than md5....and newest recomendation is to use SHA2(SHA-224, SHA-256, SHA-384, and SHA-512) hashing....
I used redux 2 as a start and then made it fit my needs. I doubt you'll find an "off-the-shelf" solution that you're 100% happy with.
Redux Auth seems to have some great potential, the structure seems well through out
Though the version 2 beta seems to have come to a stand still w/ some buggy code (example app does not work - I spent over an hour trying to get through it)
Crossing my fingers for tank auth
This is a follow-up to Jens Roland's great post... I think he has made the most complete list of good practices talking about authentication, which for me is the most important brick of an application.
I have a question though: don't you think that using random.org (or another "true" random generator) could slow down your application? Plus you never know if their server is down, in that case your application would be unusable.
I completely understand Jens' point, as a random string is not random if it follows a pattern, and it could be recreated.
What could be the best way to generate a random salt for every registered user? Also, is PHPass better than sha256/512?
Thanks in advance, gyo
Isn't a mistake to send the login and password with no secure encryption of the paswword, in a signup form? It's the same in the login form.
I used an ajax call for the salt in the database corresponding to the login and use it to md5 the given password by javascript before posting the login and crypted password.
Here is some exemple and explainantion of the javascript used :
http: actuel.fr.selfhtml.org/articles/javascript/md5/index.htm (fr)
http: www.webtoolkit.info/javascript-md5.html (eng)
Here is my example of implementation of this method in CI :
http: code.google.com/p/planification/source/browse/
I think my authentification is not well documented and nice but just an exemple for current others library.
Is it a real problem to send login and paswword by Post method?
Note that the "comprehensive listing" by Jens Roland doesn't include user roles. If you're interested in assigning different user roles (like admin/user or admin/editor/user), these libraries allow it:
- Ion_Auth (rewrite of Redux)
- Redux
- Backend Pro
Tank_Auth (#1 above in Jens's list) doesn't have user roles. I realize it's not exactly part of authentication, but since - authentication and role management are both handled upon page load - Both involve security - The same table/model can be used for both. - Both can be set up to load in the controller constructor (or even autoload)
It makes a LOT of sense to have one library to handle both, if you need it. I'm switching to Ion_Auth from Tank_Auth because of this.
A3M looks a good one, anyone tried this??
Ion_Auth beats tank_auth mainly for two reasons, user roles and documentation, these two are missing from tank_auth.