School of Computing. Dublin City University.
On a shared machine with multiple users and network access, we need to protect process memory spaces and user file spaces from:
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.
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?
qrfg34rXSecure - can't be guessed.
Allow user change it:
FidoSecure - In user's head, not written down.
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:
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
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)
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?
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.)
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),
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.