Bài giảng An toàn an ninh thông tin - Chương 6: Xác thực danh tính - Bùi Trọng Tùng

: Hash(Password, Salt)
 16
16
 8
 Băm mật khẩu với “salt”
 • Lưu trữ [salt,Hash(password || salt)
 • Ví dụ: Hệ điều hành Linux
 username salt hash
 bkcs:$1$J54g/weK$aAVR2Nd6opPl9kcUuTTgk.:17422:0:99999:7:::
 algorithm Lần cuối thay đổi(tính từ ngày 1/1/1970)
 1: MD5-based Số ngày tối thiểu trước khi đổi
 2: Blowfish Số ngày tối đa trước khi đổi
 5: SHA-256 Số ngày trước khi hết hạn sẽ cảnh báo
 6: SHA-512 Ngày hết hạn (tính từ 1/1/1970)
 • Lưu trữ trong CSDL
 username salt hash
 levn iU9KjTeD 5myyo4W7zppTOEdVUeP8/E6Km
 tungbt r.PhJ0HG Y.xOpTBqJbWpc3f0uri.g8ErCu4wIiUGq
 17
17
 Băm mật khẩu với “salt” – Nâng cao an toàn
 • Kẻ tấn công có thể tạo ra từ điển mới với các giá trị “salt”
 • Băm nhiều lần: hash(hash(..hash(password || salt)))))
 Mục đích: làm chậm thời gian tính toán giá trị xác thực làm 
 chậm thời gian tấn công dò tìm
 nhưng kẻ tấn công có thể kiên nhẫn hơn nữa tạo ra từ điển mới
 • Băm mật khẩu với một giá trị “pepper” bí mật
 Mục đích: ngăn chặn kẻ tấn công tạo ra từ điển mới
 • Sử dụng một trong thuật toán bcrypt, scrypt, PBKDF2 
 thay cho các hàm băm thông thường
 18
18
 9
 Khôi phục mật khẩu
 • Làm thế nào để người dùng có thể khôi phục mật 
 khẩu khi họ quên?
 Gửi trực tiếp qua email
 Reset qua email
 Câu hỏi bí mật
 Sử dụng tin nhắn SMS
 ...
 • Lưu ý: xây dựng giao thức an toàn
 19
19
 Sử dụng câu hỏi bí mật còn an toàn?
 • Năm 2008, ứng viên Phó Tổng thống Hoa Kỳ Sarah Palin 
 bị đánh cắp tài khoản Yahoo Mail
 • Năm 2012, ứng viên Tổng thống Mitt Romney bị đánh cắp 
 tài khoản Hotmail
 20
20
 10
 Một số chính sách sử dụng mật khẩu
 • Mục đích: tăng cường an toàn cho hệ xác thực dựa trên 
 mật khẩu
 • Quy định độ dài tối thiểu
 • Quy định các ký tự bắt buộc phải sử dụng
 • Thay đổi mật khẩu định kỳ
 • Hạn chế sử dụng lại mật khẩu cũ trong một khoảng thời 
 gian nhất định
 • Hạn chế số lần thử xác thực
 • Tăng thời gian chờ thử xác thực lại
 • Yêu cầu đổi mật khẩu sau lần đăng nhập đầu tiên
 • Tuy nhiên, luôn phải cân nhắc sự trả giá cho tính tiện lợi
 21
21
 3. MỘT SỐ GIAO THỨC XÁC THỰC
 22
22
 11
 Giao thức PAP
 • Password Authentication Protcol
 • Được sử dụng trong giao thức mạng PPP trước đây
 • Nội dung:
 (1) U S: ID || Password
 (2) Server kiểm tra trong CSDL
 S U: ACK/NAK
 • Không an toàn
 23
23
 Xác thực 1 chiều dựa trên hệ mật mã KĐX
 • Giả sử 2 bên đã trao đổi một giá trị khóa bí mật KS
 (1) U S: Request
 (2) S U: Challenge
 (3) U S: f(Pass, Challenge)
 Hàm f: có thể là các hàm mã hóa KĐX, hàm băm
 Pass : mật khẩu
 • Bài tập: Phân tích các điểm yếu của sơ đồ này
 24
24
 12
 Xác thực 1 chiều dựa trên hệ mật mã KCK
 ISO/IEC 9798-3 / FIPS-196
 (1) A B: Request
 (2) B A: TokenID || NB
 (3) A B: TokenID || CertA || TokenAB
 TokenID: chứa thông tin của phiên
 TokenAB = NA || NB || E(KRA, NA || NB)
 25
25
 Giao thức CHAP
 • Challenge Handshake Authentication Protocol
 (1) U S: Request
 (2) S U: Challenge
 (3) U S: ID || Hash(ID || Hash(Password) || Challenge)
 (4) Server kiểm tra
 S U: ACK / NAK
 • Challenge: chuỗi ký tự ngẫu nhiên
 • Hash: MD5
 26
26
 13
 Giao thức EAP
 • Extensible Authentication Protocol
 • Có khoảng 40 biến thể kết hợp thêm nhiều cơ chế khác 
 nhau:
 EAP-MD5: tương tự CHAP
 EAP-TLS, EAP-TTLS, PEAP: kết hợp TLS
 EAP-POTP: kết hợp One-Time-Password
 EAP-PSK: kết hợp pre-shared key
 ...
 27
27
 Xác thực 2 chiều sử dụng hệ mật mã KĐX
 • Giả sử A và B đã chia sẻ khóa KS
 (1) A B: IDA
 (2) B A: NB
 (3) A B: f(KS, NB) || NA
 (4) B A: f(KS, NA)
 Hàm f: có thể là các hàm mã hóa KĐX, hàm băm
 KS : khóa hoặc mật khẩu
 28
28
 14
 Bài tập
 • Xem xét tính an toàn của giao thức xác thực sau:
 (1) A B: IDA || NA
 (2) B A: f(KS, NA) || NB
 (3) A B: f(KS, NB)
 • Nhận xét: người bắt đầu giao dịch phải là người chứng 
 minh trước
 29
29
 Xác thực 2 chiều sử dụng hệ mật mã KCK
 ISO/IEC 9798-3 / FIPS-196
 (1) A B: Request
 (2) B A: TokenID || NB
 (3) A B: TokenID || CertA || TokenAB
 (4) B A: TokenID || CertB || TokenBA
 TokenAB = NA || NB || E(KRA, NA || NB)
 TokenBA = NA || NB || E(KRB, NA || NB)
 30
30
 15
 Giao thức dạng zero-knowledge (ZKP)
 • Giữa hai hành lang có một cánh 
 cửa bị khóa
 • Peggy biết mật khẩu để mở cánh 
 cửa (VD. “Vừng ơi, mở ra!” )
 • Victor muốn bỏ tiền để mua lại 
 mật khẩu
 • Làm thế nào để Peggy chứng 
 minh với Victor có thể đi qua hành 
 lang mà không làm lộ mật khẩu?
 31
31
 Giao thức ZKP
 • Là các giao thức cho phép một bên chứng minh được thông 
 tin của mình mà không làm lộ nội dung thông tin đó cho các 
 bên còn lại (bên thứ 2 hoặc kẻ tấn công)
 • Các bên tham gia giao thức:
 Peggy-Người chứng minh: Peggy nắm được một số thông tin nào đó 
 và muốn chứng minh cho Victor nhưng không muốn để lộ thông tin 
 này
 Victor-Người thẩm tra: Được quyền hỏi một số câu hỏi đến khi chắc 
 chắn Peggy nắm thông tin. Victor không thể đoán thông tin từ câu trả 
 lời của Peggy, hoặc do cố tình lừa Peggy tiết lộ thông tin
 Eve-Kẻ nghe lén: Giao thức cần chống lại việc Eve nghe lén thông tin
 Mallory: có nhiều quyền hơn Eve, có thể nghe lén, sửa đổi bản tin 
 hoặc phát lại bản tin 
 32
32
 16
 Một ví dụ - Giao thức Feige–Fiat–Shamir
 • Khởi tạo: Peggy chọn p, q là 2 số nguyên tố:
  Tính  =  ×  
  Chọn s sao cho UCLN(s, n) = 1,  sao cho  =   
  Công bố (n,v). Peggy cần chứng minh cho Victor biết mình nắm 
 giữ giá trị s
 • Giao thức:
 (1) P V:  =    r: số ngẫu nhiên
 (2) V chọn ngẫu nhiên  ∈ {0, 1}
 V P: b
 (3) P V:  =  ×   
 (4) V kiểm tra phương trình đồng dư  ≡  ×  ( )
 Hoặc viết dưới dạng khác    =  ×   
 33
33
 Giả mạo
 • Mallory có thể giả mạo bằng 2 cách:
 (1) Bắt các cặp giá trị (x, y) và phát lại
 (2) Phán đoán giá trị của bit b mà Victor thử thách:
 Đoán b = 0, Mallory gửi  =    và  =   
 Đoán b = 1, Mallory chọn y trước và tính x sao cho
  ≡  ×  ( )
 • Xác suất thành công của Mallory là bao nhiêu?
 • Làm thế nào để giảm xác suất thành công của
 Mallory trong 1 vòng kiểm tra?
 34
34
 17
 Nhận xét
 • Vì Peggy nắm được giá trị của s nên có thể qua được vô 
 số vòng kiểm tra (Tính đầy đủ - Completeness)
 • Nếu Mallory không biết s, thì xác suất giả mạo thành công 
 lớn nhất là 2−n với n là số vòng kiểm tra (Tính vững chãi-
 Soundness)
 • Mallory không thể sử dụng lại bộ số (x,y) để lừa Victor
 • Victor không biết gì về s vì bài toán tính căn bậc 2 rời rạc 
 là khó
 • Tương tự, Eve nghe trộm được mọi bộ số (x,y,b) cũng 
 không thể đoán được s
 35
35
 Các nguy cơ
 • Peggy không thay đổi r sau mỗi vòng kiểm tra
 • Chess Grandmaster Problem
 • Mafia Problem
 • Terrorist Problem
 36
36
 18
 Giao thức ZKP dựa trên hệ mật mã RSA 
 (Một ví dụ khác)
 • Peggy có khóa công khai KU = (e,n) cần chứng minh anh 
 ta có bí mật m
 • Khởi tạo: Peggy tính c = me mod n
 • Giao thức:
 (1) P V:  =    r: số ngẫu nhiên
 (2) V chọn ngẫu nhiên  ∈ {0, 1}
 V P: b
 (3) P V:  =  ×   
 (4) V kiểm tra phương trình đồng dư  ≡  ×   
 Tự kiểm tra tính đầy đủ và bền vững của giao thức.
 Hãy đọc thêm lý thuyết tổng quan về ZKP trong tài liệu.
 37
37
 4. ONE TIME PASSWORD (OTP)
 38
38
 19
 Xác thực đa yếu tố
 • Phương pháp xác thực sử dụng mật khẩu không đủ an 
 toàn (Nguyên nhân chủ yếu từ người dùng!)
 • Sử dụng mật khẩu một cách an toàn:
 Đủ dài và khó đoán
 Không dùng chung cho nhiều tài khoản
 Thay đổi thường xuyên
  hầu hết người dùng không thực hiện được
 cần thêm các yếu tố xác thực an toàn hơn, không phụ 
 thuộc vào thói quen của người dùng
 • Xác thực đa yếu tố (thông thường là 2 yếu tố)
 Cái người dùng biết: mật khẩu
 Cái người dùng có: (thường) thiết bị phần cứng
 39
39
 One Time Password
 • Mật khẩu chỉ dùng để xác thực cho 1 phiên hoặc 1 giao 
 dịch
 • Phân loại:
 S/Key OTP
 Event-based OTP
 Hash-based OTP (HOTP)
 Time-based OTP (TOTP)
 • Cách thức phân phối:
 SMS
 Ứng dụng
 Email
 Token
 40
40
 20
 S/Key OTP(RFC 1760)
 • Sử dụng trong một số hệ điều hành 
 Unix
 • Pha sinh mật khẩu:
 (1) Server chọn một giá trị bí mật S
 (2) Áp dụng hàm băm (hoặc HMAC) n 
 lần lên S
 (3) Lưu Hn trong CSDL
 (4) Cung cấp cho client Hn, Hn-1,, H1
 (5) Client hủy giá trị Hn
 41
41
 S/Key OTP(tiếp)
 • Xác thực lần đầu
 (1) Client gửi Hn-1
 (2) Server so sánh HMAC(Hn-1) với Hn trong CSDL
 (3) Nếu bước 3 xác thực đúng, thay Hn bằng Hn-1. Gửi 
 thông báo xác thực thành công
 (4) Client xóa Hn-1 nếu đăng nhập thành công
 • Xác thực các phiên kế tiếp: tương tự
 42
42
 21
 HOTP (RFC 4226)
 • Bộ đếm: C (8 byte)
 • Giá trị bí mật: K đã chia sẻ trước với client
 • Hàm HOTP(K, C)
 (1)Tính HS = HMAC-SHA-1(K,C)
 (2)Trích xuất 4 bytes từ HS bằng hàm Dynamic Truncation
 Sbits = DT(HS)
 (3) Chuyển Sbits sang dạng thập phân. Lấy giá trị HOTP 
 với số chữ số k tùy ý.
 Snum = StToNum(Sbits) 
 D = Snum mod 10k
 43
43
 Hàm DT
 • Đầu vào: Chuỗi 20 byte S
 • Xử lý:
 Lấy OffsetBits = 4 bit thấp của S[19]
 Biến đổi sang dạng thập phân Offset = StToNum(OffsetBits)
 Trích xuất 4 byte trong chuỗi S bắt đầu từ vị trí Offset được chuỗi 
 P
 • Đầu ra: Xóa bit đầu tiên của P
 44
44
 22
 Sử dụng HOTP trong giao thức xác thực
 • Yêu cầu: Chia sẻ khóa K và C một cách an toàn
 • Server: C  C + 1. Tính HOTP(K, C) và lưu trong CSDL
 • Client: C  C + 1. Tính HOTP(K, C) và người dùng gửi 
 cho server
 • Server:
 Nếu OTP nhận được là hợp lệ tạo OTP mới thay cho giá trị cũ 
 trong CSDL
 Nếu OTP nhận được không hợp lệ, thực hiện đồng bộ lại với tham 
 số đồng bộ s. Yêu cầu xác thực lại.
 Sau T lần xác thực lại không hợp lệ, khóa tài khoản
 45
45
 Đồng bộ trong HOTP
 • Khi sử dụng HOTP trên thiết bị OTP Hardware Token, mã 
 OTP được sinh ra theo yêu cầu người dùng
 • Tính trạng mất đồng bộ: người dùng yêu cầu mã OTP 
 nhưng không xác thực giá trị bộ đếm của Token và 
 Server khác nhau
 • Đồng bộ hóa:
 Server tính toán HOTP cho s lần kế tiếp
 Yêu cầu người dùng gửi một chuỗi (2-3, hoặc hơn) các giá trị 
 HOTP sinh được từ Token
 So sánh chuỗi HOTP của người dùng với chuỗi HOTP đã sinh và 
 thực hiện đồng bộ
 46
46
 23
 TOTP(RFC 6238)
 • Thực hiện tương tự HOTP Client Server
 • Thay thế bộ đếm C bằng giá 
 trị thời gian:
 Tạo 
 T = (Current UnixTime – T0)/X
 và gửi 
 T0: Mốc thời gian TOTP
 X: Bước thời gian (time step) Nhận 
 và kiểm 
 • Vấn đề trễ xử lý
 tra
 • Client có thể gửi cùng 1 
 TOTP trong 1 bước thời 
 gian, nhưng server chỉ chấp 
 nhận cho 1 lần xác thực
 47
47
 Mất đồng bộ trong TOTP
 • Đồng hồ của 2 bên có sai số khác nhau sau một thời 
 gian có thể mất đồng bộ
 • Phía kiểm tra cho phép chấp nhận một giá trị OTP nằm 
 trong khoảng sai số cho phép
 • Miền chấp nhận [TOTP(Tp) , TOTP(Tf)]
 Tp = (Current UnixTime – 2X + 1 – T0)/X
 Tf = (Current UnixTime + X – 1 – T0)/X
 T Thời điểm t
 p Tf
 tb kiểm tra tf
 Lưu ý: Nếu xác thực thành công có thể tinh chỉnh lại việc 
 mất đồng bộ đồng hồ thời gian tại server
 48
48
 24
 SMS OTP
 • Giá trị OTP được sinh ở server và gửi cho người dùng 
 qua tin nhắn SMS
 • Không đảm bảo an toàn:
 Điện thoại người dùng bị nghe lén
 Giả mạo trạm BTS
 Tấn công lợi dụng lỗ hổng của giao thức SS7
 49
49
 Tấn công lợi dụng lỗ hổng của SS7
 • SS7(Signaling System 7): bộ giao thức điều khiển truyền 
 dữ liệu giữa các cell trong mạng đi động
 • Không có cơ chế xác thực
 • IMSI: Định danh của thẻ SIM
 • IMEI: Định danh của thiết bị
 • MSISDN: Số thuê bao
 • HLR(Home Location Register): CSDL thuê bao
 • MSC(Mobile Switching Center): Bộ chuyển mạch
 • MAP(Mobile Application Part): giao thức điều phối truyền 
 dữ liệu giữa các thành phần trong phiên dịch vụ
 50
50
 25
 Tấn công SS7 – Bước 1
 (1) Kẻ tấn công gửi thông 
 điệp 
 SendRoutingInfoForSM 
 chứa MSISDN tới HLR
 (2) HLR gửi thông điệp trả 
 lời chứa:
 • Số thuê bao
 • Địa chỉ của MSC đang xử 
 lý kết nối của nạn 
 nhân(Bob)
 • IMSI của nạn nhân
 51
51
 Tấn công SS7 – Bước 2
 (1) Kẻ tấn công đăng ký 
 thông tin của Bob trên MSC 
 giả mạo (Fake MSC)
 (2) HLR cập nhật vị trí mới 
 của Bob
 (3) HLR yêu cầu MSC cũ 
 giải phóng thông tin
 52
52
 26
 Tấn công SS7 – Bước 3
 (1) Alex gửi tin nhắn SMS 
 cho Bob
 (2) MSC chuyển tiếp tin 
 nhắn tới SMS-C
 (3)SMS-C gửi thông điệp 
 tới HLR yêu cầu vị trí của 
 Bob
 (4) HLR trả lại địa chỉ của 
 Fake MSC
 (5) SMS-C chuyển tiếp tin 
 nhắn tới Fake MSC
 53
53
 Một vụ việc tấn công xác thực người 
 dùng
 54
54
 27
 Một vụ việc tấn công xác thực người 
 dùng
 Kịch bản sử dụng dịch vụ:
 • B1: Khách hàng đăng nhập vào hệ thống eBanking
 • B2: Khách hàng nhập lệnh chuyển tiền
 • B3: Hệ thống eBanking gửi mã OTP qua tin nhắn SMS tới 
 số điện thoại mà khách hàng đã đăng ký
 • B4: Khách hàng nhập mã OTP nhận được vào hệ thống 
 để xác nhận chuyển tiền
 Xác thực đa yếu tố:
 (1) Mật khẩu truyền thống
 (2) SMS OTP
 55
55
 Một vụ việc tấn công xác thực người 
 dùng
 • Vietcombank cung cấp ứng dụng di 
 động Vietcombank Smart OTP cung 
 cấp mã xác thực OTP
 • B1: Mở ứng dụng và điền số ĐT đăng 
 ký SMS Banking
 • B2: Hệ thống gửi mã xác thực OTP tới 
 số điện thoại
 • B3: Người dùng nhập mã xác thực vào 
 ứng dụng
 • B4: Nếu mã OTP đúng, ứng dụng 
 được kích hoạt
 56
56
 28
 5. XÁC THỰC SỬ DỤNG SINH TRẮC
 57
57
 Xác thực bằng sinh trắc (biometric)
 58
58
 29
 Dấu vân tay
 59
59
 Vân lòng bàn tay
 60
60
 30
 Cấu trúc bàn tay
 61
61
 Khuôn mặt
 62
62
 31
 Mống mắt
 63
63
 Vành tai
 64
64
 32
 Mạch máu
 65
65
 Xác thực bằng sinh trắc
 User Tấn công Server
 nghe lén
 User nonce Server
 Mẫu sinh trắc ?
 h=H( không, nonce) ổn địnhh=H( , nonce)
 66
66
 33
 Những khó khăn khi sử dụng hệ xác thực 
 bằng sinh trắc
 • Chi phí tính toán
 • Giá thành cao
 • Tính không ổn định
 • Không bền vững
 • Lo ngại của người dùng liên quan đến sức khỏe
 67
67
 5. SINGLE SIGN ON(SSO)
 68
68
 34
 Khái niệm
 • SSO là một cơ chế xác thực yêu cầu người dùng đăng 
 nhập vào chỉ một lần với một tài khoản và mật khẩu để 
 truy cập vào nhiều ứng dụng trong 1 phiên làm việc 
 (session).
 69
69
 Single Sign On
 • CAS (Central Authentication Service) là một giải pháp 
 SSO mã nguồn mở được phát triển bởi đại học Yale
 • CAS hỗ trợ nhiều thư viện phía máy khách được viết bởi 
 nhiều ngôn ngữ: PHP, Java, PL/SQL
 • Các thông tin phiên đăng nhập đặt trong cookie do CAS 
 sinh ra(Ticket Granting Cookie)
 • Hỗ trợ xác thực đa yếu tố
 70
70
 35
 Single Sign On
 • Người dùng chưa 
 được chứng thực 
 trên CAS
 • TGC: Ticket 
 Granting Cookie
 • ST: Session Token
 71
71
 Single Sign On
 • Người dùng đã 
 chứng thực trên 
 CAS
 72
72
 36
 Các giải pháp SSO khác
 • Open SAML
 • OpenID Connect
 • CA Single Sign On
 • Java Open Single Sign On
 • Google Sign-In
 • Facebook Login
 73
73
 37