1

I am trying to build a login screen for my website, I would like to make it work without having to refresh the page (using AJAX). I have decided to use JQuery AJAX for this purpose to call an ASP.net WebMethod using the code below.

myPage.aspx

        $.ajax({
            type: "POST",
            url: '<%= ResolveUrl("myPage.aspx/GetLogin") %>',
            data: '{username: "' + $("#<%=txtUsername.ClientID%>")[0].value + '" }, {password: "' + $("#<%=txtPassword.ClientID%>")[0].value + '" }',
            contentType: 'application/json; charset=utf-8',
            dataType: 'json',
            success: function (response) {
                 if(result.d == true) {
                      LogIn();
                 }
                 else {
                      LogInFailed();
                 }
            }
        });

myPage.cs

    [WebMethod]
    public static bool LogIn(string username, string password)
    {
         bool result = CheckCredentials();
         return result;
    }

The question is, is this code secure enough? is this the right way to make a login asynchronously? is it secure to expose this LogIn publicly?

Sisyphus
  • 900
  • 12
  • 32
  • I'm not so familiar with .NET, so forgive my limits here. As a longtime security guy, I cringe a bit whenever I see credentials passed over the wire, even over https (you'll usually see some form of bcrypt hash instead with some one-time nonce tossed in there to avoid replays). That said, your approach isn't too bad if you can ensure https (can't tell from your code) and you have some way to persist the login (I assume the CheckCredentials method sets a cookie/session variable or similar?). I further assume you can't use OAuth instead? – BJ Black Sep 03 '16 at 10:33
  • The connection is an HTTPS connection, but you say this is not the ideal solution, what would you do in such scenarios? this is an enterprise application, so OAuth is not an option. – Sisyphus Sep 04 '16 at 08:28

3 Answers3

1

There is nothing wrong with AJAX authentication. Please don't listen to other answers suggesting to encrypt/hash the password before sending it. This is an unnecessary and ineffective precaution. Instead just make sure that your web-app uses SSL/TLS and you are fine. (Obviously salt&hash your credentials server-side, but not client side)

Another thing to take into consideration (esp. since you are rolling your own login-in mechanism) is to make sure that session tokens are refreshed when the login succeeds. Depending on how/where you store it, you might have to update a cookie or a hidden form field on a successful login.

daniel f.
  • 1,421
  • 1
  • 13
  • 24
0

The problem is not whether it is asynchronous or not. If the connection between the browser and the web server over HTTPS, I think there is no problem with that. Otherwise, somebody could incept your packages and read the info inside them (again, no matter whether it is AJAX or not)

In my opinion there is no problem with exposing your login publicly. However, you can take some extra measures to avoid brute force attacks on your login, and this stuff. Always take into account that the security must stay at the backend, and never rely on the request that the browser does (they can be modified by the sender).

Bustikiller
  • 2,423
  • 2
  • 16
  • 34
  • So you think the code above is ideal solution? (given it is over https and secured against brute force attacks) – Sisyphus Sep 04 '16 at 08:32
  • I think your problems will not come from this code. However you should also take another security measures such as hardening your server, avoiding shared hosts, configuring saving passwords using a salted hash... Nobody can guarantee your application is completely secure, but I think you will not have any problems using this code (the only difference with classic login is making it asynchronous) – Bustikiller Sep 04 '16 at 09:31
-1

In my view, To make your login credentials secure over the network you can use some encryption algorithm for password. for more information on encryption algorithm refer the links..https://msdn.microsoft.com/en-us/library/wet69s13.aspx, Salting Your Password: Best Practices?

Community
  • 1
  • 1
Harish Nayak
  • 348
  • 3
  • 18
  • Are you suggesting to hash/encrypt passwords client-side? Cause that is generally a bad idea. – daniel f. Sep 05 '16 at 10:13
  • No actually it's better to safe guard your application from hackers, as long as your comfortable in using encryption algorithms.. – Harish Nayak Sep 07 '16 at 10:48
  • I still am not quite sure i understand you. "Safeguarding your application" is obviously the goal, but it won't happen by encrypting the passwords client side. You do safeguard it by using SSL/TLS for your connection. Sending encrypted credentials over an unprotected connection makes absolutely no sense, cause the encrypted credentials become the "de-facto" credentials. An attacker just needs to intercept those, he would not need to know the plaintext. – daniel f. Sep 07 '16 at 10:54
  • Also, if you send the pw encrypted, it would either mean that the backend has to send the salt with which the passwords were hashed, or it would mean that the hashes are not salted in the first place, both of which are not ideal scenarios! – daniel f. Sep 07 '16 at 10:56
  • what is the better approach to solve this problem? securing the application from outsiders? – Harish Nayak Sep 07 '16 at 11:10
  • To solve this specific problem (sending of credentials) the best practices are the ones mentioned already. Server side you only store salted hashes of the passwords and the hash. When a client wants to authenticate, it sends the credentials in a POST request. The post request itself is protected by HTTPS, so that any attacker could not read them even if it intercepted the traffic. Your app on the server will read the credentials in clear text, as the HTTPS connection is terminated on earlier layers. The app can then take the salt, hash the pw and see if it matches with the stored one – daniel f. Sep 07 '16 at 11:51