In this article, I will talk a little bit about some of the specifics of logging in and authentication, including what the FreeToastHost system does when you log in.

First of all, lets distinguish the difference between "logging in" and "authentication".  In the context of FreeToastHost, "logging in" means that you enter some sort of identification and password in a log in form.  In contrast, "authentication" refers to how the system identifies/verifies who you are, usually after you have already logged in.

There are several approaches to logging in and authentication in use. 

For logging in, some systems require that you enter your email address as your identification along with a password.  This has risks associated with it since email addresses could be captured by a hacker using key logger software or other means.  Therefore, while FreeToastHost will accept entry of an email address for member logins as a *secondary* login approach, it is not the preferred approach.  Another login approach is to allow users to select a made up username--this is good from the standpoint of not exposing their name or email address to potential hackers.  However, frequently users will use the same username over and over for different websites, which makes this approach not much more beneficial than if they had just typed in their name as an identification.  Currently, FreeToastHost just allows you to start typing your name for a member login and then select it from a list, which is convenient and is the preferred approach.  In the future, we may allow you to type in a username as an alternative identification (if enough users request that), but at this time we are trying to strike a good balance between security and convenience.

So... what actually happens when you log in and how does that relate to "authentication"?

When you log in, the server code looks you up in our database.  If it finds you and the password matches, then it presumes you are OK to be logged in.   By the way, all passwords are stored encrypted in the database, and cannot be decrypted, so checking for a password match involves encrypting the password you entered and checking it against the encrypted password in the database.

If the system finds you and decides you can be logged in, then it creates a string of random characters called the "session id" or "session key".  The reason for this is that it is more secure to use this random piece of text as your "key" than to be constantly sending your name and password back and forth between your computer and the server. 

The session id text is the really the key to how authentication works.  The use of session ids is generally considered a best practice for authentication (based on my research).  Every time you do a refresh of your browser screen or come to your website "newly", a request for information is sent to the server.  However, the internet is designed to be "stateless".  This means that, by default, the server does not remember anything about you or what you are doing from one refresh to the next.  It is like the server has amnesia.

So, how does the server know who you are or that you are logged in?  The answer is that the session id that the server created for you as your "key" when you logged in uniquely identifies you to the system.  The catch is that when you come to your website newly or refresh your screen, the session id has to be retransmitted to the server to identify you to the server, and the server then looks you up in the database using your session id to find you.  Unless the session id is retransmitted to the server on every refresh, the server "forgets" you and thinks that you are not logged in.

If you think about it, this means that somehow your browser has to remember your session id for you on your computer so that it can send to the server on every refresh.  This is where cookies come in.  During the early days of the internet, Netscape invented cookies as a sort of "memory aide" to get around the stateless design of the internet.  Specifically, they were designed to help people visiting shopping websites save their purchase selections as they browsed around the shopping website.  "Cookies" are really just very small files stored on your computer that store information intended to be sent to a website server.  The cookie files are named such that they are associated with a particular website.

Thus, FreeToastHost uses cookies to store your session id on your computer.  When you log in, the server instructs your browser to create a cookie file containing your session id.  Later, the browser sends this information to the FreeToastHost server on every refresh.  The server receives the session id, looks you up in its database to determine who you are and whether you are logged in or not.  If it finds the same piece of random text stored in the database as your computer sent to it, it presumes that you are logged in.   If not, then you are logged out.  It is this process of looking up your session id to verify your identity and login status on every refresh that I typically refer to as authentication. 

In the FreeToastHost implementation, we put an expiration date on session id cookies that forces them to expire within 24 hours if you do not use the system again during that time period.  Because of that, the system will remember your login status for up to 24 hours if you do not come back to the website, but after that it "forgets" you, and you have to log in again.  This is set up this way because less information is sent from the server to user's computers when they are not logged in, so it helps system performance to not keep users logged in any longer than they need to be.

It has been quite a bit of time since cookies were first invented as a "memory aide" by Netscape.  These days, there have been concerns expressed about storing information in cookies on computers that could be intercepted by spyware.  We understand this, and we have been investigating ways of accomplishing the same login and authentication process without the use of cookies (by using newer ways of storing information on your computer).  However, even in this day, cookies are still the only fast mechanism by which your browser will send your session id information to the server on your initial visit to your website.  This means that if you were logged in to your website, closed your website, then revisited it again, your login status would be sent (via the cookies) to the server, and the server would send a "logged in version" of your website to your browser.  Other mechanisms involve saving a special url somewhere or forcing your browser to do an extra refresh after it fetches the session id information (from "local storage").  While these alternatives to cookies can work, I do not believe most FreeToastHost users will want to fiddle with the extra technical considerations or wait time to see their web page, so we are still using cookies for the time being.

So, for FreeToastHost, cookies are the "memory aide" that prevents server amnesia, and it is what enables you to stay logged in.  So, please enable your cookies, and don't forget the milk.  (kidding)

Steve James, ACB, ALB
FreeToastHost Ambassador
FreeToastHost System Developer