How secure is this ASP.Net authentication model?

Question

I've created an web authentication app using c# & asp.net and want to bounce off how secure you think it is. All navigation is done by https.

User Registration

1. User enters 3 datapoints (SSN,Lname and DOB). If that combination is found in our system, a session variable is set and navigates to next page.
2. If session variable for #1 is set, proceed and ask for username, pwd, security q&A etc. Use Linq to save data and verify session variable before actual save event. PWD and security answer is hashed using salt and sha. (use validation controls and textbox limits to limit input)

Reset password

1. Same as #1 in registration but includes username. If ok, set step 1 session variable.
2. If step 1 session variable is set, ask security question up to 3x. Salt/hash and verify to database salt/hash. If match, set step 2 session variable.(use validation controls and textbox limits to limit input)
3. Check for step 2 session variable. Ask for new pwd. Hash/salt and save using LINQ.

Login (use validation controls and textbox limits to limit input)

1. Gather username and password. HASH/salt password that matches username and see if password matches hash. If okay, instatiate user objects and pass to default page.
2. All pages inherit from masterpage. Masterpage has code to verify if user objects are set to a valid instance. If not valid user object, logoff is called which redirects to main login page.

Kind of wordy but wanted to be clear.

Am I missing anything here? I wanted to use MS's forms auth but decided to roll my own as I had some issues getting some of the custom stuff I wanted done using FBA. By using session variables as step completion markers, does that adequately prevent session stealing or bookmarking? Is there a better way to do this?

Thoughts please?

Answer 1

What aspect of either ASP.NET Forms Authentication or using the Membership Provider bits didn't fit with your needs? I've found both to be very flexible in many different scenarios?

Rolling your own is usually going to make life hard in the future, especially when you need to start making changes. Also your use of a master page to verify a users logon state etc might be fine for now, but when you require more master pages you then start needing to replicate the same blob of code in every masterpage and keep it all consistent. That can then become a maintenance nightmare somewhere down the road.

If you're not using the ready baked authentication tools in the framework you should be plumbing this kind of thing in somewhere else, such in an HttpModule.

I think you should revisit what you're doing. Take a look at implementing your own custom IIdentity objects if you need to hang user specific data/objects off of a user object. Then assign to a custom IPrincipal you can attach to Context.User in ASP.NET.

@asp316 and @Jack (comment) I would advise grabbing these two books:

Developing More-Secure Microsoft® ASP.NET 2.0 Applications by Dominick Baier

Professional ASP.NET 2.0 Security, Membership, and Role Management by Stefan Schackow

You'll be surprised how flexible the built in security infrastructure in .NET really is. There's a lot more to it than just adding a <authentication mode="Forms"> setting to your web.config and slapping a <asp:login runat="server"/> control on a page.

Answer 2

I think you're pretty well set; I would also lock a user out for a time after a certain amount of bad login attempts (1 hour after 5 bad tries?) and check for time between requests (the AjaxControlToolkit "nobot" works wonders here, in my experience).

One option, rather than using your Master page for the security code, is to implement an Interface that the pages (or Master page) can inherit from; this way, if you ever do expand to multiple master pages, or if you have pages outside of the master, you can continue to use the same security-checking code.

Depending on your requirements, I'd shy away from (required) security questions; I always forget mine. You're already checking for SSN, BDay, Last Name, username, and password; anyone who knows all of this probably can guess your mother's maiden name.

[edit]

Also, I do think it's a ok to roll your own, as long as you vet it like crazy. Throw some other people at it and see how it holds up. I totally understand the inflexibility of the ASP.NET control options; their controls will probably be more secure (although, you should never blindly trust anything, especially something that you don't know what's going on behind the magical black box), but sometimes you just have to roll your own when it's not flexible enough.

Answer 3

The thing about "rolling your own" is that it's very easy to get it wrong in subtle ways such that it appears to work. You then, of course, deploy this code and move on to other things with no clue that anything is wrong. After all, it passed all your tests.

A year later it turns out your site was hacked six months previously, and you never even knew it until just then.

Much better to find a way to rely on an implementation written by security experts.