[vox-tech] sshd_config and PasswordAuthentication

[Micah J. Cowan]

On Fri, Jul 22, 2005 at 03:31:10PM -0700, Karsten M. Self wrote:
> on Fri, Jul 22, 2005 at 03:04:46PM -0700, Micah J. Cowan (micah at cowan.name) wrote:
> > On Fri, Jul 22, 2005 at 12:02:41PM -0700, Karsten M. Self wrote:
> > > on Fri, Jul 22, 2005 at 10:01:32AM -0500, Jay Strauss (me at heyjay.com) wrote:
> 
> > > > I think you are talking about passwordless authentication, 
> > > 
> > > It's not "passwordless", which is a description of negation.  It is
> > > possible to set up accounts and SSH-keys without passwords or
> > > passphrases.  Naturally, this is highly insecure.
> > 
> > A small quibble: Using assymetric key cryptography without passphrases
> > is not necessarily insecure. 
> 
> Actually, there's another scenario for which this holds, below...
> 
> Lack of a passphrase *is* significantly less secure.

I still say: depends on the context. But even so, "significantly less
secure" and "highly insecure" are quite different, to me.

> 
> > If the private key is secure, then a passphrase is not useful. 
> 
> The conclusion requires the premise.
> 
> The key must then be secure via shell access, filesystem access *and* by
> physical access to all media (you *do* have system backups, correct?).

None of which seems terribly difficult.

> With a passphrase, even an untrusted root has relatively little
> likelihood of access to the key

Er, what? An untrusted root has /complete/ access to both the key and
any passphrase entered at his/her machine.

>, and physical access / offline data
> access is similarly protected against.

That's a somewhat stronger point.

> > A private key is not really harder to secure than a passphrase is
> 
> No, it's much harder to secure.  
> 
> A passphrase isn't long-term resident on disk and accessible via
> numerous routes.

True that it's not long-term resident on disk. As to "accessible via
numerous routes": there's keystroke logging, memory snooping, physical
snooping, and a variety of techniques based on knowledge of the English
language (or whatever the native language of the passphrase) and of the
passphrase's author (these techniques, of course, still being far less
efficient than keystroke logging, etc).

> A passphrase-protected private key is a case of
> "something I have + something I know", which works pretty well in
> practice.
> 
> A private key isn't handed around as a password is.  
> 
> Threat model, unsecured private key:
> 
>     I trust me, my local host, host, and any hosts I use this password
>     on, as well as physical security of local and remote hosts, and
>     security of offline backups of local and remote hosts, any password
>     storage systems I use, and any inadvertant access to any shell
>     with access to the private key.

Er... NO. That applies to password-based authentication, and doesn't
apepar to have anything at all to do with passwordless key
authentication.

First of all, "password" should not even exist in your paragraph above,
since we explicitly are speaking of passwordless logins. That eliminates
"any hosts I use this password on"... Not sure what ", host, " in the
first line was supposed to mean... I'll assume "remote host", which is
clearly false: the remote host has no access to your private key. Same
goes for "remote host's physical security", and "backups of ... remote
hosts", and of course "password storage systems I use"... You seem to
have suddenly started talking about password-based authentication versus
what we have been talking about up until now: key-based authentication.

It should be:

      I trust me, my local host, and the physical security of any
      backups that include my private key (which I feel to be a bad idea
      in any case).

I do /not/ trust an "inadvertant access to a shell with access to the
private key... but /damn/ if that doesn't usually indicate a huge
problem already.

> 
> Threat model, passphrase:
> 
>     I trust me, my local host, and any password storage systems I use,
>     and any inadvertant access to a shell with access to the private
>     key, where that shell has activated the key (via ssh-agent).
>     
> 
> > and if the private key is accessible to someone, chances are pretty
> > good that the passphrase can be as well.
> 
> I disagree with that assessment, see threat models above.
> 
> > Also, use of a passphrase-encryption on a more-or-less publicly
> > available private key means that the "weakest link" in the security
> > chain will be the weaker of (1) the assymetric encryption algorithm and
> > (2) the symmetric encryption algorithm used to encrypt the private key
> > with the passphrase.
> 
> ...and the inherent guessability of the passphrase (mix of selection and
> passphrase length).

Right, thanks.

> My understanding is that 1 & 2 are cryptographically solid.  Which means
> that you're protected by the passphrase, and that an unsecured key falls
> to the weakest link of physical security of both the system and any data
> backups or archives.

Of course, "cryptographially solid" is a relative statement... in
reality, encryption thought to take longer than the remaining lifetime
of the universe given an *immense* amount of resources, frequently
ends up being much simpler to crack, when someone discovers a new
mathematical algorithm that drastically improves one's ability to do
whatever "something really hard" a particular encryption algorithm
relies upon.

Of course, "frequently" is a very relative term in the way that I use it
in the above paragraph: I'm thinking in the course of decades, mostly,
but still...

One of the fundamental problems of cryptography is that, with the pretty
much singular exception of the OTP, it is impossible to "prove" the
cryptographic soundness of _any_ algorithm. So it's not mathematically
provable that a vastly faster way of accomplishing something
previously considered to be a quite daunting task will not be
discovered.

However, I concede that this particular point I'm trying to make doesn't
make for a comparitively strong case.

> > Of course, if the private key is truly private, then the passphrase
> > does no harm (other than the minor nuisance it presents to the owner),
> > and provides an extra level of protection in the case of *accidental*
> > compromise of the private key, for the paranoid (a generally good
> > trait to possess).
> > 
> > Nonetheless, it seems to me that calling the use of public-key
> > cryptography without passphrases "highly insecure" is a rather harsh
> > exaggeration.
> 
> It greatly increases the number of avenues to compromise, and creates a
> single token (the private key) which if accessed allows direct access.

You seem not to have shown this to be the case, given that your threat
model above apparently addresses the wrong scenario.

> By contrast, a passphrase-protected key follows the doctrine of
> 'something I have, something I know", in providing security, and renders
> the key by itself largely useless.
> 
> 
> Following my own current practices, my risks are:
> 
>   - Someone guesses my passphrase.  They can now use the key without
>     limit.  The passphrase is long, random, and not stored in cleartext
>     anywhere.
> 
>   - Someone accesses my system while it's running with ssh-agent
>     enabled.  They can now use the key for the duration of that session.

If they have access to the decrypted key, can they not use it for every
session thereafter, as well? Or are we speaking of some other key?

Of course, again, if someone has this level of access, you've got other
problems.

>   - Someone knows a cryptographic attack on SSH (none are publicly
>     known).  Likelihood of this is low.

There is one, in fact, for RSA, IIRC. It requires fairly enormous
computing power, however; and a _relatively_ low key length
However, there are often cryptographic attacks
on /implementations/ of an algorithm as well. Of course, none of
what I've just said has any bearing on the rest of what we've been
discussing. :-)

> 
> Otherwise, opportunities to use my private key without authorization are
> pretty slim.
> 
> 
> The one exception to an unsecured private key is in the case of a forced
> command.  This is a mode of operation in SSH where a specific command is
> executed through use of a dedicated public key.  This is useful for such
> tasks as unattended backups, rsync triggers, or SSL server initiation.
> The risk can be minimized, with an appropriately constructed commande,
> to allowing Eve to run your admin tasks for you, with no other
> inadvertant program execution or data disclosure.  This isn't an
> automatic feature -- you *can* use forced commands to open yourself to
> attack.  However with appropriate precautions, it's a case where a
> non-passphrase protected key may be used securely.

I don't see how this actually changes the security or insecurity
of private-key authentication, though: either it's secure or it's not.
The example you give above seems more to illustrate a case where the
practical needs outweight any (in my mind, fairly minor) advantages that
a passphrase layer adds.

Of course, I'm not saying that one shouldn't use passphrases, or that
passphrases offer no advantages in security: I'm merely arguing with
your statement that not using a passphrase is "highly insecure."