Question

I have a ASP.NET MVC site with a private site administration application secured with ASP.NET sql-backed authorization. I need to add a login for the public site to allow visitors to sign up for an account.

I am thinking I should create totally seperate storage for the public site, rather than extend the existing user db and rely on roles to keep public users out of the back office. Is there any reason not to do this?

Was it helpful?

Solution

Yes there is. You can isolate the private database from the public database. Create 2 database user accounts, make sure they only have access to the 1 database they need. The public and private apps will use different accounts. Then lock down the database accounts to make sure they only have the rights needed for the web app to function. (I'm not sure what database you are using. if you are using ms-sql make sure they don't have access to xp_cmdshell, if you are under mysql make sure the account doesn't have FILE privileges. There are other considerations but this is outside the scope of this question.)

If a SQL Injection vulnerability is found in the public part of your site then they will be able to access that one database leaving your private site unaffected by the attack.

OTHER TIPS

Time and potentially money would be one reason. Otherwise, if you have the time. Depending on the need, not knowing exactly the issues at hand, it could also add a lot of complexity...

HTH.

Will you ever have a user with more than one role? Could you end up storing the same user in more than one database? If so, I would keep your users in a unified DB.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top