Theo hãng nghiên cứu IDC, thị trường thanh toán di động sẽ đạt mức 1 ngàn tỷ đô la Mỹ vào năm 2017. Hơn một nửa trong số 6000 ngân hàng thương mại ở Mỹ đang cung cấp dịch vụ mobile banking, tỷ lệ đó sẽ tăng lên khoảng 75% trong những năm tới. Nếu trước kia các ngân hàng thường chỉ tùy biến dịch vụ Internet banking cho khách hàng truy cập qua thiết bị di động, thì trong những năm gần đây, những điểm mạnh của ứng dụng trên mobile có thể giúp cung cấp dịch vụ đa dạng và hấp dẫn hơn. Các ứng dụng mobile banking đang là công cụ thu hút khách hàng. Theo một nghiên cứu gần đây của AlixPartners về thị trường Mỹ, mobile banking được xác định là yếu tố quan trọng nhất khiến khách hàng chuyển từ ngân hàng này sang ngân hàng khác (60%), cao hơn hẳn so với mức phí (28%), vị trí chi nhánh (21%) và dịch vụ (21%). Tuy nhiên, theo một khảo sát gần đây về thanh toán di động và gian lận, vấn đề bảo mật và chống gian lận đang được chú ý nhiều hơn. Tỷ lệ khách hàng quan ngại về vấn đề quản trị rủi ro do gian lận và an toàn tài khoản của người dùng đã tăng 40% so với năm 2014. Báo cáo về dịch vụ tài chính cá nhân và dịch vụ tài chính di động của Cục Dự trữ liên bang Mỹ năm 2014 cho thấy: trong số những người tiêu dùng không sử dụng mobile banking có tới 69% nói rằng, vấn đề bảo mật là nguyên nhân chính khiến họ không muốn thử nghiệm.

Những mối đe dọa ngày càng gia tăng

Liệu có phải người dùng đã lo lắng thái quá? Xem xét hai hệ điều hành di động phổ biến nhất hiện nay là Android và iOS. Theo Trend Micro, hơn một triệu ứng dụng Android độc hại được phát hiện trong năm 2013, nâng tổng số ứng dụng độc hại trên hệ điều hành này lên 1,4 triệu. Kaspersky Lab cũng cho biết, 98% phần mềm độc hại được phát hiện được trong năm 2013 nhắm tới hệ điều hành dữ liệu Android. Vấn đề càng trầm trọng hơn khi những lỗ hổng bảo mật lớn như Stagefright và Stagefright 2 xuất hiện trong năm 2015. Hệ điều hành iOS của Apple cũng đang gặp không ít vấn đề. Những vụ việc như WireLurker, Masque Attack, XcodeGhost liên tiếp xuất hiện, dù Apple đã nhanh chóng đưa ra các giải pháp khắc phục, nhưng cũng không làm an lòng người dùng.

Ngoài hệ điều hành, những yếu tố bảo vệ người dùng như giao thức SSL hay mã xác thực một lần OTP cũng đang bị đe dọa từ nhiều phía. Lỗ hổng Heartbleed trong thư viện ứng dụng cực kỳ phổ biến OpenSSL đã khiến cả thế giới chấn động hồi tháng 4/2014. Người ta cũng phát hiện được một loạt lỗ hổng nghiêm trọng trong các thư viện SSL khác. Đối với hệ điều hành iOS, thư viện mã nguồn mở được sử dụng phổ biến là AFNetworking cũng tồn tại lỗ hổng bảo mật nghiêm trọng. Biện pháp xác thực giao dịch bằng OTP gửi qua tin nhắn cũng là mục tiêu của không ít đe dọa như: các kiểu tấn công nhắm vào GSM, mạng 3G và mã độc (ngựa thành Tơ-roa, Zeus, Zitmo, Citadel, Perkele...). Theo Kasperksy Labs, số lượng mã độc tấn công giao dịch ngân hàng đã tăng gấp 20 lần trong năm 2013, phần nhiều trong số đó nhắm tới OTP gửi qua SMS.

Những công nghệ bảo mật mới

Để làm an lòng người dùng và nâng cao tính tiện lợi cho giao dịch bằng điện thoại di động, các doanh nghiệp đã liên tục nghiên cứu và giới thiệu những công nghệ bảo mật mới. Công nghệ TouchID của Apple đã được áp dụng khá thành công trong dịch vụ thanh toán Apple Pay. Các tổ chức thanh toán và ngân hàng như American Express, Citigroup, Discover, JPMorgan Chase ở Mỹ, RBS và Natwest ở Anh đã tích hợp TouchID với ứng dụng mobile trên iPhone 5s, 6 và 6 Plus. Ngoài ra, ngân hàng Westpac New Zealand đã phát triển ứng dụng xác thực vân tay trên các điện thoại di động Samsung.

Ngân hàng Halifax ở Anh thì đang thử nghiệm một công nghệ mới của công ty Bionym (Ca-na-đa). Chiếc vòng tay có tên Nymi đo nhịp tim - thứ duy nhất với mỗi cá nhân - có thể dùng để đăng nhập vào ứng dụng mobile banking và còn có thể áp dụng vào nhiều công việc khác như mở cửa văn phòng, mở cửa xe.... Năm 2013, công ty bảo mật EyeVerify giới thiệu Eyeprint ID - công nghệ sử dụng camera của điện thoại di động chụp bản đồ mạch máu trong tròng mắt người dùng để xác thực. Digital Insight đã cho tích hợp Eyeprint ID vào nền tảng mobile banking của họ. Một số ngân hàng khác đã sử dụng Eyeprint ID cho ứng dụng mobile banking và Wells Fargo - một trong những nhà đầu tư chính của EyeVerify đã bắt đầu sử dụng công nghệ này vào năm 2014.

Ngân hàng ING Hà Lan và US Bank, USAA Bank ở Mỹ đã thử nghiệm công nghệ xác thực bằng giọng nói cho mobile banking. Công ty cung cấp giải pháp này là Nuance Communications cho biết, 35 triệu người đang sử dụng công nghệ của họ và đăng nhập thành công với tỷ lệ tối thiểu 95% (5% còn lại đăng nhập không thành công chủ yếu là do bị nhiễm tiếng ồn xung quanh).

Ngoài ra, những chức năng đơn giản bổ sung vào ứng dụng mobile banking cũng có thể giúp nâng cao độ an toàn cho khách hàng. Ví dụ như Simple, một ứng dụng quản lý tài chính cá nhân, có thể cho phép khách hàng bảo vệ tài khoản bằng cách khóa thẻ ghi nợ bị mất (và mở lại nếu sau đó họ tìm thấy) mà không cần gọi đến tổng đài dịch vụ của ngân hàng.

Một số nguy cơ với ứng dụng mobile banking 

Với sự xuất hiện ngày càng tăng các nguy cơ bảo mật, những công nghệ xác thực mới mà các ngân hàng đang thử nghiệm chỉ có thể là yếu tố bổ sung, góp phần đem lại sự tiện dụng cho khách hàng, chứ không thể giúp khắc phục những điểm yếu của hệ thống. Những nguy cơ bảo mật đối với triển khai các dịch vụ trên thiết bị di động cần được xem xét một cách nghiêm túc để đưa ra những đối sách phù hợp. Một số nguy cơ chính như sau:

- Các thiết bị đã “Jailbrake” hay “Root”: Nếu người dùng can thiệp vào nhân hệ điều hành của điện thoại để chiếm quyền quản trị, thì độ an toàn của các ứng dụng mobile banking cũng giảm đi. Mô hình bảo mật của hệ thống bị phá vỡ, các lớp bảo vệ bị gỡ bỏ và mã độc có thể dễ dàng lây nhiễm, kiểm soát các chức năng quan trọng của thiết bị.

- Hệ điều hành lỗi thời và các kết nối không an toàn: Việc sử dụng các phiên bản lỗi thời của HĐH hay truy cập mạng Wi-Fi không an toàn sẽ tạo điều kiện cho kẻ xấu tấn công, ăn cắp thông tin, lợi dụng các phiên làm việc của ứng dụng giao dịch ngân hàng để đánh cắp tiền trong tài khoản....

- Chiếm tài khoản: Tội phạm sử dụng thiết bị di dộng để truy cập tài khoản của người dùng (có thể thông qua việc chiếm đoạt SIM, tài khoản thư điện tử,…) và chúng lại lợi dụng tính năng ẩn danh, khiến cho việc phòng vệ gặp nhiều khó khăn. Các giải pháp nhận diện thiết bị từ phía máy chủ rất khó phát hiện các thiết bị của tội phạm.

- Đánh cắp thông tin định danh qua nhiều kênh giao dịch: Mobile banking có thể chỉ là điểm bắt đầu hay điểm cuối của chuỗi hành vi gian lận. Để bảo vệ người dùng và ứng dụng mobile banking cần giám sát/phát hiện gian lận trên tất cả các kênh giao dịch, việc tập trung vào riêng kênh di động sẽ không đem lại hiệu quả mong muốn.

- Tấn công ứng dụng trên thiết bị di động: Cần có các biện pháp bảo vệ ứng dụng cài đặt trên điện thoại của người dùng. Hiện trên thị trường có rất nhiều công cụ dịch ngược và với mã nguồn trong tay, tin tặc có thể sử dụng mã nguồn để có thể truy cập tới các thông tin nhạy cảm, sửa đổi mã nguồn hay tìm cách can thiệp vào quá trình thực thi ứng dụng. Sau khi sửa đổi mã nguồn, tin tặc có thể đóng gói lại ứng dụng giả mạo nguồn gốc.

Để ứng phó với những nguy cơ đó, các tổ chức tài chính cần có chiến lược bảo mật toàn diện và các công cụ bảo mật thích hợp như: Phát hiện các nguy cơ từ bản thân thiết bị di động (Jailbrake, HĐH lỗi thời, các phần mềm độc hại); Định danh thiết bị; Bảo vệ ứng dụng mobile khỏi mọi sự chỉnh sửa, can thiệp trong quá trình thực thi; Phát triển ứng dụng an toàn.

Để phát triển ứng dụng an toàn, ngoài các yếu tố như rà soát thiết kế, tuân thủ các quy định lập trình an toàn còn cần áp dụng các công cụ hỗ trợ như phân tích mã nguồn tự động để nhanh chóng phát hiện những lỗ hổng bảo mật đã biết. Hơn thế, có thể tận dụng các thư viện/công cụ chuyên dụng để bảo vệ ứng dụng mobile như Axran, Metaforic để nâng cao độ bảo mật của ứng dụng với các tính năng phát hiện việc chiếm quyền quản trị của thiết bị (Jailbroken/Rooted). Phát hiện mã độc và kết nối Wi-Fi không an toàn, bảo vệ tính toàn vẹn của ứng dụng và dữ liệu trong quá trình thực thi, cho phép ứng dụng lựa chọn ngừng hoạt động khi phát hiện vi phạm hoặc gửi cảnh báo về máy chủ, làm rối (obfuscation) mã nhị phân của ứng dụng để bảo vệ chống dịch ngược.... Các giải pháp phân tích hành vi, phòng chống gian lận đa kênh, thời gian thực có thể giúp ích cho nhân viên điều tra và xử lý gian lận và nâng cao mức độ an toàn cho khách hàng. Để đối phó với những hình thức gian lận ngày càng tinh vi, có thể áp dụng các biện pháp mạnh như tạm ngưng giao dịch, rà soát thủ công và yêu cầu khách hàng xác nhận đối với những giao dịch có giá trị, mức rủi ro cao. 

Chiến lược bảo mật tổng thể cho ứng dụng mobile banking

Theo một nghiên cứu ngắn được IOActive thực hiện trong vòng 40 tiếng đồng hồ đầu năm 2014, 90% ứng dụng mobile banking của các ngân hàng lớn có chứa những lỗ hổng nghiêm trọng, có thể làm lộ thông tin nhạy cảm của người dùng: chúng chứa nhiều liên kết phi SSL - giúp tin tặc có thể theo dõi các thông tin truyền, nhận và chèn các đoạn mã JavaScript/HTML để giả mạo các màn hình đăng nhập, thực hiện lừa đảo.

IOActive kiểm tra ứng dụng mobile banking của các ngân hàng trên tất cả các châu lục. 40% ứng dụng không kiểm tra các chứng thực SSL và dễ dàng bị tấn công kiểu người đứng giữa (Man in The Middle). Gần 20% ứng dụng không áp dụng biện pháp bảo vệ Position Independent Executable (PIE) và Stack Smashing Protection để ngăn chặn tấn công tràn bộ đệm, vì PIE làm giảm đáng kể hiệu năng của các ứng dụng 32 bit. Hơn thế, 50% số ứng dụng có thể bị chèn JavaScript do cách triển khai UIWebView không an toàn. Trong một số trường hợp, các chức năng gốc của iOS bị lộ ra, cho phép mã độc gửi SMS hay thư điện tử từ điện thoại của người dùng. Điều đáng ngạc nhiên là 70% số ứng dụng không có biện pháp xác thực thay thế nào, như xác thực đa yếu tố. Phần lớn các tệp log do các ứng dụng tạo ra, để lộ các thông tin nhạy cảm và có thể giúp kẻ xấu tìm kiếm, phát triển các cách phá hoại nhắm tới người dùng của ứng dụng đó.

Vì các lỗ hổng bảo mật xuất hiện liên tục, nên điều quan trọng trong phát triển phần mềm là áp dụng nghiêm túc các quy định phát triển an toàn để tránh lỗi, chứ không phải tìm cách vá từng lỗ hổng cụ thể.

Nếu mỗi ngân hàng tự tìm kiếm giải pháp an toàn của mình thì sẽ tốn nhiều nguồn lực. Vì thế đã có nhiều động thái phối hợp nhằm thúc đẩy sự phát triển của thị trường. Năm 2013, BITS - bộ phận phụ trách công nghệ của Diễn đàn Dịch vụ tài chính (Financial Services Roundtable) ở Mỹ - đã phát hành tài liệu BITS Mobile Technology - Layered Security Model với nội dung đánh giá các nguy cơ bảo mật cho điện thoại di động và xác định các biện pháp phòng tránh, giảm thiểu rủi ro. Financial Services Information Sharing and Analysis Center (FS-ISAC), một diễn đàn an ninh mạng của các tổ chức tài chính toàn cầu, cũng đã xây dựng tài liệu hướng dẫn giúp các ngân hàng cộng đồng của Mỹ xử lý các vấn đề bảo mật của mobile banking.

Trong hoàn cảnh các ứng dụng mobile đang bắt đầu phát triển mạnh ở Việt Nam, các cơ quan quản lý nhà nước và các hiệp hội liên quan đến ngân hàng, bảo mật cũng cần sớm nghiên cứu, đưa ra các hướng dẫn, quy định chi tiết để giúp thị trường có thể phát triển vững chắc, an toàn hơn. Các văn bản của Ngân hàng Nhà nước như thông tư 29/2001/TT-NHNN quy định về an toàn, bảo mật cho việc cung cấp dịch vụ ngân hàng trên Internet, thông tư 47/2014/TT-NHNN quy định các yêu cầu kỹ thuật về an toàn, bảo mật đối với trang thiết bị phục vụ thanh toán thẻ ngân hàng nhằm phục vụ mục tiêu này. Trong thời gian tới, hy vọng rằng từ việc đúc kết kinh nghiệm triển khai dịch vụ mobile banking của các ngân hàng, chúng ta sẽ có được những định hướng cụ thể, giúp nâng cao tính bảo mật của dịch vụ, giúp khách hàng tự tin sử dụng công nghệ mới.

Với lập trình ứng dụng cho điện thoại di động, danh mục kiểm tra có thể bao gồm những điểm sau: Xác thực và kiểm soát truy cập - Cơ chế xác thực người dùng phải đủ mạnh; - Các thông tin định danh thiết bị như UDID và IMEI không được dùng làm tên tài khoản truy cập; - Ứng dụng phải xác thực cả người dùng và máy chủ, có biện pháp phòng chống các kiểu tấn công như SSL stripping;  - Ứng dụng client phải kiểm tra chứng thực SSL/TLS. Bảo mật dữ liệu - Sử dụng khóa bí mật và/hoặc mật khẩu không được gắn cứng trong ứng dụng; - Các khóa mã hóa phải được tạo từ tập các giá trị biến động, chẳng hạn như passcode của người dùng; - Phải áp dụng mã hóa cho cả dữ liệu lưu trữ tại chỗ và dữ liệu trên đường truyền; - Các dữ liệu nhạy cảm, trong đó có thông tin xác thực, phải được mã hóa khi lưu trữ (kể cả khi lưu trong chuỗi khóa - keychain) và không nên được lưu trong CSDL SQLite trên thiết bị, các thuật toán mật mã và độ dài khóa nên tuân thủ quy định của FIPS 140-2; - Ứng dụng phải có biện pháp ngăn chặn khả năng lộ thông tin nhạy cảm; không cho phép lưu trữ, chia sẻ hay chép dữ liệu nhạy cảm lên các thiết bị nhớ tháo lắp được hay chia sẻ; không được bật tính năng autocomplete cho các trường dữ liệu nhạy cảm; - Dữ liệu trong bộ nhớ đệm nên được giảm thiểu và xóa bỏ trước khi thoát ứng dụng. Quản lý phiên làm việc - Thời gian hết giờ cho phiên làm việc (session timeout) nên được đặt hợp lý và có thể thực hiện cấu hình được; - Dữ liệu về các phiên làm việc phải được xóa khi phiên làm việc kết thúc không bình thường; - Các lệnh GET không nên dùng để truy vấn dữ liệu nhạy cảm. Sử dụng các lệnh POST qua HTTPS. Ghi nhật ký lỗi: Ứng dụng không nên ghi các dữ liệu nhạy cảm vào system log hay các tệp thông thường và các nhật ký gỡ lỗi và thông tin lưu lại khi ứng dụng bị sự cố không nên chứa dữ liệu nhạy cảm. Phân quyền và quản lý tài nguyên Các quyền và tài nguyên được gán cho ứng dụng (ví dụ qua AndroidManifest.xml, iOS Entitlements) chỉ nên giới hạn ở phạm vi ứng dụng cần để hoạt động. Ngăn ngừa lỗi và chống sửa đổi ứng dụng - Các thư viện thứ ba phải được kiểm tra để tránh các lỗ hổng và mã độc trước khi sử dụng; - Ứng dụng phải triển khai biện pháp kiểm tra ở phía máy chủ và không nên dựa vào các biện pháp kiểm tra ở phía thiết bị đầu cuối đối với các hàm có thể bị sửa đổi để đánh cắp thông tin; - Ứng dụng nên giảm thiểu việc trao đổi với các ứng dụng khác và có các biện pháp kiểm tra/bảo vệ thích hợp khi thực hiện các trao đổi đó; - Ứng dụng không nên hỗ trợ các hành động không chỉ rõ thành phần xử lý/thực hiện và tệp nhị phân của ứng dụng nên được làm rối (obfuscation) để gây khó khăn cho kẻ xấu.