• RLB (unregistered)

    It is a pretty basic tenet of login security that you never tell a would-be cracker which of user name and password he got wrong, so this code is correct. The message could be better, but the principle is correct: a failed log-in is a failed log-in, and the would-be user should never get a clue as to why.

  • 516052 (unregistered)

    When it comes to working in a corporate setting you quickly learn that, much as in a civil war, being right is far less important than not been seen being wrong.

  • (author) in reply to RLB

    Though in this case, it's not that authentication failed- it's that it was never attempted because the function doing it was called incorrectly.

  • (nodebb)

    So ... Excellence in programming?

  • (nodebb) in reply to RLB

    It is a pretty basic tenet of login security that you never tell a would-be cracker which of user name and password he got wrong, so this code is correct. The message could be better, but the principle is correct: a failed log-in is a failed log-in, and the would-be user should never get a clue as to why.

    I totally agree. But here, the message about the password should not be that the password is incorrect (which can indicate to a hacker that the username is correct) -- it should be that a password is required. And the response for a bad login should be "Invalid login" with no indication whether it is the username or the password that is not found in the authentication store.

    (And yes, I'm quite sure there's somebody out there who, in addition to validating the supplied password against the supplied username will check to see if the password hash exists and throw a "right password wrong username" message.)

  • Tim (unregistered) in reply to Bananafish

    (And yes, I'm quite sure there's somebody out there who, in addition to validating the supplied password against the supplied username will check to see if the password hash exists and throw a "right password wrong username" message.)

    better still, how about "password character 4 is correct; characters 3 and 7 are correct but in the wrong position" ;-)

  • Scragar (unregistered)

    Optional required fields.

    Because of course someone would create that in PHP, why wouldn't you.

    It fits right in with the type safe automatic type cohersion.

  • (nodebb)

    It's already been invented. How many times have you encountered the error "An error has occurred"?

  • (nodebb) in reply to Tim

    Ok, then, I will enter "green, red, red, white, blue"

  • MRAB (unregistered) in reply to Bananafish

    Could it instead complain about the password even if there's no such username? A hacker would then be wasting time on a dead end, thinking they have a valid username!

  • Loren Pechtel (unregistered)

    @RLB Yeah, you don't tell the user what was invalid. But it is perfectly acceptable to tell the user they failed to fill in something. Acceptable results here are username required/password required/username and password required/credentials not found/internal problem/success. (Don't tell me my credentials are wrong when the actual problem was a backend system not responding!)

  • (nodebb)

    More importantly, if it's possible to supply neither of username and password, the resulting error should mention both problems. As it is, even if the password error had the correct message, the developer experience is that you're told "you need to provide a username", so you fix your code, try again, and then get an error "you also need a password lol" error that you could have got the first time as well.

    This is especially annoying when you're passing in a rich data structure and the actual error is that you put username and password (say) at the wrong level. If the error says "You should have given me fields foo, bar and baz" and you did specify all of them, that gives you a chance to look at the documentation again and realise your mistake.

Leave a comment on “Required Fields”

Log In or post as a guest

Replying to comment #700614:

Log Out

« Return to Article