I am creating a project not very large scale and came to create a system of registration and login. In which cases/projects you might want to use ASP.NET Identity and when you just want to create your own login system, whose creation is much easier?
As a result of Your practice?
Maybe I have to use Form Authenticator?
Do you want social login (google / facebook / twitter / linkedin / etc)?
Do you want two-factor authentication?
Do you require users to confirm an email address as part of registration?
YOU DO WANT TO 1-WAY ENCRYPT THE PASSWORD ...but how?
ASP.NET Identity2 makes doing a lot of these things easier, because they already wrote the code for a lot of this stuff -- password hashing, creating confirmation tokens (for registration / password reset / linking emails to an account), social logins, etc.
Also, #Tim Schmelter makes a very good point in his comment. Security is not easy to get right. When you roll your own registration and login, you are not only making more work for yourself, but you are probably going to leave holes in the registration and login system.
ASP.NET Identity is not an "all or nothing" tool. You can use pieces of it as needed. There is no reason why you can't borrow the password hashing and token generation/validation portions of it, and then use the (non-claims-based) FormsAuthentication to write the cookie. However if you want claims-based authentication and social logins, I would recommend staying away from FormsAuthentication.
Related
I have a little problem and I will be happy if someone tells me what to do.
I want people to change their Facebook password. This project is in VisualStudio, using C# in data base. How to make this possible? The new password should be affected by tge username and the password.
Have you taken a look at their API documentation: https://developers.facebook.com/docs ?
Generally, any site that lets other programs interact with the password in any way should be avoided. The proliferation of federated identity (delegating authentication to a third party) is one major way to avoid security issues across many web sites by third parties better equipped to handle the challenges of authentication. It also helps users and improves security by making it easy to authenticate and not reuse the same password across multiple sites - a major security problem
At best, your application can authenticate with Facebook and authorize the user to access your site / application using their login API: https://developers.facebook.com/docs/facebook-login/
Our system is built using MVC4-EF6-SimpleMembership.
I'm struggling for 2 days now with how to enable an affiliate company website to login to our system.
What I wanted to implement is a simple GET from their site to ours (we would check the request comes from their domain), where they would pass in an encryption or hash of the password along with a username (not hashed/encrypted).
It turns out I don't have an encrypted/hashed password, which I can give them in order to use it and login, nor I have a way to recover the password in order to hash it myself and most importantly to manage to login with it from code.
Also, I didn't find a way to use the encrypted password field inside the webpages_Membership table. I thought that would be the token to send to our affiliate, but can't see any use for it.
Any ideas?
P.S.
I know there's the OAuth possibility, but I'm afraid to loose time figuring this out and then being dependent on the affiliate site. Is this a wrong approach?
Thanks very much for any help.
This whole approach is a really bad idea, and could very easily open your application up to hackers. You really need to learn more about how to handle authentication with trusted third parties if you're going to go forward, even if it costs you time. What it costs you time now it saves you in the long run in liability.
I'm not clear on your use case for them logging in right now. If it's a human being logging in, just provide them "normal" credentials and have them log in normally (i.e. through a web page POST to get a session cookie, etc).
If you are looking for a way for one of their applications to perform actions on someone's behalf (e.g a cron job or to enable integration with their services), then you should look into providing an API (not using a website per se but a REST or SOAP API). There's a number of mechanisms for that as well (Javascript Web Tokens, SAML assertions, etc).
Finally, if you're intending one of your users on their site to authorize their site to pull information about your user, or perform actions based on your user's wishes, then that's the "sweet spot" for OAuth.
Do not go forward with your plan of issuing out hashes of people's passwords. That isn't how the auth works at all, even if it were a good idea to do so. Standards exist for a reason.
I have a login screen, and upon successful login i will display a welcome screen. But the problem is if i refresh the web page. i am taken back to the login screen. If i am successfully logged in, then if i refresh i should go to the Welcome page.
I did some research and found out that i should be using cookies to handle this. Is cookies the best approach or are there any other way i could solve this ?
Could someone please point me to a good tutorial that explains how to do this? or some sample code to start with?
Here is the MSDN on the FormsAuthenticationTicket class that is used for authorizing users to your application. This is the term that you want to ask about/Google for more information on user authentication.
The basic premise is that once you have authenticated a user, you issue an encrypted cookie that contains some basic information about that user. This cookie is what is used to prove the user is who they say they are, defines the login expiration times and allows you to authorize them to different resources in your application.
Words of Caution
With that said, if you are rolling your own authorization/login system, I highly encourage you to use the built in .NET membership providers. There are many caveats to web authorization and authentication and the likelyhood that you leave a security hole open using your own code is extremely high.
Here are some other approaches that don't require cookies:
if you can use authentication provided natively by browser (i.e. Windows if your case is intranet with Windows domain) than you can base your decision on headers other than cookie header (i.e. in case of Windows auth you can use "impersonate request as user" functionality) to see if user is "logged in" to your system.
you can also set information on local system in Local storage to say "this user is logged in" and than check on login page if some other page needs to be rendered. This is not secure approach, but it maybe ok (as you still need to have some way to secure all other pages).
I would like to implement a lightweight registration less system for my asp.net page and need some direction to go
Basically I am currently at the point where I need session elements based on the user's username. But, since authentification is done using an other system, I would simply like to create session per username based on the success or failure of that other authentification system.
So, if authentification is succesfull using the information entered in the login page, simply create a new user in the system or something using the username provided (without, if possible, saving the password used).
I got a vanilla login page at the moment and would like some direction as to how to proceed while using as much of the vanilla infrastructure as possible.
Thanks you all :)
What your talking about is claims-based authentication. You trust a third-party service to have authenticated the user and trust that the information that the service tells you about that user is correct.
See what options you have for the service to pass you those details. You can use full-on SAML-based claims and Windows Identity Foundation may take on pretty much all of the work for you. If the third-party application is acting as a proxy, you could have it inject a HTTP header with the user name in. Or you could have a form, but someone or something is going to have to enter the data and post that form (you can do it automatically from Javascript when the site is launched).
If you want to use a form, it could be a modified Forms-based logon screen that doesn't check the password, just creates the Forms Authentication cookie.
If you want to use a more 'bespoke' scheme, you could create a custom security principal implementing IPrincipal, you can transparently inject this into your application and have it behave just like it would if you were doing 'proper' authentication.
Either way, don't try to mess with the way that ASP.NET security operates, just concentrate on the best way to get the information to ASP.NET via the security principal.
I'm trying to integrate facebook authentication with an asp.net site.
So if a user decides to register at the site they can do so by using their facebook credentials.
I'm currently at the point where I have the facebook access token and the user details and not sure how I should go from here.
The site uses asp.net membership authorization.
This is what I believe should happen in case a new user decides to register: (But not sure if this the the way to go)
0) User visits the site and decides to register using their facebook credentials.
1) The user providers their credentials and I receive an access token and their user information.
2) I store this information in my database and create an asp.net membership user with the data I received. (At this point I'd have to generate a password).
3) Log the user into the site so he can navigate freely.
I would appreciate some advice if I'm on the correct path and how I should go about generating the password. (I'm thinking in maybe combining the email and facebook userId, retrieve a hash and store.)
Thanks
UPDATE 1
I found this SO question where they suggest to use:
http://msdn.microsoft.com/en-us/library/system.web.security.formsauthentication.setauthcookie(v=VS.90).aspx
I think you approach is sound; what you effectively do is to replace the username/password authentication with the received facebook id, and let that id pass as a valid identifier in you application.
You say that you will need to generate a password in you application which I am note entirely sure about. It is true that you will need to create your user with a password as far as the membership provider in ASP.NET is concerned, but you could choose to fill in a random string if you only want the users to login using facebook connections.
Deciding which facebook attribute to bind to is also worth a bit of concideration. The natural choice is of course the facebook identifier since that is unqiue to the user, but if you choose to allow other authentication mechanisms later on - google open id for one - you might also benefit from storing the email from facebook etc.
Probably it will also be a good idea to auto generate a user name in you application that is not defined by facebook. If you choose the facebook identifier as login name you have a hard dependency on facebook making the introduction of new identity providers hard. If you choose a random identifier and an associative table establishing the connection between the facebook id and your id, you will also gain some flexibility later on. Choosing the somewhat more limiting email address might be a better choice if you want to have meaningful output from ASP.NET Login-controls like LoginStatus etc.
I haven't read the response below/above so this may have been covered but be warned that I ran into a serious problem with cookies not being set from within an iframe in IE. It was a bloody nightmare. I'm not sure if this has been fixed, if its fixable, but just be conscious of my experience and test thoroughly in all browsers.
Also checkout the .net open auth project. I haven't used it personally but it supposedly supports OAuth as well as OpenId & ICards, which could be helpful later on for additional integration points.