You're welcome. I had a look at your comment history and I sincerely apologize for calling you confused, I'm probably more confused than you in a lot of things. Also I appreciate your "long form" style of commenting :)
As for using either in process or SQL Server way of storing the session tokens - there is also a third way and that is writing your own session storage provider, it should be relatively easy and have all the advantages of rolling your own solution and ASP.NET session ID strength
http://msdn.microsoft.com/en-us/library/ms178587(v=vs.100).a...
I don't believe you need to do anything special for the password storing (in browser) to work - just keep the same name or id on the HTML elements which accept the username and password and the URL of the login page.
An attacker can just fire as many requests as your simplest page can handle with incrementing GUIDs (not necessarily incrementing by one, GUIDs are made of some machine identification and current time so there is probably even smarter way). If any of the requests doesn't result in "Session expired" page, the attacker has just defeat your session ID because of using GUID. If you go with the custom session storage you can avoid this problem.
When you store stuff in the HttpSessionState, it gets stored (by default) in the memory of the process, it will use the custom session storage provider, if you write one.
I believe that 100% of users accept cookies. But it's true that for storing session id you don't really need it. Also in the EU we now have this stupid law requiring websites to inform users that they use cookies...
http://econsultancy.com/nl/blog/9202-eu-cookie-law-three-app...
Good luck with the website - you sound like you're just the right amount of crazy for changing the world :)
"Confused" is not the worst I've been called, and at
times it's, i.e., "confused", been correct!
Thanks for the feedback.
For the link to MSDN, checking my collection of such
Web pages, I downloaded that page on 3/15/2012 as
file number 739 from MSDN in my collection of
documentation for ASP.NET, TCP/IP, etc. of the 4000+
Web pages of documentation I have so far!
Reading some of that Web page again, it looks
complicated, more work to make use of their
provider framework than just write my own code.
For using my code for session state store, in a Web
page just write early in the execution of the Web
page code
result_code = SSS_retrieve( )
make whatever use want of
Public users_session_state As New SPP_session
for an instance of my class
SPP_session
and near the end of the execution of the Web page
write
result_code = SSS_store( )
Simple.
My code for making session state persistent enough,
still available anywhere in my server farm with no
issues about concurrency or locking, and nicely fast
is really simple: So, the session state store is
just a little program in Visual Basic .NET
(apparently as good as anything else at making use
of the common language runtime, CLR, and .NET
Framework).
The program runs as just a console application
started just from a command line, actually from a
short scripting program (in ObjectRexx, my favorite
scripting language until I convert over to Power
Shell).
The program implements just a key-value store. To
this program, each key is just an array of type
byte; similarly for each value. The implementation
is just via an instance of a .NET collection class,
hopefully AVL trees or red-black trees. There is a
second instance of that collection class used for
handling session time outs, as I recall, hard coded
at 40 minutes. We're taking simple, dirt simple,
here!
The program just listens on a dedicated (hard
coded!) IP port number for a connection request.
Since the program is single threaded, there are no
problems with concurrency or locking. That is, the
program serves just one customer at a time!
From timings, on a single core, 3.0 GHz processor,
the program should be able to do the work needed for
a site to send 1000+ Web pages a second. If my Web
site needs more capacity, then just do sharding,
that is, in the code for a Web page, given a session
ID, do a look up and find the IP address and port
number of the executing instance of the session
state store program that handles that session ID.
Keep 512 such instances busy, and could have a
really busy Web site! With 16 threads and instances
per processor, that would be 32 processors which
would fit easily in just two standard racks. A big
Web site and session state handled with just two
racks! Nice!
Microsoft has a collection class in storage with
scope the 'application', i.e., all Web pages in one
instance of IIS, and I tried to use that storage for
my session state store. The first bad news was that
during development something got confused raising an
exception "invalid cast". So each time I changed the
code for a Web page I had to issue Microsoft command
iisreset /restart
to get everything working again.
It is true that my way of handling session state
makes my Web page code look different.
So far I'm happy with how I'm handling session
state.
Thanks for the detail on how the next GUID is
generated -- just add 1, which is less obscure than
I had hoped.
So, maybe for a GUID start with the MAC address of a
network adapter, use some time and/or date, and then
increment or some such.
If a malicious user wants to break into my site,
then they will have to guess both the GUID of the
session ID of a current user and also that user's IP
address. If that is not secure enough, then I can
just ask ASP.NET to encrypt the data in the hidden
field. Then a malicious user would have to decrypt
to find a legal GUID, generate some trial GUIDs,
encrypt, guess an IP address, and post the data back
to my server. And at that point, all they have
managed to do is to have my server send some
confused response to the IP address of the real user
with that session ID. No biggie. Besides, my Web
site is not for a bank or trading Bitcoins, etc.!
For "crazy", it can look that way to others. To me
I just saw an unsolved problem, turned it into a
math problem, got a math solution, and wrote some
code. I believe that the problem is important and
my solution good. We will see, at least see if
users like my solution.
As for using either in process or SQL Server way of storing the session tokens - there is also a third way and that is writing your own session storage provider, it should be relatively easy and have all the advantages of rolling your own solution and ASP.NET session ID strength http://msdn.microsoft.com/en-us/library/ms178587(v=vs.100).a...
I don't believe you need to do anything special for the password storing (in browser) to work - just keep the same name or id on the HTML elements which accept the username and password and the URL of the login page.
An attacker can just fire as many requests as your simplest page can handle with incrementing GUIDs (not necessarily incrementing by one, GUIDs are made of some machine identification and current time so there is probably even smarter way). If any of the requests doesn't result in "Session expired" page, the attacker has just defeat your session ID because of using GUID. If you go with the custom session storage you can avoid this problem.
When you store stuff in the HttpSessionState, it gets stored (by default) in the memory of the process, it will use the custom session storage provider, if you write one.
I believe that 100% of users accept cookies. But it's true that for storing session id you don't really need it. Also in the EU we now have this stupid law requiring websites to inform users that they use cookies... http://econsultancy.com/nl/blog/9202-eu-cookie-law-three-app...
Good luck with the website - you sound like you're just the right amount of crazy for changing the world :)