Stallings Chapter 9, and SSH

1
Stallings Chapter 9, and SSH
From Chapter 9 well select the parts of sections
9.1 and 9.3 that focus on passwords.
2
Techniques for guessing passwords (Page 303)
Guessing 1. Default passwords shipped with
system
2. All short passwords ( 1 to 3 characters )
3. Words in dictionary
4. Information about users (spouse name, etc.)
5. User's phone numbers, SS, or room numbers
6. License plate numbers
Trojan horse
Line tapping
3
The Vulnerability of Passwords (page 316)
UNIX password scheme
Usual key
Expanded key
/etc/shadow
64-bit output
Data 64 zeros
Modified DES algorithm
4
Problem 9.7 The encryption scheme used for UNIX
passwords is one-way it is not possible to
reverse it. Therefore, would it be accurate to
say that this is, in fact, a hash code, rather
than an encryption of the password?
5
The salt ? Based on the time/date at which the
password was assigned
? Stored in the clear.
The salt serves three purposes 1. it prevents
duplicate passwords from being visible in the
password file
2. It effectively increases the length of the
password without requiring the user to
remember two additional characters (next slide)
3. It prevents the use of a hardware
implementation of DES, which would ease
the difficulty of a brute-force guessing attack.
6
Problem 9.8 Salt is stored in the clear. How
does it give any benefit?
Consider that Darth gets a copy of the
password/shadow file at a company with 1,000
employees. Without the salt Darth could take a
popular password, encrypt it and look to see if
any of the 1,000 employees have chosen that
password. With the salt he has to do the
encryption separately for each employee,
increasing the amount of work by a factor of
1,000.
7
Recall from our study of SSL
4.6.3 Creating Cryptographic Parameters
The two randoms are a salt.
8
Darth observes!
Need SSH
Hash!
9
Password Guessing
10
Experiment in password-guessing

• Try the users name, initials, account name,
  and other
  relevant personal information

2. Try words from various dictionaries (60,000
words)
3. Try various permutations on the words from
step 2. This included making the first letter
uppercase or a control character, reversing the
word, changing letter O to number 0, etc.
This added 1 million words to the list
4. Try various capitalization permutations from
step 2 that
were not considered in step 3.
11
(No Transcript)
12
Keep in mind that such a thorough search could
produce a success rate of about 25, whereas even
a single hit may be enough to gain a wide range
of privileges on the system.
Dont accept the argument I have nothing to hide
I dont mind if other people see my account.
13
Password Selection Strategies (pages 320-322)
? User education
? Computer-generated passwords
? Reactive password checking
? Proactive password checking
Enforce simple rules, such as passwords must
be at least eight characters long must
include upper-case, lower-case, numerals
and punctuation.
14
Secure Shell (SSH) 1. Remote Users Both Telnet
and FTP send passwords across the
Internet in the clear. SSH and
SFTP are secure replacements for Telnet. and
FTP that can avoid use of passwords. SSH
has many similarities with SSL,
also some differences (next slides)
15
2. Environments of SSH and SSL
Authentication of human user unnecessary.
User may not always use same client machine.
Authentication of human user vital.
16
3. Preview of SSH operation
? limited authentication of server machine
? no authentication of client machine
? server will unquestioningly participate in
establishing secure channel to
any client machine
? careful human user authentication over secure
channel
? several similarities with SSL handshaking
(next slide)
17
4. Establishment of Secure Channel between
Machines
SSH TCP connection to port 22 established.
SSL TCP connection to port 443 established.
At this point both sides know algorithms
18
Both sides know algorithms
At this point both sides compute keys
19
Both sides know algorithms
Both sides compute keys
Service SSH or SFTP
20
SSH Protocol SSH Version 2 Packet
Length 788 Padding Length 8 Key
Exchange Msg code Key Exchange Init
(20) Algorithms
Cookie 8B21EDD188AFED7EC7FC499F65CD84C7
kex_algorithms length 126
kex_algorithms string diffie-hellman-group-excha
nge-sha256, diffie-hellman-group-exchange-sh
a1, diffie-hellman-group14-sha1,
diffie-hellman-group1-sha1
server_host_key_algorithms length 15
server_host_key_algorithms string
ssh-rsa,ssh-dss
encryption_algorithms_client_to_server length
157 encryption_algorithms_client_t
o_server string aes128-cbc,3des-cbc,blowfish-c
bc, cast128-cbc, arcfour128,arcfour256,arcfour,a
es192-cbc,aes256-cbc, rijndael-cbc_at_lysator.liu.
se, aes128-ctr,aes192-ctr, aes256-ctr
encryption_algorithms_server_to_client
length 157 encryption_algorithms_
server_to_client string aes128-cbc,3des-cbc,bl
owfish-cbc,cast128-cbc, arcfour128,arcfour256,ar
cfour,aes192-cbc,aes256-cbc, rijndael-cbc_at_lysato
r.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
mac_algorithms_client_to_server length
105 mac_algorithms_client_to_serve
r string hmac-md5, hmac-sha1,umac-64_at_openssh.co
m,hmac-ripemd160, hmac-ripemd160_at_openssh.com,hma
c-sha1-96,hmac-md5-96
mac_algorithms_server_to_client length 105
mac_algorithms_server_to_client string
hmac-md5, hmac-sha1,umac-64_at_openssh.com,hmac-rip
emd160, hmac-ripemd160_at_openssh.com,hmac-sha1-96,
hmac-md5-96 compression_algorithms
_client_to_server length 26
compression_algorithms_client_to_server string
none,zlib_at_openssh.com,zlib
compression_algorithms_server_to_client length
26 compression_algorithms_server_to
_client string none,zlib_at_openssh.com,zlib
languages_client_to_server length
0 languages_server_to_client
length 0 Payload 0000000000
Padding String
Cookie
Menu of cipher suites
21
In menus, algorithms are listed in order of
preference, so those chosen are the first ones
that are on both lists.
Key exchange diffie-hellman-group-exchange-sha256
Server host key ssh-rsa
Symmetric encryption aes128-cbc
MAC hmac-md5
Compression none
22
Recall Diffie-Hellman
Global parameters q, a
Key exchange method chosen diffie-hellman-group-e
xchange-sha1
DH_GEX_REQUEST client specifies a range of
values for the modulus, q, and asks the
server to choose
DH_GEX_GROUP server responds with q, a to be
used.
DH_GEX_INIT client chooses its DH private key,
computes its public key
and sends it to server
DH_GEX_REPLY server sends its DH public key,
servers host public signing key and
signed hash of previous handshake messages.
23
(No Transcript)
24
(No Transcript)
25
(No Transcript)
26
SSH Protocol SSH Version 2 Packet
Length 700 Padding Length 10
Key Exchange Msg code Diffie-Hellman
GEX Reply (33) Payload
00000115000000077373682D727361000000012300000101..
. Padding String MAC
String
Much more on next slide!
27
(No Transcript)
28
To authenticate the server, the client
? checks servers public key against key in file
known hosts (if this is the first contact, user
is given option to risk proceeding)
? checks the servers signature of the hash of
previous handshake messages agreement
proves that the server has the RSA private
key corresponding to its public key
This gives limited authentication of the server.
Both participants compute the shared DH secret
and combine it with hashes of the previous
handshake messages to compute the various
necessary keys
29
(No Transcript)
30
At this point the secure channel between the
client host machine and the server machine has
been established. Note again that there has been
no authentication of the client host machine, and
only limited authentication of the server host
machine no X.509 certificate has been provided
and the client has been given the option of
proceeding on faith during first contact with a
particular server.
The above handshaking would be the same whether
the user had invoked the remote terminal (SSH) or
the file copy (SFTP) protocols. The client now
sends the SERVICE_REQUEST message, specifying
whether it wishes to proceed to client
authentication (in the case of SSH) or to file
transfer (SFTP). The server responds with
SERVICE_ACCEPT. Of course, these messages are
authenticated and encrypted, so are opaque to
eavesdroppers (such as you, using Ethereal in the
lab!)
31
(No Transcript)
32
There will be no authentication of the client
host machine proceed to authenticate the human
user.
33
SSH2, like SSL, is structured as a layered
software system. All of the above was provided
by the SSH Transport Layer, which is the lower
layer somewhat analogous to the SSL Record Layer.

Everything so far in SSH has been part of the
Transport Layer
The SSH user authentication protocol runs over
the transport layer, making use of the secure
channel that the transport layer has constructed.
5. User Authentication Three methods
? trusted hosts server lets client host
machine authenticate user
? user passwords not an appealing option!
? public-key authentication of user
34
Public-key Authentication of User
In advance, a copy of the users public key is
placed in the users home directory on the server
(slight problem how?)
To authenticate the user, the serve generates a
challenge, encrypts it with users public key and
sends it to client client decrypts the challenge
with users private key, hashes it and returns
hash to server, which checks the hash. Agreement
proves that client has users private key.
35
The public-key method of user authentication is
clearly superior to the password method. If you
somehow discover another persons password, the
door is wide open to you. But even if you
somehow discover another persons passphrase, it
is useless without the private key conversely if
you accidentally have access to somebodys
(encrypted) private key, it cannot be activated
without the passphrase.
The SSH documentation states that the server
automatically tries the authentication methods in
the order ?trusted-hosts ? user
public-key ? user password.
Thus, if public-key authentication fails, the
server should drop back and invite password
authentication. You should be able to see this
in the lab.
36
6. Port Forwarding Telnet passes textual
information between client and server. Although
we introduced SSH as a secure replacement for
telnet, once we have the secure channel
established between SSH client and server, we can
use it to carry any kind of data.
That is, SSH can be used to carry another
applications bidirectional data stream. SSH
intercepts the service request and carries it and
the response over the secure channel. The other
application must be configured to use the SSH
client as a proxy.
This is called port forwarding. In lab session
4 well see this for Web browser ? Web server
traffic.
37

Local Forwarding is where the two clients are
running on the same machine. Here, the browser
has been configured to use localhost2001 as
proxy the SSH forwards this port, via port 22
on the server, to port 80 on the server.
38
The full range of HTTP traffic (graphical, etc.)
will be carried across the channel a casual user
will not be aware that the direct connection was
not used.
39
End of SSH material