In article <4191e7fa$0$176$cc7c7865@news.luth.se>, Simon Aittamaa wrote:
> Right, I'm not in any way a professional or a guru I'm only supplying my
> view of things so don't mistake this for facts ;) And if I'm wrong
> please let me know, knowledge is power you know... (First post so be
> gentle).
>
> Lawrence D¹Oliveiro wrote:
>> SSH password authentication is a form of shared-secret authentication,
>> if I understand correctly. This means that the SSH client and server
>> convince each other that they both know a shared secret--the
>> password--before allowing the connection to proceed.
>>
>> Given that UNIX/Linux systems don't store passwords, but
>> one-way-encrypted password hashes, this means the shared secret is
>> actually the password hash, not the unencrypted password itself. It
>> cannot be the unencrypted password, because the server cannot determine
>> what that is.

The shared secret is the unhashed password. The secret is shared
between the server authentication system and the user. The secret
is transmited by ssh from the user to the server authentication
system. ssh transmits the authenticity decision from the server
authentication system back to the user.

Using confidential key agreement (Diffie-Hellman), or public key
encryption (RSA), ssh transmits everything (including the unhashed
password) encrypted. If it performs as designed, encryption
prevents interception of the unhashed password.

Executables on the server don't know the unhashed password.
Executables on the server receive the unhashed password (which is
not stored to disk) from the user, and pass it to the server
authentication system. ssh grants no stronger authentication
than is available to executables on the server, but is designed
to provide no weaker.

> Why wouldn't the server be able to tell what the encrypted password is?
> The logical would be for the server to encrypt the password using the
> same alg. and then checking if it matches the password in the shadow
> file. That way the client /has/ to know the right password not just the
> hash. Of course it could be sending it as hashed but I can't see why it
> should since it's already encrypted with 128 bits, if there is a reason
> please enlighten me.

Note that Lawrence said the server cannot determine the unencrypted
(not encrypted) password. One-way-encryption is also known as
hashing (to avoid confusion with asymmetric encryption).

The unhashed password is never stored on the server, lest it be
compromized by bit-reading the storage device. The server stores
the hashed password in the shadow file. If the hash used performs as
designed, then the unhashed password cannot be obtained from
the hashed password.

>> This has implications for system security. ... Even if you chose
>> good passwords which resisted a dictionary attack, they can still
>> use a suitably hacked SSH client, ...

Yes.

A suitably hacked ssh client (called a trojan) could record your
unhashed password. You should thus not enter your unhashed password
into an ssh client that may have been hacked. To avoid ssh clients
(and other executables) that have been hacked, you should check
signatures and test before installing, and use tripwire, or a variety
of other tamper detection tools. In general, don't enter sensitive
passwords into untrusted computers (e.g. don't give your ATM pin
to strangers).

>> This has implications for system security. Imagine if someone were to
>> steal a copy of your server's shadow and password files. Even if you
>> chose good passwords which resisted a dictionary attack, they can still
>> use a suitably hacked SSH client, which lets them directly enter the
>> password hash rather than the original password, to log into your system.

If they stole the shadow file, and the hash performs as designed, they
would not be able to determine the unhashed password needed to
satisfy the server authentication system.

The qualification "performs as designed" covers the fact that encryption
and hashing don't make imposture impossible, but they make it more
expensive than legitimate access by a factor called cryptographic strength.

Hopefully helpful,
--
Dr. Robert J. Meier
Compuware, Inc.