Matching Passwords with Front-End or Back-End?

Question

Does anyone have any information on the industry-standard or best practice for checking matching passwords (e.g. Gmail's "passwords do not match" feedback")? Is it a back-end, front-end or client-side process? Or is it completely based on other factors?

Here is an example of the code that I am using (Python with Bottle) to sign up a user. The code works, but I am unsure whether I should provide a flash message from the back-end (where it returns "Passwords do not match") or would it be better to use something like JS? I know that there are scripts out there to validate this, but they are all JS. My question is not how to do it with JS, but which is the preferred method.

@route('/suser', method='POST')
def sign_suser():
    cemail = request.forms.get('semail')
    cpassword1 = request.forms.get('spass1')
    cpassword2 = request.forms.get('spass2')
    ctype = request.forms.get('stype')
    if cpassword1 != cpassword2:
        return "<p>Passwords do not match</p>"
    else:
        pwhash = crypt(cpassword1)
        connection = sqlite3.connect("whatever.db")
        cursor_v = connection.cursor()
        cursor_v.execute("insert into users (cemail, cpassword, atype) values (?,?,?)", (cemail,pwhash,ctype))
        connection.commit()
        cursor_v.close()
        info = {'status': 'User Added',
                'type': 'success'}
        return template('whatever',info)

Magic

The backend is always going to be the one doing the check, but you can send the login request with an XMLHttpRequest from JavaScript. In the interest of keeping it simple, I would recommend you stick with a message from the backend for now. – Arenas

The check should always be done in the backend. About the message being displayed, you can show the message with JavaScript, according to the response of the HTTP request you send. – Cloudberry

The second password is only for the user to prevent typos. That belongs to client side form validation. I would send only one password string in the request. – Sociology

Same thing @Sociology said. You check that both passwords match client side for typos and only send one password field to the server to save. There really is no reason to check server side and if any one bypass's your client logic then it's on them if they mess up their password. The only message that should come from the server is if the password field is missing. – Quirites

Great feedback, thank you to all. I'll explore the client-side part of things. Thank you again – Magic

Answer 1

Checking if two password fields match during a sign up should be purely done with client-side logic. It is provided as a safety against a user mistakenly inserting a typo into their password. A server-side check is pointless, as your client will have prevented it and if your user is a tech savvy individual that does everything with curl then it's on them if they mess up.

Also I will expand on your question about best practices. You should not immediately save the user in your database without them first verifying via a link, usually sent to their email, that it is valid. Remember: never trust anything provided by the user.

Quirites

Makes sense, and the second part especially! Thank you – Magic

Answer 2

You need to distinguish between two cases:

1. You are not able to validate the value without using a database or any non-sharable technique in the back-end. In this case, you're only possibility is to check it in the back-end (with e.g. an Ajax call or a communication over WebSockets). Examples for this kind of validation are: username/password validation or anything which needs a connection to a database, a proprietary algorithm to check a value with a logic which cannot be published
2. You can validate the value without checking it first in the back-end (database). In this case, you can move the check for performance reasons to the front-end/client side. You still have to protect the back-end against incorrect values (in case of an attack, corrupt JavaScript etc.) Examples for this kind of check are e.g. email address validation, phone number validation etc.

For 1, I would just use a regular connection to the back-end either when submitting the value or while typing (if the response from the back-end is fast enough).

For 2, you have several options:

• Do it like in 1. Make a back-end check either while submitting or during the input. This may have some performance issues though (mainly if you are checking it on key down). If you are checking it after submitting, the validation is not real time.
• Do it with separate validations on the front-end side and the back-end side. If you are doing. This is not recommended. You are duplicating code between the front-end and the back-end. Avoid it as often as possible.
• Do it with shared validation patterns in the front-end and the back-end. This is my recommended way of validating values. This validation works best, if the checks are done with regular expressions (regex). The back-end has a Map() of patterns which are provided over an interface to the front-end. The patterns are loaded initially, when the web applications is loaded and are then present during the runtime of the application. This makes sure, that the validations are always the same on the back-end and front-end side.

---

Your example however comprises of the matching of two passwords (equality check). This is a special case, because you cannot use a regular expression to check the validity of the value. This precludes the recommended case from above and leaves the two other mentioned solutions.

If your sole purpose is to compare the two values, I would recommend to duplicate the logic. Duplicating is in this case (imho) somewhat justified because the check is very simple and not likely to be changed over time. Making a check to the back-end to soley check for equality is (imho) overstated.

Portamento

Your answer is way to long and completely misses what the question is really asking. – Quirites