IC3 - Network Security

M.Sc. in Information Security Royal Holloway, University of London

1

IC3 - Network Security

Lecture 4 Introduction to Secure Protocols

2

CINS/F1-01

Objectives of Lecture

• • • • • Define what a secure protocol is.

Model the principals involved in secure protocols, and their capabilities.

Demonstrate how basic cryptographic mechanisms can be used to build entity authentication and key distribution protocols suited to insecure networks.

Appreciate how key distribution and entity authentication can be enabled using trusted third parties.

Describe the main features of the Kerberos protocol suite and outline its application in Windows 2000.

3

Contents

4.1

4.2

Secure protocols Entity Authentication and Key Agreement 4.3 Key Distribution via Trusted Third Parties 4.4 Kerberos 4

4.1 Secure Protocols

• • • • A protocol is a set of rules for exchanging

messages

between 2 (or more)

principals

over a network.

The word ‘protocol’ in the OSI model is reserved and refers to rules governing communication between a pair of

peer entities.

We’ll use it here in a more general way.

In this lecture, we largely leave unspecified the OSI layer at which our protocols operate.

– Lectures 5 and 6 will look at protocols for specific layers.

5

Secure

Protocols

• • So what is a

secure

protocol? When acting honestly,

principals

(participants) achieve the stated aim of the protocol (e.g. A successfully authenticates to B, or A and B exchange a fresh session key). Neither passive eavesdropper nor malicious, active adversary can defeat this objective (e.g. by successfully impersonating A in an authentication protocol with B).

6

The Principals – 1

• •

Alice

and

Bob

who wish to authenticate one another or to share a key.

In more complex protocols,

Trent

, a trusted third party who is trusted by both Alice and Bob – aka (depending on application) TTP, key distribution centre (KDC), certification authority (CA),….

– What Trent is trusted to do (and not do) depends on the protocol and application.

7

The Principals – 2

• • Two kinds of adversary:

Eve

, a passive eavesdropper (‘sniffs’ messages at will).

Mallory

, an active adversary, who can view, alter, delete, replay and inject messages into the network, initiate protocol ‘runs’, take on the role of any principal in any protcol ‘run’, … .

Warning 1

: ‘Alice’, ‘Bob’, etc are only semantic sugar: most protocols on networks don’t involve real people.

Warning 2:

We’ll freely mix up A for Alice and B for Bob, etc. 8

The Principals – 3

• • • • • • Mallory is

not

all-powerful: He cannot guess a random number chosen by another principal from a sufficiently large space.

He cannot invert a one-way hash function.

Without the correct key, he cannot obtain the plaintext for a given ciphertext. Nor can he compose ciphertexts for plaintexts of his choice.

He cannot sign messages without having the appropriate private key.

He cannot correctly compute a MAC on a message without knowing the correct secret key.

In summary: Mallory cannot break strong cryptographic mechanisms.

9

Summary So Far

• • So we equip Alice, Bob, Trent with strong cryptographic mechanisms to use on a completely untrusted network. The question then is:

How do we use these cryptographic mechanisms (signatures, public-key and symmetric key encryption, hash functions, MACs) to design secure protocols (providing security services)?

10

4.2 Entity Authentication

• • • • The OSI security architecture (ISO 7498-2) distinguishes between

origin authentication

(verifying origin of received data) and

entity authentication

(identity verification).

An origin authentication service can be built from a MAC.

Here we consider

entity

authentication, a basic security service in networks (Lecture 1).

Typically achieved by exchange of cryptographic messages called an

authentication protocol (authentication exchange in ISO 7498-2)

.

11

Definitions

• • •

Entity

authentication: – the corroboration that an entity is the one claimed

a particular point in time

(no guarantees after that

at

time).

Unilateral

authentication: – entity authentication which provides one entity with assurance of the other’s identity but not vice versa.

Mutual

authentication: – entity authentication which provides both entities with assurance of each other’s identity.

12

Basis for Authentication

• Suppose we want to design a protocol which authenticates Alice to Bob. Is the following secure?

A B: ‘Hi Bob, I’m Alice’ • No: Mallory can easily impersonate Alice in this protocol.

• So we need something stronger. • Authentication protocols can be built from the assumption that Alice and Bob share a key, or that Alice and Bob have authentic copies of each others’ public keys.

13

Strong Authentication

• • • In

strong

authentication, one entity ‘proves’ its identity to another by demonstrating knowledge of a secret known to be associated with that entity,

without revealing that secret itself during the protocol

.

Also called ‘challenge-response’ authentication.

Use cryptographic mechanisms to protect messages in protocol: – Encryption.

– Integrity mechanism (e.g. MAC).

– Digital signature.

14

Example: Passwords

• • Suppose Alice sends a password matching her user ID over the network, Bob compares to entry in password file.

Is this a

strong

authentication protocol?

– Password transmitted in clear over network, so may be sniffable by Mallory – hence

weak

authentication.

– Not suitable for use over open networks.

– For a

degree

of added security, transmit only hashed passwords – still vulnerable to dictionary attack (hash an entire dictionary word by word and compare to hashed password).

15

Encryption-based Unilateral Authentication

•

Assume

Alice (client) and Bob (server) share a secret key K.

•

Design goal:

Bob to authenticate Alice.

• • • • • Alice sends an initiating message.

Bob sends Alice a

challenge

message R.

Alice

responds

with {R || B} K , message R concatenated with B, encrypted using shared key K.

Bob checks that the message he received decrypts to give message R || B.

If it does, then Alice is authenticated to Bob (or

Bob authenticates Alice)

.

16

The Protocol

1.

2.

3.

A B: B A: A B: ‘Hi Bob, I’m Alice’ R {R || B} K (challenge) (response) (Here, {X} K means string X encrypted under key K, and || means concatenation of strings.) 17

Security of the Protocol – 1

1.

2.

1.

2.

Why can Bob be sure that message 3 in the protocol came from Alice?

Why can Bob be sure that message 3 in the protocol is not a replay of a message from an earlier run of the protocol between himself and Alice?

Only Alice (and Bob) know secret key K.

Bob chose R at random just before sending message 2. This R is

fresh

: it has never been used before. This means that message 3, which includes R in encrypted form, has never been produced before.

18

Security of the Protocol – 2

1.

2.

Why can Bob be sure that message 3 in the protocol is intended for him?

Can an attacker learn the value of secret key K by observing multiple runs of the protocol?

1.

2.

Alice includes Bob identity ‘B’ in the encrypted message. This prevents Mallory taking a message intended for Alice and sending it to Bob.

No, not if the encryption algorithm is strong.

19

Security of the Protocol – 3

1.

2.

3.

Is Alice authenticated to Bob in this protocol?

Is Bob authenticated to Alice in this protocol?

Is the protocol a mutual authentication or a unilateral authentication protocol?

1.

2.

3.

Yes.

No. (In fact Mallory could impersonate Bob in the protocol, but our

design goal

was a protocol in which Alice is authenticated, not Bob, so this is not a problem.) Unilateral: Alice to Bob.

20

A Replay Attack

• Suppose Mallory wants to impersonate Alice in this protocol: 1.

2.

3.

M(A) B: B M(A): M(A) B: ‘Hi Bob, I’m Alice’ R (challenge) ???

• • Now Mallory can’t prepare the correct response {R||B} K to Bob’s challenge because he doesn’t know the secret key K.

But what if Mallory could predict R? Then we can find a serious replay attack….

21

A Replay Attack

Mallory starts a protocol run, impersonating Bob to Alice: 1.

A M(B): ‘Hi Bob, I’m Alice’ 2.

M(B) A: R

(M predicts which R will be used later by B)

3.

A M(B): {R || B} K Mallory keeps hold of {R || B} K : it’s going to come in handy later.

1.

M(A) B: ‘Hi Bob, I’m Alice’ 2.

B M(A): R

(M predicted this R would be used by B)

3.

M(A) B: {R || B} K 22

Freshness and Liveness

• • • • The replay attack shows that it is vital that the protocol contains a means of checking

freshness

of messages and

liveness

of principals.

Freshness:

assurance that message has not been used previously and originated within an acceptably recent timeframe.

Liveness:

assurance that message sent by a principal within an acceptably recent timeframe. Two main methods for providing freshness: – Nonce (

N

umber used

once

).

– Time-stamps (clock-based or `logical’ time-stamps).

23

Nonces

• • • • • Nonce also known as

random challenge

.

In our protocol, we depend on B to make sure R is freshly generated.

Main property is ‘one-time’ property, so could in theory use a counter.

But many protocols need nonces to be unpredictable to Mallory. Generate at random from a large set (128 bits, say).

Notice that in our protocol, R, the nonce is unpredictable

but not secret

.

24

Time-stamps – 1

• • • Inclusion of date/time-stamp in message allows recipient to check it for freshness (as long as time-stamp protected by cryptographic means).

A B: ‘I’m Alice’, {T || B} K – a single message instead of three.

– Bob decrypts and checks that T is recent and that his identity is included.

– Only Alice knows K, so only Alice could have prepared this message. It’s fresh, so Alice is live.

But now we require securely synchronised clocks to prevent replay – non-trivial!

25

Time-stamps – 2

• • • Typical clock drift is 1s per day on work station.

So need a window of acceptance for Alice’s messages either side of Bob’s current clock time (clock drift + variable network propagation time).

Also need a log of recently received messages to prevent Mallory exploiting window with replay attack.

26

‘Logical’ Time-stamps

• • • • Alternative to clocks: Alice and Bob could use pair of sequence numbers N communications.

AB and N BA in their Every time A sends B a message she includes value N AB, and increments it. Likewise for B.

Needs pair of sequence numbers for every pair of communicating parties.

Sequence numbers may need to be kept secret in protocol runs: otherwise they become predictable to Mallory.

27

Using MACs for Entity Authentication

Replace encryption mechanism with a MAC: 1.

2.

A B: B A: ‘Hi Bob, I’m Alice’ R (challenge) 3.

A B: MAC K (R || B) (response) Can argue security as for encryption-based protocol: Only Alice can prepare correct response for Bob, freshness of R guarantees liveness of Alice.

What properties of the MAC did we use?

28

Signature-based Entity Authentication

• • • Instead of challenge/response, now challenge/signature.

Use nonces or time-stamps for freshness.

Rather than a shared secret key, Bob needs to have authenticated version of Alice’s public key (and vice-versa for mutual authentication). 29

Signature-based Mutual Authentication – Example

• • • 1.

2.

3.

B A: A B: B A: R B R A , S A {R A S B {R B || R A || R B || B} || A} Here, S A {X} denotes A’s signature on string X.

Protocol achieves mutual authentication (via two signatures and two nonces). A and B must of course check the signatures to ensure their correctness.

30

Using Digital Signatures

• • • • Alice and Bob have to be sure that they are verifying each other’s signatures.

Hence need for

trust

in authenticity of public keys instead of shared secrets.

Public keys can be

certified

by applying the digital signature of a Trusted Third Party (TTP) or Certificate Authority (CA).

Result (public key + entity name + expiry date + TTP signature on three items) called a

certificate

.

31

Using Certificates

• • • • To check a certificate signed by a TTP requires an authentic copy of the TTP’s public key.

If two entities have certificates signed by different TTPs, then a

cross-certificate

is needed (i.e. one TTP’s public verification key signed by the other TTP).

Leads to notion of

certification paths

and

public-key infrastructures

(PKIs).

Related protocols are used in SSL and IPSec (see Lectures 5 and 6).

32

Authenticated Key Establishment – 1

• • • • • • Entity authentication

only

achieved for an instant in time, typically provided at start of a connection/session.

Mallory could always hijack the connection after that point.

What if a secure

session

is needed?

– A combination of confidentiality, integrity, data origin authenticity for remainder of communications session.

Solution: agree

session keys

authentication protocol.

as part of the Then use those session keys in encryption and MAC mechanisms to build a secure session.

Bind the session keys to the entity auth. protocol run to get

authenticated key establishment (AKE)

protocol. 33

Authenticated Key Establishment – 2

• • • • • As a simple example, we can adapt our one message time-stamp based protocol: A B: {T || B} K simply by adding a session key SK in Alice’s message: A B: {T || B || SK} K Alice is authenticated to Bob and they now share session key SK.

Because SK is agreed as part of the entity auth. protocol, it is bound to that protocol run.

So Bob can be sure that only Alice knows SK.

Alice can be sure that only Bob

could

know SK: only Bob could decrypt the message to extract SK.

34

Authenticated Key Establishment – 3

Public-key encryption can also be used to create • • • • • authenticated session keys: Alice checks the authenticity of Bob’s public encryption key PK B using a certificate. A B: {SK} PKB Bob can obtain the session key SK by decrypting using his private key. Alice and Bob both use SK to derive encryption and MAC keys to protect their session.

Alice can be sure that only Bob could know the session key. 35

Authenticated Key Establishment – 4

• • • In this protocol, Alice is not authenticated (anyone can encrypt for Bob).

B is only

implicitly

authenticated to A: A is only assured he’s talking to B if messages in the subsequent session make sense (i.e. MAC and decrypt work properly with SK).

A (much) more complicated version of this protocol is an option in SSL (see Lecture 6).

36

ISO/IEC 9798

• • • ISO/IEC 9798, a multi-part standard (currently five parts published), specifies a variety of standard authentication protocols (and derived key establishment protocols).

Designed to be ‘generic’, i.e. suitable for most applications.

ISO/IEC 9798 protocols are robust: designed by experts who learned from mistakes of earlier designers.

37

More on Key Agreement

• • • • A session key can be established as a by-product of an authentication protocol. Here we start from the other end, and look at

key agreement protocols,

then we consider how to add authentication. The main protocol we study is the Diffie-Hellman Key Exchange (DHKE) protocol.

Scenario: – Alice and Bob don’t already share a key and can’t meet to do so. How can they make their future communications confidential?

38

Diffie-Hellman Key Exchange Set-up

• • • Alice and Bob agree on a large prime p (p has, say, 1024 bits) and a number g.

Alice chooses a random x and computes g x mod p.

Bob chooses a random y and computes g y mod p.

39

Diffie-Hellman Key Exchange

1.

2.

3.

4.

A B: g x B A: g y mod p mod p A computes (g y ) x mod p B computes (g x ) y mod p But (g x ) y = g xy = (g y ) x mod p. So A and B now share a common key g xy !

40

Diffie-Hellman and Eve

• • • • Eve sees only the public values, g x mod p and g y mod p.

But to get the key, Eve needs to compute g xy mod p.

If p and g are chosen properly, then this is a hard computational problem.

Then Diffie-Hellman key exchange protocol will be secure against Eve, a passive adversary.

41

Diffie-Hellman and Mallory

g x g a Alice x g b K 1 = A,M ( g b ) x = ( g x ) b Mallory a,b g y K 2 = M,B ( g a ) y = ( g y ) a Bob y 42

The Man-in-the-middle Attack

• • • • Alice thinks she has exchanged key K 1 Bob.

– Instead, it’s with Mallory.

with Bob thinks he has exchanged key K 2 – Instead, it’s with Mallory.

with Alice. Mallory can now – intercept all messages from A intended for to B, – decrypt them using K 1 , – read them, – re-encrypt them under K 2 – pass them on to B. and And vice-versa for messages from B to A.

43

What went wrong?

• • • Simply this: Alice and Bob exchanged a key without any performing any entity authentication. So keys were exchanged, but Alice and Bob have no guarantees about with whom their exchange took place!

So Diffie-Hellman key exchange protocol is not secure against Mallory, an active adversary.

44

Station-to-Station Protocol

• • • • The

station-to-station protocol

adds authentication (via signatures) to DHKE: 1.

2.

3.

A B: B A: A B: g x g y , {S B {g y , g x }} K {S A {g x , g y }} K After step 1, B can compute the shared key K. After step 2, so can A. The additional messages are encrypted signatures on everything fresh in the protocol run; these are intended to provide authentication and key

confirmation

. These signatures should be checked by A and B.

45

4.3 Key Distribution via TTPs

• • • Scenario: closed system (security domain) with n users, potentially n(n-1)/2 keys to allow all pairs to communicate securely with each other.

Could use public-key techniques with trust in keys based on certificates (see SSL example).

Alternatively, use a trusted third party called a

Key Distribution Centre

(KDC) who co-operates to enable users to authenticate one another and share session keys.

46

Keys and Trust

• • • • • Alice shares a long-term key K A,T Trent.

with KDC, Bob also shares a long-term key K B,T But Alice and Bob do

not

share a key.

with KDC.

Alice and Bob use KDC Trent to help them authenticate one another and agree a session key K. We have a

security domain

by Trent and all the clients: (or

realm

) formed

‘a system under the control of a single authority which the entities therein trust’

47

Application Scenarios

• • A corporate network, with KDC being a server managed by IT department (say).

Campus network: authentication controls access to different services (e-mail, printing, student records) located on the network – Now TTP is acting as an

authorization server

, granting access to services, rather than as a pure key distribution centre.

48

Needham-Schroeder Protocol

1

Trent (KDC)

2

Alice

1.

2.

3.

4.

5.

A T: A || B || N A T A: {N A || B || K || {K || A} KB,T } KA,T A B: {K || A} KB,T B A: {N B } K A B: {N B -1} K 3 4 5

Bob

49

Needham-Schroeder – Step by Step

• • In messages 1 and 2, Alice and Trent (the TTP) interact: Trent gives Alice a session key K and authenticates himself. In messages 3,4 and 5, the interaction is between Alice and Bob. Alice transfers an encrypted copy of the session key to Bob in message 3 and is authenticated to Bob in messages 4 and 5.

50

Security?

• • • • • T is authenticated by A and A is implicitly authenticated by T (recipient can only decrypt message 2 if he has the correct key K A,T ).

A is authenticated to B (challenge/response).

If key K is used for subsequent encryption or MACing, then we get implicit authentication of B to A (recipient of message 3 can only obtain K if he knows correct key K B,T ). Can make A,B authentication mutual by having A issue a challenge to B along with message 3.

Session key established: chosen by T, the KDC. 51

Advantages

• • • • • Key storage efficiency: only n keys to look after at KDC.

Only one long-term key per client (K A,T ) instead of n-1.

Only uses symmetric key cryptography.

Bob can be off-line in steps 1&2 because TTP doesn’t forward session key K directly to Bob: Alice relays it to Bob (step 3). So K can be cached by Alice and used later.

52

Disadvantages

• • • • KDC is a single point of failure – security and availability.

Potential computation/communication bottleneck at KDC.

How can we ensure clients look after their long term keys properly?

– If long-term key compromised, then entities can be impersonated.

Requirement for an on-line, trusted server.

– TTP knows all session keys and all long-term keys.

53

4.4 Kerberos

• • • • • Kerberos is a TTP-aided authentication protocol developed from Needham-Schroeder.

It’s also software implementing that protocol, currently Kerberos V5 Release 1.3.

– Version 4 (still?) widely used, no longer under development.

Also a project at MIT which devised the protocols (properly called Project Athena).

Also RFC 1510 – Kerberos V5 (1992).

A

version

of Kerberos exists in Windows 2000; Kerberos is integrated into many versions of Unix

.

54

Kerberos Principals

• •

Authentication Server

(AS) – mutual authentication with

client

at login based on

long-term key

, gives client

ticket granting ticket

and

short-term key.

– AS provides an authentication service.

Ticket Granting Server

(TGS) – mutual authentication with client based on short-term key and ticket granting ticket. TGS then issues

tickets

giving clients access to further

servers

.

– TGS provides an access control service.

55

Kerberos – Motivations

• • • • Separation of authentication and authorisation/access control (though AS and TGS usually implemented on same platform).

Differentiated control over lifetime of ticket granting tickets (typically 10 hours) and session tickets for actual access to services (typically 5 minutes).

A user only needs to use his long-term secret key once per 10 hour session, to establish short-term key and ticket granting ticket.

Once the short-term key is established (with TGS) the long-term secret key can be erased from the client host.

– Minimises risk of exposure of long-term secret key.

56

Kerberos Protocol

AS

(authentication server)

1

2

C

(client) 3

4 TGS

(ticket granting server)

5 6 S

(server) 57

Kerberos Phases

Phase 1

: In messages

1 and 2

, C and AS authenticate and set up short-term key and ticket granting ticket.

Phase 2

: In messages

3 and 4

, C and TGS authenticate and set up session keys and (session) ticket.

Phase 3

: In messaged

5 and 6

set up secure session.

, C and S use session key and ticket to authenticate and Phases 2 and 3 will usually be repeated many times for each execution of Phase 1.

58

Kerberos – Message Formats (Simplified)

1. C  AS: TGS||from||to||N C 2. AS  C:

{ K C,TGS ||C||from||to} KAS,TGS

|| {K C,TGS ||N C ||from||to||TGS} KAS,C (Note that the

first

part of message 2 is the

Ticket Granting Ticket

the TGS).

for 3. C  TGS: S||from||to||N’ C || {K C,TGS ||C||from||to} KAS,TGS 4. TGS  C:

{K C,S ||C||from||to} KTGS,S

|| {K C,S || N’ C || {C||T 1 } KC,TGS ||from||to||S} KC,TGS (Note that the

first

part in message 4 is the

Ticket

for the server S).

5. C  S: {K C,S ||C||from||to} KTGS,S 6. S  C : {T 2 } KC,S || {C||T 2 } KC,S 59

Keys Used in Kerberos

• • • K AS,TGS TGS.

is a long-term secret key shared by AS and K AS,C K TGS,S is a long-term secret key shared by AS and C.

is a long-term secret key shared by TGS and S.

– These keys need to be established in advance.

• • K C,TGS is a secret short-term key shared by C and TGS (established by messages 1 and 2).

K C,S is a secret session key shared by C and S (established by messages 3 and 4).

60

Entity Authentication in Kerberos

• • • • Entity authentications are achieved using a mixture of nonces and timestamps.

Methods are similar to ones used in Section 4.2 and in Needham-Schroeder protocol.

For example: AS is authenticated to C using challenge/response protocol based on encryption, shared key K AS,C messages 1 and 2.

and nonce N C in Other authentications: C and TGS; C and S.

61

Tickets in Kerberos

• • •

{K C,TGS ||C||from||to} KAS,TGS

– Is the

ticket granting ticket.

– Received by C in message 2 and sent to TGS in message 3. – only TGS can decrypt it to obtain short-term key

K C,TGS

validity period

from||to

.

and These parameters determine ticket given to C in message 4.

{K C,S ||C||from||to} KTGS,S

– Is the

(session) ticket.

– Received by C in message 4 and sent to S in message 5. – Only S can decrypt it to obtain session key

K C,S

period

from||to

.

and validity These parameters determine access given to C in subsequent session with server S.

These tickets are the equivalent of message 3 in Needham-Schroeder: {K || A} KB,T 62

Use of Cryptography in Kerberos

• • • • Kerberos uses symmetric encryption and MACs.

Specifically, Version 5 (as in RFC 1510) uses DES combined with one of MD4, MD5, or a CRC (not recommended).

Releases 1.2 and higher of Kerberos Version 5 allow triple DES (3DES) in CBC-mode.

Extensions supporting AES and other algorithms are under development – AES implemented but not fully enabled in Kerberos v5 release 1.3.

63

Kerberos Issues – 1

• • • •

Revocation

: ticket granting tickets valid until they expire, typically 10 hours. What if compromised?

Key management

: within realms (domains): long-term keys need to be established between AS and TGS, TGS and Servers and AS and clients.

Scalability

: authentication across realms is complicated.

Synchronous clocks

needed, protected against attacks. Caches of recent messages to protect against replay within clock skew. 64

Kerberos Issues – 2

• • • •

Availability

: need for on-line AS and TGS, trusted by clients not to eavesdrop.

Passwords

: Client-AS long-term key usually based on password entered by user at start of session – vulnerable to dictionary attacks.

Key storage

: Short-term keys and ticket granting tickets located on largely unprotected client hosts.

Denial of Service

: Potential for DoS attacks on clock service or on AS/TGS?

65

Windows 2000 Network Authentication

• • • Microsoft have adopted and extended Kerberos for network authentication in Windows 2000.

Supersedes Windows NTLM (unilateral authentication) in NT4.

One extension: – support for public-key encryption to protect client/AS messages (rather than password-based long-term key).

– allows use of authentication based on client smart cards.

66

Windows 2000 Network Authentication

• • • Second extension: – use of Kerberos data authorization field (normally empty) – transports Win2K access privileges – in the form of SIDs, derived from Active Directory – these are compared to ACLs of remote objects to make access decisions.

Message formats published, but proprietary to Microsoft.

Non-standard extension to Kerberos makes it difficult to interoperate Microsoft and non Microsoft implementations.

67

Lessons Learned?

• • • • • Designing protocols is easy.

But designing

secure

protocols is hard – there are many infamous failures in the literature.

Some good protocols are already standardised (e.g. ISO 9798, ITU T X.509, …) – use these rather than rolling your own!

The problem of verifying security gets harder as the protocols get more complex. Security weaknesses arise from errors in specification, implementation, side-channels, lack of user training, host insecurities, poor random number generation… 68