I was just prompted to log into the BBC website (https://ssl.bbc.co.uk/id/signin). When entering my username i got a nice green tick - i took this to mean that the username existed (is this itself bad practice?). When i entered my password i got another green tick - this was more confusing. Was it checking my password before i'd clicked signin? That would be weird. But no, it was just checking it met the password policy for length etc.<p>Is this necessary or useful on a signin page? I found the message confused so once again, a debate on best UI practices for signing pages.
The first green tick apparently does not test for username existence, but only an acceptable username format.<p>I think there may be interactive attack models against logins where you separately report "this user does not exist" from "the password was not correct" -- somewhere in the back of my head is a "general rule" that you should just report "login failed" in both cases. However I do not recall the details. It might be worth contacting someone who has worked on real-world implementations of the Secure Remote Password protocol to know what exactly the threat model here would be. (I'm choosing SRP only because I know that I've seen SRP implementations generating deterministic 'fake keys' for users they do not recognize, since SRP requires a user-conditioned response from the very start of the protocol.)<p>On the other hand, you could probably create a system which allowed interactive password checking without revealing the password and without allowing for easy brute force attacks. The idea would be to combine a slow one-way memory-hard function f (like scrypt) and a zero-knowledge login system like SRP.<p>The idea would be that I would send you all of the detail needed for a full key negotiation except for the verifier V that you're supposed to finally get -- i.e. the quantity in the zero-knowledge proof where you go "and if that equals V then I accept the login." Instead I'd send you f(V), so that I am not revealing my hidden data, and so that it takes you, say, 100ms to try any password -- providing a sort of instant feedback for 'normal' users while suitably strengthening them against actual brute-forcing.
You will probably get mixed opinions. I prefer that a "sign-up" page gives clear indications of the minimum standards required for passwords (although these should be inclusive and not exclude characters).<p>Validating the user name is always a bit of a problem - assuming you want unique usernames (and can't use an email address). It is nice to be able to offer some user feedback (with some back end validation via AJAX) but then again you don't want to give too much away about pre-existing user names.<p>On a "sign-in" page then there should not be any validation of the password at the client end - this should only be done at the server and if the user name/password combination fails then the user should be told of the failure but not which element failed validation. I also like to slow the response to an invalid log-in.
It is stupid if you ask me. First - the site provider almost always overvalues his creation while the user just wants a test drive. So making you think of a secure password on the fly just means more utilization of the password recovery system.<p>Much better approach is to accept on the initial registration and to flag the password as weak in the DB next to the BCrypt hash and when the user becomes invested you can harass him as much as you like to give a stronger one.