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.  

Mình không nghĩ một administrator nào lại có thể nói rằng: à hệ thống của thằng kia DDoS dễ hơn kìa, sao mày không tấn công nó đi, tấn công tao làm gì.

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!

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) ).