NFN Smith wrote:
[email protected] wrote:
I'm beginning to suspect that some web developers are starting to use
two-page login forms deliberately to prevent their users from using
password managers on the assumption they won't be secure, rather than
leaving it up to their users to ensure they store their passwords
securely. In which case, even if something is done in the browser which
works most of the time, those web developers may make sure they hit the
conditions for it to not work for their site and the whole cycle would
start again...
Some of it may be a way of defending against passwords "remembered"
(whether in the browser, as with Mozilla, or in the way that IE keeps
stuff in the Windows registry). Given the antipathy of some developers
towards Mozilla (including the long-time problem of improper sniffing
methodologies, looking explicitly for "Firefox", rather than "Gecko",
and sometimes causing for Gecko browsers that aren't Firefox), I think
there's some number of developers that aren't really thinking much about
the Mozilla method of handling passwords.
Yeah, I think the concern about letting the browser remember passwords
is more those which don't need the user to enter a master password to
access them. Even if the passwords are encrypted, if the user doesn't
have to enter a password to get at them the decryption key must be
stored somewhere on the system, so is just as accessible to anyone able
to steal the password database. Letting the user use a password manager
might even makes it more likely that they'll choose a more secure
password (longer, more difficult to guess) since they don't have to
remember it.
However, I think developers are more focused on defending against
script-based authentication (presumed to be malicious). By requiring
multiple user inputs, then it's far more difficult for an attacker to
present credentials -- not only valid credentials, but a way of
defending against brute-force guessing.
Perhaps that's also part of it. But it only doubles the number of
requests needed to brute force the password (assuming the username has
to be entered again after each attempt at the password). There are more
effective ways of slowing that down, such as only allowing say 5
attempts for a given username before locking the account for 5 minutes
(if the error message doesn't differentiate between incorrect
username/password and account locked, the attacker won't be able to use
that to know if they've got the username right). Most users aren't
delayed at all, but an attacker can only make 5 attempts every 5
minutes, and may not even know that that's what the limit is (so might
even happen to try the correct password while the account is locked).
And this kind of methodology
achieves a lot of the same kind of benefit as CAPTCHA, without annoying
users with CAPTCHA images that are difficult to decipher.
I've noticed that multiple-stage logins seem to be most common with
financial institutions.
Yeah, but they (or at the ones I've used) tend to do other things which
can't be handled by a password manager anyway, like ask for 3 given
digits out of an 8 digit number plus a another piece of "memorable
information" (effectively a second password). Or use a chip+pin card
reader to log in.
I haven't checked it, but my suspicion is that a tool such as KeePass
might have capacity of scripting a multiple-stage login.
Possibly; I keep meaning to look into that. I don't have it here right
now to look, but from what I recall I think it has a default method of
automatically filling in login forms (which should work for most basic
cases) but flexibility so you can tell it how to identify the relevant
fields on a site-by-site basis. Not sure whether it handles submitting
the username and password on separate pages though...
--
Mark.
_______________________________________________
support-seamonkey mailing list
[email protected]
https://lists.mozilla.org/listinfo/support-seamonkey
