Câu chuyện này rất tếu và hay. Một sys admin biết hệ thống bị hacked. Hacker tạo một account. Sys admin không biết password của account nọ. Dĩ nhiên, hắn biết MD5-image của password. Làm thế nào để tìm pre-image của một hash function? Google!
Hah. Một chú khác thấy trò này vui tạo cả một webpage chơi. Nếu bạn muốn thử, gõ password của bạn vào. Website này tạo MD5-image của password và cho bạn một cái link tìm trên Google. Nếu tìm thấy thì password của bạn đã có người dùng, và tìm pre-image chỉ đơn giản là một Google search. Có cả một database của MD5-images để bạn tìm ngược lại các passwords.
Bài học: duyệt qua /etc/password trong hệ thống của trường/sở bạn đang học/làm việc. Tìm pre-images bằng Google. Thế nào cũng tìm ra một vài passwords mà không cần viết script duyệt từ điển gì hết. Bị phạt tôi không chịu trách nhiệm.
4 Comments
Giả sử bạn có 1 table trong database chứa 1 tỉ record lưu pre-image và và 1 hash tương ứng .
Khi cần crack 1 cái hash password bạn select trong DB , hay tự xây dựng chương trình
crack (sử dụng 1 tỉ pre-image và hàm mã hóa) cách nào cho kết quả nhanh hơn ? vì sao ?
Chào poke,
Câu hỏi hay! Không thấy ai trả lời, tôi lại ba hoa vậy. Tìm pre-image từ DB của các MD5-images nhanh hơn. Một cấu trúc cây tìm kiếm đơn giản cũng nhanh hơn cách kia nhiều lần (log vs linear).
Đồng ý với ý kiến của anh Hưng . Như vậy có thể thấy giới Hacker thường xây dựng những chương trình để crack password sử dụng dict base hoặc vét cạn là sai lầm .
Thay vì điều này họ có thể xây dụng một bộ từ điển như mô tả ở trên . Một bộ tử điển khổng lồ có sự đóng góp của nhiều người .
Hoặc xây dựng 1 chương trình kiểu google (webot) kết hợp với Nature Language Processing -NLP (phân tích text, tách câu/từ,thống kê tần xuất)
để tự xây dụng bộ từ điển pre-image/MD5-image thì việc crack các hash password có lẽ khả quan hơn nhiều .
Cũng không hẳn là sai lầm. Vấn đề là các password khi được chuyển qua MD5-image thường được gắn thêm salt, nhằm làm hạn chế hiệu quả của việc sử dụng DB như trên. Một password x khi chuyển thành MD5-image y nếu được gắn thêm 16-bit salt chả hạn thì DB sẽ phải phình to ra gấp 2^16 lần. Việc lưu trữ và sử dụng một DB super khổng lồ như thế có lẽ không khả thi.