I'm building web app without users and I want to create a back office for admin to edit something on the site. I thought to add a route that isn't accessible from any place in the app and only admin has it and there he can login.
Is there any acceptable practice?
Thanks
I think this is not best practice, as this is just hiding without proper protection (known as Security through obscurity). A lot of things can go wrong with this approche, like the URL get indexed on Google by mistake. For this reason it would be better to use a admin user with a proper password.
Related
I've had a look at this question, but when I've created the website I need to know what user to use for the pass-through authentication:
Looking at wwwroot in File Explorer, I can see it has IIS_IUSERS, which I tried giving full control to. I assume that the solution isn't to give it my admin account as authentication.
Before I deleted it, it was fine, so what have I missed? Maybe the original Default Website didn't use pass-through Authentication or maybe I'm missing something else.
What's the correct solution?
Designing a user content website and the question is for the admin section, from a security point of view, where should it be placed?
same domain and allow admin to enter site like other users from signin form using admin email
Have a separate sub-domain only for admin login
Have a separate secret domain used to access admin features
or any other suggestions?
goal is prevent anyone from knowing about the admin section and to keep it locked as much as possible.
Thanks
Actually I work on a system that uses a separate subdomain, and there's a whole another ASP.NET project dedicated for the Admin section of the parent domain.
This has many advantages for us. Some of them are:
Completly different authentication mechanism for one site and the other.
We can deploy the website without shutting down the admin site and viceversa.
Well, as a basic rule, I'd say it doesn't really matter. Your login form needs to be secure, whether it's exposed or not.
However, I understand the desire to keep the admin area hidden in any case. I personally like this variant the best:
same domain and allow admin to enter site like other users from signin form using admin email
because it doesn't leave any traces on the client computer that are easily detectable (like "admin.example.com" or "example.com/super-secret-admin-area").
does anybody have a manuel that describes the steps to create an anonymous
user authentication in SharePoint 2010 (Website for the internet with no authentication).
For editing an admin has to log in
with forms authentication. Can I hold the admin somewhere in the web.config with
membership provider ? Or do I need to install SQL Server somewhere for that task ?
Thanx a lot.
Stephan
Ah - you need SQL Server installed somewhee ANYWAY - SharePoint makes heavy use of SQL Server.
I would think that any valid ASP.NET membership provider should work with SharePoint, so in theory you should be able to write your own XML-based or text-based provider and store the admin username and password there.
But it's too much work and a bit risky. And in all honesty I would personally avoid trying anything like that since SharePoint is a complex enough behemoth by itself.
Since you only want an admin to be able to modify the website, it's probably a lot easier to just use the Active Directory provider and create a user in AD for the admin if one doesn't already exist.
HTH
I have been tasked with creating a SharePoint 2007 webpart that logs the user directly into our website (which uses forms authentication). Most likely the username and password will be same in the SharePoint account as in our website.
Ideally we would like it to be fully integrated in that the webpart looks up the SP login & password, somehow encodes that using SHA1, MD5 or similar encryption, then passes that along to our login page on the query string. However given we have little experience with SharePoint, and that it's probably impossible to programmatically access the SP username/password from a webpart we realize this isn't very likely to be possible and if so would probably require a lot of development time.
Another option would be to load a login form from the website within an iframe in the webpart, which would show the login & password first but store a "remember me" cookie after the first login, and on each subsequent load display just a button that logs them in directly using the cookie.
Has anyone done something similar before? I'm in over my head, any guidance would be much appreciated! :)
A good login system doesn't allow retrieval of passwords at all. (Forgot your password? Prove you're you and we'll reset it, send it to you, and force you to change it to something we can't see once you're back.) This way you CYA against both Angry IT Admin Guy back-dooring his way into other user accounts when he's disgruntled over coffee pot politics as well as a potential attack vector for the Internet at large to exploit.
The cookie idea is plausible. Depending on your SharePoint/other website configuration you may be able to federate your logins to a single authentication provider (using ADFS, Passport, OpenID, etc.), which would be a more elegant solution, but may not be feasible in your scenario.
If you're using SPS 2010 and your other website is based on .NET, then Windows Identity Foundation would be a option.
I wish there was a central, fully customizable, open source, universal login system that allowed you to login and manage all of your online accounts (maybe there is?)...
I just found RPXNow today after starting to build a Sinatra app to login to Google, Facebook, Twitter, Amazon, OpenID, and EventBrite, and it looks like it might save some time.
But I keep wondering, not being an authentication guru, why couldn't I just have a sleek login page saying "Enter username and password, and check your login service", and then in the background either scrape the login page from say EventBrite and programmatically submit the form with Mechanize, or use an API if there was one? It would be so much cleaner and such a better user experience if they didn't have to go through popups and redirects and they could use any previously existing accounts.
My question is:
What are the reasons why I shouldn't do something like that?
I don't know much about the serious details of cookies/sessions/security, so if you could be descriptive or point me to some helpful links that would be awesome. Thanks!
Edit:
I'm familiar with OpenID and the APIs. I was really wondering about the security/legal/confidentiality side of things. I understand the confidentiality part totally, don't know if there's anything legally written down about this, but assuming it's under ssl, and I don't store any of the data (will store the cookies and tokens), what are the security implications?
If I come to your website and give you my gmail password, what guarantee do I have that you won't read all my emails and even send a few of your own? And what if you become a little smarter and say 'people reuse passwords, I might just as well try if this password works for his bank account'.
As a user, I don't trust your site with my password. Period.
The whole point of Open Id and OAuth (that's what RPX uses) is to get around the above issue. I can give your website restricted, revocable and configurable access to my facebook account, all without giving your website my facebook password.
The UI is confusing, I agree. But with time people will understand what its all about, and it will be a lot better.
As already said above:
The site (or the site owner) accessing your {google|yahoo|etc} account cannot be trusted not to change your password and kick you out of your account.
But I feel there are other good reasons:
Many people use the same password on more than one site ore account (some could have the same password on gmail and paypal) and the site owner could abuse that
The site owner doesn't want to be held liable for other site owners abusing your account
The site owner could not be able to store your username and password in secure fashion. The site needs to be able to access them automatically. So on the server hosting there is stored everything needed to access those credentials.
And the hosting usually happens in a shared or virtual server with the hosting company administrators (and sometimes - if the hosting company isn't too conscious - fellow users) able to access them.
Security and Confidentiality. Period.
Even some websites like Facebook discourage using this approach in their TOS i believe. If so, it will be illegal to do so.