Authentication & SQL Injection

User credentials are stored in the database with passwords hashed and salted by usernames, user-specific random strings and site-wide random strings. A random single sign-on token is generated for each successful login and is only valid for a limited window of inactivity before being timed-out. This token allows for user sessions to be handled by any server instance without re-authentication as it utilises my shared-cache data access classes (discussed here).

Upon succesful authentication the page or directory specific authorisation is handled in a least-rights manner designated by user roles.

SQL injection is countered by a 2-tiered approach. Firstly the data access classes check the format of the data to be stored (for INT, ENUM, DATE fields etc., however not possible for VARCHAR, TEXT etc.). Secondly all fields are properly escaped before being saved. As no queries are written by hand I have the ability to upgrade security site-wide should I find a flaw.

Data loading follows the same approach thus mitigating common injection techniques used to bypass authentication.