Nhân cuộc tranh luận về mật khẩu Internet Banking tôi mới nhớ năm 2016 tôi phát hiện một cách vô hiệu hóa hàng loạt tài khoản của một vài ngân hàng trong nước. Thời điểm đó, một người xấu có thể dễ dàng vô hiệu hóa vài chục nghìn tài khoản. Nếu có sự chuẩn bị trong 1-2 tuần, hoàn toàn có thể vô hiệu hóa vài trăm nghìn tài khoản. Tôi đã thông báo cho các bên liên quan.
Các dịch vụ Mobile Banking mà tôi xem đều sử dụng số điện thoại để làm tên người dùng. Tôi tìm thấy một cách để xác định một số điện thoại bất kỳ có sử dụng dịch vụ Mobile Banking của một số ngân hàng trong nước. Tôi viết một chương trình, chạy trong 2 ngày cuối tuần thì tìm được gần 1500 tài khoản. Việc làm này được sự đồng ý của bên ngân hàng.
Nếu chạy lâu hơn, tối ưu chương trình, tìm được vài trăm nghìn tài khoản là chuyện trong tầm tay. Sau khi đã có danh sách tài khoản, chương trình của tôi có thể tạo ra sự kiện đăng nhập sai và từ đó vô hiệu hóa các tài khoản, vì các ngân hàng này đều thực hiện chính sách "khóa tài khoản nếu nhập mật khẩu sai 5 lần; khách hàng muốn kích hoạt phải đến chi nhánh". Hôm nay tôi mới biết chính sách này là do Ngân Hàng Nhà Nước đặt ra. Chính sách này tưởng chừng như sẽ giúp tăng bảo mật cho khách hàng, nhưng vô tình lại tạo ra một lỗ hổng có thể ảnh hưởng đến thương hiệu và uy tín của ngân hàng. Thử tưởng tượng chuyện gì sẽ xảy ra khi một ngày đẹp trời nào đó tự dưng không ai có thể đăng nhập vào tài khoản ngân hàng của họ nữa?
Đây không phải là lỗ hổng nguy hiểm nhất mà tôi phát hiện. Làm việc với các bên liên quan để sửa lỗi, tôi nhận ra rằng vấn đề không phải họ không quan tâm đến bảo mật, mà là họ quan tâm chưa đúng chỗ. Mặc dù rất muốn làm cho đúng, cho tốt, rất cầu thị và sẵn sàng đầu tư, nhưng các đơn vị này thường làm thiếu những chỗ cần và thừa những chỗ không cần. Trong báo cáo dài gần 20 trang, tôi có viết thế này (xin được lọc bỏ một số chỗ nhạy cảm, vì lý do hiển nhiên):
Cân bằng giữa an toàn và trải nghiệm người dùng
Đối với sản phẩm tài chính ngân hàng như <đã lọc bỏ>, an toàn luôn được đặt lên hàng đầu. Kiện toàn bảo mật cho một ứng dụng như thế này không quá khó, khó khăn nằm ở chỗ làm sao cho an toàn mà lại không gây ảnh hưởng đến trải nghiệm của người sử dụng. Một ngôi nhà có 10 lớp cửa, mỗi cửa có 10 ổ khóa khác nhau, sẽ rất an toàn, nhưng không ai muốn ở trong ngôi nhà đó, vì ra vào rất bất tiện. Một sản phẩm rất an toàn nhưng không ai có thể sử dụng được rồi sẽ thất bại.
Tôi thấy <đã lọc bỏ> chưa có sự cân bằng giữa an toàn và trải nghiệm người dùng. Ví dụ như khi khách hàng nhập sai mật khẩu 5 lần, tài khoản của họ bị khóa ngay lập tức, phải trực tiếp ra quầy giao dịch mới có thể mở khóa. Một thiết kế như vầy rất an toàn, nhưng cũng tạo ra một trải nghiệm rất tồi cho khách hàng. Hoặc như hiện tại <đã lọc bỏ> thực hiện rất nhiều thao tác mã hóa, nhằm mục đích che dấu cách thức hoạt động của app. Những thao tác này đóng góp rất nhỏ vào sự an toàn của app, nhưng lại ảnh hưởng rất lớn đến trải nghiệm của người dùng, vì chúng làm tăng kích thước app, giảm tính ổn định, tăng thời gian xử lý yêu cầu, gây tốn pin, tốn băng thông.
Phát triển sản phẩm với giả định tất cả phần mềm đều là mã nguồn mở
Một hệ thống an toàn là một hệ thống mở, ai cũng biết cách thức nó hoạt động, nhưng không ai có thể phá vỡ nó. Nếu sự an toàn của hệ thống phụ thuộc vào giả định rằng không ai biết cách nó hoạt động ra sao, không sớm thì muộn hệ thống đó sẽ bị tấn công. Làm rối rắm mã hay che dấu cách thức hoạt động của phần mềm không phải là không có tác dụng trong việc tăng cường bảo mật cho hệ thống, nhưng chúng không thể là phương thức bảo vệ duy nhất. Dịch ngược mã phần mềm khó, nhưng rất nhiều người làm được.
Tôi thấy sự an toàn của <đã lọc bỏ> phụ thuộc hoàn toàn vào bí mật của giao thức giữa app và máy chủ. Một khi đã hiểu được giao thức này, ai cũng có thể <đã lọc bỏ>. Khi thiết kế lại hệ thống này, người thiết kế cần phải tự hỏi rằng nếu giao thức giữa app và máy chủ bị tiết lộ ra ngoài thì người ta sẽ làm được gì?
Thiết kế của hệ thống cần phải là thiết kế mở vì chỉ như vậy mới chống lại được các hành vi phá hoại, xâm nhập từ bên trong, vốn là mối nguy lớn nhất cho các hệ thống tài chính ngân hàng. Tôi đoán rằng rất nhiều nhân viên của <đã lọc bỏ> hiểu giao thức giữa app và máy chủ, câu hỏi đặt ra là nếu những người này muốn <đã lọc bỏ>, làm sao để ngăn chặn họ? Chỉ có thể trả lời được câu hỏi này bằng cách xây dựng hệ thống với giả định rằng kẻ tấn công đã biết rõ mã nguồn và tài liệu thiết kế.
Quay trở lại cuộc tranh luận về mật khẩu Internet Banking, tôi thấy hứng khởi khi những người có uy tín trong cộng đồng bàn về chuyện cân bằng giữa an toàn và tiện lợi. Đây là đề tài mà tôi đã viết nhiều lần trên blog này. Trong chương trình đào tạo kỹ sư an toàn thông tin phải có một lớp nói về chuyện này. Mọi sinh viên an toàn thông tin đều cần phải đọc The Design of Everyday Things. Không riêng gì an toàn thông tin, bất kỳ ai làm sản phẩm sẽ khó thành công nếu không quan tâm hoặc thiếu kiến thức về thiết kế và trải nghiệm người dùng.
Các tính năng bảo mật thường là rào cản ngăn chặn khách hàng làm việc họ muốn làm. Khách hàng muốn chuyển tiền, chứ không phải muốn đăng nhập, rồi lấy điện thoại kiểm tra xem tin nhắn OTP đến chưa, nếu chờ hoài chưa đến lại phải nhấn nút gửi lại, xong rồi phải cóp mã OTP vào cái hộp nhỏ xíu. Cực chẳng đã phải làm, chứ nào ai có hứng thú gì với ba cái thủ tục này. Không riêng gì bảo mật, công nghệ tốt phải là công nghệ biết ẩn mình ở phía sau, không gây phiền hà, không cản trở, không gây khó khăn, không làm cho khách hàng bực đến nỗi chửi sản phẩm ngu :-).
Nhưng các thủ tục bảo mật này là để bảo vệ khách hàng cơ mà!?
Là một kỹ sư bảo mật, tôi hiểu tại sao cần phải kiểm tra, nhưng trách nhiệm của một kỹ sư bảo mật không chỉ đơn thuần là làm cho sản phẩm an toàn bằng mọi giá, mà phải làm sao tìm được điểm cân bằng giữa an toàn, tiện lợi và rất nhiều yếu tố khác (chi phí sản xuất, giá thành sản phẩm, time to market, v.v.) Chúng tôi hay nói đùa rằng mỗi một bước kiểm tra thêm vào là công ty mất đi một nửa khách hàng tiềm năng, thành ra không phải cứ muốn thêm vào là thêm.
Công việc hàng ngày của tôi và nhiều đồng nghiệp không có gì khác ngoài việc tìm kiếm và sáng tạo các giải pháp bảo mật càng ít ảnh hưởng đến sự tiện lợi của sản phẩm càng tốt. Chúng tôi muốn tối đa sự tiện lợi, làm sao khách hàng không phải chờ, không phải click quá nhiều nút, không phải đưa ra quá nhiều quyết định, nói chung là không cần phải suy nghĩ cũng có thể xài được sản phẩm. Câu hỏi mà chúng tôi thường hỏi không phải là thêm vào bước kiểm tra gì, mà là có thể loại bỏ, ẩn đi bước kiểm tra nào?
Các nguy cơ an toàn thông tin thường có hai cách giải quyết: bằng quy trình hoặc bằng công nghệ. Bảo vệ bằng quy trình là quy định cấm làm chuyện này, không cho phép làm việc kia. Ví dụ yêu cầu mật khẩu phải có chữ hoa, chữ thường, phải có số, có ký tự đặc biệt, phải dài bao nhiêu ký tự là một giải pháp quy trình. Giải pháp quy trình sẽ gây cản trở cho khách hàng, tôi xem mỗi quy định đặt ra là một thất bại của người làm an toàn thông tin, thành ra chừng nào không giải quyết được bằng công nghệ tôi mới nghĩ đến chuyện đặt ra quy định.
Tôi hay nói với đồng nghiệp về một bài kiểm tra đơn giản để đánh giá xem chúng tôi có thành công hay chưa trong việc làm cho sản phẩm an toàn nhưng vẫn tiện lợi: nếu mẹ tôi không thể xài được sản phẩm một cách an toàn thì chúng tôi chưa thành công. Mẹ tôi có một tài khoản Gmail, nhưng bà không nhớ mật khẩu. Trước đây, Gmail bắt buộc người dùng phải đăng nhập lại sau 2 tuần. Chúng tôi phát hiện ra có nhiều khách hàng như mẹ tôi, không nhớ hoặc không biết mật khẩu của họ là gì, thành ra mỗi lần bắt họ đăng nhập lại là họ bỏ luôn, không xài Gmail nữa. Tại sao phải bắt tất cả khách hàng đăng nhập lại? Chúng tôi không tìm được câu trả lời thỏa đáng và quyết định bỏ quy định đó đi, thay bằng một giải pháp kỹ thuật yêu cầu đăng nhập lại khi và chỉ khi khách hàng thuộc diện rủi ro cao đang muốn thực hiện một số thao tác nhạy cảm.
Điểm mấu chốt là phải bảo vệ khách hàng bằng công nghệ, chứ không phải bảo vệ bằng quy định gây phiền toái. Với góc nhìn này, chính sách khóa tài khoản sau khi đăng nhập sai 5 lần, yêu cầu phải ra chi nhánh để kích hoạt lại cần phải được thay đổi. Nếu đây là quy định của Ngân Hàng Nhà Nước, các ngân hàng phải kiến nghị để loại bỏ quy định này, ít nhất là phải loại bỏ quy định ra chi nhánh để kích hoạt. Nếu muốn khóa, có thể tạm khóa một thời gian ngắn, sau đó tự động mở lại. Câu hỏi cho các kỹ sư bảo mật ngân hàng là:
* tại sao lại là 5 lần? có cách nào tăng số lần lên hay không?
* nếu tạm khóa thì tạm khóa trong bao lâu? có cách nào giảm thời gian tạm khóa xuống hay không?
Tôi có thể nói cả ngày về chuyện này, viết cũng phải được một cuốn sách, nhưng nói như vầy không phải để so sánh các ngân hàng trong nước với Google. Mỗi lần một người dùng đăng nhập vào Gmail là có biết bao nhiêu công nghệ ẩn mình âm thầm bảo vệ người dùng và Google. Những công nghệ này được phát triển bởi một đội ngũ kỹ sư hùng hậu. Rất khó để có thể xây dựng được đội ngũ như vậy ở Việt Nam. Điều mà tôi muốn khơi gợi ở đây là nhận thức. Không xem trọng an toàn thông tin dở đã đành, xem trọng nhưng không đúng chỗ cũng dở không kém. Khi đã hiểu ra cách làm đúng, có rất nhiều thứ có thể cải thiện được ngay, mà không cần phải đầu tư tốn kém.
Các dịch vụ Mobile Banking mà tôi xem đều sử dụng số điện thoại để làm tên người dùng. Tôi tìm thấy một cách để xác định một số điện thoại bất kỳ có sử dụng dịch vụ Mobile Banking của một số ngân hàng trong nước. Tôi viết một chương trình, chạy trong 2 ngày cuối tuần thì tìm được gần 1500 tài khoản. Việc làm này được sự đồng ý của bên ngân hàng.
Nếu chạy lâu hơn, tối ưu chương trình, tìm được vài trăm nghìn tài khoản là chuyện trong tầm tay. Sau khi đã có danh sách tài khoản, chương trình của tôi có thể tạo ra sự kiện đăng nhập sai và từ đó vô hiệu hóa các tài khoản, vì các ngân hàng này đều thực hiện chính sách "khóa tài khoản nếu nhập mật khẩu sai 5 lần; khách hàng muốn kích hoạt phải đến chi nhánh". Hôm nay tôi mới biết chính sách này là do Ngân Hàng Nhà Nước đặt ra. Chính sách này tưởng chừng như sẽ giúp tăng bảo mật cho khách hàng, nhưng vô tình lại tạo ra một lỗ hổng có thể ảnh hưởng đến thương hiệu và uy tín của ngân hàng. Thử tưởng tượng chuyện gì sẽ xảy ra khi một ngày đẹp trời nào đó tự dưng không ai có thể đăng nhập vào tài khoản ngân hàng của họ nữa?
Đây không phải là lỗ hổng nguy hiểm nhất mà tôi phát hiện. Làm việc với các bên liên quan để sửa lỗi, tôi nhận ra rằng vấn đề không phải họ không quan tâm đến bảo mật, mà là họ quan tâm chưa đúng chỗ. Mặc dù rất muốn làm cho đúng, cho tốt, rất cầu thị và sẵn sàng đầu tư, nhưng các đơn vị này thường làm thiếu những chỗ cần và thừa những chỗ không cần. Trong báo cáo dài gần 20 trang, tôi có viết thế này (xin được lọc bỏ một số chỗ nhạy cảm, vì lý do hiển nhiên):
Cân bằng giữa an toàn và trải nghiệm người dùng
Đối với sản phẩm tài chính ngân hàng như <đã lọc bỏ>, an toàn luôn được đặt lên hàng đầu. Kiện toàn bảo mật cho một ứng dụng như thế này không quá khó, khó khăn nằm ở chỗ làm sao cho an toàn mà lại không gây ảnh hưởng đến trải nghiệm của người sử dụng. Một ngôi nhà có 10 lớp cửa, mỗi cửa có 10 ổ khóa khác nhau, sẽ rất an toàn, nhưng không ai muốn ở trong ngôi nhà đó, vì ra vào rất bất tiện. Một sản phẩm rất an toàn nhưng không ai có thể sử dụng được rồi sẽ thất bại.
Tôi thấy <đã lọc bỏ> chưa có sự cân bằng giữa an toàn và trải nghiệm người dùng. Ví dụ như khi khách hàng nhập sai mật khẩu 5 lần, tài khoản của họ bị khóa ngay lập tức, phải trực tiếp ra quầy giao dịch mới có thể mở khóa. Một thiết kế như vầy rất an toàn, nhưng cũng tạo ra một trải nghiệm rất tồi cho khách hàng. Hoặc như hiện tại <đã lọc bỏ> thực hiện rất nhiều thao tác mã hóa, nhằm mục đích che dấu cách thức hoạt động của app. Những thao tác này đóng góp rất nhỏ vào sự an toàn của app, nhưng lại ảnh hưởng rất lớn đến trải nghiệm của người dùng, vì chúng làm tăng kích thước app, giảm tính ổn định, tăng thời gian xử lý yêu cầu, gây tốn pin, tốn băng thông.
Phát triển sản phẩm với giả định tất cả phần mềm đều là mã nguồn mở
Một hệ thống an toàn là một hệ thống mở, ai cũng biết cách thức nó hoạt động, nhưng không ai có thể phá vỡ nó. Nếu sự an toàn của hệ thống phụ thuộc vào giả định rằng không ai biết cách nó hoạt động ra sao, không sớm thì muộn hệ thống đó sẽ bị tấn công. Làm rối rắm mã hay che dấu cách thức hoạt động của phần mềm không phải là không có tác dụng trong việc tăng cường bảo mật cho hệ thống, nhưng chúng không thể là phương thức bảo vệ duy nhất. Dịch ngược mã phần mềm khó, nhưng rất nhiều người làm được.
Tôi thấy sự an toàn của <đã lọc bỏ> phụ thuộc hoàn toàn vào bí mật của giao thức giữa app và máy chủ. Một khi đã hiểu được giao thức này, ai cũng có thể <đã lọc bỏ>. Khi thiết kế lại hệ thống này, người thiết kế cần phải tự hỏi rằng nếu giao thức giữa app và máy chủ bị tiết lộ ra ngoài thì người ta sẽ làm được gì?
Thiết kế của hệ thống cần phải là thiết kế mở vì chỉ như vậy mới chống lại được các hành vi phá hoại, xâm nhập từ bên trong, vốn là mối nguy lớn nhất cho các hệ thống tài chính ngân hàng. Tôi đoán rằng rất nhiều nhân viên của <đã lọc bỏ> hiểu giao thức giữa app và máy chủ, câu hỏi đặt ra là nếu những người này muốn <đã lọc bỏ>, làm sao để ngăn chặn họ? Chỉ có thể trả lời được câu hỏi này bằng cách xây dựng hệ thống với giả định rằng kẻ tấn công đã biết rõ mã nguồn và tài liệu thiết kế.
Quay trở lại cuộc tranh luận về mật khẩu Internet Banking, tôi thấy hứng khởi khi những người có uy tín trong cộng đồng bàn về chuyện cân bằng giữa an toàn và tiện lợi. Đây là đề tài mà tôi đã viết nhiều lần trên blog này. Trong chương trình đào tạo kỹ sư an toàn thông tin phải có một lớp nói về chuyện này. Mọi sinh viên an toàn thông tin đều cần phải đọc The Design of Everyday Things. Không riêng gì an toàn thông tin, bất kỳ ai làm sản phẩm sẽ khó thành công nếu không quan tâm hoặc thiếu kiến thức về thiết kế và trải nghiệm người dùng.
Các tính năng bảo mật thường là rào cản ngăn chặn khách hàng làm việc họ muốn làm. Khách hàng muốn chuyển tiền, chứ không phải muốn đăng nhập, rồi lấy điện thoại kiểm tra xem tin nhắn OTP đến chưa, nếu chờ hoài chưa đến lại phải nhấn nút gửi lại, xong rồi phải cóp mã OTP vào cái hộp nhỏ xíu. Cực chẳng đã phải làm, chứ nào ai có hứng thú gì với ba cái thủ tục này. Không riêng gì bảo mật, công nghệ tốt phải là công nghệ biết ẩn mình ở phía sau, không gây phiền hà, không cản trở, không gây khó khăn, không làm cho khách hàng bực đến nỗi chửi sản phẩm ngu :-).
Nhưng các thủ tục bảo mật này là để bảo vệ khách hàng cơ mà!?
Là một kỹ sư bảo mật, tôi hiểu tại sao cần phải kiểm tra, nhưng trách nhiệm của một kỹ sư bảo mật không chỉ đơn thuần là làm cho sản phẩm an toàn bằng mọi giá, mà phải làm sao tìm được điểm cân bằng giữa an toàn, tiện lợi và rất nhiều yếu tố khác (chi phí sản xuất, giá thành sản phẩm, time to market, v.v.) Chúng tôi hay nói đùa rằng mỗi một bước kiểm tra thêm vào là công ty mất đi một nửa khách hàng tiềm năng, thành ra không phải cứ muốn thêm vào là thêm.
Công việc hàng ngày của tôi và nhiều đồng nghiệp không có gì khác ngoài việc tìm kiếm và sáng tạo các giải pháp bảo mật càng ít ảnh hưởng đến sự tiện lợi của sản phẩm càng tốt. Chúng tôi muốn tối đa sự tiện lợi, làm sao khách hàng không phải chờ, không phải click quá nhiều nút, không phải đưa ra quá nhiều quyết định, nói chung là không cần phải suy nghĩ cũng có thể xài được sản phẩm. Câu hỏi mà chúng tôi thường hỏi không phải là thêm vào bước kiểm tra gì, mà là có thể loại bỏ, ẩn đi bước kiểm tra nào?
Các nguy cơ an toàn thông tin thường có hai cách giải quyết: bằng quy trình hoặc bằng công nghệ. Bảo vệ bằng quy trình là quy định cấm làm chuyện này, không cho phép làm việc kia. Ví dụ yêu cầu mật khẩu phải có chữ hoa, chữ thường, phải có số, có ký tự đặc biệt, phải dài bao nhiêu ký tự là một giải pháp quy trình. Giải pháp quy trình sẽ gây cản trở cho khách hàng, tôi xem mỗi quy định đặt ra là một thất bại của người làm an toàn thông tin, thành ra chừng nào không giải quyết được bằng công nghệ tôi mới nghĩ đến chuyện đặt ra quy định.
Tôi hay nói với đồng nghiệp về một bài kiểm tra đơn giản để đánh giá xem chúng tôi có thành công hay chưa trong việc làm cho sản phẩm an toàn nhưng vẫn tiện lợi: nếu mẹ tôi không thể xài được sản phẩm một cách an toàn thì chúng tôi chưa thành công. Mẹ tôi có một tài khoản Gmail, nhưng bà không nhớ mật khẩu. Trước đây, Gmail bắt buộc người dùng phải đăng nhập lại sau 2 tuần. Chúng tôi phát hiện ra có nhiều khách hàng như mẹ tôi, không nhớ hoặc không biết mật khẩu của họ là gì, thành ra mỗi lần bắt họ đăng nhập lại là họ bỏ luôn, không xài Gmail nữa. Tại sao phải bắt tất cả khách hàng đăng nhập lại? Chúng tôi không tìm được câu trả lời thỏa đáng và quyết định bỏ quy định đó đi, thay bằng một giải pháp kỹ thuật yêu cầu đăng nhập lại khi và chỉ khi khách hàng thuộc diện rủi ro cao đang muốn thực hiện một số thao tác nhạy cảm.
Điểm mấu chốt là phải bảo vệ khách hàng bằng công nghệ, chứ không phải bảo vệ bằng quy định gây phiền toái. Với góc nhìn này, chính sách khóa tài khoản sau khi đăng nhập sai 5 lần, yêu cầu phải ra chi nhánh để kích hoạt lại cần phải được thay đổi. Nếu đây là quy định của Ngân Hàng Nhà Nước, các ngân hàng phải kiến nghị để loại bỏ quy định này, ít nhất là phải loại bỏ quy định ra chi nhánh để kích hoạt. Nếu muốn khóa, có thể tạm khóa một thời gian ngắn, sau đó tự động mở lại. Câu hỏi cho các kỹ sư bảo mật ngân hàng là:
* tại sao lại là 5 lần? có cách nào tăng số lần lên hay không?
* nếu tạm khóa thì tạm khóa trong bao lâu? có cách nào giảm thời gian tạm khóa xuống hay không?
Tôi có thể nói cả ngày về chuyện này, viết cũng phải được một cuốn sách, nhưng nói như vầy không phải để so sánh các ngân hàng trong nước với Google. Mỗi lần một người dùng đăng nhập vào Gmail là có biết bao nhiêu công nghệ ẩn mình âm thầm bảo vệ người dùng và Google. Những công nghệ này được phát triển bởi một đội ngũ kỹ sư hùng hậu. Rất khó để có thể xây dựng được đội ngũ như vậy ở Việt Nam. Điều mà tôi muốn khơi gợi ở đây là nhận thức. Không xem trọng an toàn thông tin dở đã đành, xem trọng nhưng không đúng chỗ cũng dở không kém. Khi đã hiểu ra cách làm đúng, có rất nhiều thứ có thể cải thiện được ngay, mà không cần phải đầu tư tốn kém.