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

Cuối tháng 6/2016, 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.

Bây giờ nói đến chuyện làm sao ngay cả engineer (kỹ sư) hoặc sysadmin (quản trị hệ thống) làm việc trên các máy chủ lưu mật khẩu cũng không thể nhìn thấy các mật khẩu của người dùng. Chỗ này nhiêu khê hơn nhiều. Về mặt nguyên tắc, chúng ta không thể loại trừ 100%, vì sẽ có lúc hệ thống gặp sự cố, phải cho sysadmin hoặc engineer vào để debug.

Nhưng đó sẽ là những tình huống ngoại lệ và mỗi phiên truy cập như vậy đều phải được một hệ thống trung gian ghi lại nhật ký một cách tự động. Ví dụ như muốn SSH vào server phải đến hỏi một server trung gian, server này sẽ ghi lại nhật ký và cấp cho một SSH certificate tạm thời. Nhật ký này sẽ được kiểm tra định kỳ hàng tháng. Nói cách khác, chúng ta trust-but-verify (tin nhưng phải kiểm chứng-pv) các kỹ sư. Ông nào làm bậy sẽ bị phát hiện, không sớm thì muộn.

Đối với những thao tác mang tính định kỳ như cập nhật hệ thống, deploy new code, điều quan trọng là phải có một hệ thống release management được tự động hóa. Ví dụ như khi lập trình viên viết code mới, code này phải được review bởi ít nhất một người khác, xong rồi mới được commit vào repository (kho lưu –pv) của công ty.

Cấu hình server cũng vậy, tất cả phải qua khâu review rồi mới được chấp nhận. Chuyện này phải trở thành văn hóa của công ty. Khi đã sẵn sàng để tải code mới lên hệ thống, một quy trình tự động sẽ lấy code từ repository, build ra binary, chuyển lên máy chủ để chạy. Trong suốt quá trình này, các kỹ sư có thể theo dõi tiến trình và can thiệp khi cần thiết, nhưng nếu mọi thứ diễn ra trơn tru, con người sẽ không cần phải đụng tay vào nữa.

Theo anh Dương Ngọc Thái, một công ty nhỏ như Money Lover nên tận dụng các giải pháp có sẵn và thuê tư vấn. Money Lover đã rất sáng suốt khi sử dụng dịch vụ cloud computing của Amazon.

Không thể xây dựng các hệ thống này ngày một ngày hai và trong một email ngắn khó có thể diễn ra được hết tất cả các vấn đề cần phải giải quyết. Đối với một công ty nhỏ như Money Lover, thay vì tập trung giải quyết các vấn đề này tôi nghĩ họ nên tận dụng các giải pháp có sẵn và thuê tư vấn. Money Lover đã rất sáng suốt khi sử dụng dịch vụ cloud computing của Amazon, tôi hi vọng là Amazon có các giải pháp cho các vấn đề mà tôi nói ở trên. Tôi làm ở Google nên tôi biết hầu hết các vấn đề này đều có thể được giải quyết bằng các công cụ được cung cấp trên Google Cloud Platform (https://cloud.google.com/products/).

Có người nói đưa dữ liệu lên cloud sợ Amazon hay Google sẽ lấy dữ liệu của họ. Tôi thấy chuyện này giống như lo sử dụng máy tính của Apple hay của Microsoft sợ các công ty này cài backdoor để lấy dữ liệu. Nhưng thôi, đây là chuyện khác, hôm khác nói.”

Việc dùng Amazon Key Management Service (KMS) như là nhà cung cấp dịch vụ mã hóa các mật khẩu là một ý tưởng rất lý thú và khả dĩ, đây kiểu đặt niềm tin vô một bên thứ 3 có uy tín được xác nhận bởi đa số.”

Anh Dương Ngọc Thái sinh năm 1984  và bắt đầu tiếp xúc với máy tính từ năm học lớp 10. Sau khi tốt nghiệp cấp 3, Dương Ngọc Thái thi đỗ vào trường ĐH Bách khoa (ĐHQG TP.HCM) khoa công nghệ thông tin. Từ năm 2007 -2010, Dương Ngọc Thái là trưởng phòng an ninh thông tin, phụ trách công tác bảo mật cho Ngân hàng Đông Á. Tháng 9/2009, Dương Ngọc Thái được nhiều người biết đến với việc phát hiện lỗ hổng bảo mật nguy hiểm của dịch vụ chia sẻ hình ảnh Flickr của hãng Yahoo. Hơn một năm sau, Dương Ngọc Thái phát hiện ra lỗ hổng bảo mật nghiêm trọng của Microsoft - có thể ảnh hưởng đến khả năng bảo mật của hàng triệu website trên toàn cầu. Hiện nay, Dương Ngọc Thái đang là kỹ sư an toàn thông tin tại Google. Trước đó, anh cũng là chuyên gia tư vấn an ninh ứng dụng tại Matasano Security.