Tại sao phải dùng JWT

#1

hi,
Cho mình hỏi JWT bảo mật ở điểm nào và có ưu điểm gì hơn Basic authen hay Bearer ?

2 Likes
#2

Bạn nên tìm hiểu về JWT trước, đọc hiểu về nó trước rồi hẳng hỏi
còn câu hỏi như thế này chẳng có thông tin ngữ cảnh gì cả, giống kiểu thầy bói xem voi, chỉ mới xem một tí xíu đã bắt đầu đặt câu hỏi

6 Likes
#3

Hm, tớ đoán cậu hiểu nhầm chút rồi :smile:

Cậu chắc biết JWT gồm 3 thành phầm: header, payload và signature.
Cậu chắc cũng biết signature được tính thế này:

signature = HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret)

HMACSHA256 là giải thuật hash. Cậu cũng hiểu hash không phải là encode. Cậu không dò được secret từ kết quả của hàm băm, trừ khi cậu brute-force.

Khi server nhận được request, bao gồm header, payload và signature, tất cả những gì server cần làm là tính lại signature từ header, payload và secret (server cũng biết secret chứ :smile: ). Nếu signature được tái tạo lại giống với signature từ request => xác thực được client.

Giờ, cậu có thể thắc mắc rằng, thế nó bảo mật hơn Basic authen hay Bearer như thế nào?
Có 2 vấn đề:

  • Dùng JWT không phải truyền secret đi muôn nơi trong network. Cậu không bị đối mặt với việc secret bị compromise, so với việc dùng Basic, hay Bearer (an toàn hơn Basic chút).
  • Vấn đề là với Basic và Bearer, cậu hoàn toàn có thể bị tấn công bởi replay attack - ai đó ở giữa biết được request của cậu, và gọi y hệt như thế.
    JWT có thể chống cách tấn công này tương đối đơn giản: trong payload cậu có cả thời gian gửi. Khi đó, 2 request yêu cầu cùng 1 tài nguyên, ở 2 thời điểm khác nhau sẽ có payload và signature hoàn toàn khác nhau. Trên server chỉ cần kiểm tra thời điểm gọi, nếu nó quá lâu so với thời điểm hiện tại, thì reject.

Hope it helps!

13 Likes
Phương pháp bảo mật API
#4

nếu dùng JWT thì ai đó ở giữa cũng có token thì cũng có thể gọi y hệt như thế đúng không a ?

#5

đúng, khi bạn đưa người khác token, hoặc người khác có được token của bạn , thì đều có thể gọi API đó

7 Likes
#6

Sau khi đã được @library phân tích, bạn có thể tự edit câu hỏi để làm rõ hơn câu hỏi được không?
Xem như là tự review lại cũng là đóng góp cho cộng đồng.

6 Likes
#7

Cái em đang đề cập là Transparent Token (còn được gọi là stateless token)
Muốn bảo mật hơn thì dùng Opaque Token.
https://engineering.tiki.vn/xác-thực-và-phân-quyền-trong-microservices-37689e53c082

Đúng, cho nên không nên cho JWT có thời gian expired quá lâu, chỉ tầm 30p thôi.

10 Likes
#8

đúng vậy, facebook cũng lưu token và một số thông tin của user vào cookie, bạn có thế test thử bằng cách đăng nhập một tài khoản facebook và copy toàn bộ cookie của facebook gửi về ra notepad và restore đoạn cookie đó vào trình duyệt khác (fb vẫn hiểu đó là bạn, bạn vẫn vào được acc mà không cần biết password) Công cụ hỗ trợ lấy cookie facebook : https://plus24h.com/huong-dan-fplus/huong-dan-cai-dat-ung-dung-get-cookie.html

4 Likes
#9

@SuperFrankie8 @anon71189590 cho em hỏi nếu vậy tại sao nó lại bảo mật ? mình thấy xác thực kiểu này chỉ bảo mật cho server chứ client hình như không có lợi lắm ? các bác giải thích giúp e với

2 Likes
#10

cái này là bài ca con cá mà thôi
để người khác tấn công man-in-the-middle, hoặc để người khác có thể đọc được cái gì đó trên trình duyệt của mình, thì còn gì để nói nữa bây giờ
còn cách bạn đó mô tả cũng sai về jwt, ngoài việc kêu bạn đó đọc lại tài liệu jwt thì còn biết nói gì nữa đây

8 Likes
#11

Vấn đề là làm thế nào cậu để lộ token được? :smile:
Như @kisuluoibieng có đề cập, cậu bị lộ token khi cậu ngây thơ:

  • Để ai đó tấn công Man-in-the-middle (MITM) với cậu. Ví dụ: cậu bị cài script nào đó lên máy tính cá nhân, hoặc cậu sử dụng 1 proxy độc hại nào đó, hoặc ai đó may mắn bắt được gói tin của cậu khi cậu đang ngồi trong cafe-internet, truy cập 1 website không sử dụng HTTPS.
  • Cậu chủ động share token đó cho ai đó, và người ta dùng sai mục đích.

Thực ra, JWT không được design để chống MITM. Nhưng nếu cậu dùng JWT + HTTPS, cậu hoàn toàn có thể yên tâm chống MITM.

12 Likes
83% thành viên diễn đàn không hỏi bài tập, còn bạn thì sao?