Understanding Authentication

Because security is such a crucial concern with any web application, this document will step you through how authentication works in Bonfire, to make it easy for to determine if it meets the security needs of your application.  While the security provided should be adequate for most applications, some may require additional security to meet their unique requirements.  If you find a need for additional security (or just find a flaw in the current authentication) please let us know.  If you improve the security of the code, please send us a pull request on Github.

Summary
Understanding AuthenticationBecause security is such a crucial concern with any web application, this document will step you through how authentication works in Bonfire, to make it easy for to determine if it meets the security needs of your application.
Password Security
Forgotten PasswordsForgotten passwords are never emailed to the user so they cannot be intercepted.
AutologinWhenever the Auth library is first loaded, it will run the autologin() method to see if the user has been remembered on the site.

Password Security

Passwords are designed to provide the best security possible, while being as unrestrictive as possible.  While nothing can stop a user from making a mistake and choosing an easy to crack password.  To protect passwords, we have put the following practices into place

  • Passwords must be at least 8 characters long.  This is the base number that, if combining numbers and letters, starts to make things difficult based on the time required to crack it.
  • Passwords are never stored in the database.  To protect in case someone gets access to your database, unencrypted passwords are not stored.  Instead, a random salt is created at the user creation, and is used in a SHA1 hash together with the password.

Forgotten Passwords

Forgotten passwords are never emailed to the user so they cannot be intercepted.  Instead, a link to /reset password that contains the user’s email and a 40 character long hash that is used to verify the user’s identity is emailed to the user.  Once on that page, they can choose a new password, assuming that the hash is verified.  The hash is only valid for 24 hours.

Autologin

Whenever the Auth library is first loaded, it will run the autologin() method to see if the user has been remembered on the site.

Autologin uses the best practice as set out in http://fishbowl.pastiche.org/2004/01/19/persistent_login_cookie_best_practice/ and creates a unique token based on a SHA1 hash of the user_id joined with a 128-character random string.  This token is only valid for the current session.

  • If the system is set to NOT allow users to be remembered, the script is exited.
  • The autologin cookie is retrieved, if it exists.  If it doesn’t exist the method is exited.
  • The cookie is split into it’s two parts, the user_id and the token that previously generated.
  • We try to pull a match from the user_cookies table against the user id and token.  If no match is found, the script exits.
  • If a user is found, we check to see if there is a current session for this user.  If there is, then we’re good to go, and the logged_in class variable is set to true.  We’re done here.
  • If no session exists, we create a new one for the user, regenerate our autologin information, setup our new cookie, and go on our way.

This document is still under construction.

Close