Các phương pháp hay nhất để xử lý phía máy chủ đối với mã thông báo JWT [đã đóng]

(sinh ra từ chủ đề này vì đây thực sự là một câu hỏi của riêng nó và không dành riêng cho NodeJS, v.v.)

Tôi đang triển khai máy chủ REST API có xác thực và tôi đã triển khai thành công xử lý mã thông báo JWT để người dùng có thể đăng nhập thông qua điểm cuối / đăng nhập bằng tên người dùng / mật khẩu, trên đó mã thông báo JWT được tạo từ bí mật máy chủ và được trả về khách hàng. Sau đó, mã thông báo được chuyển từ máy khách đến máy chủ trong mỗi yêu cầu API được xác thực, trên đó bí mật máy chủ được sử dụng để xác minh mã thông báo.

Tuy nhiên, tôi đang cố gắng tìm hiểu các phương pháp hay nhất để biết chính xác cách thức và mức độ mã thông báo nên được xác thực để tạo ra một hệ thống thực sự an toàn. Chính xác thì những gì nên liên quan đến việc "xác thực" mã thông báo? Có đủ để chữ ký có thể được xác minh bằng cách sử dụng bí mật của máy chủ hay tôi cũng nên kiểm tra chéo mã thông báo và / hoặc trọng tải mã thông báo với một số dữ liệu được lưu trữ trong máy chủ?

Hệ thống xác thực dựa trên mã thông báo sẽ chỉ an toàn bằng cách chuyển tên người dùng / mật khẩu trong mỗi yêu cầu với điều kiện là việc lấy mã thông báo sẽ khó hơn hoặc bằng cách lấy mật khẩu của người dùng. Tuy nhiên, trong các ví dụ tôi đã thấy, thông tin duy nhất cần thiết để tạo mã thông báo là tên người dùng và bí mật phía máy chủ. Điều này không có nghĩa là giả sử trong một phút rằng một người dùng độc hại có được kiến ​​thức về bí mật máy chủ, giờ đây anh ta có thể tạo ra các mã thông báo thay mặt cho bất kỳ người dùng nào , do đó có quyền truy cập không chỉ vào một người dùng nhất định như thực tế nếu có mật khẩu thu được, nhưng trên thực tế cho tất cả các tài khoản người dùng?

Điều này đưa tôi đến những câu hỏi:

1) Việc xác thực mã thông báo JWT có nên được giới hạn trong việc xác minh chữ ký của chính mã thông báo, chỉ dựa vào tính toàn vẹn của bí mật máy chủ hoặc đi kèm với cơ chế xác thực riêng?

• Trong một số trường hợp, tôi đã thấy việc sử dụng kết hợp mã thông báo và phiên máy chủ, khi đăng nhập thành công qua điểm cuối / đăng nhập, một phiên được thiết lập. Yêu cầu API xác thực mã thông báo và cũng so sánh dữ liệu đã giải mã được tìm thấy trong mã thông báo với một số dữ liệu được lưu trữ trong phiên. Tuy nhiên, sử dụng phiên có nghĩa là sử dụng cookie và theo một nghĩa nào đó, nó đánh bại mục đích của việc sử dụng phương pháp dựa trên mã thông báo. Nó cũng có thể gây ra vấn đề cho một số khách hàng.

• Người ta có thể tưởng tượng máy chủ lưu giữ tất cả các mã thông báo hiện đang được sử dụng trong một bộ nhớ cache hoặc tương tự, để đảm bảo rằng ngay cả khi bí mật máy chủ bị xâm phạm để kẻ tấn công có thể tạo mã thông báo "hợp lệ", chỉ các mã thông báo chính xác được tạo thông qua điểm cuối / đăng nhập sẽ được chấp nhận. Điều này là hợp lý hay chỉ là dư thừa / quá mức cần thiết?

2) Nếu xác minh chữ ký JWT là phương tiện duy nhất để xác thực mã thông báo, có nghĩa là tính toàn vẹn của bí mật máy chủ là điểm phá vỡ, thì bí mật máy chủ nên được quản lý như thế nào? Đọc từ một biến môi trường và được tạo (ngẫu nhiên?) Một lần cho mỗi ngăn xếp được triển khai? Được làm mới lại hoặc xoay vòng theo định kỳ (và nếu vậy, cách xử lý các mã thông báo hợp lệ hiện có đã được tạo trước khi xoay vòng nhưng cần được xác thực sau khi xoay vòng, có lẽ là đủ nếu máy chủ giữ bí mật hiện tại và trước đó tại bất kỳ thời điểm nào) ? Thứ gì khác?

Có lẽ tôi chỉ đơn giản là quá hoang tưởng khi nói đến nguy cơ bí mật máy chủ bị xâm phạm, đó tất nhiên là một vấn đề chung hơn cần được giải quyết trong tất cả các tình huống mật mã ...

Tôi cũng đang chơi với các mã thông báo cho ứng dụng của mình. Mặc dù tôi không phải là một chuyên gia, nhưng tôi có thể chia sẻ một số kinh nghiệm và suy nghĩ của mình về vấn đề này.

Quan điểm của JWT về cơ bản là tính toàn vẹn. Nó cung cấp một cơ chế để máy chủ của bạn xác minh rằng mã thông báo được cung cấp cho nó là chính hãng và được cung cấp bởi máy chủ của bạn. Chữ ký được tạo ra thông qua bí mật của bạn là những gì cung cấp cho điều này. Vì vậy, có, nếu bí mật của bạn bị rò rỉ bằng cách nào đó, cá nhân đó có thể tạo ra các mã thông báo mà máy chủ của bạn nghĩ là của riêng nó. Một hệ thống dựa trên mã thông báo sẽ vẫn an toàn hơn hệ thống tên người dùng / mật khẩu của bạn chỉ vì xác minh chữ ký. Và trong trường hợp này, nếu ai đó có bí mật của bạn, hệ thống của bạn có các vấn đề bảo mật khác cần giải quyết so với việc ai đó tạo mã thông báo giả (và thậm chí sau đó, chỉ cần thay đổi bí mật đảm bảo rằng bất kỳ mã thông báo nào được thực hiện bằng bí mật cũ hiện không hợp lệ).

Đối với tải trọng, chữ ký sẽ chỉ cho bạn biết rằng mã thông báo được cung cấp cho bạn chính xác như khi máy chủ của bạn gửi nó đi. Việc xác minh nội dung tải trọng có hợp lệ hoặc phù hợp với ứng dụng của bạn hay không rõ ràng là tùy thuộc vào bạn.

Đối với câu hỏi của bạn:

1.) Theo kinh nghiệm hạn chế của tôi, chắc chắn tốt hơn nên xác minh mã thông báo của bạn bằng hệ thống thứ hai. Chỉ cần xác thực chữ ký chỉ có nghĩa là mã thông báo được tạo bằng bí mật của bạn. Lưu trữ bất kỳ mã thông báo đã tạo nào trong một số loại DB (redis, memcache / sql / mongo hoặc một số bộ nhớ khác) là một cách tuyệt vời để đảm bảo rằng bạn chỉ chấp nhận các mã thông báo mà máy chủ của bạn đã tạo. Trong trường hợp này, ngay cả khi bí mật của bạn bị rò rỉ, điều đó cũng không quá quan trọng vì bất kỳ mã thông báo nào được tạo ra sẽ không hợp lệ. Đây là cách tiếp cận mà tôi đang thực hiện với hệ thống của mình - tất cả các mã thông báo được tạo đều được lưu trữ trong một DB (redis) và theo mỗi yêu cầu, tôi xác minh rằng mã thông báo đó có trong DB của tôi trước khi tôi chấp nhận nó. Theo cách này, các mã thông báo có thể bị thu hồi vì bất kỳ lý do nào, chẳng hạn như mã thông báo đã được phát hành tự nhiên bằng cách nào đó, đăng xuất của người dùng, thay đổi mật khẩu, thay đổi bí mật, v.v.

2.) Đây là điều tôi không có nhiều kinh nghiệm và là điều tôi vẫn đang tích cực nghiên cứu vì tôi không phải là chuyên gia bảo mật. Nếu bạn tìm thấy bất kỳ tài nguyên nào, hãy đăng chúng ở đây! Hiện tại, tôi chỉ đang sử dụng khóa riêng tư mà tôi tải từ đĩa, nhưng rõ ràng đó không phải là giải pháp tốt nhất hoặc an toàn nhất.

Dưới đây là một số điều cần xem xét khi triển khai JWT trong ứng dụng của bạn:

• Giữ cho thời gian tồn tại JWT của bạn tương đối ngắn và được quản lý suốt đời tại máy chủ. Nếu không, và sau này cần yêu cầu thêm thông tin trong các JWT của mình, bạn sẽ phải hỗ trợ 2 phiên bản hoặc đợi cho đến khi các JWT cũ hơn hết hạn trước khi bạn có thể thực hiện thay đổi của mình. Bạn có thể dễ dàng quản lý nó trên máy chủ nếu bạn chỉ nhìn vào iattrường trong jwt và bỏ qua exptrường.

• Xem xét đưa url của yêu cầu vào JWT của bạn. Ví dụ: nếu bạn muốn JWT của mình được sử dụng ở điểm cuối /my/test/path, hãy bao gồm một trường như 'url':'/my/test/path'trong JWT của bạn, để đảm bảo nó chỉ được sử dụng tại đường dẫn này. Nếu không, bạn có thể thấy rằng mọi người bắt đầu sử dụng JWT của bạn ở các điểm cuối khác, ngay cả những điểm mà họ không được tạo. Thay vào đó, bạn cũng có thể xem xét bao gồm một md5 (url), vì có một url lớn trong JWT sẽ khiến JWT lớn hơn nhiều và chúng có thể trở nên khá lớn.

• JWT hết hạn phải được cấu hình theo từng trường hợp sử dụng nếu JWT đang được triển khai trong một API. Ví dụ: nếu bạn có 10 điểm cuối cho 10 trường hợp sử dụng khác nhau cho JWT, hãy đảm bảo rằng bạn có thể làm cho mỗi điểm cuối chấp nhận JWT hết hạn vào các thời điểm khác nhau. Điều này cho phép bạn khóa một số điểm cuối nhiều hơn những điểm khác, nếu ví dụ, dữ liệu được cung cấp bởi một điểm cuối rất nhạy cảm.

• Thay vì chỉ đơn giản là JWT hết hạn sau một thời gian nhất định, hãy xem xét triển khai JWT hỗ trợ cả hai:

  • N cách sử dụng - chỉ có thể được sử dụng N lần trước khi hết hạn và
  • hết hạn sau một khoảng thời gian nhất định (nếu bạn có mã thông báo chỉ sử dụng một lần, bạn không muốn nó tồn tại mãi mãi nếu không được sử dụng, phải không?)

• Tất cả các lỗi xác thực JWT sẽ tạo ra một tiêu đề phản hồi "lỗi" cho biết lý do tại sao xác thực JWT không thành công. ví dụ: "hết hạn", "không còn sử dụng", "bị thu hồi", v.v. Điều này giúp người triển khai biết tại sao JWT của họ không thành công.

• Cân nhắc bỏ qua "tiêu đề" của JWT khi chúng làm rò rỉ thông tin và đưa ra biện pháp kiểm soát cho tin tặc. Điều này chủ yếu liên quan đến algtrường trong tiêu đề - hãy bỏ qua điều này và chỉ giả sử rằng tiêu đề là những gì bạn muốn hỗ trợ, vì điều này tránh tin tặc cố gắng sử dụng Nonethuật toán, loại bỏ kiểm tra bảo mật chữ ký.

• JWT phải bao gồm một số nhận dạng nêu chi tiết ứng dụng nào đã tạo mã thông báo. Ví dụ: nếu JWT của bạn đang được tạo bởi 2 ứng dụng khách khác nhau, mychat và myclassifiedsapp, thì mỗi ứng dụng phải bao gồm tên dự án hoặc một cái gì đó tương tự trong trường "Iss" trong JWT, ví dụ: "Iss": "mychat"

• JWT không nên được ghi vào các tệp nhật ký. Nội dung của JWT có thể được ghi lại, nhưng không thể ghi lại chính JWT. Điều này đảm bảo các nhà phát triển hoặc những người khác không thể lấy JWT từ các tệp nhật ký và thực hiện những việc với tài khoản người dùng khác.
• Đảm bảo việc triển khai JWT của bạn không cho phép thuật toán "Không có", để tránh tin tặc tạo mã thông báo mà không ký chúng. Có thể tránh hoàn toàn loại lỗi này bằng cách bỏ qua "tiêu đề" của JWT của bạn.
• Thực sự cân nhắc việc sử dụng iat(cấp tại) thay vì exp(hết hạn) trong JWT của bạn. Tại sao? Vì iatvề cơ bản có nghĩa là JWT được tạo khi nào, điều này cho phép bạn điều chỉnh trên máy chủ khi JWT hết hạn, dựa trên ngày tạo. Nếu ai đó vượt qua được exp20 năm trong tương lai, JWT về cơ bản sẽ tồn tại mãi mãi! Lưu ý rằng bạn sẽ tự động hết hạn JWT nếu chúng iatở trong tương lai, nhưng hãy cho phép khoảng trống một chút (ví dụ: 10 giây), trong trường hợp thời gian của khách hàng hơi không đồng bộ với thời gian của máy chủ.
• Xem xét triển khai một điểm cuối để tạo JWT từ tải trọng json và buộc tất cả các khách hàng triển khai của bạn sử dụng điểm cuối này để tạo JWT của họ. Điều này đảm bảo rằng bạn có thể giải quyết bất kỳ vấn đề bảo mật nào bạn muốn với cách JWT được tạo ở một nơi một cách dễ dàng. Chúng tôi đã không làm điều này ngay lập tức trong ứng dụng của mình và bây giờ phải từ từ đưa ra các bản cập nhật bảo mật phía máy chủ JWT vì 5 ứng dụng khách khác nhau của chúng tôi cần thời gian để triển khai. Ngoài ra, hãy làm cho điểm cuối tạo của bạn chấp nhận một mảng các tải trọng json để JWT tạo và điều này sẽ giảm số lượng yêu cầu http đến điểm cuối này cho khách hàng của bạn.
• Nếu JWT của bạn sẽ được sử dụng tại các điểm cuối cũng hỗ trợ việc sử dụng theo phiên, hãy đảm bảo rằng bạn không đặt bất kỳ thứ gì vào JWT của mình để đáp ứng yêu cầu. Bạn có thể dễ dàng làm điều này nếu bạn đảm bảo điểm cuối của mình hoạt động với một phiên, khi không có JWT nào được cung cấp.
• Vì vậy, nói chung JWT kết thúc bằng cách chứa userId hoặc groupId thuộc một số loại, và cho phép truy cập vào một phần hệ thống của bạn dựa trên thông tin này. Đảm bảo rằng bạn không cho phép người dùng trong một khu vực của ứng dụng mạo danh người dùng khác, đặc biệt nếu điều này cung cấp quyền truy cập vào dữ liệu nhạy cảm. Tại sao? Ngay cả khi quy trình tạo JWT của bạn chỉ có thể truy cập vào các dịch vụ "nội bộ", các nhà phát triển hoặc các nhóm nội bộ khác có thể tạo JWT để truy cập dữ liệu cho bất kỳ người dùng nào, ví dụ như Giám đốc điều hành của công ty khách hàng ngẫu nhiên nào đó. Ví dụ: nếu ứng dụng của bạn cung cấp quyền truy cập vào hồ sơ tài chính cho khách hàng, thì bằng cách tạo JWT, một nhà phát triển có thể lấy hồ sơ tài chính của bất kỳ công ty nào! Và nếu một tin tặc xâm nhập vào mạng nội bộ của bạn, họ cũng có thể làm như vậy.
• Nếu bạn định cho phép bất kỳ url nào chứa JWT được lưu vào bộ nhớ đệm theo bất kỳ cách nào, hãy đảm bảo rằng các quyền cho những người dùng khác nhau được bao gồm trong url chứ không phải JWT. Tại sao? Vì người dùng có thể nhận được dữ liệu mà họ không nên. Ví dụ: giả sử một người dùng cấp cao đăng nhập vào ứng dụng của bạn và yêu cầu url sau: /mysite/userInfo?jwt=XXXvà url này được lưu vào bộ nhớ đệm. Họ đăng xuất và vài phút sau, một người dùng thông thường đăng nhập vào ứng dụng của bạn. Họ sẽ nhận được nội dung được lưu trong bộ nhớ cache - với thông tin về một người dùng siêu đẳng! Điều này có xu hướng ít xảy ra hơn trên máy khách và nhiều hơn trên máy chủ, đặc biệt là trong trường hợp bạn đang sử dụng CDN như Akamai và bạn đang để một số tệp tồn tại lâu hơn. Điều này có thể được khắc phục bằng cách đưa thông tin người dùng có liên quan vào url và xác thực thông tin này trên máy chủ, ngay cả đối với các yêu cầu đã lưu trong bộ nhớ cache, chẳng hạn/mysite/userInfo?id=52&jwt=XXX
• Nếu jwt của bạn được sử dụng như một cookie phiên và chỉ hoạt động trên cùng một máy mà jwt được tạo ra, bạn nên cân nhắc thêm trường jti vào jwt của mình. Về cơ bản, đây là một mã thông báo CSRF, đảm bảo JWT của bạn không thể được chuyển từ trình duyệt của một người dùng đến người ẩn danh.

Tôi không nghĩ mình là chuyên gia nhưng tôi muốn chia sẻ một số điều về Jwt.

• 1: Như Akshay đã nói, tốt hơn là nên có một hệ thống thứ hai để xác thực mã thông báo của bạn.

  a.: Cách tôi xử lý: Tôi lưu trữ hàm băm được tạo thành một bộ lưu trữ phiên với thời gian hết hạn. Để xác thực mã thông báo, nó cần phải được máy chủ phát hành.

  b.: Có ít nhất một điều phải được kiểm tra phương pháp chữ ký được sử dụng. ví dụ :

  header :
  {
    "alg": "none",
    "typ": "JWT"
  }
  

Một số thư viện xác thực JWT sẽ chấp nhận cái này mà không cần kiểm tra hàm băm. Điều đó có nghĩa là nếu không biết muối của bạn được sử dụng để ký mã thông báo, tin tặc có thể tự cấp cho mình một số quyền. Luôn đảm bảo điều này không thể xảy ra. https://auth0.com/blog/2015/03/31/critical-vulnerabilities-in-json-web-token-libraries/

c: Sử dụng cookie với Id phiên sẽ không hữu ích để xác thực mã thông báo của bạn. Nếu ai đó muốn chiếm quyền điều khiển phiên của một người dùng lambda, anh ta chỉ cần sử dụng một trình đánh giá (ví dụ: wirehark). Tin tặc này sẽ có cả hai thông tin cùng một lúc.

• 2: Mọi bí mật đều giống nhau. Luôn luôn có một cách để biết nó.

Cách tôi xử lý nó được liên kết với điểm 1.a. : Tôi có một bí mật trộn lẫn với một biến ngẫu nhiên. Bí mật là duy nhất cho mọi mã thông báo.

Tuy nhiên, tôi đang cố gắng tìm hiểu các phương pháp hay nhất để biết chính xác cách thức và mức độ mã thông báo nên được xác thực để tạo ra một hệ thống thực sự an toàn.

Nếu bạn muốn bảo mật tốt nhất có thể, bạn không nên làm theo các phương pháp hay nhất một cách mù quáng. Cách tốt nhất là hiểu những gì bạn đang làm (tôi nghĩ là ổn khi tôi thấy câu hỏi của bạn) và sau đó đánh giá tính bảo mật mà bạn cần. Và nếu Mossad muốn có quyền truy cập vào dữ liệu bí mật của bạn, họ sẽ luôn tìm cách. (Tôi thích bài đăng trên blog này: https://www.schneier.com/blog/archives/2015/08/mickens_on_secu.html )

Rất nhiều câu trả lời hay ở đây. Tôi sẽ tích hợp một số câu trả lời mà tôi nghĩ là phù hợp nhất và thêm một số gợi ý khác.

1) Việc xác thực mã thông báo JWT có nên được giới hạn trong việc xác minh chữ ký của chính mã thông báo, chỉ dựa vào tính toàn vẹn của bí mật máy chủ hoặc đi kèm với cơ chế xác thực riêng?

Không, vì những lý do không liên quan đến việc xâm phạm bí mật mã thông báo. Mỗi lần người dùng đăng nhập thông qua tên người dùng và mật khẩu, máy chủ ủy quyền sẽ lưu trữ mã thông báo đã được tạo hoặc siêu dữ liệu về mã thông báo đã được tạo. Hãy coi siêu dữ liệu này như một bản ghi ủy quyền. Một cặp ứng dụng và người dùng nhất định chỉ được có một mã thông báo hoặc ủy quyền hợp lệ tại bất kỳ thời điểm nào. Siêu dữ liệu hữu ích là id người dùng được liên kết với mã thông báo truy cập, id ứng dụng và thời điểm mã thông báo truy cập được phát hành (cho phép thu hồi mã thông báo truy cập hiện có và phát hành mã thông báo truy cập mới). Trên mọi yêu cầu API, hãy xác thực rằng mã thông báo có chứa siêu dữ liệu thích hợp. Bạn cần duy trì thông tin về thời điểm mỗi mã thông báo truy cập được phát hành, để người dùng có thể thu hồi mã thông báo truy cập hiện có nếu thông tin đăng nhập tài khoản của họ bị xâm phạm, đồng thời đăng nhập lại và bắt đầu sử dụng mã thông báo truy cập mới. Điều đó sẽ cập nhật cơ sở dữ liệu với thời điểm mã thông báo truy cập được phát hành (thời gian ủy quyền được tạo). Đối với mọi yêu cầu API, hãy kiểm tra xem thời gian phát hành của mã thông báo truy cập có sau thời gian ủy quyền được tạo không.

Các biện pháp bảo mật khác bao gồm không ghi nhật ký JWT và yêu cầu thuật toán ký an toàn như SHA256.

2) Nếu xác minh chữ ký JWT là phương tiện duy nhất để xác thực mã thông báo, có nghĩa là tính toàn vẹn của bí mật máy chủ là điểm phá vỡ, thì bí mật máy chủ nên được quản lý như thế nào?

Việc xâm phạm bí mật máy chủ sẽ cho phép kẻ tấn công cấp mã thông báo truy cập cho bất kỳ người dùng nào và việc lưu trữ dữ liệu mã thông báo truy cập ở bước 1 sẽ không nhất thiết ngăn máy chủ chấp nhận các mã thông báo truy cập đó. Ví dụ: giả sử rằng người dùng đã được cấp mã thông báo truy cập và sau đó, kẻ tấn công tạo mã thông báo truy cập cho người dùng đó. Thời gian ủy quyền của mã thông báo truy cập sẽ hợp lệ.

Giống như Akshay Dhalwala nói, nếu bí mật phía máy chủ của bạn bị xâm phạm, thì bạn sẽ gặp vấn đề lớn hơn phải giải quyết vì điều đó có nghĩa là kẻ tấn công đã xâm phạm mạng nội bộ của bạn, kho lưu trữ mã nguồn của bạn hoặc cả hai.

Tuy nhiên, một hệ thống để giảm thiểu thiệt hại của bí mật máy chủ bị xâm phạm và tránh lưu trữ bí mật trong mã nguồn liên quan đến việc luân chuyển bí mật mã thông báo bằng cách sử dụng dịch vụ điều phối như https://zookeeper.apache.org. Sử dụng công việc cron để tạo bí mật ứng dụng sau vài giờ hoặc lâu hơn (tuy nhiên, mã thông báo truy cập của bạn có giá trị trong bao lâu) và đẩy bí mật cập nhật cho Zookeeper. Trong mỗi máy chủ ứng dụng cần biết bí mật mã thông báo, hãy định cấu hình máy khách ZK được cập nhật bất cứ khi nào giá trị nút ZK thay đổi. Lưu trữ bí mật chính và bí mật phụ và mỗi khi thay đổi bí mật mã thông báo, hãy đặt bí mật mã thông báo mới thành bí mật chính và bí mật mã thông báo cũ thành bí mật phụ. Bằng cách đó, các mã thông báo hợp lệ hiện có sẽ vẫn hợp lệ vì chúng sẽ được xác thực dựa trên bí mật thứ cấp. Vào thời điểm bí mật phụ được thay thế bằng bí mật chính cũ, tất cả các mã thông báo truy cập được cấp bằng bí mật phụ sẽ bị hết hạn.

IETF có một RFC đang được tiến hành trong Nhóm làm việc oAuth, hãy xem: https://tools.ietf.org/id/draft-ietf-oauth-jwt-bcp-05.html