SSH vs encrypted passwords

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.

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.

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.
>

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.


> 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.

I'd say if your shadow file is stolen you have bigger problems to worry
about than this.

- Simon

---
"Life's a bitch then you die."

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.

Lawrence D¹Oliveiro <ldo@geek-central.gen.new_zealand> writes:
>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.

No.

A password happens to be one of the possible ways that the client
can authenticate itself to the server. The password is not used
to authenticate the server to the client.



>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 server *can* determine the unencrypted password, because
the client transmits a plaintext copy of it to the server:

http://www.ietf.org/internet-drafts/...serauth-22.txt



>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.

Since ssh doesn't work that way, that attack is not applicable.
However, for some other protocols where the hash of the password
*is* password-equivalent, it would be cause for concern.

If one were worried about such things, then one might look at,
for example, SRP, which protects against such attacks:

http://srp.stanford.edu/whatisit.html


-jonathan

--
Jonathan H N Chin, 2 dan | deputy computer | Newton Institute, Cambridge, UK
<jc254@newton.cam.ac.uk> | systems mangler | tel/fax: +44 1223 767091/330508

"respondeo etsi mutabor" --Rosenstock-Huessy

Hey;

On 2004-11-10, Lawrence D¹Oliveiro <ldo@geek-central.gen.new_zealand> wrote:
>
> 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.

Not quite. I think you're misunderstanding how password based login
works. You're correct in your understanding that the remote server
cannot decrypt the encrpted password. What it does instead is encrypts
the user supplied password using the same salt as is stored with
the on-disk encrypted password. There's a lot of math that I don't
even pretend to understand, but the long and short of it is: if
you encrypt the same string with the same salt multiple times, it
always comes out the same.

So, the user supplies his password to the remote system either
through ssh or any other protocl. The server identifies the salt
used in the original encryption. With standard unix crypt, this is
the first two characters of the hashed password. Not 100% sure
how the md5 encryption does it, but I'm assuming its something similar.
The server then encrypts the supplied password with the identified salt
to generate an encrypted password. The server does a simple string
comparison between the two encrypted passwords - if they match you're in.

Please note that the the above is an oversimplification of the process -
more of a concept than an actual design document. For instance, the
actual password is never encrypted anywhere - its just used to
generate a key which is what gets encypted. See crypt(3) for more
details if you're interested.

Hope that helps clear things up for you.

Doug

--
--------
Senior UNIX Admin
O'Leary Computer Enterprises
dkoleary@olearycomputers.com (w) 630-904-6098 (c) 630-248-2749
resume: http://home.comcast.net/~dkoleary/resume.html

In article <cmt6k1$qjv$1@gemini.csx.cam.ac.uk>,
jc254@newton.cam.ac.uk (Jonathan H N Chin) wrote:

>The server *can* determine the unencrypted password, because
>the client transmits a plaintext copy of it to the server:

No way would that happen, because a spoofing server could then steal the
password.

>If one were worried about such things, then one might look at,
>for example, SRP, which protects against such attacks...

Yes, I've heard about SRP, but that uses a different authentication
system which would be incompatible with the existing UNIX/Linux
passwd/shadow encryption.

In article <slrncp460a.sri.worsel@c112927lin.svinfra.compuwar e.com>,
"Dr. Robert Meier" <worsel@c112927lin.svinfra.compuware.com> wrote:

>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.

No, it cannot be, because the server doesn't know what it is. The server
only knows the hashed password. So that must be the secret.

>The secret
>is transmited by ssh from the user to the server authentication
>system.

The secret is _never_ transmitted as part of authentication. Otherwise
you couldn't guarantee it would remain secret.

>>> 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, ...
>
>A suitably hacked ssh client (called a trojan) could record your
>unhashed password.

I wasn't considering that. I was considering an intruder who had got
hold of a copy of your passwd and shadow files, being able to use them
to log into your system.

In article
<slrncp4r11.645.dkoleary@x1-6-00-b0-d0-c1-44-09.comcast.net>,
Doug O'Leary <dkoleary@olearycomputers.com> wrote:

>On 2004-11-10, Lawrence D¹Oliveiro <ldo@geek-central.gen.new_zealand> wrote:
>>
>> 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.
>
>Not quite. I think you're misunderstanding how password based login
>works.

You're misunderstanding how secure authentication has to work over an
insecure network (which is what SSH does).

>So, the user supplies his password to the remote system either
>through ssh or any other protocl.

No. The password is never transmitted to the remote system in SSH.

All this talk of hacked has me wondering. If your server has a hacked
ssh server, which runs suid root, the attacker doesnt even need your
password to compromise your system. You've already lost. The hacker
might as well just make the ssh server log him (or her) in as root
automatically.

And as far as spoofing goes, the ssh packets are encrypted.

What makes ssh really powerful is not using the password
authentication, but using the public key/private key encryption /
authentication. You can use these to authenticate the user as well as
the machine you are connecting to.

Check this out: 'ssh - how it works:'
http://www-h.eng.cam.ac.uk/help/jpmg...sh-detail.html

-Anthony

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2004-11-11, Lawrence D¹Oliveiro <ldo@geek-central.gen.new_zealand> wrote:
>
> No, it [the unhashed password] cannot be, because the server doesn't
> know what it is. The server
> only knows the hashed password. So that must be the secret.

By that logic, there is no shared secret, since the user doesn't know
the hashed password, and the server doesn't know the unhashed password.

> The secret is _never_ transmitted as part of authentication. Otherwise
> you couldn't guarantee it would remain secret.

How does the client know what salt to use to compute the hashed
password, then, since the hashed password is only in the server's
/etc/shadow? Logically, the secret must be sent from the client to the
server, and it's the server which uses its salt to create the test hash
against which to compare against its hash.

You're right, though, in that you can't guarantee that the unhashed
password will remain secret. That's why there are server keys, and why
you can be prompted if a server key has changed, so you can decide
whether or not to transmit your unhashed password to the server, and why
the entire data channel is encrypted. But it's no cure-all, of course,
which is why you also need to take care when using passwords. But
that's nothing new, right?

But anyway, don't take our word for it: read the source code for
OpenSSH, for example, and see what it does with passwords. I haven't
done so, so you shouldn't trust me any more than you'd trust a machine
you don't admin.

> I wasn't considering that. I was considering an intruder who had got
> hold of a copy of your passwd and shadow files, being able to use them
> to log into your system.

If my hypothesis above is correct, then an intruder obtaining a copy of
your shadow file is helped marginally, in that a) he knows your salt,
and b) he can attempt to brute-force match passwords to your hashed
password without having to connect to your server each time.

- --keith

- --
kkeller-usenet@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://wombat.san-francisco.ca.us/cgi-bin/fom

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFBkvSRhVcNCxZ5ID8RAu4dAJwIWZ6J4TmERkjMGrsam7 h9QSNFIACeLjnj
SqSleBSbitlTp4y3C0Cy+tA=
=5FCL
-----END PGP SIGNATURE-----