There is a maxim that, if you need to ask about hand-rolling your owns security, you shouldn't be writing your own security. It is much more complicated than it first appears, and it is very easy (even for an experienced hand) to introduce security holes.
I strongly suggest you take a look at
http://www.asp.net/web-forms/tutorials/security[
^] and
videos here[
^]. These tutorials give an overview, and uses security providers (pluggable components set up mostly by configuaration). They focus on the Sql providers which provides a double benefit: the
pre-defined schema tables can be generated using a bundled tool[
^] so you don't need to define the tables yourself, and the providers are well documented & relatively simple to use. I've found them good enough for most basic needs. This includes a time-out which can be configured to be absolute (e.g. every 30 mins) or rolling (after 30 mins of inactivity)
If you don't have an SQL Server DB, don't want one or already have a different role/auth information store you can use one of the other built in providers, or subclass them to take complete control over how the information is accessed. For example I had a scenario where we needed to have both SQL-based accounts for "web users" and internal people needing to log in with their domain credentials. I sub-classed the SQL providers and, for people using domain I checked their creds in code via Active Directory, for the Web users I just returned the results of the base class.
Submit an article or tip