Dr. Mark Humphrys

School of Computing. Dublin City University.

Online coding site: Ancient Brain

coders   JavaScript worlds

Search:

Free AI exercises


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 code).
For 1. we have login protection, plus 2. to restrict what they can do when they get in.

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 web scripting off. Never open attachments. Never use pirated games or other software. Be careful what freeware you download.




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 more secure. But nothing beats passwords' convenience - no special hardware. Can ssh 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.
Assign random password:
 qrfg34rX
Secure - can't be guessed.
Insecure - user writes it down.

Allow user change it:

 Fido
Secure - In user's head, not written down.
Insecure - Can be guessed.

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:

  1. ftp scripts
  2. ssh client Preferences




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

pa = attempt at password, ea = encryption of that, where   ea = f(pa,e)  

If pa = p, then ea = 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) = fp(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";

At login, given plain text attempt, recover stored encrypted password and process login:

 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 a computer system has an 8 digit, mixed-case, alphanumeric password, how many possible passwords are there?
A. 628

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?


Q. If the computer password is not random but is a lowercase dictionary word, how long will it take the intruder to guess it? (There are 45,000 words in a small English dictionary.)
A. 45 seconds.




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.



ancientbrain.com      w2mind.org      humphrysfamilytree.com

On the Internet since 1987.      New 250 G VPS server.

Note: Links on this site to user-generated content like Wikipedia are highlighted in red as possibly unreliable. My view is that such links are highly useful but flawed.