I agree, and if that means loading the login form in your ajaxed website and just hiding it from view, so be it.
So many ajaxed SPAs nowadays don’t work correctly with password managers because they search the page for login forms after page load, not periodically.
So requesting and injecting the login form after pageload, may get in the way of a lot of people’s login workflows.
How do you handle international keyboards with regards to special characters or do you offer this on only alphanumeric passwords ?
Wouldn’t logging in be simpler without passwords at all?
This is how my wife uses most websites:
She rarely remembers her passwords, especially for infrequently used commerce websites. The passwords are an annoyance, and they are a definite security weak point. Most people don’t use password managers, and most people are not capable of being imaginative enough to generate a decent password per website.
For a lot of real users out there, wouldn’t it be better as just:
Just send a link with a one-time / time-limited key to the one place she knows and hopefully has a strong password. This is effectively how my wife uses most websites anyways, and could we improve security by removing the fallacy that we need this password at all?
Also, this saves her time from creating a new password, going through a few more dialogs, etc. In commerce you want to remove barriers; the longer it takes to process a sale, the more sales you lose.
Maybe we just call it poor mans offline oath.
What removing the login button altogether?
As a user types their password, constantly check whether it’s accurate or not by sending requests to the server. When the user hits the right password, you automatically log them in. There are some security issues involved, but they can be dealt with.
@codinghorror I’ve noticed that Discourse’s behavior has changed in the meantime. You no longer tell people whether they’ve entered a valid email address. Instead they just get a general “Incorrect username, email or password” error message.
What caused you to change your mind?
I just tested on meta.discourse.org in an incognito window and that’s not the case…
If you see some other message, someone has switched off the “tell people when they type in an invalid email” feature in their Discourse site settings. Because technically this exposes a bit of information, though I think the cost/benefit to end users of hiding the email hit (or non-hit) on password reset is totally not worth it.
Oh, I see. You show a specific error when trying to reset the password, but a general error when trying to log in.
What’s the reason for this difference? Why not give the user who tried to log in the same information?
Generally you are most concerned about this at the time of password reset. Nobody’s ever asked for outside of forgot password, to my knowledge.
OH! Thanks. I massively misunderstood.
