System and Network Administration

lecture in color

Problem: user authenticity

are users who they say they are?
are the people doing things authorized to do so?

Two parts to administering user rights

authentication: who is the user?
authorization: what should this user be able to do?

Risk:

passwords sent in clear text can be snooped (captured).
This makes you susceptible to replay attacks in which a cracker simply plays back your username and password.
crackers can use this to get access to normal or even root accounts
can use these accounts to:
- impersonate users
- send spam
- harass others
- obtain further account privileges.

Clear-text passwords must die!

Too easy to snoop.
Getting shell access gives hackers too much power.

Approach: One-Time Passwords (OTP)

each password is used ONLY ONCE.
if you sniff it, this tells you nothing.
so you can utilize clear channels and no one's the wiser.

OPIE: One-Time Passwords in Everything.

replaces:
- /bin/su: switch-user command.
- /bin/login: login program type Username and Password.
- /usr/sbin/in.ftpd: ftp daemon. with special versions that understand one-time passwords.
backward compatible with:
- normal /bin/login
- Predecessor S/Key: uses same encryption and clients.

Idea of OPIE and S/Key (its predecessor)

write a function that's difficult to reverse
- Given A, easy to get F(A),
- Given F(A), difficult to get A.
- this is called a trapdoor function.
each user initializes the process by providing a password to a calculator on a local machine.
This password is hashed by calling F on it 100 times repeatedly. E.g.: s = F(F(F(F(...100 times...(F(F(p))...))))=F^100(p)
OPIE stores this value and the number of times F was applied.
When a user wants access, OPIE asks the user for the result of the 99th application of F, say q.
if F(q) = s, then the user is real, and we
- store q as the new s,
- decrease the count to 99,
- repeat next challenge with new s and 99.

The big deal

F is difficult to reverse.
So having F^99(p) won't get you p, or even F^98(p).
But if you know F^99(p), you can check whether F^98(p) is authentic!
If it is, you can store F^98(p) and the next time, check it against F^97(p).

Inside OPIE

OPIE's trapdoor function is the MD5 hash function (of your passphrase).
MD5 is a cryptographically secure hash function (designed by Rivest, the 'R' in RSA). This means that:
- It's easy to compute.
- Given different A and B, it is very unlikely that MD5(A) will equal MD5(B).
- Computing A from MD5(A) is computationally intractable.

Very clever OPIE features

opie one-time passwords are actually 128 bit HEX numbers, e.g., dd363c5a2b90bb985d4dbeffd7c1b21f.
OPIE observes that these are easiest to type if they're mapped into sequences of six two-to-four letter words! It uses a dictionary to do this.
So your 'passphrase' is a sequence of 6 words!
You can ask OPIE to precompute all your passphrases so you can print the list and take it with you.

Using OPIE:

opiepasswd - start up opie

 # ./opiepasswd -c couch
 Adding couch:
 Only use this method from the console; NEVER from remote. If you are using
 telnet, xterm, or a dial-in, type ^C now or exit with no password.
 Then run opiepasswd without the -c parameter.
 Using MD5 to compute responses.
 Enter new secret pass phrase: 
 Again new secret pass phrase: 
 ID couch OTP key is 499 bl2366
 SOB TURN FORM GORE NOT CUFF

opiesu - switch user ID

 blackhole{couch}64: opiesu couch
 otp-md5 498 bl2366
 couch's response: YARN ORB TEET MAE TOM GAIT

opiekey - compute a passphrase to be used in opiesu, opielogin.

 blackhole{couch}72: otp-md5 498 bl2366
 Using the MD5 algorithm to compute response.
 Reminder: Don't use opiekey from telnet or dial-in sessions.
 Enter secret pass phrase: 
 YARN ORB TEET MAE TOM GAIT

OPIE limits

each host has separate database
no concept of network-wide authentication
still susceptible to replay attacks if you use same passphrase and random number seed on two hosts!
limited to 500 insecure logins before you have to renew your passphrase.

Very Clever: how to 'renew' your opie password

login through an insecure host.
have an OPIE calculator in hand, but not on the insecure or target host.
Do an opiepasswd on the target host.
It issues a new challenge.
You calculate the response and type it.
This re-initializes the process!

Hosts.equiv and .rhosts

hosts.equiv: tells which hosts have the same users as you.
.rhosts: personal file of hosts and accounts equivalent to you.
If you have the same account name on another machine, and if your machine is listed in /etc/hosts.equiv on the other machine, then you can rsh or rlogin to that machine without password.
Good news: under UNIX only root can initiate a request for this service, so users can't spoof it.
Bad news: under MS/DOS and NT, users can spoof requests by supplying fake usernames!

SSH

session encrypted using public-key technology.
This includes password.
No snooping possible unless you can break the code.

Basics of Public-key cryptosystems (RSA)

public key: something you broadcast to everyone.
private key: something only you know.
both 48-bit or 128-bit integers.
symmetry of use:
- anything encrypted with your public key can only be decrypted with your private key.
- anything encrypted with your private key can only be decrypted with your public key.

Sending secure messages

If you want to send something to another group, and make sure that only the intended target can read it, then
Get their public key.
Encrypt it with their public key,
Send it to the them.
They decrypt it with their private key.

Providing proof of authenticity

If you want to prove that something's from you.
Encrypt it with your private key,
publish your public key.
Users can decrypt it only with your public key.
Others can't provide anything your public key decrypts!

Doubly-secure transaction assures both authenticity and privacy

 source doc from you 
    |
    | encrypt with sender's private key (only sender knows) 
    v
 encrypted once to prove authenticity
    |
    | encrypt with recipient's public key (published everywhere) 
    v
 encrypted twice to protect content
   ...
   ...send on internet
   ...
 encrypted twice to protect content
    |
    | decrypt with recipient's private key (only recipient knows) 
    v
 encrypted once to prove authenticity
    |
    | decrypt with sender's public key  (published everywhere) 
    v
 source doc to recipient

Applying Public-key technology to encrypting sessions.

Give every host a public/private key pair.
Private keys are important so they're large (128 bits)
This is too expensive for constant use.
Solution: create a 'session key' that is used just for one session.

Exchange session keys using host keys for initial encryption.

 starting up an ssl/ssh session (sketch) 
  client                                server
                                        
  accept server public key (clear)  <-- send public key to client
  generate 48-bit client session 
    public/private key pair
  encrypt client public session key 
    with server public key 
  send encrypted public session key --> decrypt client public session key 
                                          with server private key
                                        generate 48-bit server session 
                                          public/private key pair
                                        encrypt public server session key 
                                          with client public session key
  decrypt server session key        <-- send public server session key
    with client private session key

At this point (without ever sending an un-encrypted message) we have the following situation:

  client:                                server:
  private client session key             private server session key
  public server session key              public client session key

client-to server:
- client encrypts with private client session key
- server decrypts with public client session key
server-to-client
- server encrypts with private server session key
- client decrypts with public server session key

Ssh limits

requires custom client software -- can't just utilize telnet.
requires custom server software.
costs big $ for commercial users.

Ssh vulnerabilities

ssh still assumes that 'client' and 'server' are relatively secure themselves.
If you can get a server private key, you can impersonate the server.
How to crack ssh (man-in-the-middle attack)
- compromise a router close to the targeted host.
- steal the ssh private key for a server.
- redirect client request packets at a fake ssh host you create, running in promiscuous mode.
- use your fake host as a proxy; send all packets from there to the real host.
- snoop on ssh session, determine keys, sniff user password, etc.
If you have the user's real password, you can impersonate them without a trace.

Kerberos

basic assumption: all servers and clients are insecure.
strategy: direct all authentication requests to a more secure server that you protect galliantly.

Kerberos operation

user uses 'klogin' to initiate a key exchange with a secure Kerberos authentication server (similar to ssh key exchange above).
As a result of key exchange, user receives a 'ticket-granting-ticket'.
When a user requests service, each request sent to a secure authorization server includes the ticket-granting-ticket.
If the ticket-granting-ticket is OK, the authorization server responds with a true ticket for the service.
real servers accept the true ticket as proof of authenticity.

Kerberos limits

must run extra servers.
can't run anything else on them.
must run redundant servers in case things go down.