Skip to main content
Department of Information Technology

Identification and Authentication

  • Identification: announce who you are
  • Authentication: prove who you claim to be
    • Entity authentication: the process of verifying a claimed identity.

Identification sometimes enough (LISPM, ITS).

Authentication methods

  • Something you know
    like passwords, but more general - could be less secure (e.g. identifying someone over the phone, secret handshake). Steal your secret, steal your identity.
  • Something you hold
    e.g. physical key/card, uniform - often combined with something you know (PIN code)
  • Who you are
    e.g. photos, biometrics (fingerprints, voice, retina, etc). Problems: precision, imitation, privacy, security (retina). Usually low rate of false positives only if high rate of false negatives. Fingerprint devices still easily fooled.
  • What you do
    e.g. writing speed/pressure, key press intervals, etc. Similar principle, similar problems.
  • Where you are
    physical/logical location (login on console terminal, local network, GPS, etc). Usually combined with other methods

Passwords

Usual login procedure (userid+password). Note subtle difference: reject wrong userid vs userid+password.

Attacks:

  • guessing
  • spoofing (Trojan)
  • communication interception
  • object reuse
  • compromising password file
  • social engineering
(See figure 1.1, page 12)
2.1. Guessing
  • brute force (exhaustive search)
    up to a certain length - consider different character groups (lowercase a-z, 0-9, uppercase, shifted digits...)
  • heuristics (intelligent search)
    • using knowledge about the person - cat's name, girlfriends, parents, children, car, work... (see Wargames)
    • using dictionaries and other word lists - enormous amounts available
    • plus permutations etc (reverse, remove single letters, replace 1 for L, 0 for o, etc)

2.1.1. Example: Crack @ DoCS

To pre-empt crackers, a password-cracking program was run at night at the department machines (distributed over 150 machines). The tests were (e.g.)

  1. brute force up to 6 characters
  2. use word lists:
    • reversed, substitute (e.g. 1 for L, 0 for o), prefix (beginnings), suffix (ends)
      e.g. "simon" -> "s1mon", "sim0n", "simon1" "1simon", "nomis1", "n0mis"
    • Swahili, Yiddish, Swedish, Denish, Norwegian, German, Japanese, Dutch, Italian, Spanish, Finnish, Czech, Hungarian, Polish, Turkish, Gaelic, Chinese...
    • Names: rock groups, micro algae, asteroids, bacteria, from comic strip, movies, TV, litterature,
    • Words and phrases from song texts, bible, koran, nordic mythology, Tolkien, Star Trek...

(Worked well with old encryption scheme and max password length.)

2.2. Protection

2.2.1. Guessing

Simple rules:

  1. Set a password! (even in Windows)
  2. Change default passwords (do you have examples? TOPS-20.)
  3. Use long passwords (Unix no longer limited to max 8)
  4. Use mixed character groups (not only lowercase a-z)
  5. Use strong passwords (avoid "Crack" - see http://www.stack.nl/~galactus/remailers/passphrase-faq.html, http://www.unix-ag.uni-kl.de/~conrad/krypto/passphrase-faq.html)
  6. Don't tell/show anyone your password! And don't write it down!

Investigation (1979):

Distribution of 3289 passwords
0.5% 1-letter
2% 2-letter
14% 3-letter
14% 4-letter
22% 5-letter same case
19% 6-letter lowercase
15% from dictionaries or word lists
14% "good" passwords

Online bank 2002:

50% family member's names:
23% children
19% spouse/partner
9% own name
8% pet name
9% celebrities
9% football players

System features:

  • Password checks when changing ("mini-Crack")
  • Password generation - random but pronounceable (but easier to break!)
  • Password ageing - force users to change passwords every n months
  • Limit login attempts - max number of failed attempts locks account
    cf. bank teller machines - lock/disable after three failed attempts
  • Inform user of failed attempts since last successful

Problems:

  • Gollman's "Fundamental dilemma of computer security":
    security-unaware users have specific security requirements but usually no security expertise
    Users need security but don't know what it is! or how to handle it.
  • Security mechanisms must be easy to use and manage, otherwise people use work-arounds or mis-manage them!
  • Random passwords are hard to remember - people write them down, or change them to easy-to-guess ones. Cf. PIN codes.
  • Password ageing can be worked-around by changing back to "your favourite password"

Password ageing: example of Principle of Adequate Protection:

Information must be protected only until it loses its value, and to a degree consistent with its value.

Password should not possibly be cracked until it's changed again.

2.2.2. Protecting against Trojan logins:

Note that usual userid+password authentication only authenticates the user to the system, not the system to the user (unilateral authentication).

  • Display number of failed logins (weak!)
  • Ctrl-Alt-Delete: "secure attention sequence" of Windows NT/2000/XP
    but can be faked outside Windows, of course
  • Mutual authentication: not only user authentication, but also system authentication
    e.g. web servers

2.2.3. Object reuse

Passwords stored in temporary buffers, caches, etc.

Example: web caches

2.3. Password protection

Password lists need protection, of course.

  • Old systems: access control of pw lists by operating system
  • Less old systems: (one-way) encrypted passwords
  • Better/newer systems: combine both

One-way encryption uses a one-way function:

f(x) easy to compute, its inverse very hard to compute (given f(x))
  • Illusional consequence: noone can retrieve your password (e.g. if you forget it).
  • Real consequence: f(x) has collisions, i.e., f(x) = f(y) for some x different from y, but given f(x) is is (should be) very hard to find y
  • Passwords: usually not that many - use dictionary attack ("Crack")

Unix traditionally stored all encrypted passwords readable by all (/etc/passwd). Dictionary attack possible: encrypt guesses, compare with all stored encrypted passwords.

  • Counter-measure: use "salt" s, compute c=f(s+pwd), store s+c. To check, compute c1=f(s+pw1), compare with c1.
  • Consequence: same password has different stored values, and a dictionary attack must compute, for each word, f(s+word) for all values of s.
  • Unix traditionally used a 12-bit salt, max 8 chars in password, and fast encryption algorithm - dictionary attack useful
  • Recently: use 48-bit salt, longer passwords (at least 80 chars), and slower encryption algorithm (MD5) - wide dictionary attack not useful (but targeted may be)

Unix nowadays: encrypted passwords stored in (/etc/shadow) with access control. Less risk of dictionary attack.

Windows NT/XP: encrypted passwords (one-way or decryptable) stored in proprietary format - tools were developed to decode proprietary format, but still encrypted.

One-time passwords

E.g. online banking.

  • List of passwords (to be used once, in order)
  • Challenge-response systems: system sends a challenge, user computes a function and returns result.
    • security by obscurity (secret function)
    • cryptographic function (code calculator with internal tamper-proof key)
    • challenge (and thus response) only valid for limited time
    • variant: time-based random number generator

Single sign-on

"Security mechanisms should be easy to use" - instead of entering n passwords for n logins/access checks, use one login. Variants:

  • Web browser stores site passwords
  • .NET Passport
  • Kerberos tickets
  • ssh-agent in Unix

As safe as the single authentication. In all cases, the password/s must be protected. Web browser should password-protect its stored passwords (cf "Security level" in Explorer), others typically use certificates.
Note that it suffices to break one password.

How hard to crack?

At door 1, the staff all use the same 4-digit door code.
At door 2, the staff have individual 5-digit door codes.
At door 3, the staff have individual 4-digit codes for individual keypads.

Which is harder to get into? (Without using a crowbar.)

Updated  2006-08-29 16:53:45 by Björn Victor.