25 điểm bởi GN⁺ 2025-06-13 | 4 bình luận | Chia sẻ qua WhatsApp
  • Chính sách yêu cầu xác thực thường xuyên chỉ gây bất tiện cho người dùng mà không mang lại hiệu quả tăng cường bảo mật thực chất
  • Sự gia tăng của các mối đe dọa bảo mật hiện đại như MFA fatigue attacks có thể khiến việc xác thực lặp đi lặp lại trở thành một điểm yếu
  • Tính năng khóa màn hình của hệ điều hành và cập nhật chính sách truy cập theo thời gian thực là các biện pháp bảo vệ hiệu quả hơn
  • Chỉ cần xác thực bổ sung ngay trước các tác vụ nhạy cảm, còn chu kỳ đăng nhập ngắn một cách tùy tiện là không cần thiết
  • Các phương thức kiểm soát truy cập hiện đại áp dụng chính sách tự động và nhanh chóng mà không làm gián đoạn người dùng

Vì sao xác thực thường xuyên không tăng cường bảo mật

Những vấn đề do xác thực lặp lại gây ra

  • Việc phiên làm việc hết hạn giữa luồng công việc khiến người dùng phải liên tục nhập lại mật khẩu và MFA (xác thực đa yếu tố), làm suy giảm năng suất
  • Ban đầu chỉ cần nhập lại mật khẩu, nhưng khi thêm bước MFA, thời gian tiêu tốn tăng lên và sự khó chịu của người dùng cũng nghiêm trọng hơn
  • Tần suất yêu cầu MFA càng cao thì khả năng thành công của MFA fatigue attacks cũng càng lớn
  • Trước đây, việc đổi mật khẩu thường xuyên hay đặt thời gian hết hạn phiên ngắn được xem là biện pháp bảo mật hiệu quả, nhưng các hướng dẫn hiện đại lại đánh giá chúng là phản tác dụng
  • Bảo mật không phụ thuộc vào chu kỳ đăng nhập, mà phụ thuộc vào việc quản lý quyền truy cập và thay đổi chính sách được phản ánh nhanh đến mức nào

Bản chất của các phương thức xác thực

  • Xác thực chủ yếu là cách chứng minh một trong hai điều sau
    • Chứng minh quyền sở hữu thiết bị: xác nhận người dùng có đang nắm giữ thiết bị vật lý hay không, như Windows Hello PIN, YubiKey, thẻ thông minh
    • Chứng minh đúng là người đó: nhận diện đúng người dùng thông qua mật khẩu, Face ID, Touch ID
  • Vai trò chính của Identity Provider (IdP) là tập trung vào xác minh danh tính
  • Face ID, Touch ID, Windows Hello là các hệ thống tích hợp có độ an toàn cao vì đồng thời xử lý chứng minh quyền sở hữu thiết bị và chứng minh danh tính
  • Nhiều quản trị viên đặt thời gian hết hạn phiên ngắn vì cảm giác bất an rằng thay đổi chính sách sẽ không được áp dụng ngay lập tức

Các mối đe dọa bảo mật thực tế và vai trò của xác thực

  • Phần lớn kẻ tấn công tiến hành tấn công qua phishing từ xa, và việc đánh cắp mật khẩu là rất dễ
  • Để đối phó với tấn công từ xa, sử dụng xác thực lớp thứ hai (ví dụ: YubiKey) là một biện pháp phòng thủ quan trọng
  • Khi xảy ra tấn công vật lý như mất hoặc bị đánh cắp thiết bị, trong đa số trường hợp màn hình đã ở trạng thái khóa
  • Ngược lại, càng đăng nhập thường xuyên thì kẻ tấn công càng có nhiều cơ hội đánh cắp thông tin xác thực, từ đó làm suy giảm bảo mật

Vai trò của hệ điều hành và dịch vụ web

  • Các hệ điều hành hiện đại bảo vệ hệ thống tự động bằng tính năng khóa màn hình khi người dùng rời chỗ
  • Thay vì gây bất tiện cho người dùng bằng cách tăng tần suất xác thực bổ sung, nên áp dụng chính sách khóa tự động
  • Trừ khi là máy tính dùng chung, thời gian hết hạn phiên web ngắn chỉ là di sản của thời đại quán net trước đây
  • Ngoài các dịch vụ nhạy cảm (ví dụ: internet banking), chính sách thời gian hết hạn phiên không phù hợp sẽ làm giảm cả bảo mật lẫn tính tiện dụng

Mô hình bảo mật hiệu quả và thân thiện với người dùng

  • Xác thực tức thời (on-demand authentication) ngay trước tác vụ nhạy cảm là phương án lý tưởng
  • Chế độ check của Tailscale SSH, Slack Accessbot và các công cụ tương tự cung cấp khả năng xác minh người dùng ngay khi cần
  • Kết hợp với cưỡng chế khóa màn hình của hệ điều hành có thể giữ được cân bằng giữa bảo mật và tiện lợi
  • Kiểm tra trạng thái bảo mật liên tục (device posture check) và kiểm soát truy cập theo thời gian thực được thực hiện tự động, bất kể hành vi của người dùng
  • Ví dụ:
    • Khi thiết bị ngoại tuyến, bị thất lạc hoặc không vượt qua kiểm tra bảo mật, quyền truy cập sẽ bị thu hồi ngay lập tức
    • Khi có thay đổi về vai trò hoặc thân phận, chính sách truy cập sẽ tự động được cập nhật
  • So với cách buộc người dùng phải xác thực lặp đi lặp lại, phương thức tự động hóa theo thời gian thực thông minh và an toàn hơn nhiều

Kết luận

  • Đăng nhập thường xuyên không giúp tăng bảo mật một cách hiệu quả, mà ngược lại còn có thể dẫn đến tái sử dụng mật khẩu, phishing, MFA fatigue
  • Hệ thống bảo mật âm thầm và tự động hóa mới là biện pháp bảo vệ tốt nhất
  • Tailscale theo đuổi bảo mật thích ứng, thông minh và thực sự hữu ích
  • Hệ thống được thiết kế để ngay cả khi người dùng không tự điều chỉnh chu kỳ đăng nhập, cũng chỉ phát sinh mức ma sát xác thực tối thiểu vào đúng thời điểm cần thiết
  • Tính năng kiểm tra bảo mật theo thời gian thực của Tailscale còn có thể mở rộng sang các ứng dụng khác, giúp bảo vệ an toàn ngay cả các hệ thống legacy

Liên kết tham khảo

4 bình luận

 
rtyu1120 2025-06-13

Điều này cũng đã được nhắc đến trong bình luận trên HN, nhưng so với môi trường IT thay đổi nhanh chóng thì các cuộc kiểm tra/quy định bảo mật dựa trên những tiêu chuẩn cứng nhắc và lỗi thời thường trở thành lực cản rất lớn. Có lẽ đây cũng là câu chuyện mà những người ở tuyến đầu đều đã quá quen thuộc... haha

 
ndrgrd 2025-06-13

Rất nhiều dịch vụ ở Hàn Quốc cứ hiện thông báo phiền phức yêu cầu đặt lại mật khẩu mỗi 30 ngày một lần.

 
devsepnine 2025-06-13

Đây là phần đã bị bắt buộc trong nhiều năm dưới danh nghĩa nghĩa vụ bảo mật thông tin cá nhân nên thực sự rất phiền... hu hu

 
GN⁺ 2025-06-13
Ý kiến Hacker News
  • Tôi nghĩ vấn đề lớn hơn là các chính sách bắt buộc đổi mật khẩu định kỳ hoặc đặt ngày hết hạn; những chính sách này thường khiến mọi người bị khóa tài khoản (ví dụ: mật khẩu hết hạn khi đang đi nghỉ), rồi sau đó lại phát sinh phiền toái như phải trực tiếp tìm đến IT, gọi điện cho IT hàng giờ để yêu cầu đặt lại, hoặc nhờ một đồng nghiệp chưa bị khóa liên hệ hộ.
    Nhiều (đa số?) công ty vẫn đang áp dụng các chính sách như vậy, nhưng NIST hiện không còn khuyến nghị thay đổi mật khẩu tùy tiện nữa.
    Tài liệu chính thức của NIST
    Microsoft cũng không khuyến nghị việc hết hạn mật khẩu vì cho rằng nó có hại nhiều hơn lợi.
    Tài liệu chính thức của Microsoft
    Nhưng có vẻ phía IT hoặc an ninh vẫn chưa coi những khuyến nghị này là đủ “có thẩm quyền”, hơn nữa vẫn còn tồn tại các hướng dẫn tiếp tục khuyến nghị kiểu chính sách đó.

    • Thỉnh thoảng khi đăng nhập vào một trang web ngẫu nhiên mà bị buộc đặt lại mật khẩu, tôi lại nghĩ có lẽ không phải do hết hạn theo thời gian mà là vì tài khoản đã bị rò rỉ hoặc xâm phạm.
      Nếu bên vận hành trang biết rằng một số tài khoản cụ thể nằm trong danh sách dữ liệu bị rò rỉ, thì yêu cầu đổi mật khẩu bắt buộc ở lần đăng nhập tiếp theo là một phản ứng hợp lý.

    • Tôi từng nói chuyện này với người phụ trách an ninh mạng, và được nghe rằng tiêu chuẩn PCI yêu cầu thay đổi mật khẩu định kỳ, nên còn tùy họ xem cuộc kiểm toán nào quan trọng hơn.

    • Hồi trước tôi bực mấy chính sách này đến mức mỗi lần chỉ thêm một chữ cái vào cuối mật khẩu theo thứ tự a~z để đối phó.
      May mà ở công ty hiện tại tôi đã dùng cùng một mật khẩu suốt 3 năm, nên khá hài lòng.

    • Tôi thấy thật vô lý khi các nhà cung cấp bắt tôi đổi mật khẩu định kỳ dù mật khẩu của tôi chưa hề bị lộ.
      Việc chuyện này vẫn còn được áp dụng như một tiêu chuẩn chính thức thật khó tin.

    • Kết quả là mọi tài khoản của tôi đều chỉ dùng mẫu 1234abcd@.

  • Tôi thấy cực kỳ bất tiện với các sản phẩm Apple.
    Tôi xác nhận kiểu này áp dụng trên tất cả sản phẩm Apple.
    Trên Mac, dù đã thiết lập bằng TouchID, khi đăng nhập tài khoản Apple vào App Store rồi cài ứng dụng thì cứ liên tục hiện cửa sổ yêu cầu nhập mật khẩu; lẽ ra có thể xác thực bằng TouchID nhưng lần nào cũng đòi mật khẩu.
    Ngay cả khi cài ứng dụng miễn phí cũng vậy, và tôi thấy đây là thủ tục hoàn toàn không cần thiết.
    Hiện tượng này cũng thỉnh thoảng xảy ra trên iPhone của vợ/chồng tôi.
    Đặc biệt khi reset điện thoại rồi thiết lập lại từ đầu, Apple liên tục yêu cầu nhập lại mật khẩu.
    Dù đã được bảo vệ đầy đủ bằng TouchID mà vẫn cứ như vậy nên rất bực bội.

    • Khi truy cập dịch vụ Apple từ thiết bị không phải của Apple thì còn bất tiện hơn nữa.
      Mỗi lần đăng nhập vào icloud.com, dù có bấm "tin cậy thiết bị này" thì hôm sau lại phải lặp lại quy trình xác thực hai lớp bằng mật khẩu + mã dùng một lần.
      Nếu Face ID thất bại trong lúc thanh toán hoặc cài ứng dụng, hệ thống không cho thay bằng PIN mà bắt buộc phải nhập toàn bộ mật khẩu tài khoản Apple, trong khi lại không thể mở ứng dụng quản lý mật khẩu.
      Gặp tình huống đó ngay tại quầy thanh toán thì thật sự rất khó xử.

    • Cần chắc chắn rằng bạn đã bật cài đặt cho phép dùng TouchID để phê duyệt mua hàng.
      (Vào Settings > Touch ID & Password để cấu hình.)
      Nếu chưa bật thì hệ thống có thể sẽ tiếp tục yêu cầu nhập mật khẩu.
      Theo trải nghiệm của tôi, sau khi khởi động lại chỉ cần xác thực đúng một lần, rồi sau đó hầu hết đều có thể xác thực bằng TouchID.

    • Mỗi lần kết nối iPhone với Mac để đồng bộ, cả Mac lẫn iPhone đều hiện thông báo "Bạn có tin cậy thiết bị này không?", và dù lần nào tôi cũng chọn "Có" thì lần kết nối sau lại hỏi tiếp.

    • Tôi nghĩ việc yêu cầu xác thực lại đối với các tác vụ cần quyền SUDO là điều tự nhiên.
      Trong trường hợp đó, có thể gom các tác vụ liên quan lại để chỉ cần xác thực một lần, nhờ vậy giảm số lần phải xác thực lại.

    • Con tôi đang dùng một chiếc iPad rất cũ, chạy iOS 10.3 nên ứng dụng quản lý mật khẩu không hoạt động, mà trình duyệt cũng là ứng dụng 32-bit nên không thể mở các website hiện đại.
      Vì thế mỗi lần dùng App Store tôi phải tự gõ thủ công mật khẩu dài hơn 50 ký tự, cực kỳ phiền phức.

  • Tôi nghĩ những người cần đọc các bài như thế này là các kiểm toán viên làm kiểm toán an ninh.
    Chừng nào kỳ vọng của họ chưa thay đổi, nhiều công ty vẫn sẽ phải tiếp tục làm theo những chính sách ngớ ngẩn trên thực tế nhưng lại được coi là tiêu chuẩn ngành.
    Đặc biệt là các doanh nghiệp nhỏ trong một số lĩnh vực cũng phải đạt điểm cao trong kiểm toán an ninh nên đang áp dụng hàng loạt thủ tục bảo mật vô dụng.
    Hiện có ít nhất 6 biện pháp bảo mật mà chúng ta biết là không hiệu quả nhưng vẫn bị ép phải áp dụng; các kiểm toán viên đến giờ vẫn rất khó thay đổi.

    • Khi làm kiểm toán SOC2, tôi đã liên tục đưa ra các hướng dẫn của NIST.
      Nếu đưa link cho họ xem thì đa số cuối cùng sẽ chấp nhận tiêu chuẩn của NIST.

    • Cả Apple lẫn Microsoft đều hỗ trợ các thiết lập doanh nghiệp để đội bảo mật công ty tắt các tùy chọn như “ghi nhớ thiết bị của tôi”, “tin cậy thiết bị này”.
      Kiểm toán viên hay CISO (giám đốc an ninh thông tin) thường kiểm toán hoàn toàn theo checklist, nên việc bảo mật thực tế có tăng lên hay không chẳng quan trọng; điều quan trọng hơn là được thông qua kiểm toán.
      Những thiết lập này chỉ làm tăng sự bất tiện cho người dùng, còn trên thực tế lại làm suy giảm mức độ an toàn.

  • Tôi nghĩ Microsoft cũng đã phá hỏng game PC theo cách tương tự.
    Mỗi lần chạy các game như Minecraft hay Master Chief Collection là tôi biết kiểu gì cũng sẽ bật lên cửa sổ yêu cầu xác thực lại, nên cứ trì hoãn.
    Vì sự bất tiện này mà tôi còn tắt cả 2FA trên tài khoản.
    Đây chỉ là game chứ có phải xác minh tài khoản ngân hàng đâu; tôi chỉ mong họ để tôi chơi game cho vui thôi.

    • Ngay cả trên Xbox, việc phải xác thực lại liên tục bằng một mật khẩu được tạo ngẫu nhiên cũng khiến tôi thấy rất bất thường.
      Gần đây nghe nói đã có tính năng quét mã QR để xác thực, nhưng tôi thấy người thiết kế ra hệ thống này quá xa rời trải nghiệm thực tế của người dùng.
  • Có một điểm hầu như không được nhắc đến trong bài.
    Tôi cho rằng UX (trải nghiệm người dùng) tệ bản thân nó cũng có thể trở thành một lỗ hổng bảo mật.
    Nếu hệ thống thường ngày hành xử thiếu hợp lý, thì khi sự cố thật sự xảy ra, người dùng rất dễ không nhận ra sự thay đổi hay hành vi bất thường.
    Ví dụ, nếu yêu cầu nhập mật khẩu xuất hiện quá thường xuyên thì người ta sẽ gõ theo thói quen, và như vậy sẽ khó lọc ra các rủi ro như phishing.
    Ngoài ra, nếu OS không quản lý tốt các chương trình khởi động cùng hệ thống hoặc mã đáng ngờ chạy nền thì việc bị lợi dụng cũng rất dễ xảy ra.
    Một vấn đề nữa là các chuyên gia bảo mật thông thường hầu như không coi “tâm lý con người” là một biến số quan trọng, và mọi thứ có xu hướng được thiết kế theo kiểu checklist hoặc từ góc nhìn của công ty.
    Đây là những sai lầm hoàn toàn có thể ngăn ngừa nếu có thiết kế sản phẩm đúng đắn, nhưng các nhà cung cấp sản phẩm và dịch vụ lại tích cực vận động trước thay đổi quy định hơn nhiều so với người tiêu dùng, nên việc cải thiện không diễn ra tốt.
    Vì vậy trên thực tế tôi nghĩ việc tăng cường quy định có ích cho hiệu quả bảo mật, nhưng từ góc độ công ty lại nảy sinh tình huống kỳ lạ là chẳng ai hoan nghênh quy định đối với chính sản phẩm/dịch vụ của mình.

  • Những hệ thống đòi xác thực lại thường xuyên thực chất không cải thiện bảo mật (trừ trường hợp thời hạn hết hạn rất dài thì có thể là ngoại lệ).
    Với một hệ thống xác thực tử tế, điều cốt lõi là phải có khả năng thu hồi quyền ngay lập tức thông qua hết hạn phiên hoặc quản lý phiên rõ ràng.
    Trên thực tế, “độ trễ” từ lúc thu hồi quyền của một phiên cho đến khi phiên đó thật sự hết hiệu lực hoàn toàn và mất mọi quyền truy cập còn quan trọng hơn nhiều so với chu kỳ xác thực lại.
    Điều này càng phức tạp hơn khi kiến trúc xác thực và số lượng hệ thống cấu thành tăng lên.

    • Vì thế mới cần refresh token.
      Token thực tế sẽ hết hạn định kỳ, nhưng client được cấp riêng cơ hội để làm mới token mới.
      Việc thu hồi token được kiểm soát bằng cách chặn không cho tạo token mới.

    • Tôi cũng nghĩ tương tự.
      Ở công ty tôi dùng mô hình xác thực hai tầng.
      Mỗi ngày một hoặc hai lần, tôi đăng nhập vào keycloak bằng ADFS + MFA, và đa số hệ thống dùng keycloak làm OIDC provider, với token được làm mới mỗi 10~15 phút.
      Vì vậy phần lớn thời gian tôi chỉ phải trải qua quy trình xác thực phiền phức mỗi ngày một lần, đồng thời khi cần có thể chặn hoàn toàn quyền truy cập vào các dịch vụ kết nối qua VPN trong vòng 15 phút.
      Ưu điểm là khi sử dụng bình thường thì thay đổi này hầu như không lộ rõ.

    • Không cần xác thực lại; chỉ cần việc làm mới token hiện có diễn ra định kỳ là đủ.
      Nên tách riêng thời gian hết hạn của xác thực (auth) và thời gian hết hạn của cấp quyền (authorization).

    • Nếu bắt xác thực lại quá thường xuyên thì ngược lại người ta sẽ đi tìm cách lách.
      Sẽ xuất hiện đủ kiểu “mẹo” như viết mật khẩu ra giấy, lưu trong Google Docs, gắn Arduino + servo motor vào Yubikey, chuyển tiếp tin nhắn SMS sang email, hoặc gửi mã TOTP qua Wechat.

    • Rốt cuộc lại thành một tình thế tiến thoái lưỡng nan: chính sách xác thực càng bất tiện thì người dùng càng tìm đến các đường vòng kém an toàn hơn chỉ để có thể sử dụng máy tính theo ý mình một chút.

  • Trong bài có câu đại ý rằng “giờ đây đa số OS đều cho phép mở khóa bằng vân tay/khuôn mặt, nên không có lý do gì để không khóa màn hình khi rời chỗ”, nhưng trên thực tế điều này chỉ áp dụng rất hạn chế với workstation (PC desktop).
    Trong 30 năm làm hỗ trợ hiện trường, tôi mới chỉ thấy đúng 1 máy desktop có đầu đọc vân tay.
    Camera cũng hầu như không có; trong số PC ở 5 địa điểm tôi đang quản lý hiện tại, chưa đến 2% máy có camera.
    Nhận diện khuôn mặt còn có thêm yếu tố gây khó chịu cho người dùng.
    Chúng ta vốn đã mất niềm tin vì việc nhận diện khuôn mặt không có sự đồng ý, diễn ra lén lút (camera giám sát, trường học/công ty/cảnh sát, v.v.), và tôi nghĩ sự khó chịu vì điều đó là hoàn toàn chính đáng.
    Ngay cả khi thiết bị thuộc sở hữu của tôi, các công ty phần mềm trên thực tế vẫn thiết kế theo cách xâm phạm quyền của tôi mà hầu như không có giới hạn đạo đức.
    Vì vậy tôi nghĩ khóa bảo mật phù hợp với workstation hơn.

  • Chính sách an ninh IT trong ngành vận hành kiểu như quan niệm “không ai bị sa thải vì mua IBM”, tức là ai cũng chỉ làm theo những gì người khác đang làm.
    Hệ thống có hỏng đến đâu cũng không quan trọng; điều quan trọng hơn là đã làm “đúng như sách viết”.
    Mà cuốn sách đó (tiêu chuẩn) lại là thứ rất tệ được tạo ra từ 30 năm trước.
    Vì vậy muốn thuyết phục người phụ trách an ninh thông tin rằng không cần đổi mật khẩu mỗi 3 tháng là một việc cực kỳ tốn năng lượng.

    • Ít nhất thì riêng phần thay đổi mật khẩu định kỳ, thật may là giờ đã có thể phản biện bằng cách đưa ra khuyến nghị mới của NIST.
  • Ở một công ty khách hàng, mọi hệ thống đều bị đặt giới hạn phiên là 30 phút.
    Bản thân tôi vốn đã không thích Jira, mà cứ mỗi lần muốn xem một ticket lại phải đăng nhập lại thì quá khó chịu.
    Thế là rốt cuộc lại sa vào vòng luẩn quẩn chỉ ngồi đọc Hacker News thay vì làm việc.

    • Không có gì hụt hẫng bằng việc mất 30 phút nhập liệu xong bấm gửi thì ngay đúng lúc đó phiên hết hạn.
      May là dạo này đa số dịch vụ ít ra cũng lưu tạm nội dung tôi đang làm bằng cache.
  • Tên gọi là SSO, tức ‘SINGLE sign on’, nhưng trên thực tế lại bắt xác thực lặp đi lặp lại không ngừng.
    Tôi không hiểu vì sao mỗi ngày tôi phải nhìn thấy thông báo yêu cầu xác thực SSO hàng trăm lần.

    • Với điện thoại thì còn có thể hiểu được vì có rủi ro mất cắp/thất lạc, còn desktop thì nhiều người vẫn hay bỏ quên máy công cộng (ví dụ: ở thư viện) mà không đăng xuất rồi rời đi, và nhiều người dùng không nhận thức được điểm này.

    • Theo cách tôi nhớ thì ý nghĩa của SSO là đăng nhập vào nhiều hệ thống bằng một ID duy nhất, chứ không phải chỉ thực hiện hành động đăng nhập đúng một lần.