SSH vs encrypted passwords

On Thu, 11 Nov 2004 15:56:10 +1300,
Lawrence D¹Oliveiro <ldo@geek-central.gen.new_zealand> wrote:


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


If you are prompted for a password then the password is sent to the other
side and validated same way as with a telnet session. You can also use
RSA or DSA authentication, where you may be prompted for a encryption key
to decode your private key part of a public/private key pair. The server
have a copy of your public key. Then there is also the posibilty to
trust the client IP number and bypass authentication altogether, just
like rsh/rlogin. If the server doesn't have either your DSA/RSA public
key and if it doesn't trust the client IP number, then it falls back to
the mormal login dialog through /bin/login in which case your password
is sent via the encrypted SSH connection to the login program.

Villy

Lawrence D¹Oliveiro <ldo@geek-central.gen.new_zealand> writes:

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

You're wrong. Looking through a "truss" of the ssh server
it does call crypt() when you use a password authenticated login.
That means it will have gotten the clear text password (but it's
send over an encrypted connection)

The server has a key which is verified, that's how ssh protects
against rogue servers.

Casper

Am Wed, 10 Nov 2004 19:42:18 -0800 schrieb AnthonyM:

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

You are possibly right, but when a user has the public/private keys stored
on his laptop, and the laptop is stolen ... then this is worse than
password authentication.

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


You are correct that a spoofing server could steal the password.
You are wrong that this means that the password is not sent.
It is sent and, yes, that is a weakness of the protocol.
Different protocols (such as SRP that I mentioned earlier,
and even some of the other ssh authentication methods) do protect
against this kind of "snooping".


You elided the reference I gave to the ssh authentication
protocol specification. Here it is again:

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

Here is the relevant section from that document, where it is
stated categorically that the password *is* sent in plaintext
(although over an encrypted channel; So the server can read it,
but any snoopers will find it hard to do so):

|8. Password Authentication Method: password
|
| Password authentication uses the following packets. Note that a
| server MAY request the user to change the password. All
| implementations SHOULD support password authentication.
|
| byte SSH_MSG_USERAUTH_REQUEST
| string user name
| string service
| string "password"
| boolean FALSE
| string plaintext password in ISO-10646 UTF-8 encoding
^^^^^^^^^^^^^^^^^^
|
| Note that the 'plaintext password' value is encoded in ISO-10646
| UTF-8. It is up to the server how it interprets the password and
| validates it against the password database. [...]
|
| Note that even though the cleartext password is transmitted in the
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| packet, the entire packet is encrypted by the transport layer. Both
| the server and the client should check whether the underlying
| transport layer provides confidentiality (i.e., if encryption is
| being used). If no confidentiality is provided (none cipher),
| password authentication SHOULD be disabled. If there is no
| confidentiality or no MAC, password change SHOULD be disabled.



-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

Stephan Goeldi wrote:

> Am Wed, 10 Nov 2004 19:42:18 -0800 schrieb AnthonyM:
>
>> 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.
>
> You are possibly right, but when a user has the public/private keys
> stored on his laptop, and the laptop is stolen ... then this is worse
> than password authentication.

No, because you can (and should) protect the key with... a passphrase.
That way no harm can be done.

EJ
--
Remove the obvious part (including the dot) for my email address.
http://www.vanwesten.net for examples of ipf and pf.

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

I'm pretty sure I have the concept of password authentication correct.

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

As other replies have indicated, even in ssh, if the user is using
password authentication, then the password is sent to the remote system
to be encrypted. The very large benefit that ssh has over other
protocols is that the clear-text password is transmitted over an
encrypted tunnel.

Your statement is completely true if we're assuming public key
authentication; however, the topic is password based authentication...

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

Stephan Goeldi <expires.1.12.04@usable.ch> writes:

]Am Wed, 10 Nov 2004 19:42:18 -0800 schrieb AnthonyM:

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

Well, in theory yes, in practice no. People change the ssh master password
on their machines often enough that almost everyone ignores the "password
has changed" warning.


]You are possibly right, but when a user has the public/private keys stored
]on his laptop, and the laptop is stolen ... then this is worse than
]password authentication.

Agreed. Or if his machine is broken into. the attacker now has immediate
access to all machines who accept his passwordless login.

On Wed, 10 Nov 2004 19:25:22 +1300, 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.
>
> 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.

SSH uses public key encryption. Public key encryption has a public key
which anyone can see and a private key which is never transfered to the
other party. The best analogy for public key encryption that I've heard
is that instead of sending the other party a key you send them a lock for
which you have the only key. The other party then puts the lock on a box
and sends the box to you. You can then open the box with your private key.
In a single key encryption system the weak point is exchanging the key, if
someone intercepts the key they can make a copy and then use it to read
all of your messages. If someone intercepts a lock it's useless to them.
Making a copy of a lock doesn't help you to open another box with an
identical lock on it. Public key encryption is actually even better than
this analogy because one of it's properties is that you can sign a message
with an unforgeable signature. The parties exchange public keys and then
encrypt messages for each other using their own private keys and the
other parties public key, the messages are then exchanged and decrypted.
Because the messages can only be decrypted with complementary public and
private keys they can only have a single origin. SSH calls this RSA
authentication, RSA is the initials of the developers of public key
encryption (actually public key encryption was developed simultaneously be
different groups not just RSA, the first developers worked for British
intellegence but they didn't get the credit because their work was secret).

On 2004-11-12, General Schvantzkoph <schvantzkoph@yahoo.com> wrote:
> On Wed, 10 Nov 2004 19:25:22 +1300, Lawrence D¹Oliveiro wrote:
>
>> SSH password authentication

[snip]

> SSH uses public key encryption.

[snip]

ssh *can* use public key encryption for user authentication, but
it can also authenticate based on a username/password provided by
the client. The latter is what Lawrence is concerned about.

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

Keith Keller wrote:
> On 2004-11-12, General Schvantzkoph <schvantzkoph@yahoo.com> wrote:
>> On Wed, 10 Nov 2004 19:25:22 +1300, Lawrence D¹Oliveiro wrote:

>>> SSH password authentication
>
> [snip]
>
>> SSH uses public key encryption.
>
> [snip]
>
> ssh *can* use public key encryption for user authentication, but
> it can also authenticate based on a username/password provided by
> the client. The latter is what Lawrence is concerned about.

Unfortunately, Lawrence has no clue what he's talking about, since he seems
to believe that an SSH client hashes the password before sending it. It
doesn't. It establishes the encrypted connection, then sends the username
and password in "plain text" through that connection. The server decrypts
it, then takes that plain text username and password and uses the system's
normal login functions with it.

If SSH *didn't* work this way, then SSH clients would have to know about all
the different kinds of password hashes that different systems use --
crypt() and MD5 on Unix, whatever Windows uses for SSH servers running on
Windows, whatever VMS uses there, etc. It's much, much simpler to let
server ports worry about what sort of authentication scheme the OS uses
instead -- and doesn't require that SSH clients be upgraded to deal with a
new server OS.

--
ZZzz |\ _,,,---,,_ Travis S. Casey <efindel@earthlink.net>
/,`.-'`' -. ;-;;,_ No one agrees with me. Not even me.
|,4- ) )-,_..;\ ( `'-'
'---''(_/--' `-'\_)