If your using forms authentication in .net and the application that creates the authentication cookie is different than the one that consumes it (i.e. Web farm scenario), the consuming application may not be able to decrypt the authentication token in the cookie and hence you might see something similar to ‘Forms authentication failed for the request. Reason: The ticket supplied was invalid’ in your event log. I had this recently and two common causes were:
Machine key is different between application creating the authentication cookie and the application(s) using it. Keys must match. You can edit machine keys through IIS (as in below image) or directly through the web.config. Restart IIS/App pool shouldn’t be required.
Application creating the authentication cookie and the application(s) using it use a different cryptography core due to one targeting .net 4.5 and the other targeting 2.0 or 4.0. The method of decrypting tokens has changed since 4.5 and so an authentication token created by an application targeting 2.0/4.0 cannot be validated by an application targeting 4.5. The 4.5 cryptographic core is opt in (so not to break 2.0/4.0 applications running on machines which happen to have 4.5 installed) but the Visual Studio 4.5 project template includes one of the two different tags required to opt-in in the generated web.config. In our case our login app was a 2.0 app, but our new app was targeting 4.5.1 and so the default web.config included the following tag:
<httpRuntime targetFramework=”4.5.1″ />
which meant our new 4.5.1 app couldn’t decrypt the generated auth cookie. We simply changed that to <httpRuntime /> and things worked then. The second way to opt in is via the machinekey tag i.e:
<machineKey compatibilityMode=”Framework45″ />
so if you having problems decrypting make sure your apps have compatible runtimes set.
If you’re in an enterprise environment some form of auditing is likely to be required so you can track who inserted, updated or deleted what in your database. Using triggers to insert into audit tables is usually a good fit for this, particularly if your database can be updated from multiple sources.
Within both insert and update triggers you have access to the original record inserted or updated from your web app so you can access the updated_by column from the original record and pop this into your audit_* tables. In the case of deletes however, there never is any user information passed to the delete statement so delete triggers don’t know who specifically (the DB connection itself is usually shared) issued the delete. Using a session like feature in SQL Server 2000+ called CONTEXT_INFO however we can ‘pass’ the specific id of the user issuing the delete from our web app to the trigger.
Passing user info to delete trigger using CONTEXT_INFO
CONTEXT_INFO allows us to associate a limited (very limited but enough space for user info) amount of information with the current SQL Server connection. This info can then be read back at any stage from within the same connection. Using this to pass user info to a trigger is quite easy then:
Set CONTEXT_INFO to userID logged into your web app
Issue delete statement from your web app
Read CONTEXT_INFO back in the delete trigger
As long as all three above happen in the same connection this should work fine. Setting the context is easy, but is best done from within a store procedure to encapsulate the code to deal with CONTEXT_INFO (cumbersome binary). SetUserContext below takes the user id as a param and stores it into CONTEXT_INFO.
CREATE PROCEDURE [dbo].[SetUserContext]
@userId NVARCHAR (30)
SET NOCOUNT ON;
DECLARE @context VARBINARY(128)
SET @context = CONVERT(VARBINARY(128), @userId)
SET CONTEXT_INFO @context
Reading CONTEXT_INFO is best done through a function so you can just directly call it from your delete trigger statement that inserts into your audit_* tables. The GetUserContext function below returns CONTEXT_INFO if it is set or the standard suser_name() if it is not set.
Checking for null and falling back on the connected DB user is important if a DB can be updated directly by an admin or support person outside the context of an app which would set CONTEXT_INFO.
CREATE FUNCTION [dbo].[GetUserContext] ()
RETURNS NVARCHAR (30)
DECLARE @idToReturn NVARCHAR(30)
IF CONTEXT_INFO() IS NOT NULL
SELECT @IdToReturn = CONVERT(NVARCHAR (30), CONTEXT_INFO())
SELECT @IdToReturn = suser_name()
And finally a sample delete trigger which calls the function is below:
FROM deleted AS d
After you have created the sproc for setting the context, the function for reading the context and have a couple of delete audit triggers created that’s things from the database point of view set up.
Setting CONTEXT_INFO using entity framework
In your web app you only care about setting the context. This can be done by simply calling the procedure. In entity framework this is easy:
public virtual void SetUserContext(string userId)
var idParam = new SqlParameter("@userId", userId);
this.Database.ExecuteSqlCommand("SetUserContext @userId", idParam);
Then in an overload of the SaveChanges method you simple call the SetUserContext sproc before you call the base SaveChanges method:
public void SaveChanges(string userId)
using (var scope = Database.BeginTransaction())
Both the above functions would go in your database context class (the one which derives from DbContext).
Due to the fact that when executing stored procedures entity framework opens a connection, executes the proc and then immediately closes the connection, the context_info will be lost by the time we call SaveChanges which is when the delete trigger will run. To ensure both the setting and the reading of the context takes places in the same connection, we need to wrap them both in the same transaction as can be seen above.
This means if you’re using connection pooling, which you really should be, you will not run into state sharing issues and thus connection pooling does not preclude you from using CONTEXT_INFO as part of your auditing solution. SQL Server 2000 users… get with the times or just reset CONTEXT_INFO after you issue your delete.
I hope you find the above useful. Please let me know your thoughts or questions below.
Account enumeration is a potential security risk whereby a web site gives out information about what accounts are already in the system. This may a) leave them susceptible to a brute force-esque attack and b) may violate their users privacy which may be very important for certain types of sites. There are a couple of prominent Irish websites covered below which I’m familiar with and I just happened to notice they allow account enumeration but it is important to note that the vast majority of ecommerce sites online do this too. Certainly there are greater security risks out there such as SQL Injection, badly stored passwords, not using https when you should etc. but when this exploit is found alongside other exploits… well let’s just say that’s when bad things can happen.
keep login failed messages generic
I think most developers have the possibility of account enumeration in their minds when considering the messages returned from a login page for failed logins. When logging into most websites with a non existing username you will commonly see ‘Invalid username/password combination‘ type messages rather than ‘That username does not exist‘ type messages. An attacker now cannot just keep trying usernames on the login page until they find one that does exist, at which point they may (if possible) launch a dictionary password attack against that specific account. A few examples of Irish sites doing a good job here include easons.com and water.ie:
Another prominent Irish site; ticketmaster.ie does present different messages to the user if the account exists or not on their login page. The following image shows the login for non existing accounts:
It all looks good right? No mention that the specific email address does not exist, just that the address and password as a whole did not match any accounts. If however, you know of one account that does exist (the one the hacker just created for himself) and try to login with that you’ll notice that the message is different:
Ticketmaster do appear however to have an account lock out facility which locks accounts after 5 failed accounts. What this means is that although an attacker can find out if an account exists due to the slightly different error messages returned (which would be really bad for a very private site.. think ashleymadison.com) they will only get five password tries thus a full on brute force attack against a specific account with a password dictionary is not feasible.
Although locking accounts help mitigate against brute force attacks there are a number of potential problems with this approach. It can for example leave ticketmaster.ie open to an account lockout attack, whereby the attacker can deliberately lock out a large number of accounts in a denial of service-esque attack (this is possible as ticketmaster sends a reset password rather than URL to reset a password). It also means an attacker could build a large list of valid accounts and try the same password on all of them (ticketmaster1234 perhaps) which could return a few matches. Ideally ticketmaster would not reveal if an account existed or not.
preventing account enumeration on the forgot password page?
The same idea should of course apply to the forgot/reset password pages. Unfortunately what is very common is that although a website’s login fail message is generic, the websites goes and undoes all this good work on their forgot/reset password page. Remember easons.com who displayed ‘If you have an account but can’t remember your password, click on “Password Problems?” below‘ regardless if the account existed or not? Well here’s what happens on their reset password page:
Remember water.ie who upon failed login just presented ‘Please enter a valid username and password’ to the user? The first image below is what the forgot your password screen shows when the account doesn’t exist, while on the right, we see what the screen shows for an account that does exist.
So previously undiscoverable accounts are now discoverable on both easons.com and water.ie via their reset password pages. This is probably not a huge deal from a privacy perspective (does your neighbour like books? / has your neighbour paid his water charges?) for these particular sites. If however these sites don’t implement some kind of brute force mitigation individual accounts could be vulnerable. Ticketmaster.ie, as noted does appear to have brute force protection in place, this is just as well because their password reset page gives up existing accounts too:
What should happen in reset password scenarios is that the website should display the same generic message regardless if the username/email address exists. A message such as ‘Further instructions have been sent to your email address‘ or similar is often used in both cases. If the email address does exist the email can contain a password reset link (not a reset password in email – search for ‘Sending a reset password versus sending a reset URL’) which the email account holder can click on if it was them that asked for the reset or ignore if it was not. If the email account doesn’t exist in the user DB, just don’t send any email.
…but what about the registration page? I have to tell a potential new user that their chosen username/email is already taken on screen!
Not necessarily. Preventing account enumeration is most problematic on the registration page that’s for sure, at least from a usability perspective. The goal here is the same as with the login and password reset pages and that is to keep the outward (what’s on the screen) process the same for usernames/emails that already exist and those that don’t.
If the site uses the email as the username, it should be possible to do this pretty nicely and in a manner similar to before. It might require some re-jigging of your registration pages, but the idea would be to start the process by requiring the user to enter their email address. When they submit this notify them that they have been sent an email with further instructions regardless if the email is in the DB or not. If the email address is already in the system the email will advise them that they have already registered and perhaps provide a link to the password reset page. If the email address is unused the email will contain a time limited URL link to verify email and continue the registration process. There is a very small usability hit on this approach as the notification about email addresses already existing now happens via email rather than on screen, but this will affect only a tiny percentage of registrations.
Both easons.com and ticketmaster.ie use the users email as their username so could use the above approach. Their current registration processes let us all know if accounts already exist or not:
Note – water.ie is not really applicable in this case as their registration process begins with the entering of a application ID and associated pin which has been sent out in the post.
What if a website uses arbitrarily chosen usernames rather than email addresses to login? Well, for sure preventing account enumeration in this case is a bigger problem than above. In this instance, the first step of the process could capture both of these and in the follow up email notify if the email entered is already taken and advise of the username already associated with the email. Not a major problem so far… but what if the email is available but the username is already being used by a different user.
On popular sites, millions of usernames could already be taken, so it would be impractical to send a ‘username already taken’ email everytime someone tries to use an existing username as it could take them god knows how tries to find a free one. In this case, the best balance between security and usability may be to notify the user trying to register that their desired username is already taken on the registration page itself rather than via email but alsoto reCAPTCHA enable the page so scripts won’t work. This means the task of trying to find if a username already exists requires manual intervention by the attacker which significantly reduces their ability to build lists of existing accounts. Of course reCAPTCHA from Google and similar plugins by others are not unbreakable so there is no 100% perfect solution here. Your specific implementation is likely to be yet another trade off between security and usability.
suggestions to prevent account enumeration:
Use email addresses as usernames as this makes accounts easier to protect on password reset and registration pages.
Show generic‘Invalid username/password combination’ message on failed login.
Show generic‘Further instructions have been sent to your email address’ message on password reset. If email is already in DB, send a time limited reset password URL
First registration step is user enters email address and submits, then the site shows generic‘Further instructions have been sent to your email address’ message. If email is already in DB, email says already registered etc. If email not in DB, email should contain a continue registration URL.
OWASP page on preventing brute force attacks. Note in particular the section on account lockouts and the potential exploits that remain even when doing this after X bad attempts. The surface space of many of these exploits can be reduced by preventing account enumeration on login, reset and registration pages as per above.