Thông tin xác thực phiên được liên kết với thiết bị (DBSC)

Thông tin xác thực phiên được liên kết với thiết bị (DBSC) tăng cường xác thực bằng cách bổ sung tính năng bảo mật phiên dựa trên phần cứng.

Daniel Rubery
Daniel Rubery
José Luis Zapata

Giới thiệu

Nhiều trang web dựa vào cookie có thời gian tồn tại lâu dài để xác thực người dùng, nhưng những cookie này dễ bị đánh cắp phiên. Thông tin xác thực phiên được liên kết với thiết bị (DBSC) bổ sung một lớp bảo mật dựa trên phần cứng để giảm thiểu rủi ro này, đảm bảo các phiên được liên kết với các thiết bị cụ thể.

Hướng dẫn này dành cho những nhà phát triển duy trì quy trình xác thực trong các ứng dụng web. Tài liệu này giải thích cách hoạt động của DBSC và cách tích hợp DBSC vào trang web của bạn.

Cách hoạt động của DBSC

Ở cấp độ cao, DBSC giới thiệu một cặp khoá mã hoá được liên kết với thiết bị của người dùng. Chrome tạo cặp khoá này trong quá trình đăng nhập và lưu khoá riêng tư trong phần cứng bảo mật, chẳng hạn như Mô-đun nền tảng đáng tin cậy (TPM), nếu có. Các phiên sử dụng cookie ngắn hạn. Khi một trong những cookie này hết hạn, Chrome sẽ chứng minh quyền sở hữu khoá riêng tư trước khi làm mới chúng. Quá trình này liên kết tính liên tục của phiên với thiết bị ban đầu.

Nếu thiết bị của người dùng không hỗ trợ bộ nhớ khoá an toàn, DBSC sẽ chuyển về hành vi tiêu chuẩn mà không làm gián đoạn quy trình xác thực.

Tổng quan về quy trình triển khai

Để tích hợp DBSC vào ứng dụng, bạn cần thực hiện các thay đổi sau:

  • Sửa đổi quy trình đăng nhập để thêm tiêu đề Secure-Session-Registration.
  • Thêm một điểm cuối đăng ký phiên có:
    • Liên kết một khoá công khai với phiên của người dùng.
    • Phục vụ cấu hình phiên.
    • Chuyển sang cookie có thời gian tồn tại ngắn.
  • Thêm một điểm cuối làm mới để xử lý việc gia hạn cookie và xác thực quyền sở hữu khoá.

Hầu hết các điểm cuối hiện có của bạn đều không yêu cầu thay đổi. DBSC được thiết kế để bổ sung và không gây gián đoạn.

Khi một cookie bắt buộc có thời gian tồn tại ngắn bị thiếu hoặc hết hạn, Chrome sẽ tạm dừng yêu cầu và cố gắng làm mới cookie. Nhờ đó, ứng dụng của bạn có thể tiếp tục sử dụng các quy trình kiểm tra cookie phiên thông thường để xác nhận rằng người dùng đã đăng nhập. Vì điều này phù hợp với các quy trình xác thực thông thường, nên DBSC hoạt động với những thay đổi tối thiểu đối với logic đăng nhập của bạn.

Các bước triển khai

Phần này hướng dẫn bạn thực hiện những thay đổi cần thiết đối với hệ thống xác thực, bao gồm cả cách sửa đổi quy trình đăng nhập, xử lý việc đăng ký phiên và quản lý việc làm mới cookie có thời gian tồn tại ngắn. Mỗi bước được thiết kế để tích hợp liền mạch với cơ sở hạ tầng hiện có của bạn.

Các bước triển khai tuân theo quy trình chung mà người dùng đã đăng nhập sẽ trải qua khi DBSC đang hoạt động: đăng ký khi đăng nhập, sau đó là làm mới cookie thông thường trong thời gian ngắn. Bạn có thể kiểm thử và triển khai từng bước một cách độc lập, tuỳ thuộc vào mức độ nhạy cảm của phiên trong ứng dụng.

Sơ đồ minh hoạ quy trình DBSC

1. Sửa đổi quy trình đăng nhập

Sau khi người dùng đăng nhập, hãy phản hồi bằng một cookie có thời gian lưu trữ dài và tiêu đề Secure-Session-Registration. Ví dụ:

Tiêu đề phản hồi HTTP sau đây sẽ được trả về sau khi đăng ký phiên thành công:

HTTP/1.1 200 OK
Secure-Session-Registration: (ES256 RS256); path="/StartSession"
Set-Cookie: auth_cookie=session_id; max-age=2592000; Domain=example.com; Secure; SameSite=Lax

Nếu thiết bị hỗ trợ bộ nhớ khoá an toàn, thì Chrome sẽ liên hệ với điểm cuối /StartSession bằng khoá công khai trong Mã thông báo web JSON (JWT).

auth_cookie trong ví dụ này đại diện cho mã thông báo phiên của bạn. Bạn có thể đặt tên cho cookie này theo ý muốn, miễn là tên đó khớp với trường name trong cấu hình phiên và được sử dụng nhất quán trong toàn bộ ứng dụng của bạn.

2. Triển khai điểm cuối đăng ký phiên

Tại /StartSession, máy chủ của bạn phải:

  • Liên kết khoá công khai nhận được với phiên của người dùng.
  • Phản hồi bằng một cấu hình phiên.
  • Thay thế cookie có thời gian lưu giữ lâu dài bằng cookie có thời gian lưu giữ ngắn.

Trong ví dụ sau, cookie có thời gian tồn tại ngắn được định cấu hình để hết hạn sau 10 phút:

HTTP/1.1 200 OK
Set-Cookie: auth_cookie=short_lived_grant; Max-Age=600; # Expires after 10 minutesSet-Cookie: Domain=example.com; Secure; SameSite=Lax

{
  "session_identifier": "session_id",
  "refresh_url": "/RefreshEndpoint",
  "scope": {
    "origin": "https://example.com",
    "include_site": true,
    "scope_specification": [
      { "type": "exclude", "domain": "*.example.com", "path": "/static" }
    ]
  },
  "credentials": [{
    "type": "cookie",
    "name": "auth_cookie",
    "attributes": "Domain=example.com; Secure; SameSite=Lax"
  }]
}

3. Triển khai điểm cuối làm mới

Khi cookie có thời hạn ngắn hết hạn, Chrome sẽ bắt đầu một quy trình làm mới để chứng minh quyền sở hữu khoá riêng tư. Quá trình này bao gồm các hành động phối hợp của cả Chrome và máy chủ của bạn:

  1. Chrome chuyển yêu cầu của người dùng đến ứng dụng của bạn và gửi yêu cầu làm mới đến /RefreshEndpoint:

    POST /RefreshEndpoint HTTP/1.1
Sec-Secure-Session-Id: session_id

  2. Máy chủ của bạn phản hồi bằng một thử thách:

    HTTP/1.1 403 Forbidden
Secure-Session-Challenge: "challenge_value"

  3. Chrome ký thử thách bằng khoá riêng tư đã lưu trữ và thử lại yêu cầu:

    POST /RefreshEndpoint HTTP/1.1
Sec-Secure-Session-Id: session_id
Secure-Session-Response: <JWT proof>

  4. Máy chủ của bạn xác thực bằng chứng đã ký và phát hành một cookie ngắn hạn mới:

    HTTP/1.1 200 OK

Set-Cookie: auth_cookie=short_lived_grant; Max-Age=600; Domain=example.com; Secure; SameSite=Lax

  5. Chrome nhận được cookie mới và tiếp tục yêu cầu ban đầu bị hoãn lại.

Mẫu tích hợp thay thế

Để cải thiện khả năng phục hồi, các trang web có thể thêm một cookie thứ hai không phải là DBSC cùng với cookie có thời gian tồn tại ngắn. Cookie có thời gian tồn tại lâu dài này chỉ được dùng để phát hành mã thông báo mới có thời gian tồn tại ngắn và giúp phân biệt giữa các yêu cầu thực sự chưa được xác thực và các lỗi DBSC tạm thời.

  • Cookie có thời gian tồn tại lâu dài vẫn tồn tại ngay cả khi DBSC gặp lỗi.
  • Cookie ngắn hạn được làm mới bằng DBSC và bắt buộc đối với các thao tác nhạy cảm.

Mẫu này giúp các trang web có thêm quyền kiểm soát đối với cách xử lý các trường hợp đặc biệt.

Lưu ý và hành vi dự phòng

Chrome có thể bỏ qua các thao tác DBSC và gửi yêu cầu mà không có cookie ngắn hạn do DBSC quản lý trong các trường hợp sau:

  • Không thể truy cập vào điểm cuối làm mới do lỗi mạng hoặc sự cố máy chủ.
  • TPM đang bận hoặc gặp lỗi ký. Vì TPM được chia sẻ trên các quy trình hệ thống, nên việc làm mới quá mức có thể vượt quá giới hạn tốc độ của TPM.
  • Cookie ngắn hạn do DBSC quản lý là cookie của bên thứ ba và người dùng đã chặn cookie của bên thứ ba trong phần cài đặt trình duyệt.

Trong những trường hợp này, Chrome sẽ quay lại sử dụng cookie có thời gian tồn tại lâu dài nếu cookie đó vẫn còn. Cơ chế dự phòng này chỉ hoạt động nếu quá trình triển khai của bạn bao gồm cả cookie có thời gian lưu trú dài và cookie có thời gian lưu trú ngắn. Nếu không, Chrome sẽ gửi yêu cầu mà không có cookie.

Tóm tắt

Thông tin xác thực phiên được liên kết với thiết bị giúp cải thiện tính bảo mật của phiên mà không cần thay đổi nhiều cho ứng dụng của bạn. Chúng cung cấp khả năng bảo vệ mạnh mẽ hơn trước các cuộc tấn công chiếm đoạt phiên bằng cách liên kết các phiên với các thiết bị cụ thể. Hầu hết người dùng đều được hưởng lợi mà không gặp phải bất kỳ sự gián đoạn nào và DBSC sẽ chuyển về trạng thái dự phòng một cách trơn tru trên phần cứng không được hỗ trợ.

Để biết thêm thông tin, hãy tham khảo quy cách DBSC.