

Ask HN: Is it wise to put password validation on a signin page? - mwillmott

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.
======
drostie
The first green tick apparently does not test for username existence, but only
an acceptable username format.

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.)

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.

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.

------
bdfh42
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).

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.

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.

------
venomsnake
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.

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.

