Change background image
LOVE quotion

Bắt đầu từ 4.53' thứ Hai ngày 17/10/2011


You are not connected. Please login or register

Xem chủ đề cũ hơn Xem chủ đề mới hơn Go down  Thông điệp [Trang 1 trong tổng số 1 trang]

OLD
OLD Developer

Cấp bậc: Developer

Giới tính : Nam

Bài viết : 666

Danh vọng : 1095

Uy tín : 16

Series các bài viết về bảo mật 2 lớp (2FA)! của Conor Gilsenan, một kỹ sư phần mềm đam mê việc đặt người dùng lên hàng đầu. Tác giả đã đồng tạo 2fanotifier.org để giúp mọi người kích hoạt 2FA. Conor Gilsenan tham khảo ý kiến ​​của các công ty về tính bảo mật và quyền riêng tư có thể sử dụng được.

#2 Xác thực và ủy quyền: mô hình trách nhiệm chung
(Lược dịch từ bài Shared Responsibility Model)
#3 Bảo mật 2 lớp (2FA) là gì, nó hoạt động như thế nào? Và tại sao bạn cần quan tâm đến nó
(Lược dịch từ bài Two Factor Authentication (2FA): What is it? How does it work? Why you should care!)
#4 SMS 2FA: Phổ biến nhất nhưng lại kém an toàn nhất
(Lược dịch từ bài SMS: The most popular and least secure 2FA method)
#5 TOTP: an toàn hơn (rất nhiều) so với SMS, nhưng so với Push lại không tiện bằng
(Lược dịch từ bài TOTP: (way) more secure than SMS, but more annoying than Push)
#6 Tìm hiểu kỹ về thông số Mật khẩu một lần (TOTP) dựa trên thời gian
(Lược dịch từ bài A medium dive on the Time-based One-time Passwords (TOTP) spec)
#7 Giới thiệu trình thông báo 2FA - Cách thu hút nhiều người dùng Internet hơn kích hoạt 2FA trên tài khoản của họ
(Lược dịch từ bài Introducing 2FA Notifier - How to Get More Internet Users to Enable 2FA on Their Accounts)

_________________

Cám ơn đời mỗi sớm mai thức dậy
Ta có thêm ngày nữa để yêu thương
http://www.cuuhvlq2.tk
      
OLD
OLD Developer

Cấp bậc: Developer

Giới tính : Nam

Bài viết : 666

Danh vọng : 1095

Uy tín : 16

Mô hình trách nhiệm chung

(Được lược dịch từ bài viết Shared Responsibility Model)

Xác thực và ủy quyền là trách nhiệm được chia sẻ giữa nhà cung cấp dịch vụ và người dùng cuối.

Hiểu biết về 2FA - xác thực hai yếu tố People10

Bạn là ai? Bạn được phép làm gì?

Trong giới công nghệ, hai câu hỏi đó chính thức được gọi là xác thực (“bạn là ai?”) Và ủy quyền (“bạn được phép làm gì?”) Và được gọi chung là “auth”.

Rõ ràng, các nhà cung cấp dịch vụ có lợi ích nhất định trong việc đảm bảo rằng họ biết câu trả lời chính xác cho cả hai câu hỏi đó; họ không muốn cho phép người dùng sai đăng nhập vào tài khoản và họ cũng không muốn cho phép người dùng tương tác với dữ liệu mà họ không được phép truy cập.

Xác thực và ủy quyền là trách nhiệm được chia sẻ giữa nhà cung cấp dịch vụ và người dùng cuối.

Mô hình chia sẻ này là cần thiết để đạt được mục tiêu cuối cùng: tránh truy cập tài khoản trái phép và giữ an toàn cho dữ liệu . Cả nhà cung cấp dịch vụ và người dùng cuối đều không thể đạt được mục tiêu đó một mình.

Các nhà cung cấp dịch vụ chịu trách nhiệm triển khai các tính năng bảo mật mạnh mẽ, dễ sử dụng cho người dùng cuối. Họ chịu trách nhiệm ghi lại cách thức hoạt động của các tính năng đó, duy trì chúng theo thời gian và thúc đẩy việc sử dụng chúng. Đổi lại, người dùng có trách nhiệm tận dụng các tính năng bảo mật đó và thực sự kích hoạt chúng. Tính năng giao diện người dùng không cung cấp bất kỳ bảo mật hiệu quả nào nếu nó không được sử dụng.

Các nhà cung cấp dịch vụ cũng có trách nhiệm thực hiện các cơ chế bảo mật minh bạch thay mặt cho người dùng cuối. Tuy nhiên, bất kể nỗ lực như thế nào để đảm bảo an toàn cho một dịch vụ, sẽ luôn có một số hành động mà người dùng bất cẩn có thể thực hiện khiến tài khoản của họ gặp rủi ro. Người dùng có trách nhiệm tự giáo dục về các phương pháp hay nhất để giữ an toàn khi trực tuyến để họ có thể tránh những cạm bẫy phổ biến nằm ngoài tầm kiểm soát của nhà cung cấp dịch vụ.

Hãy cùng khám phá một số ví dụ cụ thể để làm rõ lý do tại sao cả nhà cung cấp dịch vụ và người dùng cuối đều có vai trò trong việc đạt được bảo mật hiệu quả khi nói đến xác thực và ủy quyền.

Hãy tưởng tượng rằng bạn là một nhà cung cấp dịch vụ

Bạn có một đội ngũ gồm các kỹ sư, nhà thiết kế, nhà văn, nhà nghiên cứu, nhà tiếp thị và người làm việc tài năng nhất thuộc mọi loại. Bạn có hỗ trợ nội bộ đông đảo và ngân sách cần thiết để làm mọi thứ trong khả năng của mình nhằm xây dựng một dịch vụ vốn đã an toàn.

Có vẻ như bạn đã thiết lập để thành công! Chắc chắn, bạn sẽ đạt được mục tiêu cuối cùng là đạt được bảo mật hiệu quả, phải không ?! Đáng buồn thay, ngay cả sau khi thực hiện tất cả các bước cần thiết này để bảo mật dịch vụ của bạn, người dùng cuối đóng một vai trò rất lớn trong việc xác định xem liệu tương tác của họ với dịch vụ của bạn có thực sự an toàn hay không.

Dưới đây là danh sách (rất) không đầy đủ các dự án liên quan đến bảo mật mà nhóm của bạn có thể đã giải quyết:

Bạn triển khai các phương pháp hay nhất về mật khẩu

  • Bạn thực thi các yêu cầu mật khẩu tối thiểu và giải thích cho người dùng cách tạo cụm mật khẩu mạnh.

  • Bạn ngăn không cho người dùng sử dụng các mật khẩu phổ biến như “password”, “123456” và “qwerty”.

  • Bạn làm theo các phương pháp hay nhất để lưu trữ an toàn mật khẩu trong cơ sở dữ liệu của mình.

  • Bạn thậm chí có một đề xuất trên trang đăng ký của mình để người dùng tải xuống và sử dụng trình quản lý mật khẩu.


Và sau đó người dùng sẽ sử dụng lại mật khẩu yêu thích của họ mà họ sử dụng cho mọi dịch vụ khác. Một trong những dịch vụ khác không siêng năng như bạn, lưu trữ mật khẩu không an toàn, có vi phạm và bây giờ mật khẩu của người dùng nằm trong tay tin tặc. Tin tặc đó vui vẻ thử mật khẩu của người dùng trên dịch vụ của bạn và rất ngạc nhiên khi đăng nhập thành công.

Viễn cảnh này là một thực tế đáng sợ. LastPass nhận thấy rằng “91% [mọi người] biết có rủi ro khi sử dụng lại mật khẩu, nhưng 61% vẫn tiếp tục làm như vậy.” Google đã phân tích 1,9 tỷ tên người dùng và mật khẩu bị lộ do vi phạm dữ liệu và ước tính rằng “7-25% mật khẩu bị lộ khớp với tài khoản Google của nạn nhân”. Đối với một ví dụ trong thế giới thực, hãy đọc về cách sử dụng lại mật khẩu của nhân viên Dropbox dẫn đến việc đánh cắp hơn 60 triệu thông tin đăng nhập của người dùng.

Bạn định cấu hình HTTPS để các kết nối của người dùng được an toàn

  • Bạn đảm bảo rằng tất cả các kết nối tới dịch vụ của bạn đều được cung cấp qua HTTPS để khóa màu xanh lục xuất hiện trên thanh địa chỉ của trình duyệt để thông báo cho người dùng rằng kết nối là an toàn.

  • Bạn sử dụng chứng chỉ EV để tên công ty của bạn xuất hiện bên cạnh ổ khóa màu xanh lục trên thanh địa chỉ trình duyệt để người dùng thêm tin tưởng.

  • Bạn đảm bảo rằng bạn chỉ hỗ trợ các phiên bản được đề xuất của TLS, định cấu hình các bộ mật mã mạnh nhất và các tính năng quan trọng, đồng thời nhận được xếp hạng cao từ các công cụ phân tích TLS có uy tín.


Và sau đó, một người dùng nhận được một email có vẻ như nó đến từ bạn, nhấp vào liên kết yêu cầu họ đăng nhập và không xác minh URL trong thanh địa chỉ trước khi nhập tên người dùng và mật khẩu của họ. Họ vừa trở thành nạn nhân của một cuộc tấn công lừa đảo và giao thông tin đăng nhập của họ cho một tin tặc.

Nhóm công tác chống lừa đảo (APWG) cho biết trong báo cáo quý 4 năm 2016 của họ rằng các chiến dịch tấn công lừa đảo trong năm 2016 đã phá vỡ tất cả các kỷ lục của các năm trước với hơn 1,2 triệu cuộc tấn công lừa đảo, tăng 65% so với năm 2015. những người dùng Gmail ngoài đó, Google gần đây đã phát hiện ra rằng “nạn nhân của lừa đảo có khả năng bị tấn công thành công cao hơn 400 lần so với một người dùng Google ngẫu nhiên”.

Bạn hỗ trợ xác thực đa yếu tố (MFA)

  • Bạn hỗ trợ triển khai tốt nhất xác thực hai yếu tố (2FA).

  • Bạn hỗ trợ các tùy chọn xác thực sinh trắc học tốt nhất hiện có trong ngành.

  • Bạn triển khai xác thực thích ứng và thay đổi động các chính sách bảo mật và xác thực dựa trên ngữ cảnh của người dùng và thiết bị.

  • Bạn cho phép quản trị viên buộc tất cả người dùng trong tổ chức bật xác thực đa yếu tố (MFA) trên tài khoản của họ.


Và sau đó, quản trị viên chọn không chọn hộp bên cạnh “yêu cầu MFA trên tất cả các tài khoản” và người dùng trong tổ chức chọn không bật MFA. Mật khẩu bị rò rỉ trong cuộc tấn công lừa đảo hiện cấp toàn quyền truy cập vào tài khoản của người dùng.

Duo, nhà cung cấp giải pháp xác thực hai yếu tố (2FA) hàng đầu, phát hiện ra rằng chỉ có ~ 28% người ở Hoa Kỳ sử dụng 2FA và chỉ ~ 56% thậm chí biết 2FA là gì trước cuộc khảo sát của họ. Trung tâm nghiên cứu Pew đã thực hiện một bài kiểm tra an ninh mạng trong đó chỉ 18% người dùng có thể xác định chính xác xác thực đa yếu tố (MFA). Tỷ lệ chấp nhận MFA thấp một cách đáng thất vọng và giáo dục phổ thông còn thiếu rõ ràng. Tuy nhiên, ngay cả dân công nghệ cũng gặp phải tình trạng bị xâm nhập tài khoản mà MFA có thể ngăn chặn được. ArsTechnica đã báo cáo rằngFox-IT, một công ty CNTT của Hà Lan, “đã trở thành nạn nhân của một cuộc tấn công được thực hiện tốt cho phép tin tặc kiểm soát các máy chủ của nó và đánh chặn thông tin đăng nhập và dữ liệu bí mật của khách hàng. Lỗi lớn nhất của Fox-IT là không thể bảo mật tài khoản đăng ký tên miền của mình bằng xác thực hai yếu tố. "

Bạn giải quyết cụ thể các tổ chức có nhiều người dùng

  • Bạn cho phép các tổ chức cung cấp tài khoản cho từng người dùng cá nhân.

  • Bạn triển khai các khả năng kiểm tra mạnh mẽ để quản trị viên có thể xác minh nhân viên nào đã truy cập vào dữ liệu nhất định và cách họ sử dụng dữ liệu đó.


Và sau đó người dùng quyết định chia sẻ một tài khoản và mật khẩu duy nhất thay vì tạo một tài khoản và mật khẩu cho từng nhân viên trong công ty. Có lẽ, một trong những nhân viên đó sử dụng tài khoản được chia sẻ cho một việc gì đó bất chính; chúc may mắn tìm ra người chịu trách nhiệm!

Thật nực cười, một kịch bản tương tự đã xảy ra gần đây khi chính trị gia Anh Damian Green bị dính nước nóng vì bị cáo buộc truy cập nội dung khiêu dâm trên máy tính của chính phủ ông ta. Một đồng nghiệp, Nadine Dorries, đã lên tiếng bênh vực Green với ngụ ý rằng có thể ai đó trên PC đang sử dụng danh tính của anh ta.

Hiểu biết về 2FA - xác thực hai yếu tố 2fa10

Troy Hunt, một chuyên gia bảo mật nổi tiếng, đã giải thích lý do tại sao chia sẻ một tài khoản theo cách này là vấn đề và cũng nhấn mạnh nhiều công cụ phổ biến cho phép người dùng duy trì các tài khoản cá nhân trong khi vẫn chia sẻ dữ liệu để hoàn thành công việc của họ.

Bạn cung cấp khung cấp phép mạnh mẽ để giúp hạn chế quyền truy cập vào dữ liệu

  • Bạn triển khai khuôn khổ quyền mạnh mẽ cho phép quản trị viên giới hạn dữ liệu nhạy cảm cho các nhóm người dùng nhỏ hơn dựa trên vai trò của họ.

  • Bạn có một nhóm các nhà văn công nghệ, những người phát triển các hướng dẫn, tài liệu và ví dụ hữu ích về cách tận dụng tối đa giá trị của khung cấp phép.


Và sau đó người dùng quyết định chỉ định vai trò quản trị viên cho mọi người trong tổ chức. Giờ đây, tất cả người dùng đều có quyền truy cập vào tất cả dữ liệu trong tổ chức và người thực tập quyết định truy cập dữ liệu khách hàng nhạy cảm chỉ để giải trí.

Hãy tưởng tượng rằng bạn là một người dùng có động cơ cao

Bạn đã chủ động nghiên cứu và hiểu tất cả các phương pháp hay nhất về an ninh mạng được các chuyên gia trong ngành khuyến nghị. Nếu thích hợp, bạn đã chi một số tiền nhỏ để bạn có sẵn những công cụ tốt nhất giúp bạn giữ an toàn.

Có vẻ như bạn đã thiết lập để thành công! Chắc chắn, bạn sẽ đạt được mục tiêu cuối cùng là đạt được bảo mật hiệu quả, phải không ?! Đáng buồn thay, ngay cả sau khi thực hiện tất cả các bước cần thiết này để bảo mật tài khoản của bạn, nhà cung cấp dịch vụ vẫn đóng một vai trò quan trọng trong việc xác định mức độ bảo mật mà bạn thực sự có thể đạt được.

Dưới đây là danh sách (rất) không đầy đủ các bước bạn có thể đã thực hiện để giữ an toàn:

Bạn đã sẵn sàng để bật xác thực đa yếu tố (MFA)

  • Bạn mua một vài khóa bảo mật U2F hoạt động với máy tính và điện thoại của mình để bạn có thể tận dụng xác thực hai yếu tố (2FA) mạnh nhất hiện có trên tất cả các thiết bị của mình.

  • Bạn mong muốn bật Thông báo đẩy 2FA, chẳng hạn như Lời nhắc của Google , nếu có.

  • Bạn đã sẵn sàng vuốt ngón tay cái, quét mống mắt hoặc chụp ảnh khuôn mặt của mình trong khi bật các tùy chọn xác thực sinh trắc học.


Và sau đó nhà cung cấp dịch vụ tuyên bố rằng các câu hỏi kiến thức mà họ yêu cầu bạn điền đủ điều kiện là 2FA khi được kết hợp với tên người dùng / mật khẩu của bạn và tài khoản của bạn được bảo mật. Tất nhiên, bạn biết rằng các câu hỏi kiến thức được coi là một yếu tố kiến thức trùng lặp chứ không phải là 2FA thực và quá yếu đến mức chúng luôn luôn vô dụng . Tài khoản của bạn vẫn rất dễ bị tấn công vì bạn không thể kích hoạt yếu tố xác thực sở hữu hoặc liên tục để đạt được 2FA thực tế.

Làm thế nào về việc mất hàng triệu đô la cho một ví dụ trong thế giới thực? Tin tặc đã đánh cắp số bitcoin trị giá hàng triệu đô la từ tài khoản của nạn nhân có bật 2FA dựa trên SMS. Chờ đã, cái gì ?! Họ đã bị tấn công ngay cả khi bật 2FA? Thật không may, không phải tất cả các triển khai 2FA đều cung cấp cùng một mức độ bảo mật và SMS nổi tiếng là một trong những yếu tố kém nhất . Tài khoản của nạn nhân có thể đã được an toàn với loại 2FA mạnh, nhưng hãy tưởng tượng điều đó sẽ trở nên tồi tệ như thế nào đối với tin tặc nếu không có 2FA nào được kích hoạt!

Bạn sử dụng trình quản lý mật khẩu

  • Bạn sử dụng trình quản lý mật khẩu để đảm bảo rằng mỗi dịch vụ có một mật khẩu mạnh duy nhất.


Và sau đó nhà cung cấp dịch vụ lưu trữ mật khẩu của bạn một cách không an toàn trong cơ sở dữ liệu, bị vi phạm và mật khẩu của bạn giờ đã nằm trong tay của một tin tặc. Vì nhà cung cấp dịch vụ không triển khai 2FA thực tế, mật khẩu của bạn và một số câu hỏi kiến thức dễ trả lời cho phép tin tặc dễ dàng chiếm đoạt tài khoản của bạn.

Thật là sốc và đáng sợ là ngay cả với tất cả các tài nguyên sẵn có bao gồm rất chi tiết các phương pháp tốt nhất để lưu trữ mật khẩu trong cơ sở dữ liệu, một số nhà cung cấp dịch vụ lại loại bỏ hoàn toàn bảo mật ra khỏi cửa sổ và lưu trữ mật khẩu dưới dạng văn bản thuần túy. Cuối năm 2015, Troy Hunt báo cáo rằng 000webhost.com, một máy chủ web giá rẻ, đã bị tấn công và mất 13 triệu email người dùng và mật khẩu văn bản thuần túy. Tương tự, The Hacker News đã báo cáo vào giữa năm 2016 rằng VK.com, trang mạng xã hội lớn nhất của Nga, đã mất 100 triệu địa chỉ email và mật khẩu văn bản thuần túy trong một vụ vi phạm.

Bạn cài đặt tiện ích mở rộng trình duyệt để đảm bảo lưu lượng truy cập web của mình

  • Bạn cài đặt HTTPS Mọi nơi trong trình duyệt của mình để các kết nối của bạn đến các trang web được mặc định là bảo mật HTTPS hết mức có thể.


Và sau đó nhà cung cấp dịch vụ chỉ hỗ trợ các phiên bản TLS không dùng nữa , chẳng hạn như SSLv3 hoặc thậm chí có thể không hỗ trợ HTTPS. Giờ đây, bất kỳ ai trên cùng mạng với bạn đều có thể dễ dàng ghi lại dữ liệu bạn gửi đến dịch vụ, chẳng hạn như tên người dùng và mật khẩu của bạn; tin tặc đang ngồi cạnh bạn trong quán cà phê giờ đã có thông tin đăng nhập của bạn.

Let's Encrypt, một dự án cung cấp chứng chỉ TLS miễn phí, báo cáo rằng Web đã tăng từ 46% lượt tải trang được mã hóa lên 67% vào năm 2017 - tăng 21 điểm phần trăm trong một năm! Đây là một tin thực sự đáng khích lệ, nhưng nó cũng nhấn mạnh rằng một phần ba trang Web vẫn đang sử dụng HTTP và hoàn toàn không được mã hóa! Hardenize báo cáo rằng chỉ 38% trong số 500 trang web hàng đầu đang sử dụng HTTPS được cấu hình tốt; 19% trong số 500 người hàng đầu đang sử dụng các cấu hình bị thiếu sót nghiêm trọng. Gần đây vào cuối năm 2017, một ngân hàng của Vương quốc Anh có tên là NatWest đã cung cấp trang chủ của họ qua HTTP không an toàn .

Bạn cố gắng tuân theo nguyên tắc ít đặc quyền nhất

  • Bạn làm việc với các nhóm tuân thủ và an ninh tại công ty của mình để ghi lại thông tin mà nhân viên cần truy cập để thực hiện công việc của họ một cách hiệu quả. Bạn ngồi xuống để cấu hình dịch vụ nhằm thực thi các chính sách cấp phép đó.


Và sau đó, dịch vụ không hỗ trợ khái niệm tổ chức có tài khoản người dùng cá nhân và bạn buộc phải có nhiều nhân viên chia sẻ thông tin đăng nhập cho một tài khoản. Bạn không có bất kỳ khả năng nào để giới hạn quyền truy cập vào dữ liệu dựa trên bộ phận hoặc vai trò của nhân viên. Mọi người đều có quyền truy cập vào mọi thứ! Ngoài ra, bạn không thể bật 2FA cho tài khoản vì tài khoản được chia sẻ giữa nhiều người và tất cả họ không thể chia sẻ cùng một thiết bị đáng tin cậy, hình in ngón tay cái hoặc mống mắt.

Tất cả chúng ta đều ở trong đó cùng nhau

Với một nhịp độ ổn định của các vụ vi phạm dữ liệu lớn làm cho tin tức trên trang nhất, an ninh mạng hiện có mặt nhiều hơn trong các cuộc trò chuyện công khai hơn bao giờ hết.

Ngoài các ví dụ ít được biết đến đã được thảo luận trong các phần trước, có rất nhiều trường hợp cấu hình cao mà lỗi rõ ràng nằm ở nhà cung cấp dịch vụ. Equifax đã làm lộ dữ liệu của 147 triệu người sau khi hãng này không vá được phần mềm máy chủ trong hai tháng . Tin tặc đã đánh cắp dữ liệu của 57 triệu khách hàng và tài xế khi các kỹ sư Uber chia sẻ thông tin đăng nhập bí mật trong kho mã trên GitHub. Đáng buồn thay, có quá nhiều ví dụ để liệt kê ở đây; Rõ ràng là các nhà cung cấp dịch vụ có một lượng lớn công việc phải làm để hoàn thành trách nhiệm của họ trong việc triển khai các hệ thống an toàn.

Không có gì đáng ngạc nhiên khi người dùng gặp khó khăn khi tin tưởng các nhà cung cấp dịch vụ để giữ an toàn cho dữ liệu của họ. Tuy nhiên, như chúng ta đã thảo luận, người dùng cũng có trách nhiệm quan trọng trong việc giáo dục bản thân để tránh góp phần gây ra sự cố. Theo một cuộc khảo sát của Trung tâm Nghiên cứu Pew năm 2017 , “nhiều người Mỹ không tin tưởng các tổ chức hiện đại để bảo vệ dữ liệu cá nhân của họ - ngay cả khi họ thường xuyên bỏ qua các phương pháp hay nhất về an ninh mạng trong cuộc sống cá nhân của họ”.

Tenable đã thực hiện một cuộc khảo sát vào cuối năm 2017, đưa ra kết luận tương tự về tình trạng đáng buồn của việc hiểu biết về an ninh mạng của người dùng. Họ kết thúc báo cáo của mình bằng cách nhấn mạnh cùng một nguyên lý của Mô hình Trách nhiệm Chung được thảo luận trong bài tiểu luận này: “[Các tổ chức] cần đi đầu trong các phương pháp bảo mật cơ bản để giữ an toàn cho khách hàng và dữ liệu kinh doanh quan trọng của họ. Nhưng các cá nhân cũng phải làm phần việc của mình - cả với tư cách là người tiêu dùng và trong nhiều trường hợp, là nhân viên của cùng các doanh nghiệp đó - và điều đó bắt đầu với việc hiểu biết về không gian mạng ”.

Xác thực và ủy quyền là trách nhiệm được chia sẻ giữa nhà cung cấp dịch vụ và người dùng cuối.

All Things Auth dành riêng để giúp các nhà cung cấp dịch vụ cũng như người dùng cuối điều hướng các trách nhiệm được chia sẻ đó và đạt được tiến bộ hướng tới mục tiêu cuối cùng: tránh truy cập tài khoản trái phép và giữ an toàn cho dữ liệu . Không nhóm nào có thể làm được một mình. Tất cả chúng ta đều ở trong đó cùng nhau.

_________________

Cám ơn đời mỗi sớm mai thức dậy
Ta có thêm ngày nữa để yêu thương
http://www.cuuhvlq2.tk
      
OLD
OLD Developer

Cấp bậc: Developer

Giới tính : Nam

Bài viết : 666

Danh vọng : 1095

Uy tín : 16

Bảo mật 2 lớp (2FA) là gì, nó hoạt động như thế nào? Và tại sao bạn cần quan tâm đến nó

(Được lược dịch từ bài viết Two Factor Authentication (2FA): What is it? How does it work? Why you should care!)

Cùng tìm hiểu lý do tại sao 2FA lại quan trọng, thực chất thì nó bảo vệ tài khoản của bạn như thế nào, và cách để đánh giá các phương thức 2FA có sẵn trên các dịch vụ mà bạn đang sử dụng.

Chào mừng bạn đến với bài viết đầu tiên trong series về Bảo mật 2 lớp (2FA).

Trước hết, series này không phải nói về những dịch vụ nào thì hỗ trợ 2FA. Bạn có thể tìm hiểu nó qua trang web cực kì hữu dụng twofactorauth.org. Series này cũng không nhằm trình bày cách để cài đặt 2FA lên website, nếu bạn cần cài đặt hãy tham khảo TurnOn2FA.com.

Thay vào đó, series này sẽ tập trung vào việc cách mà 2FA hoạt động từ đó mà bạn có thể đưa ra những quyết định đúng đắn để bảo vệ an toàn khoản online của mình.

Rất nhiều dịch vụ khuyến khích người dùng sử dụng 2FA với thông điệp đại loại là “2FA sẽ tăng cường thêm một lớp bảo mật cho tài khoản của bạn bên cạnh mật khẩu”. Điều đó thực sự có nghĩa là gì? Thông điệp trên không giải thích tại sao 2FA lại tăng cường bảo mật cho tài khoản cũng như không đề cập đến những rủi ro của nó. Một vài dịch vụ thì đưa ra thông điệp rõ ràng hơn: “Điều đó nghĩa là nếu có ai đó đánh cắp được mật khẩu của bạn thì họ cũng không thể nào mà truy cập được tài khoản nếu không có điện thoại của bạn.” Thông điệp trên hẳn là sẽ tạo thêm động lực để một số người dùng sử dụng 2FA nhưng buồn thay phần lớn người dùng lại không làm thế. Thực tế là, hầu hết mọi người đều không biết 2FA là cái gì. Giáo dục là phần cốt yếu để phổ biến 2FA và tôi hy vọng series này có thế giúp ích được phần nào.

Có khá nhiều tài liệu hay để ta có thể tìm hiểu về 2FA. Hai trang web mà tôi nhắc đến ở trên giúp cho người dùng, khi họ hiểu tầm quan trọng của 2FA, có thể kích hoạt 2FA lên. Tuy nhiên, nếu bạn giống tôi, bạn sẽ luôn đặt câu hỏi tại sao khi mà ai đó bảo bạn làm gì đó. Để giải quyết vấn đề đó, Electronic Frontier Foundation (EFF) đã có một tài liệu hướng dẫn xuất sắc thảo luận về những phương thức 2FA phổ biến trên web (Common Types of Two-Factor Authentication on the Web). Series này sẽ trình bày dựa trên tài liệu trên, chia nhỏ và phân tích một cách cụ thể rõ ràng hơn.

Bạn có thể tự hỏi rằng: Thế 2FA bảo vệ mình khỏi cái gì nhỉ? Và nó không thể bảo vệ được mình khỏi cái gì? Đâu là phương thức 2FA phổ biến và chúng hoạt động như thế nào? Cái nào tốt hơn, cái nào không tốt bằng? Để bảo mật hơn thì ta phải đánh đổi cái gì?

Nếu bạn là người dùng cuối, thì series này sẽ giúp bạn hiểu được một cách chính xác cách 2FA bảo vệ tài khoản của bạn và cách để đánh giá các phương thức 2FA có sẵn trên các dịch vụ mà bạn đang sử dụng. Nếu dịch vụ bạn đang dùng không hỗ trợ 2FA, thì với kiến thức trong tay, bạn sẽ có đủ tự tin để yêu cầu nhà cung cấp hỗ trợ 2FA để bạn có thể bảo vệ tài khoản của mình khỏi bị tấn công.

Nếu bạn là nhà cung cấp dịch vụ, thì series chắc chắn là dành cho bạn! Hiểu rõ kỹ thuật nằm sau 2FA và trải nghiệm của người dùng (UX) khi sử dụng 2FA sẽ giúp cho phương thức 2FA mà bạn cung cấp đáp ứng được nhu cầu của bạn (nhà cung cấp) và người dùng.

Thế 2FA là gì?

Có 3 yếu tố bảo mật thường được sử dụng để xác thực nhân dạng của bạn khi đăng nhập vào 1 hệ thống, đó là:

  • Knowledge: Một thứ gì đó mà bạn biết, như là mật khẩu, PIN code…
  • Possession: Một thứ gì đó mà bạn sở hữu, như là smartphone, security key, hoặc một thiết bị tin cậy nào đó.
  • Inherence: Một thứ gì đó mà thuộc về con người bạn, như là gương mặt, vân tay, hoặc màu mắt.


Mặc dù bất kỳ bộ 2 nào của các yếu tố (factor) trên đều có thể xem là bảo mật 2 lớp (two factor authentication), thông thường thì 2FA sẽ là Knowledge + Possession. Sinh trắc học đã dần trở nên phổ biến trong thời đại phát triển như vũ bão của smartphone các năm gần đây, nhưng mà nó hiếm khi được sử dụng khi đăng nhập vào website. Định nghĩa trên có thể thay đổi trong tương lai, nhưng hiện tại hãy cứ định nghĩa 2FA trong series này bao gồm thứ gì đó mà bạn biết và thứ gì đó mà bạn có.

Lý do mà 2 factor hợp lại sẽ tăng bảo mật một cách đáng kể là vì mỗi factor có mô hình mối đe dọa (threat model) khác nhau. Một mô hình mối đe dọa đơn giản là một danh sách có ưu tiên bao gồm tất cả các phương pháp mà tin tặc có thể tấn công. Tin tặc sẽ thử những phương thức đơn giản, xác suất thành công lớn trước khi thực hiện các phương thức tấn công phức tạp để tấn công người dùng cá nhân. Hầu hết các giải pháp bảo mật đều không thể loại bỏ được hoàn toàn rủi ro, mà chỉ có thể giảm thiểu rủi ro tối đa dựa vào mô hình mối đe dọa.

Nếu tin tặc có thể ăn cắp knowledge factor (ví dụ như mật khẩu) từ xa thì hắn vẫn không thể truy cập được vào tài khoản vì hắn thường không thể truy cập vật lý vào possession factor (ví dụ như trusted device).

Một số người đọc tinh ý có thể thấy rằng tôi dùng cụm từ thiếu chắc chắn là “thường không thể”. Những cụm từ kiểu này sẽ xuất hiện nhiều trong bài viết bởi vì mỗi phương thức 2FA có điểm mạnh yếu khác nhau cho phép chúng chống lại được những cuộc tấn công nhất định nhưng mà lại yếu trước loại tấn công khác.

Phần còn lại của bài viết này sẽ liệt kê một vài cách trong vô số cách mà tin tặc có thể trộm được mật khẩu của bạn. Hiểu được việc bạn có thể mất yếu tố xác thực Knowledge dễ dàng sẽ giúp bạn hiểu được tại sao cần phải kích hoạt 2FA cho tất cả tài khoản của mình.

“Tôi sử dụng 1 mật khẩu cho nhiều website.” 2FA có thể giúp bạn

Nếu bạn đã từng sử dụng 1 mật khẩu cho nhiều hơn 1 website, bạn không chỉ có một mình đâu. Pew Research chỉ ra rằng 39% người tham gia nghiên cứu thừa nhận rằng họ sử dụng mật khẩu giống nhau hoặc tương tự nhau cho nhiều tài khoản online. Và LastPass chỉ ra rằng con số đó có thể lên tới 61%! Việc mọi người sử dụng lại mật khẩu là dễ hiểu, vì khó có thể nhớ được nếu đặt mật khẩu khác nhau cho tất cả các tài khoản online. LastPass cũng chỉ ra rằng một người dùng trung bình có 191 mật khẩu cần phải nhớ. Tuy nhiên việc bạn thuộc đa số trong trường hợp này lại không phải là điều tốt cho lắm. Việc sử dụng lại mật khẩu là cực kỳ nguy hiểm, khiến cho các tài khoản dùng chung có nguy cơ bị hack cao hơn. Vậy cùng tìm hiểu xem tại sao 2FA lại có thể bảo vệ tài khoản của bạn trong trường hợp này nhé.

Giả sử có hai dịch vụ online giả tưởng. Chúng ta gọi dịch vụ hoàn toàn giả tưởng đầu tiên là “Google”. Giả sử “Google” có 1 team kỹ sư cực kỳ giỏi, cực kỳ coi trọng việc bảo mật, và thực hiện tất cả những best practice để lưu mật khẩu một cách bảo mật vào database (DB). Còn dịch vụ giả tưởng thứ hai tên là “Một trang web về mèo”. Bởi vì dịch vụ này có team kỹ sư lởm, nên họ không tuân theo best practice nào về cách lưu mật khẩu.

Giả sử rằng bạn có tài khoản ở cả hai dịch vụ trên và chúng dùng chung mật khẩu. Không may “Một trang web về mèo” bị hack và tin tặc download được tất cả dữ liệu trong DB. Vì “Một trang web về mèo” không tuân theo best practice nào về cách lưu mật khẩu nên ta có thể kết luận rằng tin tặc đã có cả username và mật khẩu tài khoản của bạn. Bạn yêu mèo, nhưng mất tài khoản  “Một trang web về mèo” vào tay tin tặc không phải là tận thế.

Tuy nhiên, vì hầu hết các trang web sử dụng email làm username, tin tặc có thể thử dùng username, mật khẩu vừa hack được để thử truy cập vào tài khoản “Google” của bạn. Vì bạn dùng chung mật khẩu cho cả hai tài khoản nên account “Google” của bạn cũng coi như đi tong luôn. Việc một trang web vớ vẩn với bảo mật không tốt đã khiến cho những tài khoản khác dùng chung mật khẩu đối mặt với nhiều rủi ro. Giả sử nếu ai đó nắm được quyền kiểm soát tài khoản mạng xã hội, tài khoản ngân hàng hoặc lịch sử khám bệnh của bạn xem, đó không phải là viễn cảnh hay ho lắm đâu.


Thế nên tip ở đây là: mỗi tài khoản nên có mật khẩu duy nhất.

Tuy nhiên, nếu chúng ta không đặt mật khẩu khác nhau thì sao?

Nếu tài khoản “Google” có kích hoạt bảo mật 2 lớp, thì tài khoản của bạn vẫn an toàn! Nhớ rằng yếu tố bảo mật đầu tiên là Knowledge (ví dụ như mật khẩu) và tin tặc có thể lấy được nó từ xa. Yếu tố bảo mật thứ hai là Possession (ví dụ như điện thoại) và tin tặc thường không thể lấy nó từ xa. Nếu không tận tay lấy thiết bị tin cậy của bạn, tin tặc sẽ không thể cung cấp bằng chứng cần thiết về yếu tố Possession trong quá trình đăng nhập và tài khoản của bạn sẽ không bị đánh cắp.

Người đọc tinh ý sẽ chú ý rằng tôi dùng từ “thường không thể lấy nó từ xa”. Một điểm đáng tiếc là một vài cài đặt 2FA phổ biến không thực sự tuân theo định nghĩa “cái gì đó mà bạn sở hữu” và do đó có nguy cơ bị tấn công từ xa. Hãy tiếp tục theo dõi series này nhé, chúng tôi sẽ phân tích điều đó với những bài viết cụ thể về các phương thức 2FA.

“Okay,  tôi sẽ không sử dụng lại mật khẩu nữa.” Tuy nhiên bạn vẫn cần 2FA đấy.

Sau khi nhận ra việc tài khoản dùng chung mật khẩu dễ bị hack như thế nào, bạn bắt đầu sử dụng mật khẩu riêng cho mỗi tài khoản. Với ví dụ trên, giờ đây lỗ hổng ở “Một trang web về mèo” sẽ không còn đe dọa đến tài khoản “Google” nữa dù bạn không kích hoạt 2FA.

Giả sử bạn không bật 2FA và “Google” bị hack. Nhớ rằng “Google” có một đội kỹ sư khủng và họ lưu mật khẩu vào DB một cách bảo mật. Không may là điều đó không có nghĩa rằng mật khẩu của bạn sẽ an toàn khi mà tin tặc download được DB. Cần hẳn một bài riêng để trình bày chi tiết về cách để lưu mật khẩu một cách an toàn vào DB, tuy nhiên có một vài nội dung quan trọng mà chúng tôi sẽ trình bày ở mức độ tổng quan để bạn có thể hiểu được bằng cách nào tin tặc có thể lấy được mật khẩu của bạn thông qua việc hack DB.

Đơn giản thì, mật khẩu mà bạn chọn khi mà tạo tài khoản không được lưu trực tiếp vào DB vì nếu thế tin tặc sau khi hack được DB thì có ngay mật khẩu của người dùng. Thay vào đó, mật khẩu mà bạn điền khi đăng ký tài khoản sẽ đi qua một hàm băm mật mã và kết quả của hàm băm đó sẽ được lưu vào DB. Tôi sẽ không trình bày tràng giang đại hải về hàm băm mật mã đâu, nhưng có một vài thuộc tính quan trọng của nó liên quan đến bài viết này. Đầu tiên thì một input sẽ cho ra 1 output duy nhất. Thứ hai, với một output cho trước thì việc tìm ra input là không thể về mặt tính toán, hàm băm mật mã là hàm một chiều. Mỗi lần bạn đăng nhập vào tài khoản, hệ thống sẽ băm mật mã mà bạn gõ và so sánh kết quả với chuỗi được lưu trong DB, nếu giống nhau thì hệ thống sẽ biết được bạn đã nhập đúng mật khẩu và cho phép bạn truy cập!

Thậm chí là khi DB bị hack thành công thì tin tặc chỉ có kết quả của hàm băm chứ không phải là mật khẩu. Bởi vì việc tính toán ngược từ output ra input là không thể nên tin tặc sẽ phải dành nhiều thời gian và công sức để xác định được mật khẩu của người dùng. Và nó trở thành một trò đoán mò. Tin tặc sẽ chạy 1 phần mềm tạo ra tất cả những tổ hợp có thể của chữ cái, chữ số, ký hiệu rồi băm nó ra và so sánh với giá trị trong DB. Nếu mà khớp nhau thì họ sẽ có được mật khẩu của bạn! Vì việc đoán mò trên rất lằng nhằng về mặt kỹ thuật nên sẽ tốn khá nhiều thời gian, đặc biệt là với những mật khẩu dài.

Tin tặc là một nhóm người thông minh, họ biết điều đó nên sẽ không ngồi đoán mò tất cả những tổ hợp có thể như là “a”, rồi “aa”, rồi “aaa”. Thay vào đó họ sẽ sử dụng nhiều chiến lược để xem những đáp số nào có khả năng hơn. Một trong những chiến lược đó là sử dụng từ điển mật khẩu, tức là một danh sách dài những mật khẩu được thu thập từ các lần hack trước trên mạng. Nếu mà ai đó dùng một mật khẩu phổ biến có trong danh sách thì bùm, quá là dễ đoán rồi. Tin tặc cũng sử dụng tâm lý học để phân tích cách mà người dùng thường đặt mật khẩu. Ví dụ như ngày sinh, tên của người thân quen, số điện thoại, một tổ hợp thường thấy trên bàn phím như qwerty… Những điều trên tạo ra những mật khẩu cực kỳ yếu vì tin tặc sẽ thử chúng đầu tiên.


Thế nên tip ở đây là: mật khẩu không chỉ cần duy nhất, mà còn phải mạnh nữa.
Một mật khẩu mạnh thường dài và không theo một khuôn mẫu nào cả.

Quay trở lại trường hợp khi mà “Google” bị hack và tin tặc có được chuỗi băm mật khẩu của người dùng. Mặc dù bạn sử dụng mật khẩu riêng cho “Google” và “Một trang web về mèo”, tin tặc vẫn có khả năng đoán được mật khẩu của bạn vì bình thường người ta cũng ít khi đặt được mật khẩu mạnh. Một khi mà tin tặc đoán được mật khẩu, tài khoản của bạn sẽ bị chiếm dụng và gần như là mất mãi mãi. Trừ khi bạn kích hoạt 2FA!

Không có yếu tố bảo mật thứ hai (ví dụ như là Possession), tin tặc không thể nào đăng nhập vào tài khoản của bạn. Tài khoản của bạn khả năng cao vẫn an toàn vì chỉ có bạn có quyền truy cập vật lý vào thiết bị tin cậy của mình.

Người đọc tinh ý sẽ để ý thấy tôi dùng từ “khả năng cao vẫn an toàn”. Một vài cách thức cài đặt 2FA dễ bị bẻ khoá hơn những cách khác khi mà tin tặc đã truy cập được vào toàn bộ DB. Tiếp tục tìm hiểu về các phương thức đó qua các bài tiếp theo của series này nhé.

Một chút lạc đề nhé: Phần mềm quản lý mật khẩu

Bạn có thể thấy rằng chúng ta đã dành khá nhiều thời gian phân tích về các mật khẩu yếu như là lý do để sử dụng 2FA. Vậy tại sao chúng ta không dạy mọi người cách đặt mật khẩu mạnh, duy nhất mà tin tặc không thể phá được và cho 2FA vào dĩ vãng?

Đó thực sự là một câu hỏi hay đó!

Sẽ là lý tưởng nếu tất cả mọi người đều sử dụng mật khẩu mạnh và duy nhất cho mỗi tài khoản online của họ. Nhưng như chúng tôi đã đề cập, thường thì mọi người khá tệ trong việc nghĩ ra mật khẩu tốt và không thể nhớ hết chúng. May mắn thay đã có giải pháp cho vấn đề này!

Một phần mềm quản lý mật khẩu có thể tạo ra những mật khẩu mạnh và duy nhất cho mỗi tài khoản online của bạn và lưu lại chúng, nhờ đó mà bạn không cần phải nhớ nữa. Thứ duy nhất cần phải nhớ đấy là một mật khẩu mạnh và duy nhất để mở khóa phần mềm quản lý mật khẩu.

Sử dụng phần mềm quản lý mật khẩu là một cách đơn giản mà hiệu quả để quản lý mật khẩu. Dù vậy thì vẫn chưa nhiều người sử dụng dù chúng đã xuất hiện nhiều năm trở lại đây. Trong một khảo sát năm 2017, Pew Research ghi chú rằng:


Chỉ 12% người sử dụng Internet từng sử dụng phần mềm quản lý mật khẩu và chỉ có 3% nói rằng họ phụ thuộc vào nó.

Cộng đồng công nghệ nên tiếp tục phổ cập cho người dùng về những thói quen tốt liên quan đến mật khẩu và lợi ích khi sử dụng phần mềm quản lý mật khẩu, dù sẽ mất thời gian dài để có thể đạt được hiệu quả.

Trong thời gian đó thì điều mà các nhà cung cấp dịch vụ có thể làm đấy là đảm bảo rằng người dùng tuân theo các quy tắc tốt về mật khẩu. Ví dụ nhà cung cấp có thể dùng một bộ đo nào đó để khuyến khích người dùng chọn những mật khẩu mạnh, nhưng lại không thể làm gì được việc người dùng dùng một mật khẩu cho nhiều tài khoản.

Tuy nhiên, nhà cung cấp dịch vụ biết rằng người dùng của họ có đang kích hoạt 2FA hay không và cũng biết rằng 2FA là hoàn toàn duy nhất đối với dịch vụ của họ do đó nó không bị ảnh hưởng bởi lỗ hổng của dịch vụ khác. Vì nhà cung cấp dịch vụ không thể nào bắt người dùng thay đổi thói quen của mình với mật khẩu, đặc biệt là việc sử dụng lại mật khẩu, thế nên 2FA là một công cụ hữu dụng để nhà cung cấp khuyến khích (hoặc buộc) người dùng sử dụng để bảo vệ tài khoản của mình tốt hơn.

Cùng xem xét một vài trường hợp khác khi mà cả người dùng và nhà cung cấp dịch vụ đều thực hiện tốt các vấn đề liên quan đến bảo mật và 2FA sẽ tăng cường bảo mật như thế nào!

“Okay! Tôi sẽ sử dụng mật khẩu mạnh và duy nhất cho mỗi tài khoản từ bây giờ!” Tuyệt vời! Nhưng bạn vẫn nên sử dụng 2FA đó, không đùa đâu.

Giờ đây bạn đã hiểu rõ mức độ nguy hiểm của việc sử dụng chung mật khẩu cho nhiều tài khoản và mật khẩu yếu, bạn tận dụng phần mềm quản lý mật khẩu để tạo ra mật khẩu mạnh và duy nhất cho mỗi tài khoản. Tuyệt vời! Giờ bạn đã an toàn hơn rất nhiều trên internet, nhưng chỉ ở những nơi cho phép bạn an toàn thôi. Rất nhiều nhà cung cấp dịch vụ buộc mật khẩu phải tuân theo những quy tắc chặt chẽ, ví dụ như là giới hạn độ dài 10 ký tự. Những trường hợp như thế buộc bạn phải đặt một mật khẩu yếu hơn, gây ra rủi ro cho tài khoản của bạn, và bạn chẳng thể làm gì để thay đổi điều đó cả. Trong hoàn cảnh đó, nếu nhà cung cấp hỗ trợ 2FA, thì rõ ràng là tài khoản của bạn đã được bổ sung thêm một lớp bảo mật. Bạn có sẽ thắc mắc là “nếu nhà cung cấp đã không hỗ trợ mật khẩu mạnh thì sao lại hỗ trợ 2FA?”. Đó là một câu hỏi hay mà không có nhiều lời giải đáp thỏa đáng. Không có lí do hợp lý nào để giới hạn mật khẩu theo cách như vậy trong một hệ thống hiện đại.

Thế nên hãy xem xét một trường hợp khác với dịch vụ giả tưởng “Google” nhé. Trong ví dụ này thì bạn đang sử dụng một mật khẩu mạnh và duy nhất cho tài khoản “Google” và “Google” vẫn tuân theo những best practice để lưu mật khẩu. Đây chính là viễn cảnh lý tưởng! Đáng tiếc là, yếu tố bảo mật Knowledge (ví dụ như mật khẩu) vẫn dễ bị đánh cắp với nhiều loại tấn công khác. Hãy xem xét ba hình thức tấn công phổ biến nhất: Man in the middle attack, phishing và malware/keyloggers.

“Hacker đánh cắp mật khẩu của tôi khi mà tôi đang uống cafe!” 2FA vs Man in the Middle attack

Giả sử bạn đang ngồi thưởng thức cafe và kết nối với Wifi miễn phí. Đây chính là cơ hội tuyệt vời để tin tặc thực hiện Man in The Middle (MITM) attack, kiểu tấn công mà cho phép họ xen vào và đọc toàn bộ lưu lượng truy cập web của bạn. (Một chút ngoài lề, HTTPS giúp ngăn chặn MITM attack, bạn nên cài đặt HTTPS Everywhere để tận dụng điều đó).

Ngay khi mà bạn nhập username/mật khẩu và click “login”, tin tặc sẽ có được mật khẩu của bạn. Lúc này mật khẩu mạnh yếu duy nhất hay không không quan trọng nữa. Giờ đây họ có thể đăng nhập vào tài khoản “Google” của bạn sử dụng username/mật khẩu của chính bạn.

“Ê đợi đã”, bạn nói, “Khi mà 2FA được kích hoạt thì tôi vẫn cần chứng minh với website là tôi đang có quyền truy cập vào điện thoại mà tôi sở hữu mà. Thường thì website sẽ yêu cầu tôi nhập thêm một số thông tin lúc đăng nhập mà, đúng không? Ví dụ, dịch vụ có thể sẽ gửi một mã bảo mật đến điện thoại của tôi, hoặc là tôi sẽ tìm mã bảo mật trong ứng dụng mà tôi đã cài đặt. Nếu tin tặc có thể đọc toàn bộ lưu lượng web của tôi, thì họ cũng có thể lấy được mã 2FA trong quá trình đăng nhập mà?”

Những điều bạn vừa nói hầu như là đúng!

Trong khi hầu hết các cài đặt 2FA đều thể bảo vệ người dùng trước MITM attack, thì có một phương thức 2FA gọi là U2F có khả năng chống lại được MITM attack tốt hơn nhiều. Chúng tôi sẽ trình bày về U2F ở một trong các bài viết sau nhé.

Tin tặc sẽ chỉ có thể đăng nhập vào tài khoản của bạn 1 lần dựa vào username/password và mã 2FA vừa lấy được. Tại sao lại chỉ 1 lần? Một trong những thuộc tính quan trọng của 2FA là một mã 2FA chỉ hợp lệ trong một khoảng thời gian ngắn, cho là một vài phút đi, và chỉ có thể được sử dụng một lần. Việc tin tặc đăng nhập được vào tài khoản của bạn chẳng phải là điều tốt lành gì, nhưng dù sao vẫn chưa phải là mất tất cả!

Một vài nhà cung cấp dịch vụ đã tỉnh táo yêu cầu người dùng xác nhận bảo mật lại trước khi thực hiện một số hành động nhạy cảm, ví dụ như thay đổi địa chỉ email, mật khẩu, thiết lập 2FA, thực hiện một giao dịch tài chính… Những biện pháp đó ngăn tin tặc không thể đăng xuất các phiên đăng nhập trước đó của bạn vì tin tặc không có mã 2FA để xác thực khi hệ thống yêu cầu lần 2. Lý tưởng thì nhà cung cấp sẽ gửi cho bạn một email để báo cho bạn biết rằng có ai đó đã cố thực hiện những hành động nhạy cảm đó với tài khoản của bạn, điều đó giúp bạn có thể đổi mật khẩu và kết thúc phiên đăng nhập của tin tặc.
Dù không phải tất cả phương thức 2FA đều có thể chặn được MITM attack khi nó xảy ra lần đầu tiên, rõ ràng là bạn nên sử dụng 2FA, đặc biệt là khi nhà cung cấp dịch vụ có những cơ chế để giảm thiểu rủi ro và ngăn chặn việc mất tài khoản vĩnh viễn.

“Tôi vô tình ĐƯA mật khẩu cho hacker!” 2FA vs phishing

Như Jimmy Kimmel đã thể hiện một cách thú vị, cách tốt nhất để lấy mật khẩu của ai đó là chỉ cần hỏi họ thôi!


Đây chính là cách tiếp cận mà tin tặc thực hiện khi chúng tiến hành các cuộc tấn công lừa đảo (phishing). Thông thường, nó bắt đầu bằng việc người dùng nhận được email có chứa liên kết lừa đảo. Khi người dùng nhấp vào liên kết, một trang web trông giống như trang web họ dự định truy cập hiện lên, nhưng thực sự là một trang web giả mạo do tin tặc kiểm soát.

Tấn công lừa đảo là một vấn đề lớn trong hầu hết các ngành công nghiệp. Anti Phishing Working Group (APWG) đã nêu trong báo cáo Q4 năm 2016 của họ rằng các chiến dịch tấn công lừa đảo trong năm 2016 đã phá vỡ mọi kỷ lục của những năm trước với hơn 1,2 triệu cuộc tấn công lừa đảo, tăng 65% so với năm 2015. Để đưa ra một ví dụ gần gũi hơn cho tất cả những người dùng Gmail, Google gần đây đã phát hiện ra rằng


Nạn nhân của lừa đảo có khả năng bị tấn công thành công gấp 400 lần so với một người dùng Google ngẫu nhiên.

Sau khi nhập thông tin đăng nhập trên trang lừa đảo giả, bạn đã đưa tận tay yếu tố xác thực đầu tiên của bạn (một thứ gì đó mà bạn biết) cho các tin tặc có thể sử dụng ngay để đăng nhập vào tài khoản của bạn trên trang web thật. Sau đó, tin tặc có thể yêu cầu yếu tố xác thực thứ hai của bạn (một thứ gì đó mà bạn có) giống như trang web thật. Khả năng cao bạn sẽ điền mã 2FA để đăng nhập, điều này vô tình cấp cho tin tặc quyền truy cập ngay vào tài khoản của bạn. Hãy nhớ rằng tất cả điều này được tự động hóa bằng phần mềm và có thể xảy ra trong thời gian thực. Rất khó phát hiện nếu không để ý URL của trang web.

Độc giả tinh ý sẽ lại để ý cách dùng từ của tôi. Trong khi hầu hết các phương thức 2FA không bảo vệ bạn khỏi các cuộc tấn công lừa đảo, U2F lại làm được điều đó! Hãy theo dõi về tấn công lừa đảo trong các bài tiếp theo của series này nhé.

“Hackers đánh cắp mật khẩu của tôi ngay trên thiết bị của tôi!” 2FA vs malware và keyloggers

Trong cùng một nghiên cứu gần đây, Google cũng kết luận rằng “hiện tại thì mối đe dọa gây ra bởi rò rỉ thông tin xác thực và tấn công lừa đảo lớn hơn keylogger”. Mặc dù nguy cơ của phần mềm độc hại và keylogger ít hơn so với tấn công lừa đảo, nạn nhân của keylogger vẫn có khả năng bị tấn công thành công cao hơn khoảng 40 lần so với người dùng Google ngẫu nhiên. Rõ ràng, đó vẫn là một vấn đề rất lớn!

Phần mềm độc hại, bao gồm keylogger, có thể xâm nhập vào thiết bị của bạn theo bất kỳ cách nào. Bạn có thể trở thành nạn nhân của một email lừa đảo và tải xuống tệp đính kèm email độc hại. Hoặc có thể do bạn click vào đâu đó trên một trang web vớ vẩn. Nó thậm chí có thể đến từ một browser extension mà bạn đã cài đặt; nếu tài khoản tạo extension bị hack, thì mã độc có thể được chèn vào download xuống trong lần cập nhật tự động tiếp theo. Bất kể nó xâm nhập vào thiết bị của bạn như thế nào, phần mềm độc hại có thể là một vấn đề lớn khi được cài đặt.

Như tên của nó, keylogger có thể ghi lại từng ký tự mà bạn nhập trên thiết bị của mình. Ngay cả khi bạn được kết nối an toàn với trang web “Google” xịn, phần mềm độc hại trên máy tính của bạn có thể đánh cắp username/mật khẩu của bạn ngay khi bạn nhập chúng và gửi chúng cho tin tặc. Bạn biết sẽ nguy hiểm thế nào nếu điều đó xảy ra.

Các loại phần mềm độc hại khác có thể được thiết kế để đánh cắp thông tin cụ thể từ thiết bị của bạn, chẳng hạn như authentication secret hoặc token.

Cách chính để chống phần mềm độc hại là không truy cập phần mềm ngay từ đầu bằng cách thận trọng trên internet và cảnh giác về trang web mình chuẩn bị truy cập, liên kết mà mình chuẩn bị click . Rõ ràng, lời khuyên đó là vô ích nếu máy tính của bạn đã bị nhiễm. Nếu đã bị nhiễm phần mềm độc hại rồi thì giải pháp tốt nhất là cập nhật phần mềm chống virus và phần mềm độc hại.


May mắn thay, một số phương thức 2FA có thể giúp bảo vệ tài khoản
 của bạn ngay cả khi máy tính của bạn bị nhiễm phần mềm độc hại!

Hãy tưởng tượng rằng bạn đang đăng nhập vào tài khoản “Google” trên một thiết bị có chứa keylogger. Username/mật khẩu của bạn sẽ bị lộ vì chúng được nhập trên máy tính của bạn. Tài khoản của bạn có thể vẫn an toàn nếu bạn sử dụng phương pháp 2FA tên là “Out of band” (OOB). Trong trường hợp đó, bạn không phải gõ bất cứ thứ gì vào máy tính bị nhiễm phần mềm độc hại của bạn, vì vậy nó không thể bị đánh cắp. Khi sử dụng OOB, yếu tố xác thực Knowledge (ví dụ như mật khẩu) được gửi qua kênh chính (ví dụ như kết nối web trong trình duyệt của bạn), trong khi yếu tố xác thực Possession của bạn (ví dụ như điện thoại), được xác minh qua kênh phụ (ví dụ như kết nối độc lập với điện thoại của bạn).

Hãy theo dõi phần còn lại của loạt bài nhé, chúng ta sẽ thảo luận về phương pháp 2FA nào sẽ không có tác dụng trước phần mềm độc hại và phương pháp nào khả năng chống lại cao hơn!

Tổng kết

Chúng tôi đề cập đến rất nhiều thứ trong bài viết này. Cùng tóm tắt lại một chút nhé.

Thuật ngữ 2FA thường đề cập đến sự kết hợp của hai yếu tố xác thực PossessionKnowledge. Về lý thuyết, tin tặc sẽ phải sử dụng các loại tấn công khác nhau để đánh cắp thành công cả thứ bạn biết và thứ bạn có.

Yếu tố Knowledge (ví dụ như mật khẩu) dễ bị đánh cắp trước nhiều loại tấn công từ xa khác nhau. Vấn đề đầu tiên là cái cách mà chúng ta quản lý mật khẩu. Chúng ta đã thảo luận về việc 2FA hữu ích nhất khi bạn sử dụng lại mật khẩu giữa các tài khoản và/hoặc sử dụng mật khẩu yếu có thể dễ dàng bị tin tặc bẻ khóa trong trường hợp DB bị hack. Tốt nhất, bạn nên sử dụng trình quản lý mật khẩu để tạo mật khẩu mạnh, duy nhất cho mỗi tài khoản của mình.

Ngay cả đối với người dùng quản lý mật khẩu tốt, có nhiều cách khác mà mật khẩu của bạn có thể bị đánh cắp từ xa. 2FA nhằm mục đích cung cấp bảo mật tốt hơn bằng cách buộc tin tặc đánh cắp thứ gì đó trong quyền sở hữu vật lý của bạn (Possession). Thật không may, nhiều phương pháp 2FA cũng dễ bị tấn công trước các loại tấn công từ xa khác nhau. Tùy thuộc vào phương pháp 2FA được sử dụng, yếu tố Possession của bạn có thể chống lại man in the middle attack, phishing và thậm chí là malware/keyloggers.

Trong các bài viết sau, chúng tôi sẽ đi sâu vào chi tiết về các loại 2FA phổ biến nhất. Chúng tôi sẽ giải thích cách chúng hoạt động và thảo luận về việc liệu nó có thể chống lại các cuộc tấn công từ xa này hay không. Thêm vào đó, chúng tôi sẽ làm nổi bật một số đánh đổi khả năng sử dụng  có thể biết được phương pháp nào phù hợp nhất với bạn (hoặc người dùng của bạn)!

_________________

Cám ơn đời mỗi sớm mai thức dậy
Ta có thêm ngày nữa để yêu thương
http://www.cuuhvlq2.tk
      
OLD
OLD Developer

Cấp bậc: Developer

Giới tính : Nam

Bài viết : 666

Danh vọng : 1095

Uy tín : 16

SMS 2FA: Phổ biến nhất nhưng lại kém an toàn nhất

(Được lược dịch từ bài viết SMS: The most popular and least secure 2FA method)

SMS không thực sự xác thực được “một thứ gì đó mà bạn có”, vì vậy đừng dùng SMS cho bảo mật 2 lớp trừ khi bạn bắt buộc phải làm điều đó! Tìm hiểu cách SMS 2FA hoạt động để hiểu lý do tại sao nhé.

Chào mừng bạn quay trở lại với series về bảo mật 2 lớp (2FA)!

Nếu bạn là người mới, hãy xem bài viết đầu tiên trong series nhằm giải thích 2FA là gì và tại sao bạn thực sự nên kích hoạt nó trên tài khoản của mình (ngay cả khi bạn đã đặt mật khẩu mạnh và duy nhất).

Trong bài viết này, chúng tôi sẽ nói về cách thức hoạt động của bảo mật 2 lớp thông qua SMS. Bài viết này sẽ thảo luận về chi tiết kỹ thuật, nêu bật các lỗ hổng bảo mật và những đánh đổi khi sử dụng SMS 2FA.

Nhắc lại một chút rằng các yếu tố xác thực liên quan đến 2FA là yếu tố Knowledge (thứ gì đó mà bạn biết) và yếu tố Possession (thứ gì đó mà bạn có).

Trước khi chúng ta đi vào các phần hay ho, hãy cùng làm rõ điều này đã. Mặc dù SMS 2FA là lựa chọn cực kỳ phổ biến với các nhà cung cấp dịch vụ, nó có nhiều lỗ hổng phổ biến khiến nó không thể đáp ứng mục đích của yếu tố xác thực
Possession
. Nói cách khác, bạn không thể dựa vào SMS để thực sự chứng minh “một thứ gì đó mà bạn có” với nhà cung cấp dịch vụ. Trên thực tế, Viện Tiêu chuẩn và Công nghệ Quốc gia (NIST) đã ngừng sử dụng SMS cho 2FA trong các hệ thống của chính phủ Hoa Kỳ vào tháng 6 năm 2017. Bài viết này sẽ cho bạn hiểu rõ hơn tại sao đó là một quyết định cần thiết và ta cần phải làm gì.

Đăng ký ban đầu

Hãy bắt đầu bằng quá trình đăng ký SMS 2FA điển hình.

Hiểu biết về 2FA - xác thực hai yếu tố 01-reg10

Tôi sẽ định nghĩa “service provider” là nhà cung cấp dịch vụ web (ví dụ như Google, Facebook, Twitter…), và “phone company” có nghĩa là nhà cung cấp dịch vụ điện thoại di động của người dùng (ví dụ AT&T, Verizon…).

Sau khi chọn SMS 2FA từ cài đặt bảo mật, quá trình đăng ký tiếp theo khá dễ dàng. Đầu tiên, người dùng (hãy gọi cô ấy là Alice) nhập số điện thoại của mình. Tiếp theo, service provider tạo mật khẩu một lần duy nhất (OTP), ví dụ mã gồm 6 chữ số, rồi gửi nó đến điện thoại của Alice. Để thực hiện việc này, service provider gửi SMS có chứa OTP cho phone company, sau đó họ chuyển tiếp OTP đến thiết bị tương ứng với số điện thoại mà Alice đã nhập. Lý tưởng nhất là Alice nhận được tin nhắn chứa OTP và nhập nó vào trình duyệt của cô. Service provider xác minh rằng OTP Alice đã nhập khớp với OTP mà họ đã tạo lúc trước cho việc đăng ký SMS 2FA của Alice và kích hoạt SMS 2FA trên tài khoản của Alice.

Chúng ta sẽ thảo luận về các lỗ hổng bảo mật nên tôi phải trình bày hầu hết các bước trong workflow, nhưng trước tiên hãy xem xét quá trình xác thực khi Alice cố gắng đăng nhập vào tài khoản của mình.

Xác thực trong quá trình đăng nhập

Không có gì đáng ngạc nhiên khi quy trình đăng ký và xác thực SMS 2FA trông gần như giống hệt nhau, ngoại trừ việc Alice không cần nhập số điện thoại của mình vì nó đã được lưu khi đăng ký thành công.

Hiểu biết về 2FA - xác thực hai yếu tố 02-aut10

Nếu quy trình xác thực hoạt động bình thường thì SMS 2FA khá là dễ dùng đối với bất kỳ ai đã từng nhận SMS trên điện thoại, tức là rất nhiều người. Tuy nhiên, chúng ta hãy xem xét kỹ hơn từng bước của workflow trên để hiểu các lỗ hổng bảo mật của SMS 2FA.

Trong sơ đồ sau, tôi khoanh vùng màu đỏ xung quanh nơi mà dễ xảy ra lỗ hổng với SMS 2FA. Yup, đó là nằm ở phone company.

Hiểu biết về 2FA - xác thực hai yếu tố 03-aut10

Chuyện gì sẽ xảy ra nếu tôi không thể truy cập được điện thoại của mình?

Vậy, chuyện gì sẽ xảy ra nếu Alice bị mất, làm vỡ hoặc không thể truy cập điện thoại của mình? May mắn là cô ấy sẽ không phải lo lắng về việc mất tài khoản vĩnh viễn.

Alice có thể dễ dàng đến cửa hàng Verizon hoặc ATT, mua một chiếc điện thoại mới và cài đặt nó theo số điện thoại hiện có của mình. Giống như việc mọi người vẫn có thể tiếp tục gọi và nhắn tin theo cùng số điện thoại cho bạn khi bạn đổi máy, SMS 2FA sẽ tiếp tục hoạt động mà không cần sửa đổi gì.

Đợi chút. 2FA là sự kết hợp giữa hai yếu tố Knowledge (thứ gì đó mà bạn biết) và Possession (thứ gì đó mà bạn có). Thiết bị tin cậy cho yếu tố Possession của Alice (là điện thoại) đã bị mất. Nếu thiết bị đáng tin cậy thực sự là một thứ gì đó mà cô ấy đã có, vậy thì có phải Alice nên bị mất quyền truy cập vào tài khoản của mình khi mất điện thoại không? Hoặc, ít nhất cô ấy phải sử dụng mã khôi phục 2FA để truy cập vào tài khoản của mình, phải không?

Vấn đề nằm ở đây.

Mọi người có thể nhận được SMS theo hàng chục cách mà chả cần đến điện thoại. Ví dụ, bạn có thể chuyển tiếp SMS của mình đến máy tính bảng hoặc địa chỉ email. Hoặc là bạn có thể truy cập SMS online thông qua trang web của nhà cung cấp điện thoại di động của bạn chỉ bằng mật khẩu (một cái gì đó bạn biết). Hoặc, có thể bạn sử dụng Google Voice hoặc dịch vụ VoIP khác cũng hoạt động hoàn toàn trực tuyến thông qua trang web hoặc ứng dụng và có thể được truy cập từ bất kỳ thiết bị nào.

Mật khẩu một lần (OTPs) được gửi qua SMS không chứng minh quyền sở hữu vật lý của một thiết bị đáng tin cậy. Do đó, SMS không thỏa mãn mục đích của yếu tố xác thực Possession.

Những độc giả thông minh sẽ nhận ra rằng nếu Alice có thể bước vào một cửa hàng và mua một chiếc điện thoại mới để giải quyết vấn đề về điện thoại bị mất của cô ấy, thì điều đó có nghĩa là ai đó có thể giả vờ là Alice để làm điều tương tự.

Cuối cùng, chúng ta có thể bắt đầu nói về các lỗ hổng bảo mật của SMS 2FA.

Con người luôn luôn là liên kết yếu nhất

Thay vì cố gắng đánh cắp điện thoại của bạn, thì tin tặc sẽ tấn công từ xa để đánh cắp số điện thoại của bạn. Vậy chính xác thì nó hoạt động như thế nào? Bằng cách lừa đảo.

Hiểu biết về 2FA - xác thực hai yếu tố 04-soc10

Hacker có thể sử dụng tấn công phi kỹ thuật (social engineering) để thuyết phục nhân viên dịch vụ viễn thông rằng họ là bạn để kích hoạt SIM mới được liên kết với số điện thoại của bạn. Khi điều này xảy ra, tin tặc sẽ nhận được tất cả tin nhắn SMS và cuộc gọi điện thoại của bạn trên điện thoại của họ và điện thoại của bạn sẽ ngừng hoạt động.

Hiện đã có nhiều tài liệu chi tiết về các cuộc tấn công phi kỹ thuật trên SMS 2FA. Wired có một bài viết xuất sắc từ tháng 6 năm 2016 có tiêu đề là “So, hey. You should stop using texts for 2FA”, trong đó họ tập trung vào cách tin tặc tấn công tài khoản Twitter của nhà hoạt động DeRay McKesson của Black Lives Matter sau khi thuyết phục Verizon liên kết số điện thoại ứng với tài khoản đó với điện thoại của họ.

Vào khoảng giữa năm 2016, SIM của Lorrie Cranor, người sau đó trở thành Chief Technologist của FTC, cũng bị tấn công phi kỹ thuật. Bà nhấn mạnh rằng Cục Bảo vệ người tiêu dùng New York có cảnh báo chính thức về loại lừa đảo này trên trang web của họ.

Vào cuối năm 2016, Forbes đưa tin về việc tin tặc đã sử dụng tấn công phi kỹ thuật để kiểm soát điện thoại nạn nhân và có thể đánh bại SMS 2FA để đánh cắp lượng bitcoin trị giá hàng triệu đô la. New York Times đưa tin vào tháng 8 năm 2017 rằng các cuộc tấn công nhằm chiếm quyền kiểm soát số điện thoại tiếp tục gia tăng khi tin tặc cố gắng vượt qua SMS 2FA của các tài khoản tiền ảo.

Một số người thường tranh luận rằng mặc dù SMS 2FA tồn tại các lỗ hổng tấn công phi kỹ thuật, việc tấn công này không phải là dễ dàng với hacker vì họ phải nhắm vào những người cụ thể và thu thập đủ thông tin để thuyết phục phone company rằng họ là nạn nhân. Lập luận cổ lỗ sĩ này trở nên kém thuyết phục dần theo thời gian.

Đúng là các công ty điện thoại có nghĩa vụ xác thực danh tính của bạn trước khi thay đổi tài khoản của bạn, nhưng điều đó thường liên quan đến việc đặt câu hỏi như tên, địa chỉ, số an sinh xã hội, v.v. Về cơ bản, những thông tin đó đã phổ biến rộng rãi kể từ tháng 9 năm 2017 do vụ hack Equifax.

Mới đầu tháng 2 năm 2018, T-Mobile đã gửi một thông cáo cho tất cả các khách hàng của mình cảnh báo về một vụ lừa đảo chiếm quyền điều khiển điện thoại phạm vi toàn ngành, trong đó tin tặc sẽ thuyết phục các nhà mạng điện thoại chuyển số cho một nhà mạng khác, và kiểm soát số điện thoại trong quá trình đó. T-Mobile thậm chí có một trang riêng trên trang web của họ nói về rủi ro của việc chuyển số. Rõ ràng, vấn đề này không nhỏ một chút nào.

Ngay cả khi các công ty điện thoại, bằng một cách nào đó, có thể giải quyết các rủi ro tấn công phi kỹ thuật, sẽ luôn có mối đe dọa nội bộ cần được xem xét. John McAfee, người tạo ra McAfee AntiVirus, đã bị chiếm đoạt tài khoản Twitter và suy đoán rằng ai đó tại ATT có thể đã bị tin tặc mua chuộc để chuyển số của anh ta sang một điện thoại khác. Mặc dù anh ta không có bằng chứng để chứng minh điều đó, nhưng rủi ro kỹ thuật sẽ luôn tồn tại bởi vì SMS 2FA hoàn toàn phụ thuộc vào việc các công ty điện thoại có thực hiện đúng không, và rõ ràng, họ thường không làm tốt điều đó.

Dễ bị tấn công SS7 trên mạng điện thoại

Chúng tôi đã trình bày vài lỗ hổng bảo mật xoay quanh phone company, nhưng đó chưa phải là tất cả. Bây giờ, hãy nói về các lỗ hổng kỹ thuật với SMS.

Hiểu biết về 2FA - xác thực hai yếu tố 05-ss710

Có một lỗ hổng nổi tiếng trong mạng điện thoại hoàn toàn không dựa vào tấn công phi kỹ thuật. Signal System 7 (SS7) là một loạt các giao thức xử lý các cuộc gọi điện thoại và tin nhắn văn bản trên mạng điện thoại toàn cầu. Nó được tạo ra vào năm 1975 và, thật sốc khi nó vẫn là cốt lõi của các mạng điện thoại toàn cầu ngày nay, sau hơn 40 năm. MotherBoard nhấn mạnh rằng “bảo mật và xác thực đã không thực sự được tích hợp vào mạng SS7 ngay từ đầu, và phần lớn mạng có nhiều lỗ hổng để bị khai thác.”

Những lỗ hổng này cung cấp cho tin tặc một phương pháp kỹ thuật định tuyến tin nhắn SMS của bạn trực tiếp đến điện thoại của chúng mà không cần thông qua phone company của bạn.

Mặc dù được biết đến và thảo luận trong nhiều năm, năm 2016 là một năm phổ biến với việc khai thác các lỗ hổng SS7 trên phương tiện truyền thông.

Positive Technologies đã trình bày cách sử dụng các lỗ hổng SS7 để chiếm quyền điều khiển tài khoản WhatsApp và nhấn mạnh rằng “mạng SS7 có thể bị kẻ tấn công xâm nhập… Một sự thật rõ ràng là OTP qua SMS không an toàn, vì truyền tin trên mạng di động không an toàn.”

Forbes cũng đã viết về việc bạn có thể trả tiền cho một công ty Israel để theo dõi bất kỳ điện thoại nào trên thế giới và ghi lại tin nhắn văn bản từ xa.

Nhiều người trước đây cho rằng việc khai thác SS7 rất khó khăn và tốn kém vì mạng ban đầu được giới hạn chỉ các nhà vận hành mạng điện thoại lớn, tức là khoảng 5 nhà mạng. MotherBoard chỉ ra rằng việc đó giờ đã không còn nữa:

… Trong những năm gần đây, định nghĩa về một nhà vận hành mạng đã thay đổi. Ngày nay, trên thực tế, bất cứ ai cũng có thể trở thành một nhà vận hành mạng.. Các nhà cung cấp dịch vụ di động, nhà cung cấp VoIP và dịch vụ SMS của bên thứ ba mới nổi trên mạng di động toàn cầu đều có quyền truy cập vào SS7 và họ có thể chia sẻ quyền truy cập đó với những người khác.

Vào tháng 5 năm 2017, The Hacker News đã đưa tin rằng bọn tội phạm công nghệ cao đã khai thác lỗ hổng SS7 để lấy mã xác thực hai lớp (OTP) được gửi cho khách hàng sử dụng ngân hàng trực tuyến và rút tiền từ tài khoản ngân hàng của họ. MotherBoard cũng đưa tin về cuộc tấn công này, và một bài báo mà họ đã viết chỉ 5 tháng trước đó có tựa đề là “You’re Probably Fine with SMS-Based Two-Factor Authentication” đã được khẳng định là không còn đúng nữa.
Một bài viết trên Security Intelligence tổng hợp ngắn gọn về SS7 như sau:

…Các chuyên gia đã biết trong 30 năm qua rằng SS7 – giao thức switching được sử dụng bởi hơn 800 doanh nghiệp viễn thông toàn cầu – không hề an toàn… Quan trọng nhất là cần phải hiểu rằng mạng điện thoại không an toàn và có lẽ sẽ không bao giờ an toàn.

Phone company luôn có thể đọc được SMS của người dùng

Ngay cả khi các lỗ hổng của SS7 được xử lý bằng cách nào đó và mạng điện thoại được bảo mật, SMS vẫn là một lựa chọn tồi cho 2FA vì các tin nhắn SMS truyền qua mạng điện thoại không được mã hóa đầu cuối.

Giao tiếp giữa điện thoại của bạn và trạm phát sóng có một số biện pháp bảo mật, nhưng không có mã hóa đầu cuối thì công ty điện thoại vẫn có thể đọc nội dung của tất cả các tin nhắn SMS của bạn. Điều này bao gồm mật khẩu một lần (OTP) nhằm “chứng minh” rằng bạn có quyền sở hữu vật lý đối với điện thoại của mình.

Có khá nhiều ứng dụng chat hỗ trợ mã hóa đầu cuối. Ví dụ, hàng triệu người sử dụng Signal, một ứng dụng chat phổ biến và tôn trọng quyền riêng tư của người dùng, để gửi tin nhắn được mã hóa đầu cuối. WhatsApp và Facebook Messenger cũng đã triển khai giao thức Signal hỗ trợ mã hóa đầu cuối cho 2,4 tỷ người dùng của họ. iMessage của Apple cũng hỗ trợ mã hóa đầu cuối. Tuy nhiên, không có ứng dụng nào trong số đó sử dụng SMS như là công nghệ nền tảng. Tất cả đều yêu cầu ứng dụng (mobile hoặc desktop) và kết nối mạng để hoạt động.

Nguy cơ trước phishing và MITM attack

Hiểu biết về 2FA - xác thực hai yếu tố 06-phi10

Biểu đồ trên cho thấy ngay cả khi SMS 2FA hoạt động bình thường, người dùng vẫn dễ dàng trở thành nạn nhân của phishing.
Trong kịch bản này, Alice nghĩ rằng cô ấy đang sử dụng trang web thật, vì vậy cô ấy đăng nhập bằng mật khẩu của mình. Các tin tặc điều hành trang fake sử dụng mật khẩu Alice cung cấp để đăng nhập vào trang thật. Nhà cung cấp dịch vụ sẽ xác minh mật khẩu của Alice, tạo OTP và gửi nó cho Alice qua SMS. Một lần nữa, Alice nghĩ rằng cô đang ở trên trang web thật và biết rằng mình đã bật SMS 2FA, vì vậy cô vui vẻ nhập OTP vào trang fake. Khi đó, tin tặc sẽ sử dụng OTP hợp lệ đó để đăng nhập thành công vào tài khoản của Alice trên trang web thật. Game over.

SMS 2FA cũng không mạnh trước Man in the Middle attack. Phishing dựa vào các trang web giả mạo trông giống thật để lừa Alice. Nếu Alice trở thành nạn nhân của một cuộc tấn công MITM, thì cô ấy thực sự được kết nối với trang web thực sự, nhưng được sử dụng kết nối HTTP không an toàn. Điều này cho phép tin tặc đọc tất cả lưu lượng truy cập web mạng, bao gồm cả OTP mà Alice nhập thủ công vào trình duyệt của cô.

Hãy nhớ rằng, HTTPS giúp ngăn chặn các cuộc tấn công MITM; bạn nên cài đặt HTTPS Everywhere để ngăn chặn điều đó.

Nguy cơ trước malware/keyloggers

Trong bài viết giới thiệu về 2FA, chúng tôi đã nêu ra rằng có nhiều phương thức 2FA dễ bị tổn thương trước malware và keylogger. SMS 2FA là một trong số đó.

Hiểu biết về 2FA - xác thực hai yếu tố 07-aut10

Kiến trúc phổ biến của SMS 2FA không sử dụng xác minh Out of band (OOB).

Trong sơ đồ trên, kết nối giữa máy tính của Alice và service provider (bước 1 và 4) là “kênh chính”. Giao tiếp giữa service provider và điện thoại của Alice (bước 2 và 3) là “kênh phụ”. Lưu ý rằng mật khẩu (thứ mà Alice biết) và OTP (thứ mà Alice “có”) đều được gửi đến nhà cung cấp dịch vụ thông qua kênh chính. Điều này có nghĩa là tin tặc chỉ cần chiếm được kênh chính là có thể truy cập vào tài khoản. Điều này có thể được thực hiện thông qua phần mềm độc hại trên máy tính của Alice.
Nếu kiến trúc được thay đổi sao cho Alice bắt buộc phải gửi lại OTP cho nhà cung cấp dịch vụ qua kênh phụ (ví dụ như sử dụng SMS), thì điều đó sẽ được tính là OOB. Kiến trúc ngăn chặn được malware trên máy tính của Alice, nhưng điện thoại cũng có thể bị nhiễm malware. Nếu điện thoại của Alice nhiễm malware có thể đọc được SMS, thì OOB SMS 2FA vẫn sẽ tồn tại rủi ro.

Vậy nên làm gì với SMS 2FA?

Bất chấp các lỗ hổng mà chúng tôi đã trình bày ở trên, SMS 2FA vẫn là việc phương thức 2FA phổ biến nhất hiện nay.
Có nhiều lý do cho sự phổ biến đó, nhưng rõ ràng nhất là vì khả năng sử dụng. Hầu hết mọi người có điện thoại có thể nhận được SMS và họ có thể dễ dàng nhập 6 chữ số vào trình duyệt.

Một số người đưa ra lập luận rằng SMS 2FA không nên bị bỏ đi vì có 2FA còn hơn là không có gì. Thật vậy, tôi hoàn toàn đồng ý rằng SMS 2FA tốt hơn là không có gì, nhưng đó là ngụy biện rơm. Lựa chọn ở đây không phải là giữa SMS 2FA và không có gì. Mà là giữa SMS 2FA và ít nhất ba phương thức 2FA khác: time-based one-time passwords (TOTP), Push notification, và U2F. So với các lựa chọn kia thì SMS 2FA không nghi ngờ gì là phương thức yếu nhất và quyết định của NIST về việc loại bỏ SMS 2FA là một định hướng đúng đắn cho hầu hết các service provider để người dùng không phụ thuộc vào các giải pháp kế thừa không an toàn.

Nếu bạn là người dùng cuối, đây là một vài lời khuyên dành cho bạn. Đầu tiên, sử dụng trang web cực kỳ tiện dụng https://twofactorauth.org/ để tra cứu xem dịch vụ có cung cấp phương thức 2FA nào hay không. Nếu họ không hỗ trợ, hãy gửi cho họ một dòng tweet khó chịu và gây áp lực cho họ để họ hỗ trợ 2FA! Nếu dịch vụ chỉ cung cấp SMS 2FA, thì hãy kích hoạt nó! Mặc dù đây là hình thức yếu nhất của 2FA, nhưng chắc chắn là tốt hơn không có gì! Một tweet khó chịu yêu cầu các tùy chọn tốt hơn cũng ok, cái này là tuỳ bạn nhé. Nếu dịch vụ cung cấp các phương thức 2FA an toàn hơn, thì nên tránh dựa vào SMS. Có nhiều tùy chọn an toàn hơn mà vẫn rất thuận tiện để sử dụng. Chúng tôi sẽ thảo luận về tất cả các phương pháp 2FA khác trong suốt phần còn lại của series này. Hãy theo dõi nhé!

Nếu bạn là service provider – bên xây dựng phần mềm, thì quyết định của bạn chỉ phức tạp hơn một chút thôi. Như NIST khuyến nghị, bạn nên xác định mức độ rủi ro chấp nhận được đối với (các) hệ thống của mình và dữ liệu liên quan và nếu bạn chọn triển khai SMS 2FA, thì bạn cần phải đánh giá, hiểu và chấp nhận các rủi ro liên quan đến trình phương thức xác thực bị giới hạn đó và hiểu rõ rằng rủi ro có thể sẽ tăng theo thời gian.

Không khó để hiểu rằng NIST đang nói rằng SMS 2FA có quá nhiều lỗ hổng, đặc biệt là trong các dự án mới. Họ cho rằng các lỗ hổng đó SMS 2FA sẽ không được khắc phục, và nếu không kể đến các yếu tố khác thì service provider thực sự không nên hỗ trợ SMS 2FA vì nó không an toàn.

Tất nhiên, có những kịch bản cụ thể mà ta cần xem xét. Nhiều dịch vụ nhắm đến người dùng trên toàn thế giới, và có những người có thể không có khả năng sử dụng các phương thức 2FA khác. Ví dụ: nếu một phần không nhỏ người dùng của bạn không có điện thoại thông minh, thì họ không thể sử dụng Push notification hoặc TOTP. Nếu họ không đủ khả năng để mua một vài thiết bị vật lý, thì U2F cũng không phải là một lựa chọn hợp lý. Trong trường hợp này, chắc chắn SMS 2FA tốt hơn so với giải pháp thay thế duy nhất là không có 2FA!

Tuy nhiên, vấn đề chính là người dùng của bạn không đồng nhất. Bạn chắc chắn sẽ có một số người dùng có điện thoại thông minh và/hoặc có thể mua thiết bị U2F. Thông thường các dịch vụ cung cấp nhiều phương thức 2FA vì lý do này. Thật không may, quyết định sử dụng phương pháp nào thường hoàn toàn phụ thuộc vào người dùng. Duo, nhà cung cấp hàng đầu các giải pháp xác thực hai yếu tố (2FA), nhận thấy rằng chỉ có ~ 28% người dân ở Mỹ sử dụng 2FA và chỉ ~ 56% biết 2FA là gì. Trung tâm nghiên cứu Pew đã thực hiện một bài kiểm tra an ninh mạng trong đó chỉ có 18% người dùng có thể xác định chính xác cái nào là phương thức xác thực đa yếu tố (MFA).

Nhiều người dùng có thể sử dụng phương pháp 2FA an toàn hơn có thể sẽ chỉ chọn sử dụng SMS đơn giản vì nó quen thuộc và không yêu cầu thêm bước tải ứng dụng hoặc mua thiết bị khác. Rõ ràng là hầu hết người dùng không tìm hiểu sự khác biệt giữa các phương thức 2FA là gì.

Người dùng có thể biết rằng họ nên kích hoạt 2FA và thường nghĩ rằng các phương thức 2FA có độ bảo mật như nhau. Nếu họ chọn SMS 2FA, thì họ vô tình chọn sử dụng phương thức 2FA kém an toàn nhất hiện có.

Là service provider, bạn có trách nhiệm cho người dùng biết về sự đánh đổi bảo mật cơ bản giữa các tùy chọn 2FA được cung cấp. Sau đó, người dùng có thể đưa ra quyết định sáng suốt hơn và hy vọng là họ có thể hiểu được rủi ro khi chọn SMS 2FA. Trên thực tế, NIST đặc biệt yêu cầu service provider phải cung cấp thông báo rõ ràng cho người dùng về các rủi ro bảo mật của những phương thức xác thực BỊ GIỚI HẠN và tính khả dụng của các giải pháp thay thế KHÔNG BỊ GIỚI HẠN. Nói cách khác, nếu bạn cung cấp SMS 2FA, bạn cần nói với người dùng rằng nó không an toàn và làm nổi bật các phương thức xác thực an toàn hơn mà bạn cung cấp.

Tất nhiên, nếu dịch vụ của bạn nhắm mục tiêu người dùng có điện thoại thông minh, thì tôi khuyên bạn nên tránh sử dụng SMS 2FA hoàn toàn và thay vào đó hỗ trợ TOTP và / hoặc Push. Tài khoản của người dùng sẽ được bảo mật hơn và người dùng sẽ ít phải đưa ra quyết định hơn.

Tổng kết

Nói tóm lại, SMS không thực sự chứng minh “một thứ gì đó mà bạn có”, vì vậy đừng dựa vào nó trong bảo mật 2 lớp trừ khi bạn thực sự cần. Các phương thức 2FA khác an toàn hơn nhiều và một số thậm chí còn thuận tiện hơn để sử dụng! Push không yêu cầu bạn nhập thủ công OTP vào trình duyệt, TOTP và U2F đều không yêu cầu kết nối mạng, rất phù hợp để đi du lịch. Chúng tôi sẽ trình bày chi tiết về các phương thức 2FA đó trong suốt phần còn lại của series này.

Một lời nhắc cuối cùng. Nếu bạn giao dịch tiền điện tử, bạn chắc chắn nên ưu tiên các phương thức 2FA an toàn hơn SMS 2FA bất cứ nơi nào bạn có thể. Bạn hoàn toàn không muốn mất hàng triệu đô la nếu tin tặc nhắm vào bạn và xâm nhập vào ví trực tuyến của bạn phải không?

_________________

Cám ơn đời mỗi sớm mai thức dậy
Ta có thêm ngày nữa để yêu thương
http://www.cuuhvlq2.tk
      
OLD
OLD Developer

Cấp bậc: Developer

Giới tính : Nam

Bài viết : 666

Danh vọng : 1095

Uy tín : 16

TOTP: an toàn hơn (rất nhiều) so với SMS, nhưng so với Push lại không tiện bằng

Bạn đã bao giờ tự hỏi Google Authenticator hoạt động như thế nào chưa? Cùng tìm hiểu lý do tại sao TOTP 2FA an toàn hơn SMS 2FA và sự an toàn hơn đó cần phải đánh đổi những gì nhé.

Chào mừng bạn quay trở lại loạt bài xác thực hai yếu tố (2FA)!

Nếu bạn là người mới, hãy đọc bài viết đầu tiên trước nhé. Bài viết giải thích 2FA là gì và tại sao bạn thực sự nên kích hoạt nó trên tài khoản của mình (ngay cả khi bạn có một mật khẩu mạnh và duy nhất).

Bài viết thứ hai chỉ ra lý do bạn nên ưu tiên các phương pháp khác 2FA an toàn hơn thay vì 2FA SMS nếu có thể.

Một trong những phương pháp an toàn hơn 2FA SMS là sử dụng Google Authenticator hoặc một ứng dụng tương tự trên điện thoại của bạn để tạo mã 2FA. Bạn đã bao giờ nghe nói về các ứng dụng này và tự hỏi chúng thực sự hoạt động như thế nào chưa? TODAY YOU LEARNED xD

Bài viết sẽ đề cập đến cách triển khai phổ biến của xác thực hai yếu tố sử dụng mật khẩu một lần dựa trên thời gian (time-based one-time passwords – TOTP 2FA).

Trước tiên hãy làm rõ một số khái niệm đã nhé:

  • service provider: nhà cung cấp dịch vụ web (ví dụ: Google, Facebook, Twitter, v.v.);
  • OTP: mật khẩu dùng một lần;
  • trusted device: bất kỳ thiết bị nào chạy được ứng dụng xác thực (authenticator app) có thể tạo OTPs dạng TOTP, chẳng hạn như Google Authenticator. Thông thường, trusted device là điện thoại thông minh hoặc máy tính bảng, nhưng cũng có thể bao gồm máy tính để bàn, máy tính xách tay, đồng hồ thông minh…


Và cuối cùng, xin nhắc lại rằng các yếu tố xác thực liên quan đến 2FA là yếu tố Knowlegde (thứ bạn biết) và yếu tố Possession (thứ bạn có).

Ok let’s start!

Luồng đăng ký của user lần đầu tiên sử dụng TOTP 2FA

Trong suốt bài viết này, chúng ta hãy cùng theo chân Alice (người bạn quen thuộc của chúng ta) trong quá trình sử dụng TOTP 2FA của cô ấy nhé. Hãy bắt đầu bằng với hình ảnh mô tả luồng đăng ký nhé. A picture is worth a thousand words, right?

Hiểu biết về 2FA - xác thực hai yếu tố 01-tot10

Khi Alice bắt đầu quá trình đăng ký 2FA, nhà cung cấp dịch vụ sẽ show ra một mã QR trong trình duyệt của Alice và yêu cầu cô ấy quét mã đó bằng ứng dụng xác thực trên trusted device của mình. Nếu Alice chưa có ứng dụng xác thực thì cô ấy phải cài đặt ứng dụng trước khi tiếp tục.

Có rất nhiều ứng dụng có sẵn dùng để lấy TOTP, chẳng hạn như Google Authenticator, Authy, Duo Mobile, Auth0 Guardian và FreeOTP đều có khả năng tạo OTP như nhau. Alice cần chọn một trong số các ứng dụng trên và cài đặt nó.

Đây là ảnh chụp màn hình của ứng dụng Google Authenticator:

Hiểu biết về 2FA - xác thực hai yếu tố 02-goo10

Sau khi cài đặt ứng dụng xác thực, Alice sử dụng nó để quét mã QR được hiển thị trong trình duyệt của cô ấy nhằm lưu một secret chung vào trusted device. Secret chung này chính là nền tảng hoạt động của TOTP và tôi sẽ giải thích cụ thể sau, tuy nhiên có hai điều đơn giản cần phải làm nổi bật trước. Đầu tiên, sercret này được chia sẻ; Alice giữ một bản và nhà cung cấp dịch vụ giữ một bản. Thứ hai, sercet này là bí mật; chỉ Alice và nhà cung cấp dịch vụ mới có quyền truy cập nó.

Sau khi quét mã QR, ứng dụng xác thực bắt đầu tự động tạo OTP cho tài khoản của Alice. Các mã này thường dài 6 chữ số và thay đổi sau mỗi 30 giây. Để hoàn tất quy trình đăng ký TOTP 2FA, Alice nhập OTP hiện tại được hiển thị trên trusted device của mình vào trình duyệt. Điều này cho phép nhà cung cấp dịch vụ xác minh rằng đó là OTP chính xác và kích hoạt TOTP 2FA trên tài khoản của Alice.

Công bằng mà nói, đăng ký TOTP 2FA phức tạp hơn SMS 2FA. Lần đầu tiên Alice thiết lập TOTP 2FA, cô ấy sẽ cần tải một ứng dụng mới xuống trusted device của mình, sử dụng ứng dụng đó để quét mã QR. Trong khi đó với SMS 2FA, trong đó Alice chỉ cần nhập số điện thoại của mình và nhập mã từ SMS vào trình duyệt. May mắn thay, việc sử dụng TOTP 2FA đơn giản nhiều so với việc đăng ký.

Luồng đăng ký của user lần thứ n sử dụng TOTP 2FA

Alice chỉ cần cài đặt ứng dụng xác thực trên điện thoại của mình một lần duy nhất. Như đã đề cập trước đây, hầu hết các ứng dụng xác thực đều triển khai thuật toán TOTP tiêu chuẩn và do đó có thể tạo các mã OTP giống nhau. Việc Alice lựa chọn ứng dụng xác thực nào để sử dụng chủ yếu dựa vào việc cô ấy thích cái nào.

Hiểu biết về 2FA - xác thực hai yếu tố 03-tot10

Sơ đồ trên cho thấy quy trình đăng ký khi mà Alice có sẵn ứng dụng xác thực trên trusted device của mình. Cô ấy chỉ phải quét mã QR bằng ứng dụng hiện có và sau đó nhập OTP từ ứng dụng để kích hoạt TOTP 2FA trên tài khoản của mình.

Với mỗi tài khoản, Alice chỉ cần đăng ký TOTP 2FA một lần duy nhất. Sau đây là quá trình xác thực khi đăng nhập (đơn giản hơn đăng ký nhiều!).

Xác thực khi đăng nhập

Việc duy nhất mà Alice cần làm thêm lúc đăng nhập đó là nhập OTP từ trusted device của mình vào trình duyệt.

Hiểu biết về 2FA - xác thực hai yếu tố 04-tot10

Quy trình đăng nhập này khá đơn giản và được cho là thân thiện với người dùng hơn so với SMS 2FA.

Điểm cải tiến quan trọng là không có gì được gửi qua mạng từ service provider tới trusted device của Alice. Ứng dụng sử dụng secret (mà service provider cũng có) để tạo OTP ngay tại trusted device. Điều này có nghĩa là Alice không cần sim hay sóng điện thoại để sử dụng TOTP 2FA. Điều đó khiến người dùng không cần chờ đợi tin nhắn đến và rất thuận tiện cho những người ở những khu vực sóng kém hoặc đi du lịch nước ngoài.

Ngoài những lợi ích về tính khả dụng, TOTP 2FA còn an toàn hơn đáng kể so với SMS 2FA. Nếu xem lại bài viết SMS 2FA, bạn sẽ nhận thấy rằng có một nguồn lỗ hổng bảo mật lớn đến từ công ty điện thoại và mạng điện thoại. Loại bỏ những điều đó mang lại lợi ích bảo mật rất lớn: không bị tấn công phi kỹ thuật, không sợ người ở công ty điện thoại cố tình đánh cắp thông tin, không còn các cuộc tấn công SS7 trên mạng điện thoại nhằm chuyển hướng SMS…

Tuy nhiên, TOTP 2FA có những nhược điểm riêng. Trước khi chúng tôi đề cập đến những điều đó, hãy trả lời một câu hỏi mà một số độc giả thường thắc mắc: Làm thế quái nào mà service provider lại biết rằng Alice đã nhập đúng mã OTP?!

Quét QR, nhận mã liền nha! (mã ở đây chính là secret chung)

Secret chung là nền tảng về cách hoạt động của TOTP 2FA và tôi muốn giải thích nhanh cách nó trusted device lấy được nó một cách an toàn từ nhà mạng.

Hiểu biết về 2FA - xác thực hai yếu tố 05-qr-10

Mã QR chỉ đơn giản là một cách mã hóa một vài loại dữ liệu, chẳng hạn như văn bản ký tự thuần túy. Bạn có thể thấy trong các ví dụ trên rằng mã QR có thể được tạo để mã hóa bất kỳ văn bản nào bạn muốn. Cùng trải nghiệm với The QR Code Generator nhé, bạn chỉ cần nhập văn bản và có thể xem mã QR tương ứng của nó ngay tức thì.

Mã QR được hiển thị trong quá trình đăng ký TOTP 2FA mã hóa thông tin mà ứng dụng xác thực trên trusted device cần để hoạt động một cách chính xác. Các chi tiết kỹ thuật được xác định trong đặc tả kỹ thuật, nhưng tổng quát thì mã QR bao gồm những thứ như địa chỉ email / username của Alice và tên của service provider để ứng dụng có thể biết được OTP nào đi với tài khoản nào. Quan trọng nhất, nó bao gồm secret chung.

Vậy sau khi ứng dụng xác thực trên trusted device có secret chung từ mã QR, nó sẽ tạo OTP như thế nào?

Cách mà OTP được sinh ra và xác thực

Trong bài viết đầu tiên của series này, chúng ta đã thảo luận về hai thuộc tính quan trọng của các hàm băm mật mã. Chúng có vai trò mật thiết để có thể hiểu được cách mà mật khẩu được lưu trữ an toàn trong cơ sở dữ liệu. Các hàm băm mật mã được sử dụng rộng rãi trong thuật toán TOTP, nên giờ chúng ta thảo luận về chúng ở mức chi tiết hơn.

Tính chất quan trọng nhất cần phải nhớ của các hàm băm mật mã là deterministic; tức là các giá trị đầu vào giống nhau sẽ luôn tạo ra các giá trị băm đầu ra giống nhau.

Trên trusted device, ứng dụng xác thực sẽ đưa vào hàm băm secret chung cùng với thời gian hiện tại, hàm băm sẽ xử lý các kiểu rồi trả về OTP! Server cũng sinh ra OTP y hệt vì nó có bản sao của secret chung và có cùng thời gian hiện tại với trusted device dựa vào Network Time Protocol (NTP). Service provider có thể xác minh rằng Alice đã nhập đúng giá trị OTP trong quá trình đăng ký và xác thực vì việc tính toán cục bộ trên trusted device và trên server của service provider là tương đương.

Có một số thuộc tính quan trọng khác của các hàm băm mật mã giúp chúng ta hiểu rõ các nguy cơ bảo mật của TOTP 2FA, nhưng chúng nằm ngoài phạm vi của bài viết này. Tôi sẽ đề cập đến các thuộc tính đó trong một bài viết sau này nhé!
Hy vọng lời giải thích trên giúp bạn hiểu rõ cách OTP được tạo, được xác thực và tại sao ta không cần phải gửi bất cứ thứ gì qua bên thứ ba như công ty điện thoại. Đây là lý do chính mà TOTP 2FA an toàn hơn nhiều so với SMS 2FA. Tuy nhiên, kiến trúc này phải đối mặt với một thách thức khác mà SMS 2FA không có: bảo vệ secret chung.

Đánh cắp secret chung từ service provider!

Nếu kẻ tấn công có thể sao chép được secret chung, thì hắn có thể tạo OTP hợp lệ và vượt qua được lớp bảo mật TOTP 2FA.

Hiểu biết về 2FA - xác thực hai yếu tố 06-ser10

Để ngăn secret chung bị lộ ngay lập tức trong trường hợp bị rò rỉ dữ liệu, service provider phải lưu trữ secret chung một cách an toàn (tham khảo thêm tại NIST 800-63B).

Nhân tiện đây ta sẽ nói thêm về băm mật mã một chút! Hãy nhớ rằng, một thuộc tính quan trọng khác của chúng là one-way; tức là việc tìm ra input từ output là không khả thi về mặt tính toán. Mặc dù đây là thuộc tính lý tưởng mà chúng ta muốn khi lưu trữ mật khẩu một cách an toàn, nhưng nó lại không phù hợp để lưu trữ secret chung. Cần nhớ rằng, thuật toán TOTP cần secret chung làm input, vì vậy nếu ta lưu secret chung dưới dạng băm, thì ta sẽ không thể khôi phục được giá trị ban đầu.

Thay vào đó, service provider sẽ mã hóa secret chung bằng key mã hóa. Điều này vừa ngăn nó được việc secret chung bị lưu trữ một cách không an toàn dưới dạng văn bản thuần túy trong cơ sở dữ liệu, vừa cho phép nhà cung cấp dịch vụ sử dụng khóa để giải mã secret khi cần. Mỗi khi người dùng đăng nhập, secret chung được giải mã làm đầu vào cho hàm băm trong thuật toán TOTP. Điều này nghe có vẻ tuyệt vời, nhưng bây giờ nhà cung cấp dịch vụ lại phải lo lắng việc việc lưu trữ key mã hóa ở một nơi an toàn! Nếu key và mã hoá của secret chung được lưu trữ trong cùng một cơ sở dữ liệu mà tin tặc đã hack được, thì ầu nâuuuu!

Có nhiều giải pháp cho bài toán quản lý key, chẳng hạn như sử dụng hardware security module (HSM). Điểm mấu chốt quan trọng là service provider có trách nhiệm triển khai TOTP theo đúng cách và một sai sót có thể gây nguy hiểm cho bảo mật của 2FA của người dùng nếu cơ sở dữ liệu bị xâm phạm.

Sẽ là lý tưởng nếu service provider không lưu bất kỳ thông tin nào trong cơ sở dữ liệu có thể làm ảnh hưởng đến phương pháp 2FA khi mà database bị rò rỉ thông tin. Phần sau của loạt bài này, chúng ta sẽ nói về Push 2FA và U2F 2FA, chúng đều tiếp cận bài toán theo hướng đó. Cùng đón đọc nhé!

Đánh cắp secret chung từ trusted device của Alice!

Vì secret được chia sẻ giữa service provider và trusted device của Alice nên rõ ràng nó cũng có thể bị đánh cắp khỏi thiết bị của Alice! Trên thực tế, khả năng xảy ra điều này là cao hơn.

Hiểu biết về 2FA - xác thực hai yếu tố 07-tru10

Trusted device của Alice có thể bị đánh cắp. Nếu thiết bị không mã hoá ổ cứng, thì hacker có thể lấy secret chung ra một cách dễ dàng. Tình huống tồi tệ hơn là Alice không đặt mật khẩu cho trusted device và hacker có thể dễ dàng sử dụng ứng dụng xác thực để xem dịch vụ nào được đăng ký cùng với username và OTP cho mỗi dịch vụ.

Bên cạnh nguy cơ bị đánh cắp, trusted device cũng có thể bị hack qua phần mềm. TOTP 2FA là một trong những phương pháp có thể bị tấn công bởi malware. Alice có thể vô tình cài malware trên trusted device và phần mềm đó được thiết kế để đánh cắp secret chung.

Bảo vệ trusted device là điều tối quan trọng khi sử dụng TOTP 2FA.

Nếu Alice làm mất trusted device, có cách nào để cô ấy đăng nhập được không?

Nếu Alice làm mất trusted device (hoặc nó bị đánh cắp), thì có thể cô ấy sẽ lo lắng về việc ai đó có ác ý đăng nhập vào tài khoản của mình. Tuy nhiên, ít có khả năng một người qua đường ngẫu nhiên tìm thấy trusted device của cô ấy (ví dụ: điện thoại) lại có cả mật khẩu và có thể nhanh chóng đăng nhập vào tài khoản của cô ấy. Thông thường Alice sẽ có đủ thời gian làm việc cần làm để bảo vệ tài khoản của mình, trừ khi có ai đó cố ý đánh cắp tài khoản của cô ấy.

Hành động cần làm đó là thu hồi những secret chung đã được lưu trữ trên trusted device của cô ấy để chúng trở nên vô dụng. Điều này, tất nhiên, yêu cầu cô ấy đăng nhập vào tài khoản của mình! Tuy nhiên, để đăng nhập vào tài khoản của mình, Alice lại cần cả mật khẩu và trusted device??? May mắn là có một số tùy chọn khôi phục tài khoản có thể áp dụng được trong tình huống này.

Việc triển khai theo tiêu chuẩn thực tế của TOTP 2FA bổ sung thêm một bước vào quy trình đăng ký, đó là cung cấp cho người dùng một bộ mã khôi phục sử dụng một lần.

Hiểu biết về 2FA - xác thực hai yếu tố 08-git10

Các mã này nên được lưu trữ ở một nơi an toàn và độc lập với trusted device của bạn: in chúng trên một mảnh giấy để ở nhà, hoặc lưu trữ chúng một cách an toàn trên máy tính… Alice có thể sử dụng mã khôi phục thay cho OTP được tạo bởi ứng dụng xác thực của cô ấy nếu cô ấy bị mất trusted device, hoặc lỡ tay xoá mất ứng dụng xác thực, .v.v...

Tùy chọn khôi phục thứ hai cho TOTP 2FA là sử dụng nhiều trusted device. Trong quá trình đăng ký, Alice có thể cài đặt ứng dụng xác thực trên cả điện thoại và máy tính bảng của mình và sử dụng ứng dụng này để quét mã QR được hiển thị trong trình duyệt của cô ấy. Bằng cách này, cả điện thoại và máy tính bảng của cô ấy sẽ có một bản sao của secret chung và có thể tạo các mã OTP hợp lệ giống nhau. Nếu Alice bị mất điện thoại, thì cô ấy có thể sử dụng máy tính bảng mà cô ấy để ở nhà để đăng nhập thành công vào tài khoản của mình. Chiến lược này có thể hoạt động rất hiệu quả đối với bất kỳ ai có thiết bị cũ ở nhà và không muốn in ra hoặc nghĩ cách lưu trữ mã khôi phục một cách an toàn. Tuy nhiên, việc theo dõi nhiều thiết bị đáng tin cậy là cực kỳ quan trọng! Tất cả các thiết bị đáng tin cậy đều có thể được sử dụng để tạo OTP hợp lệ, vì vậy hãy bật mã hóa trên tất cả các thiết bị đó và đừng bỏ quên chúng ở đâu đó nha!

Nếu Alice không nhận thức đc việc cần lưu mã khôi phục và / hoặc quét mã QR bằng nhiều trusted device, thì cô ấy đang ở trong tình thế khó khăn. Lựa chọn cuối cùng của cô là liên hệ với bộ phận hỗ trợ của service provider và hỏi xem họ có support việc khôi phục tài khoản hay không. Việc này mỗi công ty lại mỗi khác. Ví dụ, một số công ty có các tiêu chí cụ thể và chặt chẽ để bạn có thể chứng minh rằng mình là chủ tài khoản, trong khi một số lại chẳng quy trình khôi phục nào cả và tài khoản của Alice sẽ bị khoá vĩnh viễn.

Sau khi đăng nhập được vào tài khoản bằng phương pháp khôi phục, Alice nên thu hồi secret chung trên trusted device của cô ấy để nếu nhỡ may có ai đó có thể truy cập vào thiết bị thì secret đã vô dụng rồi. Sau đó, Alice có thể kích hoạt lại TOTP 2FA cho cùng tài khoản đó với trusted device mới (ví dụ như mua điện thoại mới). Và Alice cần phải làm vậy với tất cả tài khoản riêng lẻ mà Alice đã bật TOTP 2FA.

Nguy cơ trước phishing và MITM attacks

Sơ đồ dưới đây cho thấy TOTP 2FA là một trong các phương thức 2FA dễ bị phishing attack.

Hiểu biết về 2FA - xác thực hai yếu tố 09-phi10

Trong kịch bản quen thuộc này, Alice nghĩ rằng cô ấy đang ở trên một trang web thật, vì vậy cô ấy đăng nhập bình thường với username và password. Và các hacker điều hành trang web lừa đảo sử dụng username và password Alice vừa nhập để đăng nhập vào trang web thật. Sau đó, trang web lừa đảo sẽ nhắc Alice nhập OTP được tạo bởi ứng dụng xác thực trên thiết bị đáng tin cậy của cô ấy. Một lần nữa, Alice nghĩ rằng cô ấy đang ở trên trang web thật và biết rằng cô ấy đã bật TOTP 2FA trên tài khoản của mình, vì vậy cô ấy vui vẻ nhập OTP vào trang web lừa đảo. Ngay sau khi cô ấy làm vậy, hacker có thể sử dụng OTP hợp lệ đó để đăng nhập thành công vào tài khoản của Alice trên trang web thực. GAME OVER!

TOTP 2FA cũng dễ bị tấn công bởi Man in the Middle (MITM) attack. Alice sử dụng kết nối HTTP không an toàn để đăng nhập vào trang web thật. Điều này cho phép hacker đọc tất cả lưu lượng truy cập web, bao gồm cả OTP mà Alice đã nhập thủ công vào trình duyệt của mình.

Hãy nhớ rằng, HTTPS giúp ngăn chặn các cuộc tấn công MITM; và hãy cài HTTPS Everywhere nhé!

Wrap up

TOTP 2FA thực hiện tốt hơn nhiều việc chứng minh “something you have” so với SMS 2FA.

Với SMS 2FA, OTP được tạo bởi service provider và được gửi đến thiết bị liên kết với số điện thoại của bạn. Tôi đã nói về các vấn đề với kiến trúc đó và cách OTP có thể bị đánh cắp theo nhiều cách khác nhau trong quá trình truyền qua mạng điện thoại. Với TOTP 2FA, ứng dụng xác thực trên trusted device sẽ quét mã QR để lấy secret chung, được sử dụng để tạo OTP cục bộ. Việc không gửi secret chung qua mạng làm giảm đáng kể nguy cơ bị tấn công từ xa. Nó cũng có một sổ điểm ưu việt hơn về tính khả dụng, chẳng hạn như không cần đợi chờ tin nhắn văn bản đến hoặc không cần kết nối mạng.

Tuy nhiên, TOTP 2FA không thể tránh khỏi việc còn tồn đọng những hạn chế về tính khả dụng và bảo mật.

Về tính khả dụng, có một vài điểm khó chịu nho nhỏ có thể khiến người dùng cảm thấy phiền theo thời gian. Ví dụ: nhập OTP theo cách thủ công vào trình duyệt đã khó chịu rồi, nhưng đang nhập mà OTP bị reset thì còn khó chịu hơn. Nếu bạn mà không nhớ kịp cả 6 chữ số thì lại phải xoá hết đi và nhập OTP mới. Ở phần sau của loạt bài này, Push 2FA và U2F 2FA loại bỏ việc phải nhập thủ công bất kỳ thứ gì vào trình duyệt của bạn; một cải tiến lớn về trải nghiệm người dùng.

Một thách thức khác về tính khả dụng là thực tế là trusted device của bạn thường là điện thoại của bạn – một thiết bị được tối ưu hóa để đánh cắp sự chú ý của bạn. Không biết bao nhiều lần tôi đã nhấc điện thoại lên để lấy mã OTP từ ứng dụng xác thực nhưng lại bị phân tâm bởi một tin nhắn văn bản đến từ một người bạn, một email đang chờ hoặc một cái noti hấp dẫn về một bài blog. Năm phút sau, tôi nhớ rằng mình đang làm việc, đặt điện thoại xuống, nhìn lên màn hình máy tính và thấy rằng nó đang đợi tôi nhập OTP. Quay lại điện thoại để lấy OTP và quay lại làm việc. Phải thừa nhận rằng vấn đề mất tập trung này không dành riêng cho TOTP 2FA và áp dụng cho tất cả các phương pháp 2FA coi điện thoại như một trusted device.

Về bảo mật, TOTP 2FA đề cao tầm quan trọng của việc bảo mật secret chung trên cả trusted device và server của service provider. Nếu trusted device bạn là điện thoại, thì bạn có thể sẽ nhận ra việc nó bị mất khá nhanh, điều này có thể cho phép bạn hành động trước khi ai đó tìm thấy nó và cố gắng truy cập vào tài khoản của bạn. Tuy nhiên, bạn sẽ không bao giờ biết liệu secret chung có bị đánh cắp từ service provider hay không trừ khi họ nói với bạn, thậm chí họ có thể còn không biết mình đã bị hack!

Như tôi đã nhấn mạnh trước đây, một kiến ​​trúc an toàn hơn nhiều sẽ là một kiến ​​trúc trong đó service provider không lưu bất kỳ thông tin nào có thể ảnh hưởng đến phương thức 2FA trong trường hợp cơ sở dữ liệu bị rò rỉ. Phần sau của loạt bài này sẽ nói về Push 2FAU2F 2FA, cả hai đều có cách tiếp cận chính xác đó.

Và cuối cùng, đừng quên rằng, giống như hầu hết các phương pháp 2FA, TOTP 2FA dễ bị tấn công bởi malware trên trusted device, phishing và MITM attacks.

_________________

Cám ơn đời mỗi sớm mai thức dậy
Ta có thêm ngày nữa để yêu thương
http://www.cuuhvlq2.tk
      
OLD
OLD Developer

Cấp bậc: Developer

Giới tính : Nam

Bài viết : 666

Danh vọng : 1095

Uy tín : 16

Tìm hiểu kỹ về thông số Mật khẩu một lần (TOTP) dựa trên thời gian

(Được lược dịch từ bài viết A medium dive on the Time-based One-time Passwords (TOTP) spec)

Kỹ thuật hơn so với bài viết tổng quan về All Things Auth và ít kỹ thuật hơn chính thông số kỹ thuật, đây là thông tin chi tiết về cách hoạt động của TOTP!

Chào mừng bạn quay trở lại loạt bài xác thực hai yếu tố (2FA)!

Nếu bạn chưa có, hãy xem bài viết đầu tiên trong loạt bài giải thích 2FA là gì và tại sao bạn thực sự nên bật nó trên tài khoản của mình (có, ngay cả khi bạn có một mật khẩu mạnh, duy nhất).

Trong bài viết trước , tôi đã giới thiệu về mật khẩu một lần dựa trên thời gian (TOTP). Tôi đã đề cập đến quy trình đăng ký và xác thực, đánh dấu sự cân bằng khả năng sử dụng và thảo luận về một số khía cạnh kỹ thuật quan trọng của TOTP. Tuy nhiên, tôi đã tránh đi quá sâu và giải thích chi tiết của chính thuật toán TOTP.

Bài viết này sẽ đóng vai trò như một phương tiện đi sâu vào chính xác chủ đề đó. Nó sẽ kỹ thuật hơn nhiều so với bài viết trước, nhưng không bỏ qua một số chi tiết cấp thấp quan trọng. Dưới đây là danh sách nhanh các tài liệu tham khảo dành cho những người có đầu óc công nghệ trong số chúng ta, những người muốn đi thẳng vào các thông số kỹ thuật:



Đối với những người khác quan tâm đến lời giải thích trung bình đó, hãy đọc tiếp!

Tóm tắt nhanh TOTP

Tôi nghĩ sẽ hữu ích nếu tóm tắt nhanh những điểm chính từ bài viết trước về cách TOTP thực sự hoạt động.

Hiểu biết về 2FA - xác thực hai yếu tố 01--to10

Sau khi Alice bắt đầu quy trình đăng ký TOTP 2FA, nhà cung cấp dịch vụ sẽ hiển thị mã QR và nhắc cô quét mã đó bằng một ứng dụng xác thực trên thiết bị đáng tin cậy của cô. Nếu đây là lần đầu tiên Alice sử dụng TOTP 2FA, cô ấy sẽ cần vào cửa hàng ứng dụng để cài đặt ứng dụng tương thích. Thông thường, nhà cung cấp dịch vụ sẽ đề xuất một hoặc hai ứng dụng cụ thể, nhưng bất kỳ ứng dụng nào triển khai thuật toán TOTP sẽ tạo ra các mã OTP chính xác giống nhau.

Sau khi ứng dụng được cài đặt, Alice sẽ sử dụng nó để quét mã QR được hiển thị trong trình duyệt của cô ấy. Trong bước này, một bí mật được chia sẻ sẽ được lưu vào thiết bị đáng tin cậy của cô ấy. Bí mật được chia sẻ này là nền tảng về cách TOTP hoạt động và chúng ta sẽ tìm hiểu sâu hơn về vấn đề đó trong bài viết này. Sử dụng bí mật được chia sẻ, ứng dụng xác thực trên thiết bị đáng tin cậy của Alice tạo mã gồm 6 chữ số mà Alice nhập thủ công vào trình duyệt của mình để hoàn tất quá trình đăng ký.

Như bạn có thể thấy trong sơ đồ, có hai lĩnh vực mà tôi muốn trình bày chi tiết hơn. Đầu tiên, hãy xem xét chính xác những gì được mã hóa trong mã QR. Thứ hai, là cách OTP thực sự được tạo trên thiết bị đáng tin cậy và được xác minh bởi nhà cung cấp dịch vụ.

Mã QR và bí mật được chia sẻ

Trong bài viết trước , tôi đã giải thích cách mã QR chỉ đơn giản là một cách mã hóa một số dữ liệu, chẳng hạn như các ký tự văn bản thuần túy. Hãy nhớ những ví dụ thú vị này?

Hiểu biết về 2FA - xác thực hai yếu tố 02--qr10

Trong TOTP 2FA, mọi thứ nghiêm trọng hơn một chút. Mã QR mã hóa một URI được định dạng cụ thể bao gồm thông tin quan trọng cần thiết để tạo mã OTP hợp lệ cục bộ trên thiết bị đáng tin cậy.

Trang wiki Định dạng URI Chính trong repo Google Authenticator GitHub có đầy đủ chi tiết về định dạng, nhưng đây là tổng quan.

Hiểu biết về 2FA - xác thực hai yếu tố 03--ke10

URI bắt đầu bằng một lược đồ cụ thể otpauth: // và xác định thuật toán nào (HOTP hoặc TOTP) nên được sử dụng. Đừng lo lắng nếu bạn không quen thuộc, tôi sẽ giải thích từng điều dưới đây. Nó cũng bao gồm địa chỉ email / tên người dùng của Alice và tên của nhà cung cấp dịch vụ để ứng dụng có thể liên kết trực quan tài khoản với OTP. URI cũng xác định các thông số cụ thể cần thiết để tạo OTP, chẳng hạn như thuật toán băm để sử dụng và tần suất ứng dụng sẽ tạo OTP mới. Quan trọng nhất, nó bao gồm bí mật được chia sẻ được lưu vào thiết bị đáng tin cậy.

Bạn có thể nhớ rằng một trong những nguồn lỗ hổng chính của SMS 2FA là OTP do nhà cung cấp dịch vụ tạo ra có thể bị tấn công / xâm nhập / chiếm quyền điều khiển theo nhiều cách khi nó được gửi qua mạng điện thoại.

TOTP 2FA là một bước tiến vượt bậc về mặt bảo mật vì nó loại bỏ hoàn toàn công ty điện thoại (và các lỗ hổng liên quan) khỏi quy trình đăng ký và xác thực. Thay vì gửi bí mật qua mạng, bí mật được truyền trực quan qua mã QR. Mặc dù TOTP 2FA có các lỗ hổng bảo mật riêng mà tôi đã đề cập trong bài viết trước, nhưng việc sử dụng mã QR sẽ loại bỏ khả năng ai đó sẽ đánh chặn bí mật được chia sẻ trong quá trình đăng ký, điều này cung cấp khả năng tấn công nhỏ hơn nhiều so với tới SMS 2FA.

Vì vậy, sau khi bí mật được chia sẻ và các thông số liên quan được lưu trên thiết bị đáng tin cậy, thông tin đó được sử dụng để thực sự tạo OTP như thế nào?

HOTP: tiền thân của TOTP

Để hiểu thông số kỹ thuật TOTP, trước tiên chúng ta phải hiểu một thông số kỹ thuật khác được gọi là HOTP: Thuật toán mật khẩu dùng một lần dựa trên HMAC đã được hệ thống hóa vào năm 2005.

Từ viết tắt đó là một từ đầy miệng, vì vậy chúng ta hãy chia nhỏ nó. Phần “mật khẩu dùng một lần” rất đơn giản: thuật toán liên quan đến việc tạo mã / mật khẩu hợp lệ cho một lần sử dụng.

Phần “HMAC” là viết tắt của Mã xác thực tin nhắn dựa trên băm, một loại cụ thể của danh mục chung hơn Mã xác thực tin nhắn (MAC). MAC là thứ có thể xác minh tính toàn vẹn và tính xác thực của một tin nhắn. Nói cách khác, nếu bạn gửi tin nhắn cho ai đó và bao gồm MAC, thì người nhận của bạn có thể sử dụng MAC để xác minh rằng tin nhắn không bị giả mạo sau khi bạn viết (tính toàn vẹn) và có thể xác minh rằng bạn đã viết tin nhắn (tính xác thực).

Phần quan trọng nhất của từ viết tắt HMAC cho mục đích của chúng tôi là “Dựa trên băm”. Trở lại bài viết giới thiệu cho loạt bài này trên 2FA, tôi đã thảo luận về hai thuộc tính của các hàm băm mật mã rất quan trọng để hiểu những điều cơ bản về cách mật khẩu được lưu trữ an toàn trong cơ sở dữ liệu. Như từ viết tắt HMAC ngụ ý, các hàm băm mật mã là nền tảng cho thuật toán HOTP, vì vậy chúng ta hãy tóm tắt lại những gì chúng ta đã học trước đây và giới thiệu thuộc tính quan trọng thứ ba:

  1. Thuộc tính # 1 - Bất kỳ đầu vào nào cho hàm băm sẽ luôn cung cấp cho bạn cùng một giá trị băm đầu ra; nó là một hàm xác định.
  2. Thuộc tính # 2 - Với giá trị băm đầu ra, việc tính toán đầu vào ban đầu là không khả thi về mặt tính toán; nó là một chức năng một chiều.
  3. Thuộc tính # 3 - Một thay đổi nhỏ đối với đầu vào của hàm băm sẽ dẫn đến sự thay đổi mạnh mẽ đối với giá trị băm đầu ra, do đó đầu ra mới không thể tương quan với đầu ra cũ ( không tương quan).


Hãy nhớ rằng, mục tiêu tổng thể là cho phép thiết bị đáng tin cậy của Alice và máy chủ của nhà cung cấp dịch vụ tạo ra cùng một giá trị (phần mật khẩu của OTP) và giá trị này chỉ nên có giá trị một lần duy nhất (tính một lần của OTP) .

Điều gì sẽ xảy ra nếu chúng ta chỉ băm bí mật được chia sẻ?

băm ( bí mật được chia sẻ ) = X

Thuộc tính # 2 (hàm một chiều) đảm bảo với chúng ta rằng nếu kẻ tấn công nắm giữ giá trị đầu ra X, thì chúng không thể tính toán đầu vào cho hàm băm; trong trường hợp này, bí mật được chia sẻ. Chúng tôi muốn bí mật được chia sẻ vẫn là bí mật, vì vậy điều này là tốt. Tuy nhiên, Thuộc tính số 1 (hàm xác định)đảm bảo với chúng ta rằng bất cứ lúc nào chúng ta băm bí mật được chia sẻ, chúng ta sẽ luôn nhận được cùng một giá trị đầu ra X. Nếu chúng ta luôn gửi cùng một giá trị X qua mạng, thì ai đó có thể chặn X trên mạng và phá hỏng ngày của chúng ta. Hàm băm không cung cấp bất kỳ biện pháp bảo vệ bổ sung nào trong trường hợp này và về cơ bản nó giống như thể chúng ta chỉ gửi chính bí mật được chia sẻ qua mạng. Ngoài ra, vì giá trị không bao giờ thay đổi, kẻ tấn công nắm giữ giá trị đầu ra X có thể đăng nhập vào tài khoản của Alice bao nhiêu lần tùy thích vì giá trị “OTP” không bao giờ thay đổi; nó chỉ là một “mật khẩu” tĩnh thứ hai.

Thuật toán HOTP giới thiệu một bộ đếm được chia sẻ để cung cấp thuộc tính một thời gian mong muốn:

băm ( bí mật được chia sẻ + bộ đếm được chia sẻ ) = OTP

HOTP yêu cầu mỗi thiết bị đáng tin cậy của Alice và nhà cung cấp dịch vụ phải theo dõi bộ đếm cục bộ bắt đầu bằng giá trị không (0). Mỗi lần Alice đăng nhập vào dịch vụ và yêu cầu ứng dụng xác thực của cô ấy tạo OTP mới, ứng dụng xác thực sẽ sử dụng giá trị hiện tại của bộ đếm để tạo OTP.

Thiết bị đáng tin cậy của Alice: băm ( bí mật được chia sẻ + 0) = OTP

Sau khi tạo OTP này, ứng dụng xác thực tăng bộ đếm cục bộ của nó lên 1.

Bởi vì bộ đếm của nhà cung cấp dịch vụ cũng bắt đầu từ 0, nó có thể chạy cùng một phép tính chính xác đã được chạy trên thiết bị đáng tin cậy của Alice và xác minh rằng cô ấy đã nhập đúng mã OTP.

Máy chủ của nhà cung cấp dịch vụ: băm ( bí mật được chia sẻ + 0) = OTP

Lần tiếp theo khi Alice đăng nhập vào dịch vụ, quá trình tương tự sẽ lặp lại, nhưng bây giờ bộ đếm sẽ có giá trị là 1. Lần đăng nhập sau đó giá trị là 2, rồi 3, v.v.

Thuộc tính # 1 (hàm xác định) đảm bảo với chúng tôi rằng giá trị được tính toán trên thiết bị tin cậy của Alice sẽ khớp chính xác với giá trị được tính trên máy chủ của nhà cung cấp dịch vụ vì cả hai đều sử dụng các giá trị đầu vào giống nhau.

Thuộc tính # 2 (hàm một chiều) đảm bảo với chúng ta rằng kẻ tấn công quan sát OTP (giá trị đầu ra) không thể sử dụng nó để tính toán bí mật được chia sẻ (giá trị đầu vào).

Thuộc tính số 3 (không tương quan) đảm bảo với chúng tôi rằng mỗi giá trị của bộ đếm được chia sẻ sẽ tạo ra một OTP khác nhau đáng kể và không thể tương quan với các OTP được tạo trong quá khứ hoặc tương lai. Nếu kẻ tấn công quan sát nhiều OTP liên tiếp, thì chúng vẫn không thể tính toán bí mật được chia sẻ cũng như không thể tính giá trị của OTP hợp lệ tiếp theo.

Tất cả đều trông tuyệt vời! Tất nhiên, có một "nhưng."

Bộ đếm chia sẻ chỉ tăng lên khi Alice thực sự đăng nhập vào dịch vụ, điều này làm cho giá trị OTP hợp lệ tiếp theo “tồn tại lâu dài”. Nói cách khác, nếu không biết bí mật được chia sẻ hoặc giá trị bộ đếm, kẻ tấn công có thể bắt đầu đoán giá trị của OTP tiếp theo. Ví dụ: “000-000”, “000-001”, “000-002”, v.v. Cuối cùng, kẻ tấn công sẽ đoán đúng giá trị của OTP bằng bạo lực hoặc may mắn.

HOTP yêu cầu các nhà cung cấp dịch vụ thực hiện cơ chế giới hạn tốc độ để ngăn những kẻ tấn công tàn nhẫn đoán OTP tiếp theo, nhưng có một OTP tồn tại lâu vẫn không phải là một tài sản bảo mật tuyệt vời.

TOTP: mật khẩu một lần tồn tại trong thời gian ngắn

TOTP: Thuật toán mật khẩu dùng một lần dựa trên thời gian được đề xuất vào năm 2011 như một phần mở rộng cho HOTP để tạo ra các OTP tồn tại trong thời gian ngắn. TOTP hoạt động theo cùng một cách giống như HOTP, nhưng có một thay đổi quan trọng: nó thay thế bộ đếm được chia sẻ bằng thời gian hiện tại.

băm ( bí mật được chia sẻ + thời gian ) = OTP

Thuộc tính # 1 (hàm xác định) đảm bảo với chúng tôi rằng cả hai bên vẫn có thể tính toán OTP giống nhau vì cả hai sẽ vẫn sử dụng cùng một bí mật được chia sẻ và đầu vào cùng thời gian nhờ NTP . Nếu bạn đang nghĩ "NTP không đảm bảo thời gian chính xác trên mỗi thiết bị", thì bạn đã nắm bắt được sự lo lắng của tôi. Kiểm tra thông số kỹ thuật để biết thêm chi tiết về cách TOTP sử dụng cửa sổ thời gian để giải quyết vấn đề này.

Thuộc tính # 2 (hàm một chiều) đảm bảo với chúng ta rằng kẻ tấn công quan sát OTP vẫn không thể sử dụng nó để tính toán bí mật được chia sẻ.

Thuộc tính # 3 (không tương quan) đảm bảo với chúng ta rằng, cũng giống như giá trị bộ đếm đã sử dụng trước đó, mỗi lần nhập thời gian mới sẽ tạo ra một OTP khác biệt đáng kể và không thể tương quan với các OTP được tạo trong quá khứ hoặc tương lai.

Bao gồm thời gian hiện tại làm đầu vào cho hàm băm có nghĩa là OTP hợp lệ sẽ thay đổi ở một khoảng thời gian tĩnh (ví dụ: 30 giây một lần) ngay cả khi Alice không đăng nhập vào dịch vụ. Điều này tạo ra một cơ hội nhỏ hơn đáng kể cho kẻ tấn công để cưỡng bức OTP tiếp theo. Kết hợp với một sơ đồ giới hạn tỷ lệ hợp lý, rất khó xảy ra (vâng, đó là một thuật ngữ kỹ thuật) mà kẻ tấn công có thể tấn công một cách đáng tin cậy OTP tiếp theo trong vòng 30 giây.

Tuy nhiên, điều quan trọng là phải nhận ra rằng kẻ tấn công vẫn có thể gặp may! Nếu họ khởi động một cuộc tấn công bạo lực và tình cờ đoán đúng 6 chữ số OTP trong vài lần thử đầu tiên được phép bởi sơ đồ giới hạn tỷ lệ, thì họ sẽ có thể xác thực thành công vào tài khoản của Alice. Rõ ràng, đây không phải là một tài sản bảo đảm mong muốn. Phương pháp Push và U2F của 2FA đều có một cách tiếp cận khác nhau mà không gặp phải vấn đề này. Hãy theo dõi các bài viết sau trong loạt bài này giải thích cách hoạt động của chúng!

Mang mọi thứ trở thành vòng tròn đầy đủ, chúng ta hãy xem xét URI được mã hóa bằng mã QR. Hy vọng rằng, các thông số có ý nghĩa hơn bây giờ.

Hiểu biết về 2FA - xác thực hai yếu tố 04--ke10

Thông qua mã QR, nhà cung cấp dịch vụ sẽ cho ứng dụng xác thực biết thuật toán băm nào mà nó sẽ sử dụng để tạo OTP cục bộ trên máy chủ của mình. URI cũng chỉ định tần suất sẽ thay đổi đầu vào thời gian và bao nhiêu chữ số nên được đưa vào OTP được tạo. Điều này cho phép ứng dụng xác thực chạy cùng một phép tính cục bộ trên thiết bị đáng tin cậy của Alice và tạo ra cùng một OTP.

Tạm kết

Tôi hy vọng bạn thích phương tiện này khi đi sâu vào thông số kỹ thuật TOTP và thông tin cơ bản liên quan. Nếu bạn quan tâm đến việc tìm hiểu sâu đầy đủ, hãy xem các liên kết ở đầu bài đăng này để biết các thông số kỹ thuật.

Nếu bạn đã cố gắng cho đến cuối, thì bạn chắc chắn nên tham gia vào danh sách email dưới đây để đảm bảo rằng bạn không bỏ lỡ bài viết tiếp theo trong loạt bài 2FA này! Tôi đã nêu bật một số nhược điểm bảo mật của TOTP trong bài viết này, chẳng hạn như khả năng ai đó đoán ngẫu nhiên một OTP. Tôi sẽ giải thích cách Push và U2F tránh được vấn đề đó và cả hai đều được cho là dễ sử dụng hơn!

_________________

Cám ơn đời mỗi sớm mai thức dậy
Ta có thêm ngày nữa để yêu thương
http://www.cuuhvlq2.tk
      
OLD
OLD Developer

Cấp bậc: Developer

Giới tính : Nam

Bài viết : 666

Danh vọng : 1095

Uy tín : 16

Giới thiệu trình thông báo 2FA - Cách thu hút nhiều người dùng Internet hơn kích hoạt 2FA trên tài khoản của họ

(Được lược dịch từ bài viết Introducing 2FA Notifier - How to Get More Internet Users to Enable 2FA on Their Accounts)

Ray và tôi đã xây dựng một tiện ích mở rộng trình duyệt mã nguồn mở có tên là 2FA Notifier giúp mọi người kích hoạt 2FA trên tài khoản của họ. Đọc về tiện ích mở rộng và vấn đề nó giải quyết trong bài viết của tôi được xuất bản lần đầu trên Blog nhà phát triển Okta.

Hiểu biết về 2FA - xác thực hai yếu tố Large-10

Vài tháng trước, Ray và tôi đã bắt đầu làm việc cùng nhau trên một tiện ích mở rộng trình duyệt mã nguồn mở có tên là 2FA Notifier để thông báo cho bạn biết bất cứ lúc nào bạn truy cập trang web hỗ trợ 2FA cung cấp thông tin để giúp bạn kích hoạt 2FA trên tài khoản của mình.

Gần đây, tôi đã viết về tiện ích này và vấn đề nó giải quyết trong một bài báo được xuất bản trên Blog nhà phát triển Okta có tiêu đề Cách thu hút nhiều người dùng Internet hơn để kích hoạt 2FA trên tài khoản của họ .

Tôi đang sao chép lại bài viết của mình ở đây để có thể giới thiệu với độc giả All Things Auth về tiện ích mở rộng 2FA Notifier mà tôi sẽ tiếp tục viết trong các bài viết sau.

Hãy xem bài viết và chia sẻ 2FA Notifier với bạn bè và gia đình của bạn, đặc biệt là những người ít kỹ thuật. Nó được xây dựng đặc biệt để giúp họ giữ tài khoản trực tuyến của mình an toàn hơn! Bất kỳ và tất cả các phản hồi về 2FA Notifier đều được đánh giá cao.




Cách thu hút nhiều người dùng Internet hơn để kích hoạt 2FA trên tài khoản của họ

Nếu bạn đang đọc bài viết này trên blog Nhà phát triển Okta, rất có thể bạn đã khá quen thuộc với xác thực hai yếu tố (2FA) và cách nó giúp ngăn chặn tin tặc xâm nhập tài khoản người dùng ngay cả khi họ đang sử dụng mật khẩu bị xâm phạm.

Có thể bạn đã bật 2FA trên tất cả các tài khoản trực tuyến của mình.

Đáng buồn thay, bạn lại nằm trong một nhóm thiểu số đáng kể.

Hầu hết mọi người không sử dụng 2FA


Duo Security đã thực hiện một cuộc khảo sát để nghiên cứu nhận thức và tỷ lệ chấp nhận 2FA ở những người dùng internet trung bình. Các kết quả, được công bố trên State of the Auth , rất nghiêm túc.

Họ phát hiện ra rằng chỉ có ~ 28% người dân ở Mỹ hiện đang sử dụng 2FA. Điều đó có nghĩa là ~ 72% người dùng Internet trung bình khác chỉ bảo mật tài khoản của họ bằng mật khẩu. Điều đó thật đáng sợ, đặc biệt khi xem xét rằng phần lớn mật khẩu hoàn toàn là rác bởi vì mọi người rất tệ trong việc tạo ra những mật khẩu tốt .

Con số 28% đó nhìn chung cũng phù hợp với tỷ lệ chấp nhận 2FA thấp được một số nhà cung cấp dịch vụ lớn báo cáo. Vào tháng 1 năm 2018, Google tuyên bố rằng chưa đến 10% tài khoản Google đang hoạt động đã bật 2FA. Mặc dù có một chút lỗi thời và hy vọng sẽ được cải thiện trong những năm gần đây, nhưng Dropbox cho biết tỷ lệ chấp nhận 2FA của họ chưa đến 1% tính đến tháng 6 năm 2016.

Đáng quan tâm hơn nữa, báo cáo tương tự cho thấy chỉ có ~ 56% người thậm chí biết 2FA là gì trước khi họ tham gia cuộc khảo sát. Hãy để điều đó chìm trong giây lát. Mặc dù bạn và tôi có thể đã bật 2FA trên tất cả các tài khoản của chúng tôi ngay bây giờ, nhưng phần lớn người dùng internet trung bình thậm chí còn không biết 2FA thậm chí là gì! Chắc chắn, họ sẽ không kích hoạt nó trên tài khoản của mình nếu họ không biết rằng nó tồn tại.

Đối với những người biết rằng 2FA tồn tại, nhiều người vẫn không thể xác định được nó khi họ nhìn thấy nó. Trung tâm nghiên cứu Pew đã thực hiện một bài kiểm tra an ninh mạng , trong đó chỉ 10% người dùng có thể xác định chính xác xác thực hai bước khi được cung cấp một bộ tùy chọn bao gồm mã được gửi đến tài khoản email, reCaptcha, một số câu hỏi bảo mật dựa trên kiến thức và một trong số những lời nhắc "hình ảnh an ninh" vô lý.

Có một khoảng cách giáo dục cơ bản giữa đa số người dùng internet và những người hiểu biết về công nghệ khi nói đến 2FA.

Thu hẹp khoảng cách giáo dục 2FA


Tôi thấy có hai cách tiếp cận song song để giải quyết khoảng cách về giáo dục.

Đầu tiên, chúng ta cần xây dựng các giải pháp xác thực tốt hơn. Người dùng nên tận dụng xác thực mạnh mẽ trên tất cả các tài khoản của họ mà không hề nhận ra. Các mốc quan trọng như các trình duyệt chính thông báo hỗ trợ API WebAuthN là một bước đi thú vị theo hướng đó. Tuy nhiên, vẫn còn là những ngày đầu và WebAuthN có thể sẽ không sớm trở nên phổ biến đối với người dùng internet bình thường.

Trong thời gian chờ đợi, cách tiếp cận thứ hai là tiếp tục hướng dẫn người dùng về các giải pháp 2FA hiện có mà họ có thể sử dụng để bảo vệ tài khoản của mình ngay hôm nay . Có một số tài nguyên tuyệt vời nhằm giúp người dùng làm điều đó.

Trang web twofactorauth.org duy trì một danh sách các trang web có thể tìm kiếm được và chúng có hỗ trợ 2FA hay không. Các trang web hỗ trợ 2FA cũng có liên kết đến tài liệu hỗ trợ của họ giải thích cách bật 2FA trên tài khoản của bạn.

Một tài nguyên hữu ích khác là turnon2FA.com , cung cấp các hướng dẫn từng bước để kích hoạt 2FA trên hàng trăm trang web khác nhau.

Tuy hữu ích như những tài nguyên này, nhưng nhược điểm chính của cả hai là người dùng cần phải chủ động sử dụng chúng. Câu nói cổ "khuất mắt, mất trí" có vẻ phù hợp ở đây. Tôi tập trung vào 2FA một cách chuyên nghiệp và thậm chí tôi thường quên kiểm tra các tài nguyên đó thường xuyên để xem liệu dịch vụ mới mà tôi đang đăng ký có hỗ trợ 2FA hay không. Tôi nghĩ rằng người dùng Internet bình thường cũng có khả năng quên.

2FA Notifier khuyến khích một cách thụ động việc áp dụng 2FA


Sẽ không tuyệt vời nếu chúng ta có thể hướng dẫn người dùng về những trang web họ truy cập hỗ trợ 2FA mà họ không cần phải làm bất cứ điều gì?

Đó là những gì 2FA Notifier có thể làm được.

2FA Notifier là một phần mở rộng web mã nguồn mở cho Chrome và Firefox được xây dựng bởi chính bạn và đối tác tội phạm của tôi, Ray Gonzales , sẽ thông báo cho người dùng bất cứ lúc nào họ truy cập trang web hỗ trợ 2FA.

Hiểu biết về 2FA - xác thực hai yếu tố 01--br10

Tiện ích mở rộng sử dụng dữ liệu từ haifactorauth.org và các nguồn khác để xác định xem trang web trong tab trình duyệt hiện tại có hỗ trợ 2FA hay không. Nếu có, thì người dùng sẽ nhận được thông báo trực tiếp trong cửa sổ trình duyệt của họ cho họ biết! Tốt hơn, người dùng có thể nhấp vào thông báo để truy cập trực tiếp vào tài liệu hỗ trợ của trang web cho họ biết cách thực sự bật 2FA trên tài khoản của họ.

Ngay cả khi người dùng bỏ lỡ thông báo, biểu tượng tiện ích mở rộng cũng cập nhật để cho biết liệu trang web hiện tại có hỗ trợ 2FA hay không. Nhấp vào biểu tượng sẽ mở ra menu giải thích rõ ràng liệu 2FA có được hỗ trợ hay không và cũng cung cấp liên kết đến tài liệu thiết lập.

Hiểu biết về 2FA - xác thực hai yếu tố 02--ex10

Người dùng cũng có thể dễ dàng nói với Trình thông báo 2FA rằng họ đã bật 2FA cho trang web hiện tại, điều này ngăn nó ném thông báo vào mặt họ mỗi khi họ truy cập trang web đó. Mục đích là cung cấp cho người dùng thông tin họ cần để thực hiện hành động và sau đó thoát ra khỏi con đường.

Cài đặt Trình thông báo 2FA và sử dụng nó. Xem các trang web bạn truy cập hỗ trợ 2FA và đảm bảo bật nó nếu bạn chưa bật. Quan trọng nhất, hãy chia sẻ Trình thông báo 2FA với bạn bè, gia đình và đồng nghiệp của bạn, những người sẽ được hưởng lợi nhiều nhất từ lời nhắc thân thiện để bật 2FA trên tất cả các tài khoản của họ!

Tái bút: Bạn có thể theo dõi tôi trên Twitter ( @conorgil ) để nghe về những cải tiến của tính năng Trình thông báo 2FA và đọc các bài viết của tôi về 2FA và các chủ đề liên quan tại AllThingsAuth.com .

_________________

Cám ơn đời mỗi sớm mai thức dậy
Ta có thêm ngày nữa để yêu thương
http://www.cuuhvlq2.tk
      
      

Xem chủ đề cũ hơn Xem chủ đề mới hơn Về Đầu Trang  Thông điệp [Trang 1 trong tổng số 1 trang]

Quyền hạn của bạn

Bạn không có quyền trả lời bài viết
free counters



  • Đoàn Ngọc Khánh

    mobile phone 098 376 5575


    Đỗ Quang Thảo

    mobile phone 090 301 9666


    Nguyễn Văn Của

    mobile phone 090 372 1401


    IP address signature
    Free forum | © PunBB | Free forum support | Liên hệ | Báo cáo lạm dụng | Thảo luận mới nhất