Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I have two related questions as to what happens when a user tries to log in to a website

If the entered password is wrong what should happen?

I have two ideas:

  1. Redirect to a page saying "wrong username/password, click here to try again"
  2. Always redirect to the members section since it checks already if the variable session has been set and if not the user would see "You are not logged in. Click here to sign in".

How does it work when the page does not need to reload to tell a user the password they entered was wrong?

It must use Ajax/JavaScript but anyone could mess with that using Fiddler or Charles. Is this feature just for convenience purposes and even if the JavaScript says the password right, on the server the entered password is double checked and if it matches the session is created?

share|improve this question
add comment

1 Answer

up vote 2 down vote accepted

For your first question, this would be dependent upon your application logic and what works best in the circumstance. For example, if you have a logon box on every screen, on a failed logon you may want to return the user to the same page and post a message or alert, since there intention may be to stay on the same page and then you save them navigation. In other cases, you may direct them to a page with just the warning or the members page with a warning saying blocked. I would say from a usability stand point you are probably better off keeping them where they are unless there is a clear separation between the "public" site and the "private" site. Metaphorically, is the logon on a gate or a light switch?

As for your second question in terms of security, it does not matter if it's a full page request or AJAX. The server side logic will still be needed to create the session, cookies, and any other backend settings that change the session to authenticated. If you are saying they could mess with the client-side validation, the response would be not to rely on client side validation. If you are concerned that some type of XSS attack or MiTM attack could prevent this message from being seen, then you would need to address the attack vectors separately.

The server side must be involved to create the session. If you were checking the password on the client side, that would mean you have already provided the password in a variable, cookie, local storage, file, etc. That would be a poor security choice. The session would still have to be setup on the server side. Most of the things you are doing with HTML/JavaScript/AJAX are going to be manipulating the content once its provided by the server.

If the security is just checking some local variable which is the password, anyone could change the logic check code locally and bypass the protection. If you require real security, not just a quick block for basic end-users, then you should be ensuring the password check occurs where you control the code only, the server side.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.