1. Như vậy là kỹ thuật tấn công đối với giải pháp hash mật khẩu là có thể thực hiện được. Điều này em cũng đã có lần thảo luận ở chủ đề: /hvaonline/posts/list/0/19653.html#193616 

2. Kỹ thuật này có được thực hiện ở dạng ứng dụng khác không? Các hệ thống xác thực khác windows. 

3. Các cách phòng chống như trên có đủ, và nên chọn cách nào hoặc có cách nào hiệu quả hơn nữa không? 

4. Độ bền vững của thuật toán hash có ảnh hưởng đến kiển tấn công này không? (em nghĩ là không) 

Mình không hiểu làm thế nào mà User có thể đăng nhập vào hệ thống nếu hệ thống hoạt động như trên. Mỗi lần server tạo ra một cái khoá khác nhau và dẫn đến h cũng khác nhau vậy Client gởi h đến Server mỗi lần cũng khác nhau thì làm thế nào server verify được User? Bạn có thể giải thích rõ hơn một chút được không? 

Sau này thì mình dùng cách hash 2 lần với khoá k ngẫu nhiên từ server. Khi client kết nối, server sẽ gửi lại một khoá k ngẫu nhiên. Client sẽ gửi h = MD5(k, MD5(clear_text_password)) cho server. Nếu h bị capture thì không thể giải ra k và password. Nếu dùng kỹ thuật "Pass the hash" - gủi trực tiếp h đã capture được - thì cũng failed vì lần sau server sẽ gửi khoá k khác. Bây giờ thì mình ưa thích dùng giải thuật HMAC để hash password, cho nó có chuẩn !  

Quanh đi quẩn lại thì cuối củng hash lại trở thành pass, quay về điểm xuất phát :D Theo mình để ngăn chuyện này mấu chốt chính là làm sao để xác định cái từ client gởi đi là do chính user nhập vào chứ không phải do giả lập qui trình chứng thực. Nói đúng hơn là kiểm tra từ lớp ứng dụng 

@radiohead: quá chuẩn. Mình biết có một ý tưởng như sau: làm một cái hòm có 2 ổ khoá, user sau khi cho password vào hòm sẽ khoá lại bằng ổ của mình, sau đó gửi đến server. Server sau đó khoá cái ổ còn lại và gửi về user. User mở khoá của mình và gửi hòm lại server. Server mở khoá hòm và lấy password, sau đó hash nó và so sánh với giá trị hash trong database. Để hiện thực hoá cần hai one-to-one mappings f và g (tượng trưng cho 2 ổ khoá) với commutative composition. Ví dụ lý tưởng là commutative encryption. Mình thấy cũng thú vị nếu các bạn thảo luận về những vấn đề liên quan đến giải pháp này.  

@WinDak: bất cứ một kết nối nào (sử dụng bất cứ một loại cryptographic protocol nào) không có secure authentication của ít nhất một end-point thì đều có thể bị MITM hoặc/và impersonation attack. Vì vậy, đối với mô hình trong topic, đòi hỏi về security không nên quá tham vọng, mà chỉ nên dừng lại ở 2 mục tiêu quan trọng: i) không lưu password dưới dạng plaintext và ii) không truyền password dưới dạng plaintext để chống sniffing. Ngoài ra, bạn WinDak thử mô tả xem tấn công MITM diễn ra như thế nào. Riêng mình thì mình không nghĩ là có thể tấn công MITM, tuy nhiên impersonation thì được.  

A contact đến B sau khi authenticate đến bước trao đổi khoá, C ở giữa và thay vì gửi hòm đến B thì C khoá bằng khoá của C và giả làm B. C có thể không contact luôn đến B, hoặc giả làm A contact đến B. Như vậy sau 2 quá trình trao đổi khoá trong hòm, C có khoá A<->C và C<->B, C có thể thoải mái forward message từ A đến B như thật, trong khi 2 người này hoàn toàn không biết có người ở giữa. Không biết cái này là impersonation hay là MITM ? xin StarGhost cho mở mang tầm mắt.  

Trên thực tế thì có thể thêm identity của A và B ở trong hòm thì sẽ không bị trường hợp này. 

Bạn thêm identity bằng cách nào để "không bị trường hợp này"?  

thế bồ có ý tưởng gì về phương pháp giúp xác thực cái hash kia là do người dùng mới nhập password vào và được "hash" ra thay vì là một cái hash đã bị chôm trước đó không , ý tưởng này có lần được đề cập đến trong Topic "Phương pháp chống DDoS" nhằm tạo ra một cái cookie không thể bị giả tạo, vấn đề khác nhưng ý tưởng giống :D Rất mong bồ có ý tưởng đề xuất :D 

Mình biết có một ý tưởng như sau: làm một cái hòm có 2 ổ khoá, user sau khi cho password vào hòm sẽ khoá lại bằng ổ của mình, sau đó gửi đến server. Server sau đó khoá cái ổ còn lại và gửi về user. User mở khoá của mình và gửi hòm lại server. Server mở khoá hòm và lấy password, sau đó hash nó và so sánh với giá trị hash trong database. Để hiện thực hoá cần hai one-to-one mappings f và g (tượng trưng cho 2 ổ khoá) với commutative composition. Ví dụ lý tưởng là commutative encryption. Mình thấy cũng thú vị nếu các bạn thảo luận về những vấn đề liên quan đến giải pháp này.  

@WinDak: bất cứ một kết nối nào (sử dụng bất cứ một loại cryptographic protocol nào) không có secure authentication của ít nhất một end-point thì đều có thể bị MITM hoặc/và impersonation attack.  

Ý sau thì anh hiểu nhầm cái em muốn nói, anh mrro muốn mô tả một cái attack đối với scheme sử dụng OTP. Ý em là hiện nay các kiểu xác định attack như vậy không phải là một điều gì khó khăn, vì đã có các phương pháp hình thức rất tốt để làm điều này. Về mặt lý thuyết, thì bài toán kiểm tra một giao thức bất kỳ là NP-complete, tuy nhiên trong thực tế đối với phần lớn các giao thức hiện tại (em không rõ có phải tất cả hay không) thì các thuật toán kiểm tra đều rất hiệu quả. Điều này cũng giống như việc phát hiện virus, trong trường hợp tổng quát, bài toán kiểm tra sự tồn tại của virus cũng là NP-complete, tuy vậy thực tế vẫn tồn tại các chương trình diệt virus rất tốt. Nhưng về mặt lý thuyết, vẫn có thể thiết kế các virus mà cực kỳ khó phát hiện (em chưa biết trong thực tế điều này đã được ứng dụng để viết virus phá hoại hay chưa), theo nghĩa độ phức tạp tính toán mà không phải theo nghĩa nó sử dụng các tricks khó khăn về mặt kỹ thuật. 

StarGhost wrote:

Bạn thêm identity bằng cách nào để "không bị trường hợp này"?  

Đưa ra cái ý tưởng để mọi người phát triển thêm thôi, chứ mình solo tiếp thì hơi mất tính thú vị của thảo luận. Bà con có thể thảo luận thêm cách chống MITM / impersonation trong trường hợp mà mình đã đưa ra, nếu mà topic chìm quá thì mình sẽ solo tiếp  

Còn chuyện brute-force mật khẩu không có phụ thuộc vào sức mạnh của hàm hash (đã gọi là brute-force mà), mà chỉ phụ thuộc vào độ phức tạp của mật khẩu. 

Nhầm rồi. Hàm hash phức tạp (1000 vòng lặp chẳng hạn), cần 100 ms để hash xong 1 chuỗi thì nó sẽ làm thời gian brute-force tăng gấp 100.000 lần so với dùng md5 (xem như 1 giây hash được 1 triệu md5). Đa số các hệ thống mới đều dùng strengthening kiểu này. 

Anh jcisio, em trích dẫn câu trả lời của anh vì câu đấy khá mơ hồ và sai lầm về một số mặt. Thứ nhất, anh cũng biết là số phép tính cần thiết để hash một chuỗi phụ thuộc vào thuật toán hash và kích thước của chuỗi đó. Điều thứ hai, anh nói hàm hash phức tạp "1000 vòng lặp" thì em cũng không rõ cái 1000 vòng lặp ở đây là cái gì, anh cũng biết là độ mạnh hay yếu của các thuật toán hash không chỉ phụ thuộc vào các "vòng lặp". Điều cuối cùng là việc tìm collision của hàm hash, ngay cả dùng brute-force đi nữa, thì trong thực tế người ta cũng không sai lầm đến mức mỗi lần thực hiện là sinh ra hàng tỉ tỉ giá trị hash để so sánh. Em không biết tất cả các phương pháp hiện tại, nhưng có một bài báo của Hellman viết cách đây cũng khá lâu mô tả phương pháp để tạo ra trade-off giữa thời gian và bộ nhớ cho việc tìm collision. Hiện nay thì em biết ý tưởng này người ta sử dung trong cái gọi là RainbowTable. Do vậy cái phép chia của anh sai lầm cả trên lý thuyết lẫn thực tế. 

@eicar: 100 ms / 1 us = 100.000 là hiển nhiên rồi, chứng minh gì nữa? @SG: mình không có tham gia tranh cãi, mình chỉ bảo câu bạn nói (được trích) là sai thôi, đó là một ngộ nhận rất nguy hiểm. Việc xây dựng một hàm hash đòi hỏi thời gian tính toán "lâu" là rất quan trọng. 2 trong 3 CMS phổ biến nhất (Drupal, Joomla, WP) đã dùng phpass rồi http://www.openwall.com/phpass/ 

jcisio wrote:

@eicar: 100 ms / 1 us = 100.000 là hiển nhiên rồi, chứng minh gì nữa? @SG: mình không có tham gia tranh cãi, mình chỉ bảo câu bạn nói (được trích) là sai thôi, đó là một ngộ nhận rất nguy hiểm. Việc xây dựng một hàm hash đòi hỏi thời gian tính toán "lâu" là rất quan trọng. 2 trong 3 CMS phổ biến nhất (Drupal, Joomla, WP) đã dùng phpass rồi http://www.openwall.com/phpass/ 

Haha, bạn jcisio nói đúng, mình đã ngộ nhận, còn nguy hiểm như thế nào thì mình còn chưa rõ. Mình ngộ nhận như vậy, căn bản là vì mình luôn giả sử rằng người ta thiết kể các hash function với một thuộc tính bất di bất dịch: càng nhanh càng tốt. Chính vì vậy mình luôn mặc định rằng sự biến thiên về độ phức tạp là không đáng kể. Quan điểm của mình là cái gì được thiết kế ra và test kĩ lưỡng để dùng với mục đích này thì chỉ nên dùng nó với mục đích đó, và không nên trao cho nó trọng trách khác, vì có thể gây ra nhiều phiền toái bất ngờ trong tương lai. Còn bạn cho nó hash n lần (n=1000) thì mình công nhận là gây khó khăn cho quá trình brute-force. Tuy nhiên, mình cho rằng đây là một hạ sách. Vì sao? Security bao giờ cũng có cái giá của nó. Tuy nhiên, khi thay đổi một hệ thống để tăng cường security cho một điểm yếu, người ta cố gắng làm sao để chi phí càng ít càng tốt, và security được tăng cường càng nhiều càng tốt, đồng thời không tạo ra điểm yếu ở chỗ khác. Với việc hash 1000 lần, hoặc thiết kế một hàm hash khác có độ phức tạp hơn 1000 lần hàm hash cũ, bạn làm cho nỗ lực brute-force tăng thêm 1000 lần, nhưng đồng thời cũng làm cho chí phí trong quá trình xác thực của hệ thống tăng thêm 1000 lần. Nói cách khác, security và cost có cùng tỉ lệ. Giả sử kẻ tấn công có khả năng brute-force password khi bạn dùng hàm hash cũ. Bây giờ bạn có khả năng tăng 1000 lần chi phí cho việc xác thực, phải chăng attacker không có khả năng tăng 1000 lần chi phí cho việc tấn công, thậm chí là tệ hơn nữa nếu cái mớ chi phí đó không hoàn toàn do attacker bỏ ra? Ngoài ra, việc tăng cường độ phức tạp tính toán trong quá trình xác thực còn gây ra một vấn đề, đó là DoS, khi mà thời gian xác thực mất tới 100ms. Thú thực mình không biết là phương pháp này đã được cài đặt vào các sản phẩm nào, và bao nhiều phần trăm các hệ thống trên thế giới sử dụng các sản phẩm đó, và bao nhiêu phần trăm trong số đó enable chức năng này. Nếu bạn (hoặc ai đó tham gia topic) có thống kê thì có thể đưa ra để cùng thảo luận, vì có thể phương pháp này còn có ưu điểm khác mà mình chưa nhận ra.  

Cả 2 trong cùng 1 hệ thống mà. Nhà bạn có 2 cửa: một cửa dễ vào, một cửa khó vào (trang đăng nhập không bao giờ là trang tiêu tốn tài nguyên nhiều nhất, nó chẳng phải làm gì ngoài việc tính hash), thế ăn trộm vào nó chọn cửa nào? PS: cho rằng một hệ thống dùng hash, thí dụ MD5, cũng an toàn như một hệ thống khác dùng key strenngthening (cũng với MD5 luôn) mà không nguy hiểm hả trời!]]> /hvaonline/posts/list/35603.html#230700 /hvaonline/posts/list/35603.html#230700 GMT PS: cho rằng một hệ thống dùng hash, thí dụ MD5, cũng thiếu an toàn như một hệ thống khác dùng key strenngthening (cũng với MD5 luôn) thì có nguy hiểm hay không?  

Một khi mình đã giả định rằng hàm hash hoạt động nhanh, tức là mình đã không còn tính phụ thuộc vào nó như là một miếng vá security. Như vậy có nghĩa là mình sẽ tính đến việc sử dụng các giải pháp khác thay thế/bọc lót để chống password cracking. Như vậy thì có nguy hiểm chăng? Như đã nói ở trên, mình công nhận là trong hầu hết trường hợp thì việc áp dụng vẫn cho hiệu quả. Tuy nhiên, mình vẫn bảo lưu 2 quan điểm rằng kĩ thuật này không có "stand the test of time", và không nên dùng với hệ thống quan trọng và cần sự ổn định lâu dài. Bạn thử tưởng tượng attacker nắm trong tay hệ thống tính toán gồm vài chục nghìn máy tính thì sao?  

invalid-password wrote:

Sau này thì mình dùng cách hash 2 lần với khoá k ngẫu nhiên từ server. Khi client kết nối, server sẽ gửi lại một khoá k ngẫu nhiên. Client sẽ gửi h = MD5(k, MD5(clear_text_password)) cho server. Nếu h bị capture thì không thể giải ra k và password. Nếu dùng kỹ thuật "Pass the hash" - gủi trực tiếp h đã capture được - thì cũng failed vì lần sau server sẽ gửi khoá k khác. Bây giờ thì mình ưa thích dùng giải thuật HMAC để hash password, cho nó có chuẩn !  

Cách của invalid-passwd sẽ bị qua mặt nếu kẻ tấn công đã từng thu được bản hass của pass trước đó (sniff từ trước khi có giải pháp thêm k, hoặc kẻ tấn công thu đc file lưu hash password của server. Vì khóa k ngẫu nhiên nhưng vẫn phải gửi clear text cho client hiểu nên việc tính ra h= MD5 (k, MD5(clear_text_pass)) là vẫn khả thi cho dù ko cần biết clear_text_pass Có thể sử dụng cách này h = MD5 (clear_text_pass, k) Vì kẻ tấn công trong quá khứ chỉ có được MD5 (clear_text_pass), và kết quả hash khác hoàn toàn so với MD5 (clear_text_pass, k) nên có thể giải quyết kiểu tấn công pass the hash (với điều kiện clear_text_pass phải đủ dài để ko thể bị đoán ngược từ bản MD5(clear_text) ).