Intro To Secure Comm' Exercise 7

1
Intro To Secure Comm.Exercise 7
2
Guessing passwords

• Andersons formula P gt TG/N
• P Probability password is guessed in a unit of
  time.
• T Number of time units attacker can guess.
• G Number of guesses that can be tested in a
  single time unit.
• N Number of possible passwords.

3
Example stolen VISA

• Assume ATMs dont swallow cards until it is
  reported as stolen.
• Assume driving from ATM to ATM
• Time unit 30 minutes
• T 48 (24 hours before card is reported)
• G 3
• N 104 (4 digits code)
• P gt 483/104 1.4

4
Password Security A Case History Morris
Thompson79

• In a collection of 3,289 passwords gathered
• from many users over a long period of time
• 15 were a single ASCII character
• 72 were strings of two ASCII characters
• 464 were strings of three ASCII characters
• 477 were string of four alphanumerics
• 706 were five letters, all upper-case or all
  lower-case
• 605 were six letters, all lower-case.
• An additional 492 passwords appeared in various
  available dictionaries, name lists, and the like.
  
• A total of 2,831, or 86 of this sample of
  passwords fell
• into one of these classes.

5
Password security example

• The following is a a design of a password scheme
• for a version of an old Unix implementation
• Since users dont choose good passwordsthe
  system will choose a random password for them.
• The password will be chosen from 26 letters, and
  will have length of 10 (2610 247)
• The password generation itself would be based on
  a pseudo-random generator whose seed is
  HHMMSSLL

6
Password security example

• Quite bad design
• Password space 2610 247 whichis ok (for
  an old unix implementation).
• However, the number of seeds for PRF is
  246060100 223
• Only 223 values are possible in the
• passwords space.

7
Checking passwords

• Suppose we have a system with N users and D is
  the size of the password space.
• System stores a hash of the password, and
  compares hashes upon entry
• The expected number of passwords we would have to
  check to break into a given account is D/2
• However, we may do the followingSystematically
  go over all possible passwords.For each
  password, go over the system passwords file, and
  check for a match.Since we have N users, the
  expected number of passwords we have to traverse
  is D/(N1)

8
Dictionary attack

• In the previous slide wed assumed passwords are
  uniformly distributed.
• This is not true for human-chosen passwords.
• The D/(N1) is the maximum - dictionaries,
  exists, which lists the common objects and their
  combinations, allow much faster attacks.
• Some common objects can be seen back at the
  Morris Thompson79 slide.

9
Salt

• To prevent a systematic search over the passwords
  space, we will employ salt
• When the user chooses a password, the system
  generates a random number, salt.
• The password file stores H(f(salt,x)),salt,f
• Why this prevents the systematic search for all
  users passwords ?

10
Problem

• You wish for your users to access a remote server
  via user and password.
• All of the users have modems and you trust the
  phone company to have secured phone lines (no
  eaves dropping on the line).
• All the users must use good passwords.
• What is a good password?
• What is the problem with good passwords?
• How can you build a device that can help the
  user?Hint the device may generate the passwords

11
Solution

• A good password is one that is immune to common
  dictionary-attacks, and is pseudo random
• Good passwords are hard to remember so users tend
  to write them down
• The device may be
• PRFK(USERDATETIME)
• MD5(KUSERDATETIME)

12
Problem

• You wish your users to login to a remote computer
• You wish that ADV getting hold of that computer
  wont be able to retrieve the stored passwords
  easily
• What method would you use to store the passwords?

13
Solution

• The simplest solution would be to store a hash of
  the passwords.

14
Problem

• What hash attributes do we require for this
  scheme?

15
Solution

• We would like OWF
• So that ADV cant efficiently find a pre image
  for our passwords
• We would like CRHF
• So that ADV cant efficiently find a collision to
  our password

16
Problem

• Authentication possibilities
• Something You know
• Something You have
• Something You are
• Give examples for the above
• What may be the problems?

17
Solution Something you know

• Password/secrets are things you suppose to know
  and no other
• The cost is minimal, however we usually choose
  intuitive things to know.
• When secrets are not intuitive we tend to forget
  them/write them down so we dont forget them.

18
Solution Something you have

• Usually smart cards are things we have and no one
  else.
• Problems are higher cost
• We tend to forget the devices if they are small
• We tend not to use them if they are big
• They may be stolen, and then what?

19
Solution Something you are

• Biometrics is a common way to identify a person
  (eye, finger print )
• Costs a lot (smart devices, training time)
• May not have high precision, i.e. long retries,
  forgeries

20
Suggested solution

• Hybrid approach
• A small device which incorporates a PIN or a
  password to operate
• Something like a SecureID device, Portable phone
  with a key

21
Definitions

• Clients want to ensure that only authorized
  people can access and modify personal information
  they share on a web site.
• Web sites want to ensure that only authorized
  users have access to the services and content it
  provides.
• Client Authentication addresses the needs of both
  parties

22
Problem

• Remember the ways of authentication
• Things you know
• Things you have
• Things you are
• Which of them are more applicable when using the
  internet. (Why?)

23
Solution

• When using the internet, client side applications
  tend to be very simple.
• As such, Things you know is the main
  possibility for authentication.
• Few users will install a smart-card reader or any
  biometric equipment
• Few services will justify the cost and
  inconvenience of devices

24
Problem

• The HTTP protocol is stateless, i.e. may use
  client computation for saving state or doing
  security related computations.
• What are the common technologies via the web
  which help client-side computations (other than
  normal HTTP processing)
• What may be the problems with these technologies?
• What may be the problems of client authentication
  schemes based on these technologies?
• What is the most widely deployed mechanism for
  maintaining client state?

25
Solution

• There are many client side technologies
• Flash, Shockwave, java-script, java, activeX
• Some of the technologies are not cross platform,
  some are not even cross-browser.
• i.e. compatibility issues are a main problem.
• Some technologies may not provide suitable
  authentication.
• Mostly scripting languages which can be easily
  altered/viewed
• The most widely deployed mechanism is the cookie
  mechanism

26
Intro To Secure Comm.Exercise 8
27
What are cookies

• A server can store key/value pairs on a client.
• The client sends previously set cookies to the
  server.

28
(No Transcript)
29
(No Transcript)
30
More On Cookies

• Cookies are client-side data which is usually
  used to identify server based sessions.
• Server based sessions are a kind of state a
  server process is in.
• Cookies play an important role in authentication
  of users as well as other session based roles.
• When a user uses a session based server service,
  he needs to upload the cookie to identify
  himself.

31
Problem

• In a model of spoofing adversary and intercepting
  adversary, which adversary may break the cookie
  scheme?

32
Solution

• The intercepting adversary may break the cookie
  scheme.
• This is due to the fact he may do a replay attack
  when intercepting the cookies.
• Spoofing adversary may not if the cookie is used
  properly.
• How can one protect even against intercepting
  adversary?

33
Solution (2)

• It is preferred to use SSL sessions for initial
  login (user/password).
• It is preferred to send cookies and other
  authentication data over SSL sessions.
• Since SSL does not preserve server state across
  sessions, It is preferred to use cookies rather
  than just SSL sessions.

34
Why use cookies rather than just SSL sessions

• SSL sessions provide the ability for a clients
  authentication (either based on user/password or
  client Certs).
• We do not wish for our client to send his login
  credentials over and over again, this is why we
  use cookies in conjunction with SSL
• Cookies can only store credentials.
• Cookies are PASSIVE.
• Cookies may be used for single sign-on process.
• The can be transmitted cross SSL sessions, i.e.
  cross many connections to many different servers.

35
The interrogative ADV

• Can make a reasonable number of queries of a web
  server.
• It can adaptively choose its next query based on
  the answer to a previous query.
• The ADV can generate queries but not sniff the
  network.

36
Comparison of adversaries

• Interrogative Adversary
• Weakest adversary
• Only able to send packets from his own ip address
• Spoofing Adversary
• Able to inject packets (with arbitrary IP source
  address)
• Not able to capture cookies (even w/o SSL)
• Intercepting Adversary
• Able to listen to the network and to inject
  messages
• Not able to break SSL authentication

37
Comparison of adversaries

• Active adversary
• Able to listen to the network
• Able to modify network traffic
• Able to disguise himself as a host
• Usually, In case cookies are incorporated with
  SSL, and cookies are protected, not able to break
  the authentication
• In case cookies are not incorporated in SSL, may
  break authentication
• if cookies dont use cryptography as a basis for
  authentication
• If cookies rely on SSL to provide secrecy
• If protocol relies on SSL to provide
  authentication

38
Types of forgeries

• Existential forgery ADV can forge an
  authenticator for at least one user
• Selective forgery ADV can forge an
  authenticator for a particular user
• Total break ADV can recover the secret key used
  for all authenticators

39
Problem

• Consider the following authentication scheme
• When a user is authenticated, the information is
  stored in a cookie using unix crypt function
• h(UserServerSecret)
• Define a simple selective forgery attack on such
  an authenticator scheme.
• Suggest a simple solution

40
Solution

• Obviously the intended hash function was supposed
  to be some kind of MAC.
• Instead of a key, the company appended
  serverSecret to the input.
• In case hash function truncates some of the
  input, many similar inputs would yield forgeries.
• H(abc12)abF54x
• H(abcd345)abF54x
• May lead to serverSecret break.

41
(No Transcript)
42
Extending the former

• Cookies for WSJ.com

43
Problem

• A vendor wishes to incorporate the following
• Upon any login/change the vendor updates the
  cookie
• Cookie(SessionTimeItemPrice)
• What kind of attacks may be done?
• What kind of attackers may do it?
• How does SSL help protect against certain
  attacks/adversaries?

44
Solution

• The interrogative adversary may easily change the
  cookie.
• The attacks may be
• extending the session time indefinitely
• Changing products prices
• SSL may prevent sniffing/active adversaries from
  intercepting the cookies and/or changing them
  while theyre transmitted

45
Problem

• The following is a cookie based login process
• User
• Login to server, provide user/password
• Server
• Set Cookie(usernameh(password))
• The login process is protected with SSL.
• The rest sessions are not.
• Against what types of adversaries is this scheme
  effective?

46
Solution

• This scheme is immune to spoofing attacks, as no
  spoofer can generate the cookie
• This scheme is immune to sniffing attacks as the
  secret is not sent in the clear.
• However, active adversaries may do replay attacks
  after the initial login.
• How may you defend against active adversaries?

47
Solution (2)

• The simplest thing would be to protect the entire
  client-server protocol using SSL.
• Developing a proprietary protocol may lead to
  more complex client-side applications.

48
Problem

• The following identifier is put into a cookie
  after user logon (to identify the session)
• Cookie(GlobalId)
• What types of adversaries may attack this scheme?
• What is the attack?

49
Solution

• The interrogative adversary may attack this
  easily.
• The attack would be to guess the sequence number
  of another session.
• Since this uses sequential numbers it is quite
  easy.
• How will you mend this flaw?
• Use cryptographic randomness
• PRF(GlobalIdDate)

50
(No Transcript)
51
PassMark Securitywww.passmarksecurity.comPassMa
rk techniques are trademarked and patent-pending.

52
(No Transcript)
53
(No Transcript)
54
PassMark

• What is the traditional shared secret between a
  web-site and a user ?
• What is the additional shared secret ?
• Can e-mail be passmarked ? Of course.
• Question Suggest an initial enrollment process.

55
PassMark MIM

• Still MIM is possible, as always, the settings
  are very simple
• Attacker lures customer to a fake site, and
  quickly submits his username to real site.
• Real site presents the passmark to the attacker,
  which in turn replays it to the user.

56
Passmark MIM solution

• A secure cookie must be presented by the user
  (aka deviceID).
• If no secure cookie, the user is shown a blank
  passmark (since his machine is not recognized).
• The blank passmark, may advise, for example, to
  manually re-type URL.

57
Device Identifiers

• Except secure cookies, other deviceIDs include
• Hardware token/Trusted computer (the Trusted
  Computing initiative)
• Hardware signature
• Software token or a certificate

58
(No Transcript)
59
Summary

• Passmarks are very simple to use yet very
  effective.
• Reverse the traditional direction - authenticate
  site to user.
• Increase the level of trust between customers and
  institutions.
• May catalyze on-line self services solutions.
• Secure deviceID.