Social Authentication in ASP.NET Core MVC

A common modern convenience for apps is the ability to choose to authenticate and create an account based on credentials from an existing service that most people have (ie. Google, Twitter, LinkedIn, GitHub, etc.). in this post I will walk through the configuration of social authentication for Google and LinkedIn accounts.

Setting up social authentication in ASP.NET Core is a lot easier than you might think...

Before implementing this feature you will need to register for a Google and a LinkedIn developer account which will then give you access to the 2 values that make the magic of this built-in authentication possible: clientKey and clientSecret.

Important(!): you will also want to register the Callback/Redirect URLs for each social authentication as shown below. This redirect URL below is for my project running on localhost:44396 obviously ("/signin-google" is the path you want to append to your app root for Google and "/signin-linkedin" for LinkedIn):

Once you have this setup, you will be able to wire them up in the Startup.cs ConfigureServices() method of an ASP.NET Core 3 MVC Web Application ie:

  public void ConfigureServices(IServiceCollection services)  
     {  
       services.AddDbContext<ApplicationDbContext>(options =>  
         options.UseSqlServer(  
           Configuration.GetConnectionString("DefaultConnection")));  
       services.AddDefaultIdentity<IdentityUser>(options => options.SignIn.RequireConfirmedAccount = true)  
         .AddEntityFrameworkStores<ApplicationDbContext>();  
       services.AddControllersWithViews();  
       services.AddRazorPages();  
       services.AddAuthentication()  
       .AddGoogle(o =>  
       {  
         o.ClientId = "[YourGoogleClientId]";  
         o.ClientSecret = "[YourGoogleClientSecret]";  
       })  
       .AddLinkedIn(o =>  
       {  
         o.ClientId = "[YourLinkedInClientId]";  
         o.ClientSecret = "[YourLinkedInClientSecret]";  
       });  
       // Add application services.   
       services.AddMvc();  
     }  

Now you just have to:

• Create your ASP.NET Core 3 MVC Web Application project with Identity options as below

• Install a couple Nuget packages for Google OAuth2 and Linked OAuth respectively

• Call "Update-Database" from Nuget Package Manager Console

• Modify Startup.cs

To implement this feature for your users you only need follow a couple steps when setting up the project (whether ASP.NET MVC or the newer ASP.NET Core MVC) to enable some builtin identify and authentication handling after which you can configure and customize to fit your app's particular custom authentication needs. Follow the images below for proper installation of the required 2 Nuget packages, the db command, etc.

First, make sure you create your ASP.NET Core MVC project with "Individual User Accounts" radio button selection and "Store user accounts in app" dropdown selection as follows:

Change Authentication to use Individual User Accounts- this sets up the required boilerplate template code

You will add this Nuget package for LinkedIn authentication

You will add this Nuget package for Google authentication

Next you will need to create the database objects (ASPNET app auth db and tables) via "Update-Database" Package Manager Console command

Finally, modify Startup.cs ConfigureServices() method as shown in the snippet above. Compile and give it a whirl.

And that is all there is to it. Strangely there is not a lot of documentation on exactly how to do this and what can cause it to not work; I spent over an hour debugging what turned out to be a not-so-obvious issue (in my case I was following instructions that erroneously suggested I inject unneeded services to the services.AddAuthentication() instantiation in the snippet of Startup.cs above).

If your keys and Callback URLs are correct you will be able to authenticate to Google and LinkedIn

Once you have registered your social account, you can then log in with it and you will see the following (notice "Hello!...." and "Logout")

If you are like me and do not want to keep to adding yet more and more credentials to LastPass, your users probably don't either. Implementing Social Authentication is a powerful tool that you can leverage with relative ease in ASP.NET Core 3 MVC Web apps.

If you have questions on implementing this or just need some help and general guidance, feel free to comment or drop me an email at colin@sonrai.io


GitHub: https://github.com/cfitzg/DotNetSocialAuth


References:

http://codereform.com/blog/post/asp-net-core-2-1-authentication-with-social-logins/

https://docs.microsoft.com/en-us/aspnet/mvc/overview/security/create-an-aspnet-mvc-5-app-with-facebook-and-google-oauth2-and-openid-sign-on

https://ankitsharmablogs.com/authentication-using-linkedin-asp-net-core-2-0/  

https://stackoverflow.com/questions/53654020/how-to-implement-google-login-in-net-core-without-an-entityframework-provider

Common Exploits and How They Work

Man in the Middle: "an attack where the attacker secretly relays and possibly alters the communications between two parties who believe they are directly communicating with each other."-Wkipedia.

A MITM or MTM attack does not happen at the source or destination but rather along the route between them. To prevent this type of attack one must ensure the integrity of their network. This includes enabling only the latest recommended security protocols, ensuring SSL cannot be impersonated, and general configuration of network firewalls and routing equipment to ensure no unauthorized user can ever connect to your router or any other interception point.


SQL Injection: "An SQL injection is a computer attack in which malicious code is embedded in a poorly-designed application and then passed to the backend database. The malicious data then produces database query results or actions that should never have been executed." -Techopedia.com

Cross-site Scripting (XSS): "XSS enables attackers to inject client-side scripts into web pages viewed by other users." -Wikipedia

For a basic example, if UserA is logged into some secure that is authenticating each UserA HttpRequest via a key that UserX can obtain- (perhaps by successfully MITM'ing)- UserX can then impersonate User A by using UserA's authentication key to craft HttpRequests containing malicious scripts that run automatically on User A's browser.



Buffer Overflow Attack:

Buffer Overflow attacks cause a memory buffer boundary (stack or heap) to be exceeded and memory pointers to be overwritten to point to attackers own malicious functions instead of the normal user, machine or OS instructions.

Intrusion detection systems can be used to mitigate this type of attack by alerting Network Administrators if any irregular/bad actor is on the network. Some well-known buffer overflow attacks: https://www.cypressdatadefense.com/education-training/buffer-overflow-attacks-need-know/


Rootkit Deployment: "A rootkit is a clandestine computer program designed to provide continued privileged access to a computer while actively hiding its presence." -Veracode.com

The unique feature of rootkits is their design to be undetectable. In Windows systems for instance, rootkits will override Win32 API methods that the OS uses to verify the integrity and authorization of certain method calls, etc. In this way, rootkits can allow a malicious program to run in the background, undetected by most normal system checks. Sysinternals' RootKitRevealer can show you if your machine is affected by any rootkit-based malware.

Sony Music infamously used rootkits: https://blogs.technet.microsoft.com/markrussinovich/2005/10/31/sony-rootkits-and-digital-rights-management-gone-too-far/

The following are some of the more well-known Exploits:

StuxNet: Uncovered in 2010, this severely malicious virus spread through Windows USB "Autorun" feature and mostly affected an Iranian nuclear enrichment plant. StuxNet was a self-propagating worm hidden via root level masking. The machine operators had no forewarning that StuxNet was installed and configured to ruin several centrifuges. StuxNet was developed jointly by US and Israeli cyber actors. Shockingly, the Iran centrifuge destruction was "just a test" of StuxNet's power. It successfully stalled Iran's nuclear enrichment program for up to several years according to NY Times researchers: https://www.nytimes.com/2011/01/16/world/middleeast/16stuxnet.html


WannaCry: "The WannaCry ransomware attack was a May 2017 worldwide cyberattack by the WannaCry ransomware cryptoworm, which targeted computers running the Microsoft Windows operating system by encrypting data and demanding ransom payments in the Bitcoin cryptocurrency." - Wikipedia 

WannaCry affected a number of targets (and successfully extorted a number of ransoms) including Britain's National Health Institute.


Sony Music: Sony's privates network was compromised by a group calling themselves "Guardians of Peace". The attack apparently happened simply from one of the attackers obtaining admin credentials through email phishing. Embarrassing internal email correspondence and future film material was leaked to the public. Ultimately, North Korean Park Jing Hyok has been charged for the Sony attack as well as the WannaCry ransom attack: https://www.pbs.org/newshour/nation/north-korean-programmer-charged-in-sony-hack-wannacry-attack


Spectre: In 2018 this hardware-based attack method altered the way microprocessors perform a  basic branch speculation function which leads to side effects that include revelations of what was in the process instruction, private data, etc. Although this attack is not remotely exploitable, it is likely to go undetected unless systems are maintained and secured diligently.



Cybersecurity Organizations and Resources:

OWASP Free and Open Security Community

Offensive Security

Microsoft Security

Android Security

Linux Security

Visualize Hashing and Salt as Part of Password Encryption Process

The image below is a simplified and easy-to-understand illustration of how hashing and salting work. The main takeaway from this post- multiple users can have the same password, but will all have different salt values, thus making their hash result value different, and when you authenticate, you authenticate by the hash result value of your passwords, which is virtually always going to be unique for each user record:

Simple, no?

Even in the case of 2 users having the same hash result, the usernames will/should not be the same, so you still have distinct accounts, because UserID is also checked in the authentication process.

Companies increasingly (and for good data privacy reasons) do not even store the clear text textbox value you enter when you sign up for and then log into Fb, Google, Amazon, etc- they check your entered password's hash result against the hash result they have for your user/account record either from when you registered or last changed your password.

Good answer to the question you may come across, "what is the difference between salt and an IV (initialization vector)?" (TL;DR: not all IV's are salt, but salt is a kind of IV): https://security.stackexchange.com/questions/6058/is-real-salt-the-same-as-initialization-vectors

Reference: https://www.slideshare.net/rahulrajatsingh/password-hashing-28725754