Custom identity using Session state

Question

User511735230 posted

Hi, I could use some advice from the guru's here.

A long time ago, I built the first release of an ASP.NET web forms application. A requirement for the web site is that only known customers may log-in. So after they buy access, they get a temporary login, which allows them to change their password. At the time I decided not to use ASP membership because I needed full control of the database schema for users.

So instead of the ASP membership, I just check on each page whether there is an active Session. If (Session("Logon") == null) Response.Redirect ... This was based on the assumption that in memory Session state is secure. 

This works satisfactory, so no need to change from that perspective. We are now in the process to completely revamp the site to allow responsive behavior and a more modern user interface. Much more of the user interaction is done in the browser, with ajax calls to the ASP.page. There I can do the same thing, check the Session, before allowing any thing that should stay confidential.

My question to the forum is, should I absolutely redo the authentication towards ASP.NET Identity for security reasons, or can I assume safely that no one can hack Session (as far as you can assume anything).

Thanks

Pieter

Answer 1

User1779161005 posted

You most likely need to update your security and you have a long road ahead of you (and ASP.NET Identity would only be one small piece of this larger effort). Here are some potential issues:

APIs should not use cookies for authentication because of XSRF and if you ever want to support non-browser clients.

Session state was never designed for security.

Session state was generally a bad idea anyway and should be avoided.

You might not be protecting yourself from the myriad of common attacks (password brute forcing for one).

Your home grown identity database might not be storing/protecting credentials properly.

You might need to support non-password authentication, including federation/social logins.

You might want SSO across multiple apps.

Answer 2

User511735230 posted

Thanks Brock, that really helps. I will familiarize myself and implement ASP.NET identity. You mention a long road ahead, what else do you mean? Some more information below.

You most likely need to update your security and you have a long road ahead of you (and ASP.NET Identity would only be one small piece of this larger effort). Here are some potential issues:

APIs should not use cookies for authentication because of XSRF and if you ever want to support non-browser clients.

-> I don't need non-browser clients on the current API's, but XSRF seems a good argument to implement Identity anyway

Session state was never designed for security.

Session state was generally a bad idea anyway and should be avoided.

-> 100%? Most state is in the database, I use Session only to keep track of who the request comes from

You might not be protecting yourself from the myriad of common attacks (password brute forcing for one).

->  I think I  am, after 10 (customizable) attempts, the site shuts down

Your home grown identity database might not be storing/protecting credentials properly.

-> I think so, it is storing a hash, not the password itself

You might need to support non-password authentication, including federation/social logins.

-> not needed, although I would not exclude it.

You might want SSO across multiple apps.

-> No SSO needed, it is a closed dedicated site.