Camping and Website Authentication

Just got back from vacation and had a great time. We traveled up to Traverse City to see my Grandma and cousin; then stopped by Mackinac Island with our bikes to stay the night; then finally arrived at our destination in Tahquamenon Falls to spend the rest of the week camping with my dad, sisters, and brother-in-law.

After getting back home, I finally got around to adding authentication to my website (salgat.net/Manager). While ASP.NET comes with several forms of authentication support built in, I decided to do it the old fashioned way as a quick learning experience. 

Implementing authentication was done using both the Session state and a User SQL table. The table has a UserName, Salt, Hashed (Password+Salt), and Authentication Level stored. When the user goes to the Manager webpage, if they are not authenticated, they are sent to the Login page. In the login page, they submit a username and password, where the username is found in the table, its corresponding salt is found and appended to the provided password, and that value is hashed and compared against the stored hash value. If they both match, the Session collection is updated with the UserName and Authentication level. When the user tries to access any protected pages, the Authentication level stored in Session is checked, and if it fails, the user is redirected to the login page.

Login page located at www.salgat.net/Manager/Login.aspx

The purpose of not storing the raw password in the database is to prevent a database breach from resulting in user's passwords being visible to the hackers, which, while not very helpful for security of your own website, prevents a user's username/password from being used on other websites. The salt is used as a way to prevent rainbow tables from allowing for easy password lookups on the database, since the hacker would have to create unique rainbow tables for each user.

As a final note, it should go without saying that doing any of this is a really bad idea unless you know exactly what you are doing. Security is an extremely serious topic and, unless you are an expert, should not be done in any serious setting. Additionally, any security related programming should be regularly audited by a third party security company/consultant.