Security

On a shared machine with multiple users and network access, we need to protect process memory spaces and user file spaces from:

1. Hostile break-in by malicious external users.
2. Malicious users on our own system (unlikely, but possible in some situations).
3. Non-malicious but incompetent users (e.g. accidentally sending commands, writing scripts or programs that will in effect delete system files or other users' files).
4. Competent users running incompetent (buggy) programs.
5. Competent users running malicious programs by mistake (email attachments, viruses, trojans, malicious Web applets).

For 2. we have strict file protection and process protection.

For 3. how could you be so incompetent as to try to delete other people's files? Easy - especially if you write scripts to delete stuff and accidentally run them when you are in the wrong directory.

For 4. bug may overflow memory and do anything by accident.

For 5. browse with Java, Javascript, Active-X off. Never open attachments. Never use pirated games or other software. Be careful what freeware you download.

Network break-ins

SATAN, a program that scans systems for security holes, is freely available on the Internet. Is this a good or a bad thing?

In general it is probably good for sysadmins to get ahead of the curve rather than play catch-up.

Yet it still provides tools to attack sysadmins who aren't paying attention. What the on-the-ball sysadmins could do is scan other people's systems and let them know - be Good Samaritans.

Passwords

In some ways surprising that these are still the main way we do access security (always have been). Many problems with them. e.g. Iris recognition much better. But nothing beats passwords' convenience - no special hardware. Can telnet from anywhere.

Which of the following is the least secure password policy?

1. Allow users keep the same password forever.
2. Force users to change their password every month.
3. Don't allow the users change their password, but give them a new random password every month.
4. Don't allow the users change their password, but give them a new random password every week.

 qrfg34rX

Allow user change it:

 Fido

Force user to change every month?
User develops defence mechanisms.
User might change perfectly good secure password to insecure.

Other insecurities - user builds password into ftp Preferences etc.

Passwords on UNIX

  plain text -> encrypted text  
Encrypted text stored in   /etc/passwd  
Plain text not stored on the system. If you forget your password, sysadmin can't tell you it. All he/she can do is assign you a new one.

Let p = plain text password, e = encrypted version,   e = f(p,s)   where s is some random string

p_a = attempt at password, e_a = encryption of that, where   e_a = f(p_a,e)  

If p_a = p, then e_a = e

i.e. f(p,e) = e
i.e. f has the property that:   f(p,f(p,s)) = f(p,s)   for any random string s, and also that given f(p,s), there is no practical way of calculating p.

Note that f(p,f(p,f(p,s))) = f(p,f(p,s)) = f(p,s) etc.
In general, let F(x) = f_p(x) = f(p,x)
Then F(F(s)) = F(s)
but given F(s) and not knowing s, you cannot calculate p.

View it as a search problem. Find p such that:
crypt(p,e) = e

C++ sample code

Given plain text, store encrypted text:

  #include <crypt.h>

  for ( j=0; j<=1; j++ )
   salt[j] = randomChar();

  char * e = crypt ( p, salt );

  file << e << "\n";

 e_a = crypt ( p_a, e );

 if ( strcmp ( e_a, e ) )
  (refuse login, exit)

Guessing Passwords

OK there is no straightforward way to calculate the plain text from the encrypted.
Q. Could you just guess passwords until you got in?
A. No, if they are random strings.
A. Maybe, if they are dictionary words. The following will illustrate this.

Q. If an intruder can guess 1 random password every millisecond, how long will it take before he is guaranteed to guess our password?
A. 7000 years.

Q. If an ATM (bank machine) password is 4 random numeric digits, how long would it take to guess?
A. 10 seconds.

Q. If it is so easy to guess, what extra protection does an ATM account have?

Password Cracking

Hacker might try passwords repeatedly until gets in. e.g. Run program to try all dictionary words.
Q. What could stop him doing this?

A. Time delays. Also, more than n login failures and alarm bells ring / account is disabled (until user contacts sysadmin by phone). Run automated suspicious-activity-spotter. Compare with usual pattern of activity. Login from unusual locations or times or while user on holiday.

In UNIX, given encrypted text, you can't calculate plain text. So OK,   /etc/passwd   can be readable! The idea is that if security depends on the password data file being secret, system is not very secure. If it leaks out, everyone's password can be cracked. So instead we have a system where password file can be readable.

Problem then is people take   /etc/passwd   home, and run password guessing in privacy on their PC, with no login alarm bells, no suspicious-activity-monitors. Not hard to crack if there are any dictionary words.

So on modern UNIX (e.g. at DCU),   /etc/passwd   is hidden again.
This is only first line of defence though. The real defence is to make sure there are no dictionary or easy-to-guess words. How? Don't allow users change password? Check password at moment when they try to change it?

Many sysadmins now agree that best way to check security is to run their own, authorised, password-guessing programs regularly, and notify any accounts they are able to crack.

Cryptography - Secret algorithms are not secure

Funny enough, a system whose security relies on the algorithms by which it is implemented being secret is not regarded as secure at all.

• Good algorithms like one-way encryption are rare and hard to invent. There are not many of them, and the cryptographic community is probably aware of your one. Keeping a branch of mathematics secret is impossible! (Many sci-fi plots fail to realise this.)

• Keeping algorithms secret is hard! - If a new algorithm is invented, many people world-wide have to keep the secret, and it can't be changed to a new secret once it gets out.

• Furthermore, publishing means that other academics can go to work looking for vulnerabilities in the algorithm. If they can't find any, it's really secure.

• Unpublished algorithms are untested.

Similar philosophy with open-source UNIX / Linux. These are probably more stable because they have been thoroughly debugged over the years by a community in open discussion.

If it's private (Windows), who knows why it crashes. Only a small group of people have checked it, and none of them are detached or objective. They all work for 1 company. Who knows what they have put into it. We just have to trust them.

Viruses

Written by human (in the sense that a cruel bully is a human).
Code embedded in something apparently useful - .exe, screensaver, movie, game, document (macro virus).
Recall Dual Mode and Viruses on Windows v. UNIX.
Virus detection - Look for signatures. Need constant updates over Net.

Will viruses always be with us?

Hard to say. Maybe they were a relic of an age when progs could do anything. In future, we download "game" and it can only do what games can do. We download "screensaver" and it can only do what screensavers can do. (at least, without prompting us if it wants to do more).

As for the motivation to write viruses - yes, human nature doesn't change. Frustrated wasters who nobody admires will always be with us. Cruel bullies will always be with us. So railway grafitti, litter, burnt-out cars, computer viruses and smashed phone boxes will be too.