CHƯƠNG 3 TRIỂN KHAI
3.2. Bảo vệ mật khẩu
3.2.2. Giải pháp bảo vệ
Như trên, ta thấy một lỗ hổng trong dịch vụ thưñiện tử của website Đại học Quốc gia Hà Nội. Những website sử dụng giao thức mã hóa không gặp phải vấn ñề này. Học viên xin lấy ví dụ dịch vụ email của Google. Khi người dùng truy cập http://gmail.com, lập tức ñịa chỉ này biến mất khỏi trình duyệt, thay vào ñó là một dòng ñịa chỉ khác, bắt ñầu bởi “https”. Lý do là Google ñã sử dụng giao thức ssl/ tls (secure sockets layer/ transport layer security) ñể truyền siêu văn bản. Bản tin chặn bắt sẽ hoàn toàn bất ñịnh, và mật khẩu ñược bảo vệ.
Hình 3.5. Chặn bắt thông tin ñăng nhập http://gmail.com
Tuy nhiên, chi phí cho “https” ñắt hơn nhiều lần so với “http”, còn tốc ñộ truy cập lại chậm hơn. Đó là nguyên nhân hầu hết website ñều dùng “http”. Với thực tế như vậy, học viên ñề xuất giải pháp bảo vệ mật khẩu mà quản trị có thể tự phát triển cho website của mình.
Sinh khóa
Giải mã Dd(c) = h c
2. Cấp khóa
3. Gửi thông tin xác thực
Mã hóa Ee(h) = c d e Client Server Nhận yêu cầu Gửi yêu cầu So sánh h 1. Yêu cầu Đăng nhập thành công 4. Chấp nhận Mật khẩu Hash h h CSDL Tên ñăng nhập
3. Gửi tên ñăng nhập
Sinh khóa Giải mã Dd(c) = h+x c
2. Cấp khóa 3. Gửi thông tin xác thực
Mã hóa Ee(h+x) = c d e Client Server Nhận yêu cầu Gửi yêu cầu So sánh 1. Yêu cầu Đăng nhập thành công 4. Chấp nhận Mật khẩu Hash h CSDL Tên ñăng nhập
3. Gửi tên ñăng nhập
Sinh x 2. Cấp x x x h h+x Hình 3.7. Giải pháp bảo vệ mật khẩu – mô hình 2
Ở mô hình 1, server sinh 1 cặp khóa (e, d) sau mỗi lần nhận yêu cầu ñăng nhập. Mật khẩu có ñộ dài bất kỳ nhưng client chỉ mã hóa giá trị “hash” của nó (hoặc thậm chí là một số bits xác ñịnh trong giá trị này). Kết quả là thông tin xác thực, ñược server giải mã rồi so sánh với giá trị “hash” của mật khẩu ñã lưu trong cơ sở dữ liệu. Nếu trùng khớp, client sẽñăng nhập thành công.
Ở mô hình 2, server không thay ñổi cặp khóa (e, d) mà sinh 1 giá trị x ngẫu nhiên cho mỗi lần ñăng nhập. Client trộn x với giá trị “hash” của mật khẩu trước khi mã hóa, tạo thông tin xác thực. Phía server cũng trộn x với giá trị “hash” của mật khẩu lưu trong cơ sở dữ liệu, rồi so sánh với kết quả giải mã thông tin xác thực. Nếu trùng khớp, client sẽñăng nhập thành công.
Như vậy, giá trị e hoặc x ñã làm thông tin xác thực c không giống nhau ở các lần ñăng nhập. Hàm hash sử dụng phải mang tính chất hàm một chiều, tức việc tìm mật khẩu từ h là cực kỳ khó khăn. Do ñó nếu kẻ xấu suy ra h bằng cách chặn bắt nhiều lần c cùng e hoặc x tương ứng thì cũng không thể tìm ra mật khẩu.
Tuy nhiên, học viên lưu ý rằng chúng ta nên sử dụng mô hình 2. Phép trộn x với h là bất ñịnh với kẻ xấu, vì thế chỉ riêng việc tìm h cũng hết sức khó khăn. Ngoài ra thao tác sinh cặp (e, d) thông thường sẽ phức tạp hơn 2 thao tác sinh x, và trộn x với h. Mà mô hình này, công việc ñó chỉ phải thực hiện duy nhất 1 lần!
Thực hiện luận văn, học viên thu ñược kết quả chính sau:
- Hiểu rõ các hệ mật phổ biến hiện nay.
- Triển khai thành công phần mềm mật mã theo chuẩn AES. - Minh chứng cụ thể cho nguy cơ mất mật khẩu.
- Đề xuất ñược giải pháp kỹ thuật mới giúp bảo vệ mật khẩu.
Học viên xin ñánh giá kết quảñạt ñược:
- Học viên chưa biết một tài liệu chính thống nào (cả tiếng Anh và tiếng Việt) trình bày ñầy ñủ về các hệ mật phổ biến hiện nay. Đặc biệt, tài liệu bảo mật thông tin bằng tiếng Việt thì rất khan hiếm. Do vậy, luận văn ñược viết rất xúc tích, nhưng ñầy ñủ về các hệ mật sẽ là một tài liệu tham khảo tốt cho các kỹ sư/ cử nhân Công nghệ Thông tin, Điện tử Viễn thông cũng như bất cứ ai làm, nghiên cứu bảo mật.
- Phần mềm mật mã theo chuẩn AES ñạt mức ñộ hoàn chỉnh, có kết quả mã hóa vô ñịnh, kết quả giải mã chính xác.
- Minh chứng của học viên rõ ràng, thực tế. Nó cũng cho thấy nguy cơ chặn bắt thông tin nói chung trong mô hình server/ client không sử dụng giao thức bảo mật, ñang rất phổ biến hiện nay.
- Đề xuất giải pháp kỹ thuật mới của học viên rất khả thi, có thể áp dụng rộng rãi vào thực tiễn, mang lại hiệu quả cao, chi phí thấp.
1. Joan Daemen and Vincent Rijmen (1999), AES Proposal: Rijndael, Brussel and
Heverlee, Belgium.
2. Xuejia Lai and James L. Massey (1998), A Proposal for a New Block
Encryption Standard, Institute for Signal and Information Processing, Swiss
Federal Institute of Technology, CH−8092 Zürich, Switzerland.
3. Xuejia Lai, James L. Massey and Sean Murphy (1998), Markov Ciphers and
Differential Cryptanalysis, Institute for Signal and Information Processing,
Swiss Federal Institute of Technology CH−8092 Zürich, Switzerland.
4. Aleksandr Malchik (1994), Cryptographic Protection for Data Processing
Systems, Sun Microsystems Laboratories, Mountain View, California, USA.
5. A. Menezes, P. van Oorschot and S. Vanstone (1997), Handbook of Applied
Cryptography, CRC Press, USA, pp. 67−68, 82−83, 285−287.
6. National Institute of Standards and Technology (1999), Federal Information
Processing Standards Publication 46−3, National Technical Information
Service, 5285 Port Royal Road, Spring field, VA 22161, USA.
7. National Institute of Standards and Technology (2001), Federal Information
Processing Standards Publication 197, National Technical Information
Service, 5285 Port Royal Road, Spring field, VA 22161, USA.
8. Josef Pieprzyk and Leonid Tombak (1994), Soviet Encryption Algorithm,
Department of Computer Science, University of Wollongong, Wollongong, NSW 2500, Australia.
9. Ronald L. Rivest (1997), The RC5 Encryption Algorithm, MIT Laboratory for
Computer Science, 545 Technology Square, Cambridge, MA 02139, USA. 10. Ronald L. Rivest, M.J.B. Robshaw, R. Sidney and Y.L. Yin (1998), The RC6TM
Block Cipher, MIT Laboratory for Computer Science, 545 Technology Square,