Summary of password strength discussion

[Enrico Tagliavini]

If I can step in I would like to share my experience about the SSH
topic. I'm a Systems Administrator, worked in three different
companies by now and in all three cases there is always a common
problem, among others: users asking, ignoring, misusing, having
problem setting up SSH keys. So I would like to make the humble
suggestion of not disabling password auth by default for users. You
are going to confuse the crap out of normal users. It's easier to
explain then how to make a good password by linking
https://xkcd.com/936/ then having them understanding ssh keys. Not to
talk about the problems about using the SSH agent, proxy commands,
rsync from / to servers where you don't have your keys.

On my side instead I love to use passwords access instead of SSH keys
for servers I don't use frequently or to transfer between two servers.
A strong password makes the setup a lot easier than SSH keys (you
require the ssh agent and the like, I don't like this usually and I
keep my key on my laptop only encrypted and on an encrypted
partition). Also if I can't access my laptop I can still work from
another place without even touching my backup. I recall most of the
passwords by memory even if unique.

I can understand disabling root password login by default, looking at
how many servers are easily compromised by common or short passwords
for user root makes it clear than by default this should be disabled.
I'll be annoyed and will enable it again, but it's for the good.

To be honest I think part of the fault lies in the most common SSH
server / client used: openssh. The doc is a bit confusing, it is easy
to misconfigure and when the auth fails the client doesn't really give
the user any useful information about the reason. Most of the time I
ask the user to show me the output of ssh -v and they solve the
problem themselves. And just now the changed the fingerprint hash
format, making confusing even for me. Was not trivial to find how to
get it in the old format out of the client in Fedora (my servers
mostly run Red Hat or CentOS where it is not possible to output the
new format). SSH utilities have to become a bit more user friendly
before moving to keys by default.

This doesn't really solve the password strength problem anyway, since
you should encrypt your key with a very strong one eheheh.

Returning more on topic. Allowing just 6 chars passwords is just
allowing the user to get a bad habit, and sort of legitimate the use
of weak (in the broad usage) passwords. Yes "butter" might keep local
users away from your PC, but if you just get used to longer passwords
for everything, and you need to do that anyway... who doesn't have an
email, it's a good thing. That said enforcing a longer password (like
12 or even more) without pissing off the user completely requires a
little bit of education. What about adding few lines to the anaconda
installer to explain the 4 random (unrelated) words or some rule like
that? May bundle the xkcd comic as well if possible (only half
kidding, but blacklist "correcthorsebatterystaple").

Sorry this was way longer than I initially intended.

Best regards!

On 24 July 2015 at 12:45, Michael Stahl <mstahl at redhat.com> wrote:
> On 23.07.2015 18:55, Michael Catanzaro wrote:
>> 4) Our requirements for local password strength will allow passwords
>> that would be much too weak were remote access via SSH to be enabled.
>> We should have some user interaction when enabling SSH in the Sharing
>> panel to force the user to pick a much stronger password.
>
>> Point (4) above sets the goal of setting stricter password requirements
>> when remote access is enabled. Remote access is disabled by default and
>> will remain disabled forever for most Workstation users, so it's not
>> appropriate for that case to dictate our default password requirements.
>
> i've never understood why the sshd_config by default allows password
> auth; first thing i do when installing SSH is to configure it to only
> allow public keys.
>
> that would avoid the password strength problem too, since you can set a
> different and better password on the private key.
>
> would it be reasonable to expect the sort of user that wants to use SSH
> to be able to set that up?  maybe provide some GNOME UI to generate a
> key and copy it to .ssh/authorized_keys?
>
>
>
> --
> desktop mailing list
> desktop at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/desktop