How to build (and how not to build) a secure “remember me” feature

> Because HMAC collisions are easy now?

When you get the details wrong? Relatively so. And even experienced people get this shit wrong more often than they get it right. Rails had this vulnerability. Google's KeyCzar had this vulnerability. The average, non-crypto-enthusiast has effectively zero chance of getting this right out of the box.

Comparing server-computed hashes is inherently safer and less error-prone than comparing client-controlled HMACs.

  * https://github.com/rails/rails/commit/5e6dab8b34152bc48c89032d20e5bda1511e28fb
  * http://rdist.root.org/2009/05/28/timing-attack-in-google-keyczar-library/

> but can't we admit that "I'm going to describe best practice" was a bit overstated?

Not when it is accepted as best practice.

  * http://fishbowl.pastiche.org/2004/01/19/persistent_login_cookie_best_practice/
  * http://stackoverflow.com/questions/549/the-definitive-guide-to-forms-based-website-authentication

The only difference between my description is I do not store the username with the cookie; it is unnecessary and confers no discernable security benefit. I also avoid associating multiple remember-me tokens with a user, so an attacker who intercepts one must use it before the user next logs in.

Is your approach wrong? No. But it is more difficult for the average programmer to do securely and correctly, and confers few (if any) real benefits.

Email me (in profile).

"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.