DATA & COMPUTER SECURITY (CSNB414) MODULE 5 AUTHENTICATION PROTOCOLS
ThreatsSecurity GoalsSecurity Mechanisms EavesdroppingConfidentialityEncryption schemes Data modificationData Integrity, Data Origin Authentication Hash functions, digital signatures ImpersonationEntity Authentication Entity authentication protocols RepudiationNon-repudiationDigital signatures
Something to Ponder….. We ore often members to several institutions / organizations where we are identified by our respective IDs (e.g. IC & student matrix numbers, email IDs etc.) Authentication methods are needed to ensure that a user is who he / she claimed to be. This is to ensure that security is well implemented to protect the respective assets (data, resources etc). Authentication can be carried out manually or automatically through computer systems. Automatic authentication pose threats from spoofing, eavesdropping, modification and masquerading.
Types of Authentications What the user ‘knows’ e.g. passwords, PINs, secret codes etc. What the user ‘possesses’ e.g. MyCard, Passport, smartcards, keys etc. ‘Characteristics’ of the user himself = biometrics e.g. behavioral traits like signature, voice etc. e.g. physical traits like thumbprint, face etc.
Threats to Password Authentication Due to user errors ~ user-chosen passwords are easy to be cracked e.g. birthdays, names, common words, favorite celebrities, club etc. ~ system generated passwords are often written down on papers, stored on PC, hp etc. ~ same passwords for several systems Due to system vulnerabilities ~ Trojan horse masquerade ~ inadequate / ineffective security measures to protect the password files e.g. plaintext system password list **Read text book page 216-217** Untrustworthy employees
Tips for Password Selection Choose mixed types of characters Choose long passwords Avoid names / words Change passwords regularly Avoid using same passwords for different applications Do not disclose to others Do not write it down
Brute Force Vs. Dictionary Attacks Brute Force Attack An exhaustive attack on a password authentication system by trying out all possible combination of passwords. E.g. a password of letters A – Z (26 letters) of max 8 letters length. No of tries = 26 1 + 26 2 + ……+ 26 8 ~ almost five millions Dictionary Attack An attack on a password authentication system by trying out all possible words, beginning with the one with the highest probability of being used
Plaintext Passwords Vs. Encrypted / Hashed Passwords Plain text Encrypted / Hashedpassword file User key in password It is difficult to crack hashed password unless hash code is known!! System stores my_password User key in password System hash password System store 1500020F0C e.g. password = my_password e.g. hashed password =1500020F0C
Verification Process of Hashed Passwords Example of available standards: MD4, MD5, SHA-0 System derive hashed reference password User key in password System hash password Input password == reference password? e.g. password = my_password e.g. hashed input password =1500020F0C Access deniedAccess granted Yes No e.g. hashed reference password =1500020F0C
Problem of Hashed Passwords What if ??? If a hacker knows Tom’s password & he discover Tom’s hashed password = Jerry’s hashed password Then he know Jerry’s password (&& THE HASH CODE TOO!!) **check MDcrack** Tom’s hashed password = Jerry’s hashed password =1500020F0C Tom’s password = my_password Jerry’s password = my_password
Salted Hashed Passwords Solution : Add ‘salt’ to password to make it unique Salt = unique random code User key in password System add salt to password System hash salted password e.g. password = my_password e.g. salted password = my_passwordUNT1079 e.g. salted hashed password =1124520Z0D System store 1124520Z0D and salt Therefore, Tom & Jerry will never have the same hashed password even if they use the same password
Biometrics Several types of biometrics are accurate (e.g. no 2 persons have the same DNA, iris or thumbprint pattern) Others not (e.g. twins may look alike) Accurate biometrics are hard to be fooled, assist in audit trail HOWEVER, issues of privacy intrusion Biometrics data may also be encrypted Biometrics identification Vs. Biometrics verification - Identification : 1 to many searches (only for very accurate biometrics, closest match) - Verification : 1 to 1 comparison (often require ID, either positive or negative verification result)
Biometrics Accuracy False Rejection Rate (FRR) The likelihood that a legitimate user is rejected by the system. False Acceptance Rate (FAR) The likelihood that an impostor is accepted by the system as a genuine user. Equal Error Rate (EER) The point at which FRR == FAR.
Biometrics Accuracy (cont.) FRR & FAR varies with the sensitivity threshold. FRR and FAR are related, where if one figure is improved, then the other deteriorates. How to set the sensitivity threshold? - Depends on system requirements e.g. A high security application does not tolerate any intruders, hence requiring low FAR. While a credit card verification system may require low FRR, in order to avoid its users being annoyed with a high frequency of rejection at counters. A national civilian applications would demand low FRR and low FAR to instil public trust and confidence. Biometrics products often specified by its EER. An ideal biometrics systems should produce 0%EER, however, this is often not realised.
Two types of authentication protocols: User authentication Data authentication (we just focus on user authentication) User authentication protocol is a protocol to authenticate a user. Usually user authentication is realized by the use of password. Authentication Protocol
UAP1: Password-based protocol The problem arised when an Eve can read and store the H(P) that goes along the network. She can use the stored H(P) for later sessions, acting like a legitimate Alice. This is called a REPLAY ATTACK. AliceServer [PT]: “I want to log on. I am Alice101” [PT]: “Give me your credential” H(Password A ) Compar e H(P) H(P) Yes No Access is granted Access is denied Status of access Figure A
Explanation on password-based authentication This is the scenario: Alice wants to gain access to a particular server and for this purpose she registers her userID and password at the server. The server will compute the hash of Alice’ password and store both Alice’ userID and hashed password in its repository. Now Alice wants to log on to a server, and she sends a message something like this: ‘I want to logon and my userID is Alice101’ Alice also compute the hash of her password and sends this together with her userID to the server. The server would compare the userID and password hash sent by Alice and userID and password hash in its repository. If they are matched, then the server will grant an access to Alice. Otherwise, the access is denied
This scenario/protocol seems to work well. Alice can authenticate herself to the server using the hash of her password. INote: remember that hash function produces unique message digests (or hash values) to different messages. Therefore message_A will have message_digest_A, and message_B will have message_digest_B, where message_A≠ message_B and message_digest_A ≠ message_digest_B. If message_digest_A = message_digest_B, therefore we say that this is a collision. However, this is not a good protocol because an Eve can do a replay attack. Password-based authentication
Replay attack Definition: is a form of network attack in which a valid data transmission is maliciously or fraudulently repeated or delayed. This is carried out either by the originator or by an adversary who intercepts the data and retransmits it. Figure A shows that an Eve (or intruder) has no difficulty to steal the network packet that contains the Alice’ hashed password. She can uses the network packet to gain access to a server at later time without Alice knowing it, masquerading as if she is a real Alice. In this case, the server would not know that this is not Alice since the comparison of hashed passwords gives a match.
Reminder… As you can see here, it is very easy for an attacker to guess or discover your password, IF your password is an English word. As explained in a lecture, they have a so called ‘rainbow table’ which lists all the English words together with its hash value. Finding the password based on the dictionary table is called a dictionary attack. Therefore it is VERY essential to ensure that you create a strong password that conforms to the password criteria listed in the previous slide.
UAP2: Stronger protocol: Challenge- Response Protocol AliceServer [PT]: “I want to log on. I am Alice101” Challenge :a Nonce Comp -are H(P) Yes No Access is granted Access is denied E(H(P))H(P) H(P)||Nonce Figure B Response: append hashed password with a nonce
This is the scenario: Alice wants to gain access to a particular server and for this purpose she registers her userID and password at the server. The server will generate a list of Nonce. It also computes the hash of Alice’ password, append the hashed password with a Nonce and store both Alice’ userID, and her appended hashed password and Nonce in its repository. Challenge-Response Protocol (cont..)
Now Alice wants to log on to a server, and she sends a message something like this: ‘I want to logon and my userID is Alice101’ The server then gives Alice the first Nonce. Alice will append this Nonce together with her hashed password. Alice then send the appended hashed password to the server. The server would compare the userID and appended hashed password sent by Alice and userID and appended hashed password in its repository. If they are matched, then the server will grant an access to Alice. Otherwise, the access is denied Challenge-Response Protocol (cont..)
In this protocol, there is no point of an Eve to store the network packet that contains Alice encrypted hashed password. She cannot re-use this packet for future access because the Nonce used for each session will be different. Therefore the network packet will also be different for each session. Challenge-Response Protocol (cont..)
Nonce Definition: is a random number and can only be used once. The size would depend on the system administrator.
For Challenge-Response protocol, you may encounter (in your readings from the book or internet) a few ways of sending the challenge and response. Some say: Encrypt the hashed password with the nonce, or Hash the nonce with the password together. Using timestamping All of those are accepted provided that the main goal in this protocol is to avoid the eve from replaying the same network packet for illegal access. Challenge-Response Protocol (cont..)
If you don’t like the idea of password-based Challenge- Response protocol, we have another protocol that avoids the use of password. It is called a Key-based Challenge-Response Protocol.
UAP3: Key-Based Challenge-Response Protocol Alice Server [PT]: ‘I want to log on and I am Alice101’ Challenge: E[Nonce] KpubA D Response: Message||Nonce K privA
In this scenario, the protocol avoids using a password to authenticate auser. First, Alice sends a message to the server saying that she wants to log on to it. The server will then issue a Nonce, encrypted using Alice’ public key K pubA, and send the encrypted Nonce to Alice. Upon receiving, Alice decrypts the ciphertext using her private key, K privA and obtain the Nonce. Alice sends back the message appended with a Nonce to the server. With this, the server knows that the person who it sends the Nonce to is Alice, because only Alice can decrypt the Nonce and return it back to the server. This is what we call as, a challenge-response protocol, as a way to authenticate a user. Key-Based Challenge-Response Protocol
DATA & COMPUTER SECURITY (CSNB414) MODULE 5 --END--