Bill Bosacker

This is just my normal user blog for things that don't fit in the other blogs, but are tailored for the open source C/C++/C# and .NET communities.

May 2007 - Posts

Holie CardSpace Batman!

WARNING: THE FINAL SENTENCE OF THIS POST MAY GROSS YOU OUT! 

Hey All,

I went to another MSDN event yesterday, mostly for the AJAX.NET stuff, but the first presentation was for CardSpace.  The only thing that I knew about CardSpace before the presentation was that it is another personal authentication management system.  After the presentation I was thinking that identity thieves must be rejoicing.  This system seems to ignore every single studie that I have read on the matter, and bypasses all of the safeguards that have been put into place over the past few years as well.  Its basis is a local store for single click proxy authentication by identity stores.

I'm not going to get into any of the details, but the entire system relies on the fact that only the true owner will have access to the cards.  If someone were to steal your HD, copy your HD, or export your CardSpace information to another computer, you are screwed.  CardSpace does not only contain references to your personal information, it also contains a history of every site that has requested information from your CardSpace store.  No longer will identity thieves need to work very hard at getting your personal information, they can just take it from your computer.

The presenter did say in a lowered voice that CardSpace is currently not being used (nor is it ready) for secure sites and that there hasn't been any studies for its use in these areas, but she did say that it is ready for all other types of use.  All I can say is that CardSpace in its current form would be a total waste of time to implement on any system.  Until there is a complete safe and secure way to bypass Login/Password requests, logins and passwords will be required for all types of secure authentication.  To ensure the safety of the user, biometrics and other forms of authentication can only be used as secondary forms of authentication as this other information can be forcefully removed from its owner.

Take it easy,
Bill

Posted Wednesday, May 16, 2007 9:17 AM by Bill Bosacker | with no comments

Behinds the scenes look at Telligent in action!

During a closed interview, a camera crew was able to take some sneak footage of Telligent in action when a customer called in with cursor issues.  Click here to take a look at this never before seen footage.

Posted Wednesday, May 02, 2007 2:07 AM by Bill Bosacker | with no comments

Cookies 101

I was going to title this Cookies for Dummies, but there are lot of knowledgable people out there that really don't know all that they need to about cookies.  In fact, they only know a couple of the basics.  In this post I will give an overall view of cookies without really getting into any specifics.

Cookies were added to the HTML specification for the sole purpose of keeping state in what is a stateless medium.  Prior to cookies, the only way to keep state was through the query string which is an extremely daunting task as every page request needed to contain this information.  Some very old sites did this, but they were extremely difficult to code and maintain.  This has changed somewhat recently as there are now tools available to make this easier, especially in the newer languages.

Cookies are nothing more that a string of characters, but they can contain any type of data that your platform can encode into the cookie store.  The most common misunderstanding about cookies is that there is only 1 type of cookie, when in fact there are 2:

  1. Session Cookies.
  2. Persisted Cookies.

Session cookies exist only for the current browser session.  Once the browser is closed (this includes all parent and child windows), the session cookie expires and no longer exists.  These cookies should only be persisted in memory due to security concerns and should not be stored on the file system.  Early versions of Netscape Navigator used to save these cookies on the file sytem, but this is a very severe security risk as these cookies are used for secure transactions.

Persisted cookies are stored in some fashion on your file system and have a set expiration date.  Session cookies do not have expiration dates, in fact it is this setting that differentiates the 2 types of cookies.  If you give a session cookie an expiration date, it becomes a persisted cookie.  You cannot change a persisted cookie into a session cookie.  You must first expire the persisted cookie and then create a new cookie without and expiration date.

The most common question about cookies is, "Are they safe and secure (i.e. SSL/HTTPS)?"  This requires a simple explaination of how SSL requests are processed.  When an SSL package is sent over HTTP, the entire package is encrypted and sent to an IP address and port.  Absolutely nothing in the request is left unencrypted (i.e. the URL, cookies, referrer, etc.).

This means that session cookies are as secure as SSL and the security of the memory space that your browser is running in.  Persisted cookies are as safe as session cookies with the additional security hole being that of the file system where it is stored.  Some browsers have settings to prevent persisted cookies on SSL sites from being saved to the file system, in which case the cookie is handled like a session cookie.

Besides the date, there are 2 other properties of cookies, domain and path.  The domain relates to a FQDN that would be used in a URL.  The FQDNs www.domain.com and domain.com are 2 completely different domains even though they may point to the same IP address, and thus they also treated as being differnent as far as cookies go.  Cookies are only passed in requests to the domain for which it was created.  You can however create a cookie for domain B while on a page in domain A, go to a page in domain B, and the cookie will be sent in the request for the page on domain B.

The path relates to a folder under the domain and is used as a filter to reduce the number of cookies being sent with each request.  The default is usually the root ("/" or an empty string), which means that the browser will send the cookie with every request for that domain.  If the path were set to "/member/", then that cookie would only be send with page requests to the domain that are under the /member/ folder (i.e. /member/login.aspx).  A page request to /user/profile.aspx would not contain the cookie.

I hope this helps with your understanding of cookies.  If you have any comments or suggestions, please post them here.

Posted Tuesday, May 01, 2007 9:45 PM by Bill Bosacker | with no comments