Chuyên gia bảo mật của Google bàn về việc lưu mật khẩu trên các ứng dụng như Money Lover_soi kèo ukraine
Cuối tháng 6/2016,êngiabảomậtcủaGooglebànvềviệclưumậtkhẩutrêncácứngdụngnhưsoi kèo ukraine Ngân hàng Vietcombank vừa đưa ra thông báo về việc nâng cao cảnh giác và bảo mật khi sử dụng dịch vụ ngân hàng điện tử, trong đó có cảnh báo về việc không nhập thông tin tài khoản cho các ứng dụng thứ 3, ví dụ như Money Lover. Trước thông báo này, người sáng lập Money Lover, Ngô Xuân Huy đã cam kết về việc bảo mật tài khoản ngân hàng của khách hàng khi sử dụng ứng dụng này.
Anh Dương Ngọc Thái, chuyên gia bảo mật đang làm việc cho Google đã có những nhận định về vấn đề này. ICTnews xin trích nguyên văn góc nhìn về việc thiết kế hệ thống lưu mật khẩu nhạy cảm của người dùng.
“Tôi thấy đây là một vấn đề thú vị. Có ý kiến cho rằng Money Lover có thể hoàn toàn không lưu mật khẩu của user nhưng tôi nghĩ khó có khả năng Money Lover thực hiện theo mô hình này, vì như vậy hệ thống chỉ có dữ liệu mới khi mà user mở app ra, rất khó hiện thực hóa các chức năng thiên về thống kê mà Money Lover muốn làm.
Tôi nghĩ Money Lover lưu mật khẩu của người dùng trên máy chủ của họ. Tôi nghĩ chuyện này cũng bình thường, vì nếu không lưu thì làm sao mà lấy dữ liệu từ ngân hàng về cho được. Có thể có vài ngân hàng triển khai các phương án như OAUTH (một dạng xác thực danh tính người dùng-pv), nhưng tôi nghĩ đa số ngân hàng không có động cơ để làm chuyện đó.
Câu hỏi mà chúng ta quan tâm ở đây là làm sao lưu mật khẩu cho an toàn. Đây là một vấn đề khó, muốn giải quyết phải thay đổi rất nhiều thứ, chuyện này không đơn giản là chỉ cần mã hóa mật khẩu. Hồi trước có lần một công ty làm game hỏi tôi làm thế nào để đảm bảo máy chủ chứa dữ liệu thẻ game của họ không bị chính mấy ông DBA (quản trị cơ sở dữ liệu-pv) vào chỉnh sửa chôm chỉa. Lúc đó tôi không có câu trả lời, nhưng bây giờ tôi nghĩ tôi biết chút ít.
Nếu tôi thiết kế hệ thống này, tôi sẽ chuyển toàn bộ mật khẩu vào lưu ở một nhóm server tách biệt, không làm gì khác, ngoại trừ việc lưu mật khẩu và gửi request đến các ngân hàng để lấy cookies, thông qua một API đơn giản gọn nhẹ. Chỉ có các máy chủ crawler mới có thể sử dụng API này (thông qua TCP/IP firewall hoặc các phương án Digital Signature hoặc MAC, như các API của Amazon hay làm).
Trên server lưu mật khẩu, tôi sẽ mã hóa các mật khẩu này sử dụng dịch vụ Amazon KMS. Nói cách khác nếu ai đó truy cập vào các máy chủ lưu mật khẩu, họ cũng không thể lấy toàn bộ mật khẩu, mà họ phải lần lượt gửi yêu cầu đến KMS để giải mã chúng. Ý tưởng này coi bộ đơn giản nhưng tôi nghĩ nó là mấu chốt trong việc phát hiện, phòng chống và phản ứng lại khi có xâm nhập.
Chúng ta muốn kẻ tấn công phải ở trong hệ thống của mình càng lâu càng tốt, với hy vọng ở càng lâu chúng sẽ tạo ra nhiều “tiếng ồn”, làm gia tăng cơ hội hệ thống giám sát an ninh mạng của chúng ta phát hiện ra chúng. Ví dụ như nếu tôi biết rằng máy chủ lưu mật khẩu chỉ gửi request đến Amazon KMS vào lúc 12h sáng (vì đó là lúc crawler chạy), tôi sẽ thấy hoài nghi khi thấy nhiều request đến KMS vào lúc 1h trưa.
Các crawler (công cụ tự động phân tích dữ liệu-pv) sẽ lấy cookies từ máy chủ lưu mật khẩu, dùng chúng để gửi request đến các ngân hàng, lưu dữ liệu giao dịch của khách hàng vào một nhóm máy chủ tách biệt với các máy chủ lưu mật khẩu (và thậm chí là các crawler). Với kiến trúc như vậy, chúng ta sẽ có thể hạn chế được ai truy cập vào đâu.
Ví dụ đội làm crawler chỉ có thể vào crawler, đội làm mật khẩu chỉ có thể vào máy chủ mật khẩu, đội làm transaction data chỉ có thể làm trên transaction data. Đây là nguyên tắc least privileged (nguyên tắc quyền hạn tối thiểu) mà chúng ta điều biết.