I'm using the standard out-of-the-box aspnet membership provider, and I have the following settings in the web.config:

<anonymousIdentification enabled="false"/>
<authentication mode="Forms">
    <forms cookieless="AutoDetect" loginUrl="~/XXXX.aspx" name="XXXXAuth" slidingExpiration="true" timeout="432000"/>
<membership defaultProvider="XXXMembershipProvider">
     <add name="XXXMembershipProvider" type="System.Web.Security.SqlMembershipProvider" applicationName="XXX" connectionStringName="XXX" enablePasswordRetrieval="false" enablePasswordReset="true" requiresQuestionAndAnswer="false" requiresUniqueEmail="true" minRequiredPasswordLength="5" minRequiredNonalphanumericCharacters="0" passwordFormat="Hashed" maxInvalidPasswordAttempts="5" passwordAttemptWindow="10" passwordStrengthRegularExpression=""/>

Today I have had an issue where a user has reported that they went to log-in and noticed that the site was saying they were already logged-in.... as a completely different user. After contacting both users, it turns out neither accesses the site from a shared computer. Neither account's data shows any sign of being "hacked" in the database.

The is hosted on two web servers behind a load balancer. The database architecture is one server for reads, one for writes with replication keeping them in sync.

Does anyone know what might have occured to cause this?

+1  A: 

An option that can make this happen is the cookieless=AutoDetect. If one user's browser doesn't support cookies, will embed the encrypted authentication ticket in the url. If the user happened to either share a link with the other, or less directly posted it on a forum, (s)he is giving unintended access to his(her) account.

Paul Suart

I'm wondering how smart the load balancer is, and if it's caching pages as well.

The membership cookie is pretty damned locked down, so it's very very doubtful it's been compromised. If the load balancer is also caching it may well not be passing the request on.