+17

Cafe chém gió: lưu mật khẩu trong CSDL (Phần 2)

Thỉnh thoảng các trang tin tức, báo mạng, facebook,... có đăng những thông tin về một dịch vụ, mội doanh nghiệp nào đó bị hacker tấn công, đánh cắp và rao bán dữ liệu trên "chợ đen". Đối tượng bị hacker nhắm đến thường là những trang web, dịch vụ lớn, có nhiều người dùng.

image.png

Ngay cả một công ty bình thường tại VN cũng bị tấn công. Hacker trong vụ này còn nghênh ngang khiêu khích trực tiếp, bằng cách đăng tải một video cho thấy cách hắn ta truy cập được vào hệ thống mạng nội bộ của công ty này, từ đó tiến hành tấn công sâu hơn và đánh cắp dữ liệu.

Bị hacker tấn công thì là vấn đề của doanh nghiệp, nhưng dữ liệu bị lộ thì người dùng là đối tượng cần hoang mang. Nếu hacker có thể dựa vào những dữ liệu này để tìm được mật khẩu của người dùng thì rất nguy hiểm.

Vậy làm thế nào để bảo vệ thật tốt mật khẩu của người dùng kể cả khi cơ sở dữ liệu không may bị hacker đánh cắp và rao bán? Thay vì đọc một bài viết mang tính kỹ thuật đơn thuần, hôm nay chúng ta đổi phong cách một chút. Hãy theo dõi buổi trò chuyện dưới đây để biết thêm về cách bảo vệ mật khẩu an toàn nhé.

Buổi trò chuyện

... (tiếp nối phần 1) ...

Ông anh: Thế mấy dự án trước bên chú dùng thuật toán hash nào? Mấy cái nổi như MD5 với SHA-1 à?

Cậu em: Không anh, làm sao mà dùng được.

Ông anh: Sao mà không được? MD5 với SHA-1 có tốc độ tính toán nhanh, dữ liệu hash ra thì không lớn, tiết kiệm rất nhiều tài nguyên của máy chủ còn gì?

Cậu em: Nhưng mà 2 cái đó được khuyến nghị là không nên sử dụng vì không còn đảm bảo an toàn nữa.

Ông anh: Dựa vào đâu mà nói là không đảm bảo an toàn nữa?

Cậu em: Em đọc được là MD5 với SHA-1 phổ biến và được sử dụng từ lâu rồi, độ dài chuỗi hash ra cũng thấp. Nên có rất nhiều kết quả hash đã được tính toán và lưu trữ sẵn rồi. Em còn biết có nhiều công cụ crack hash trên mạng cho sử dụng miễn phí, rất nhiều chuỗi hash đều tìm ra được bản gốc khi sử dụng các công cụ đó cơ.

Ông anh: Ừ, một cái nữa là khả năng chống trùng lặp của MD5 thấp, cũng do độ dài chuỗi hash chỉ có 32 ký tự mà ra.

Cậu em: Em cũng từng thấy qua về cái việc MD5 có thể xuất hiện trùng lặp rồi, nhưng mà rõ ràng số lượng kết quả có thể xảy ra của MD5 không thấp, thế thì cũng rất khó để trùng lặp mới đúng chứ nhỉ?

Ông anh: Đúng là trên lý thuyết có tối đa 16^32 kết quả hash khác nhau. Nhưng đa số người dùng sẽ không đặt mật khẩu là một chuỗi ngẫu nhiên vô nghĩa bất quy tắc. Có đầy người đặt trùng mật khẩu với nhau đấy thôi.

Cậu em: Thế thì việc mật khẩu khác nhau có chung mã hash cũng có dễ xảy ra hơn đâu anh 😏

Ông anh: Cho dù ở trên lý thuyết thì việc trùng lặp vẫn có khả năng xảy ra cao hơn so với các thuật toán hash khác, nên người ta mới khuyến nghị không nên dùng nữa đấy thôi. Còn việc trùng lặp kết quả hash thì anh thấy dễ xảy ra với trường hợp đầu vào lớn cơ. Như kiểu em tính MD5 hash cho 2 tệp tin nặng mấy trăm Mb, vài Gb ấy. Lúc này thì do kích thước dữ liệu từ rất lớn giảm xuống chỉ còn 32 ký tự, nên việc 2 tệp tin có cùng mã hash dễ xảy ra hơn.

image.png

Cậu em: bọn em dùng SHA-3 để hash mật khẩu luôn, thế là an tâm.

Ông anh: Cũng được, dùng thuật toán hash tốt cho ra chuỗi hash có độ dài lớn sẽ an toàn hơn. Nhưng mà nếu đen bị tấn công thì vẫn có thể thất thủ.

Cậu em: Nếu bọn em triển khai thêm việc sử dụng salt trong quá trình hash mật khẩu thì ổn áp luôn chưa anh.

Ông anh: Sẽ ok hơn. Nhưng mà nhớ tìm cách bảo vệ đống salt đấy nữa nhé, không là cũng công cốc.

Cậu em: Thế là lại đẻ ra thêm 1 bài toán nữa à 🤧

Ông anh: Cũng có thể phát triển cơ chế sinh salt ngẫu nhiên và duy nhất với mỗi tài khoản. Đảm bảo một tài khoản chạy cơ chế đó bao nhiêu lần vẫn ra cùng cái salt là được.

Cậu em: Nghe cách đó có vẻ ok hơn anh ạ 🥴

Ông anh: Thực ra anh biết giờ người ta có thuật toán hash khác okla hơn mấy cái MD với SHA cơ.

Cậu em: Cái nào thế anh?

Ông anh: Bcrypt.

Cậu em: Nó có gì vượt trội hơn hả anh?

Ông anh: Nó gây lãng phí thời gian =))))

Cậu em: 🤡

Ông anh: Đúng thế thật. Mấy thuật toán hash MD với SHA được thiết kế để có tốc độ tính toán nhanh. Bcrypt thì được xây dựng dựa trên thuật toán mã hoá Blowfish. Blowfish thì có tốc độ mã hoá ok, nhưng qua trình chuẩn bị khoá mã hoá của thuật toán này lại tốn thời gian. Bcrypt cũng thừa hưởng đặc điểm này. Nhờ vậy có thể bảo vệ mật khẩu tốt hơn trước những cuộc tấn công brute force. Hacker muốn lợi dụng việc thử thật nhiều lần để tìm ra bản rõ tương ứng với 1 chuỗi hash, nhưng thử càng nhiều lần thì thời gian hao tổn do thay đổi tham số càng cao. Việc "lãng phí thời gian" này giúp giảm khả năng bẻ khoá của hacker.

Cậu em: nếu thế thì có ảnh hưởng tới tốc độ xử lý của máy chủ không anh?

Ông anh: Không phải flo, mình tính mã hash của mật khẩu, thì mỗi tài khoản chỉ cần chạy 1 lần thì chẳng ảnh hưởng gì mấy cả. Phía hacker phải chạy hàng nghìn lần chỉ để tìm ra 1 mật khẩu thì mới tốn thời gian.

Cậu em: Cao kiến, cao kiến.

Ông anh: Mà sử dụng bcrypt thì còn bắt buộc phải sử dụng salt nữa. Đảm bảo lập trình viên code phần này không thể sơ suất quên sử dụng salt được.

Cậu em: Hay thật đấy, cứ nghĩ mình biết dùng SHA-3 là đã ổn, hoá ra vẫn còn bcrypt okla hơn.

Ông anh: Có cả bài viết nói kỹ hơn về bcrypt đây nhé, về đọc thêm rồi xem xét áp dụng vào dự án: https://auth0.com/blog/hashing-in-action-understanding-bcrypt/

Cậu em: Cảm ơn anh nhiều nhé, lát nữa anh em mình ra quán bia, em mời.

Ông anh: Nó lại hợp lý 🤑


All rights reserved

Viblo
Hãy đăng ký một tài khoản Viblo để nhận được nhiều bài viết thú vị hơn.
Đăng kí