On 13/12/16 21:32, Simo Sorce wrote:
On Tue, 2016-12-13 at 18:52 +0000, Tom Hughes wrote:
The main goal of long random passwords after all is about a combination
of making them hard to brute force and ensuring that every service has a
unique password to guard against credential reuse attacks when one of
the many services everybody has logins for experiences the inevitable
loss of their poorly secured database.
I always find it somewhat depressing that the more sophisticated a login
system becomes the worse my security on it seems to get because I wind
up having to use weaker passwords. Banks are the classic example because
they rarely have a straightforward password even as one part of their
authentication but anything that means I have to remember a password
hits the same problem.
Don't remember it if it bothers you, why do you use a double standard if
the password is not sent via browser but through a CLI ?
It's an interesting question, and the first thing I'd say is that there
are actually very few passwords that I enter at a CLI at all. Once I've
unlocked gnome keyring by logging into my laptop or desktop it's mostly
only when I want to sudo as other things tend to be by ssh public key
auth from my keyring.
I think the threat model is very different as well, at least for me, as
the environments where I am entering a password for sudo for example are
all ones which I control and where I know how the password database is
stored while for web based logins I operate on the basis that I have no
idea whether any given site has the sense to hash it's passwords or to
adequately protect it's user database.
Obviously I'm sure the FAS database is properly protected but the ways
of working I have developed are based around not assuming that for web
logins hence why I switched to random passwords and a password manager
many years ago.
Anyway, it looks like like GOA with the realmd fix likely does what I
want, which is good news.
Tom
--
Tom Hughes (tom@xxxxxxxxxx)
http://compton.nu/
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
