Về cơ bản lý thuyết của cách này là tạo ra 1 hệ thống cực kì nhạy cảm theo 3 bước: - Cả RT và AT đều cùng được cấp mới mỗi lần tạo mới AT, và lưu lại RT cũ. - Một khi RT cũ bị sử dụng lại (không cần phân biệt user hay hacker) thì hủy toàn bộ RT đang hoạt động. - User đăng nhập lại và lấy RT mới.
A giải thích rất kỹ và dễ hiểu. Nhưng vấn đề là enduser ko biết = 1 cách nào đó để lộ token thì lần sau có thể vẫn sẽ bị hack tiếp 😀 => Quy trình này sẽ diễn ra liên tục rồi họ chửi hệ thống mình code lởm, cay :))
anh ơi ví dụ khi em Trả RT và AC mới , em chỉ lưu duy nhất những RF token hợp lệ , khi có 1 RF gửi đến không nằm trong ds RF hợp lệ thì em thực hiện thao tác ở hình 7. tư duy vậy đúng chưa ạ.
em nghĩ vẫn không nên để 2 token này đi cùng trong 1 rq tần suất xuất hiện càng ít càng ít nguy cơ bị tấn công, trong trường hợp như này client sẽ phải triển khai cơ chế để chỉ gọi và làm mới token 1 lần đúng không anh, vì nếu client gọi đồng thời nhiều api có thể chính client tạo nhiều rq làm mới token mà sever sẽ detect là token này đang bị ăn cắp :)) mà nếu gửi 2 token cùng 1 lúc thì trong trường hợp nó gửi nhiều rq là thì hệ thống cũng sẽ xoá các token này
12:54 hình số 5 cho em hỏi là nếu hacker yêu cầu làm mới access token bằng refresh token trước cả user hợp lệ nhưng giả sử lúc này user kia offline ( trong khoảng thời gian AT cũ còn hiệu lực) nửa năm không dùng hệ thống nữa thì tức là sẽ không có yêu cầu cấp mới access token nữa, lúc này hacker sẽ dùng AT và RT mới để sử dụng hợp lệ hay sao ạ, vì phải gọi RT cũ lần thứ 2 thì mới phát hiện bất thường
Case check an ninh bảo mật này chỉ là một ví dụ để mọi người hình dùng việc phải control các request từ client để phát hiện truy cập đáng nghi thôi. Còn cụ thể thì nó lại là nghề của đội an toàn thông tin rồi. Cảm ơn anh về 8 bức hình rất dễ hình dung với các bạn mới tiếp xúc với RT.
hay quá anh ơi. e có một câu hỏi thêm là nếu như trong 1 page gọi nhiều api để lấy dữ liệu và phát hiện token hết hạn, thì nó sẽ call đồng thời nhiều api để lấy token mới bằng refresh_token thì như hệ thống anh triển khai nó sẽ có th rơi vào bất thường và sẽ hủy vc lấy token và bắt người dùng xác thưc(đăng nhập) đk ạ. anh cho e cách xử lý với ạ
Vậy còn trong trường hợp hacker sử dụng refreshToken trước khi hết hạn, và user không sử dụng refreshToken đã hết hạn nữa (thoát web chẳng hạn => không xảy ra hình 7) thì xử lý như thế nào hả a?
@@hienvinhnguyen6729 user login lại khi hệ thống phát hiện refreshToken đã hết hạn được sử dụng lại bạn ơi. Ý mình là khi hacker đánh cắp, và sử refreshToken trước user (refreshToken hợp lệ và chưa hết hạn), và user cũng không sử dụng lại token này nữa (vì lý do thoát web, mất mạng,...).
@@hoanglongvu1538 lúc đó phải kiểm tra lại các yếu tố khác như địa chỉ IP, device id có khớp với lúc đăng nhập không. Nghi ngờ cái đẩy ra trang đăng nhập liền.
@@hoanglongvu1538 mình cũng cùng câu hỏi với bạn. Nếu như vậy thì mình thấy thường sẽ có 1 email hoặc notification về enduser để hỏi rằng đây có chắc chắn là user đó hay ko ? Nhưng mình ko rõ cách triển khai ntn.
Anh cho em hỏi nếu Hacker sử dụng token và làm gì đó trước và gây thiệt hại, sau đó một thời gian user chân chính mới đăng nhập lại và phát hiện thì có phải quá muộn không ?
quy trình vẫn vậy mà bạn. User gửi cặp AT, RT lên. Server phát hiện cặp token này đã được sử dụng ---> có gì đó bất thường ---> tiến hành vô hiệu hóa tất cả AT, RT và bắt đăng nhập lại. Lúc này user sẽ đăng nhập được, còn hacker thì không.
Em thấy là RT chỉ tồn tại ở server thôi chứ :D (lúc này, client chỉ đẩy AT lên thôi ạ, check AT mà hết hạn thì cho vào blackList) Bây giờ client lưu cả RT thì nghe vẻ ... anh ạ :)
Anh có thể cho em hỏi 1 chút, ở gần phút 11:00 anh có bảo khi AT hết hạn thì gọi lên để lấy 1 cặp token mới, như thế em đang hiểu là cả AT và RF đều mới Như thế thì em đang ko thấy sự khác biệt giữa AT và RT khi đều có time expired bằng nhau, trong khi trên lý thuyết thì RT time expired của nó lâu hơn Mong anh giải đáp ạ.
Em hỏi đúng đấy. Không sai vì đa số chúng ta đang làm là dựa trên lý thuyết em nói. Nhưng video này là cách phát hiện bất thường của một token. Nên chúng ta phải đảm bảo an toàn dữ liệu. AT hết thời gian, RT còn thời gian chứ không phải ngang nhau. Cơ chế này đã được OAuth2 LIB đã công bố 3 năm trước. Em có thể đọc sâu hơn tại OAuth2. Cảm ơn về câu hỏi của em.
ví dụ AT dài 5 phút, RT dài 1 tháng. Sau 10 ngày bạn vẫn lấy được cặp token mới, nhưng sau 31 ngày thì bắt buộc phải đăng nhập lại, do thời gian đã quá dài, khả năng cao người dùng đã bỏ quên máy tính cả tháng trời nên đăng nhập lại cũng là hợp lý.
Chào anh, anh có thể cho em hỏi một chút là anh hay thấy anh nói anh lưu RT vào trong Redis. Trong trường hợp Redis có sự cố sự thì toàn bộ RT đã lưu sẽ bị mất hết, vậy thì làm sao người dùng có thể tạo mới lại RT anh nhỉ. Đến lúc đó phải bắt buộc người dùng phải đăng nhập lại hay có cơ chế gì phục hồi Redis không anh nhỉ. Mong anh giải đáp ạ!
Câu hỏi rất hay: Nhưng redis chỉ là một cache trung gian, hệ thống lớn thì phải có HA, nếu em chưa hiểu mô hình HA thì xem lại video gần nhất. Thứ 2 là nếu redis die thì em phải lấy ở DB, việc bảo toàn dữ liệu là phải có
nếu lưu token ở cookies thì khi mình đóng Browser thì cái token đó cũng tự động bị xóa như thế lại phải login lại . có cách nào để sử lý trường hợp này ko ạ
@Tú Nguyễn Văn: "xử lý" em nhé, còn cách thì có, nếu em dùng Chrome (đa phần) thì em vào setting, chọn phần On Start Up, lúc này có thể tùy chọn của em đang là "Open the new tab page" nên khi tắt chrome mở lại nó sẽ clear cookie của em (nếu cookie của em đang chưa set maxAge). Em chọn cái bên dưới "Continue where you let off" là sẽ không bị mất cookie sau mỗi lần đóng hẳn browser nhé. Ngoài ra có thể search cookie trong phần setting xem có phần nào em block cookie các thứ không, nếu đang để mặc định như lúc cài mới browser thì cứ kệ phần này không cần đụng gì.
Cho e hỏi video của a là chỉ xử lý case với web thôi phải ko ạ?. Em từng gặp vấn đề tương tự, khi xử lý Refresh Token trên web + mobile, nên nếu cho cùng hết hạn thì tất cả device đều bị logout hết, và chỉ có 1 thiết bị được login. Nên e thấy trường hợp cho token hết hạn hết là optional như Google/FB hay làm, sẽ có mục Logout all devices cho người dùng. Để fix case này e nghĩ chỉ nên cho expiration time ngắn lại hoặc check info device + ip location
ปีที่แล้ว
Để logout tất cả device cùng lúc thì nên dùng session storage bạn ơi, điểm yếu của jwt là ko thể thu hồi token được, phải chờ hết expire time.
anh toàn nói kiến trúc mà để javascipts tý nữa em bỏ rơi mất những cái hay ho anh nói rồi hic hic :< T.T. Nhờ 1 người bạn giới thiệu anh truyền bà những tư tưởng tà đạo, em đã chửi lộn với nó javasprict có gì mà tà đạo, coi xong em phải xin lỗi nó anh quá là tà đào (")>.
hy vọng clip sau ad nói câu cú nó rõ ràng không ngắt quảng mà liền mạch , và đừng chêm chuyện nhậu nhẹt vào , vì ở đây ngta click vô coi 1 cái Clip ( coi tại nhà hoặc quán cf ) chứ có phải là đang tham gia 1 cái lớp học offline đâu ... ngồi nghe giải thích mà cứ chêm mấy cái linh tinh vào rõ ràng là gây mất thời gian và cũng chả muốn nghe thêm bác giải thích thêm...
Thì cứ out thôi. Lớp học offline người ta đóng tiền nên 100% thời gian phải dùng cho việc dạy kiến thức mới đúng, nói chuyện ngoài lề là đánh cắp thời gian và tiền bạc của người đóng tiền. Còn đây kênh cá nhân, người ta muốn nói gì thì nói, ai thik nghe thì nghe, lên giọng bố đời cái gì?
Không nghe được thì đừng nghe nữa bạn nhé !!! Quan trọng cách người ta giảng dạy bạn có hiểu hay không, ở đây nghiêm túc quá cũng không tốt đâu nha bạn? thoải mái đi bạn ơi !! với bạn mất thời gian nhưng với mọi người thì xứng đáng nhé !!
Về cơ bản lý thuyết của cách này là tạo ra 1 hệ thống cực kì nhạy cảm theo 3 bước:
- Cả RT và AT đều cùng được cấp mới mỗi lần tạo mới AT, và lưu lại RT cũ.
- Một khi RT cũ bị sử dụng lại (không cần phân biệt user hay hacker) thì hủy toàn bộ RT đang hoạt động.
- User đăng nhập lại và lấy RT mới.
@@tathanh203 Vậy nên AT lúc nào cũng để thời gian hết hạn cực kì ngắn đó.
A giải thích rất kỹ và dễ hiểu. Nhưng vấn đề là enduser ko biết = 1 cách nào đó để lộ token thì lần sau có thể vẫn sẽ bị hack tiếp 😀 => Quy trình này sẽ diễn ra liên tục rồi họ chửi hệ thống mình code lởm, cay :))
Điên là chỗ này đây..
Hay quá anh ơi, thanks anh nhiều ạ :)
anh ơi ví dụ khi em Trả RT và AC mới , em chỉ lưu duy nhất những RF token hợp lệ , khi có 1 RF gửi đến không nằm trong ds RF hợp lệ thì em thực hiện thao tác ở hình 7. tư duy vậy đúng chưa ạ.
em nghĩ vẫn không nên để 2 token này đi cùng trong 1 rq tần suất xuất hiện càng ít càng ít nguy cơ bị tấn công, trong trường hợp như này client sẽ phải triển khai cơ chế để chỉ gọi và làm mới token 1 lần đúng không anh, vì nếu client gọi đồng thời nhiều api có thể chính client tạo nhiều rq làm mới token mà sever sẽ detect là token này đang bị ăn cắp :)) mà nếu gửi 2 token cùng 1 lúc thì trong trường hợp nó gửi nhiều rq là thì hệ thống cũng sẽ xoá các token này
12:54 hình số 5 cho em hỏi là nếu hacker yêu cầu làm mới access token bằng refresh token trước cả user hợp lệ nhưng giả sử lúc này user kia offline ( trong khoảng thời gian AT cũ còn hiệu lực) nửa năm không dùng hệ thống nữa thì tức là sẽ không có yêu cầu cấp mới access token nữa, lúc này hacker sẽ dùng AT và RT mới để sử dụng hợp lệ hay sao ạ, vì phải gọi RT cũ lần thứ 2 thì mới phát hiện bất thường
T nghĩ tình huống này chắc phải check cả IP client đăng nhập để gửi thông báo đến email của user quá
@@binhnguyenthanh5279 đr, mình cx đang làm theo cách của b
Mình sử dụng cả máy tính và điện thoại đăng nhập, ví dụ như zalo chẳng hạn thì xử lý như nào ah?
Case check an ninh bảo mật này chỉ là một ví dụ để mọi người hình dùng việc phải control các request từ client để phát hiện truy cập đáng nghi thôi. Còn cụ thể thì nó lại là nghề của đội an toàn thông tin rồi. Cảm ơn anh về 8 bức hình rất dễ hình dung với các bạn mới tiếp xúc với RT.
Bạn nói đúng ý tôi. Một video khó có thể lột tả hết mọi khía cạnh, cho nên chúng ta nên thảo luận thêm. yeah!
Em cảm ơn anh vì video rất hay và dễ hiểu này ạ, kết hợp với code thực chiến trong course E-Commerce là hết bài lun
Bài giảng rất hay, dễ hiểu và tâm huyết. Cảm ơn thầy nhiều
Tâm huyết quá ạ
hay quá anh ơi. e có một câu hỏi thêm là nếu như trong 1 page gọi nhiều api để lấy dữ liệu và phát hiện token hết hạn, thì nó sẽ call đồng thời nhiều api để lấy token mới bằng refresh_token thì như hệ thống anh triển khai nó sẽ có th rơi vào bất thường và sẽ hủy vc lấy token và bắt người dùng xác thưc(đăng nhập) đk ạ. anh cho e cách xử lý với ạ
Tui cũng có thắc mắc giống bạn :> Là tình huống bản thân user spam request nhiều lần lên server với cùng 1 refresh token cũ
Vậy còn trong trường hợp hacker sử dụng refreshToken trước khi hết hạn, và user không sử dụng refreshToken đã hết hạn nữa (thoát web chẳng hạn => không xảy ra hình 7) thì xử lý như thế nào hả a?
Thì phải nâng cao hơn. Cách đây 5 phút trước token này ở HCM, giờ tại thời điểm này ở USA???? Quan trọng ở đây là điểm bất thường.
Khi phát hiện vấn đề hình 6 thì phải destroy hết các resfresh token và user phải login lại đó bạn
@@hienvinhnguyen6729 user login lại khi hệ thống phát hiện refreshToken đã hết hạn được sử dụng lại bạn ơi. Ý mình là khi hacker đánh cắp, và sử refreshToken trước user (refreshToken hợp lệ và chưa hết hạn), và user cũng không sử dụng lại token này nữa (vì lý do thoát web, mất mạng,...).
@@hoanglongvu1538 lúc đó phải kiểm tra lại các yếu tố khác như địa chỉ IP, device id có khớp với lúc đăng nhập không. Nghi ngờ cái đẩy ra trang đăng nhập liền.
@@hoanglongvu1538 mình cũng cùng câu hỏi với bạn. Nếu như vậy thì mình thấy thường sẽ có 1 email hoặc notification về enduser để hỏi rằng đây có chắc chắn là user đó hay ko ? Nhưng mình ko rõ cách triển khai ntn.
ôi video của anh chất lượng thật, rất thực tế
Cảm ơn thầy
Cảm ơn bạn đã đồng hành
Anh cho em hỏi nếu Hacker sử dụng token và làm gì đó trước và gây thiệt hại, sau đó một thời gian user chân chính mới đăng nhập lại và phát hiện thì có phải quá muộn không ?
Có cơ chế phát hiện ra token reuse trong video member. Nhưng không hệ thống nào là an toàn 100% nha em
video có nói về blacklist và whitelíst ở đâu vậy anh ơi, anh có thể cho em xin link với ạ
trong BE ecommerce á em. Hay là chưa?
Ở bước số 5 & 6 nếu hacker request trước và lấy đc RT & AT trước client thì sao a. lúc đấy client mới là thằng ko thao tác đc tiếp =))
Video trong hội viên anh nói cách khắc phục và thực hành luôn rồi nha em
quy trình vẫn vậy mà bạn. User gửi cặp AT, RT lên. Server phát hiện cặp token này đã được sử dụng ---> có gì đó bất thường ---> tiến hành vô hiệu hóa tất cả AT, RT và bắt đăng nhập lại. Lúc này user sẽ đăng nhập được, còn hacker thì không.
Em thấy là RT chỉ tồn tại ở server thôi chứ :D (lúc này, client chỉ đẩy AT lên thôi ạ, check AT mà hết hạn thì cho vào blackList) Bây giờ client lưu cả RT thì nghe vẻ ... anh ạ :)
cái này dùng giải thích thôi.
Vậy thì làm sao để generate ra AT mới nếu ko đẩy RT từ client lên?
RT lưu ở db rồi cần gì client gửi lên nữa
A có đề xuất khoá học nào để trở thành back end nodejs ko a, các khoá học miễn phí trên youtube e thấy lang mang quá
Udemy á em. Có nhiều
anh dạy test bên Backend đi anh ạ. Làm sao biết case nào cần viết, và nhưng case nào nhất định pải viết. Mong a ra seri
Anh có thể cho em hỏi 1 chút, ở gần phút 11:00 anh có bảo khi AT hết hạn thì gọi lên để lấy 1 cặp token mới, như thế em đang hiểu là cả AT và RF đều mới
Như thế thì em đang ko thấy sự khác biệt giữa AT và RT khi đều có time expired bằng nhau, trong khi trên lý thuyết thì RT time expired của nó lâu hơn
Mong anh giải đáp ạ.
Em hỏi đúng đấy. Không sai vì đa số chúng ta đang làm là dựa trên lý thuyết em nói. Nhưng video này là cách phát hiện bất thường của một token. Nên chúng ta phải đảm bảo an toàn dữ liệu. AT hết thời gian, RT còn thời gian chứ không phải ngang nhau. Cơ chế này đã được OAuth2 LIB đã công bố 3 năm trước. Em có thể đọc sâu hơn tại OAuth2. Cảm ơn về câu hỏi của em.
ví dụ AT dài 5 phút, RT dài 1 tháng. Sau 10 ngày bạn vẫn lấy được cặp token mới, nhưng sau 31 ngày thì bắt buộc phải đăng nhập lại, do thời gian đã quá dài, khả năng cao người dùng đã bỏ quên máy tính cả tháng trời nên đăng nhập lại cũng là hợp lý.
Chào anh, anh có thể cho em hỏi một chút là anh hay thấy anh nói anh lưu RT vào trong Redis. Trong trường hợp Redis có sự cố sự thì toàn bộ RT đã lưu sẽ bị mất hết, vậy thì làm sao người dùng có thể tạo mới lại RT anh nhỉ. Đến lúc đó phải bắt buộc người dùng phải đăng nhập lại hay có cơ chế gì phục hồi Redis không anh nhỉ. Mong anh giải đáp ạ!
Câu hỏi rất hay: Nhưng redis chỉ là một cache trung gian, hệ thống lớn thì phải có HA, nếu em chưa hiểu mô hình HA thì xem lại video gần nhất. Thứ 2 là nếu redis die thì em phải lấy ở DB, việc bảo toàn dữ liệu là phải có
@@anonystick Dạ em cảm ơn anh đã giải đáp ạ!
extension a dùng để vẽ hình là gì vậy a
Epic em
nếu lưu token ở cookies thì khi mình đóng Browser thì cái token đó cũng tự động bị xóa như thế lại phải login lại . có cách nào để sử lý trường hợp này ko ạ
Cookie có thời gian hết hạn, chứ không phải close là mất đâu em. Nhưng về BANK thì tầm 15 giây mà không action thì login lại thì có.
@@anonystick vâng em cảm ơn. ơ mà anh check lại video về jwt anh nên cho vào danh sách phát của khóa nodejs để tiện cho mọi người thep giõi ạ
@Tú Nguyễn Văn: "xử lý" em nhé, còn cách thì có, nếu em dùng Chrome (đa phần) thì em vào setting, chọn phần On Start Up, lúc này có thể tùy chọn của em đang là "Open the new tab page" nên khi tắt chrome mở lại nó sẽ clear cookie của em (nếu cookie của em đang chưa set maxAge). Em chọn cái bên dưới "Continue where you let off" là sẽ không bị mất cookie sau mỗi lần đóng hẳn browser nhé.
Ngoài ra có thể search cookie trong phần setting xem có phần nào em block cookie các thứ không, nếu đang để mặc định như lúc cài mới browser thì cứ kệ phần này không cần đụng gì.
@@trungquandev ok cảm ơn anh nhiều
@@trungquandev em để open the new tab page mà cookie vẫn còn ạ, ko biết là anh đang nói tới session cookie hay expire cookie ạ
Cho e hỏi video của a là chỉ xử lý case với web thôi phải ko ạ?. Em từng gặp vấn đề tương tự, khi xử lý Refresh Token trên web + mobile, nên nếu cho cùng hết hạn thì tất cả device đều bị logout hết, và chỉ có 1 thiết bị được login.
Nên e thấy trường hợp cho token hết hạn hết là optional như Google/FB hay làm, sẽ có mục Logout all devices cho người dùng. Để fix case này e nghĩ chỉ nên cho expiration time ngắn lại hoặc check info device + ip location
Để logout tất cả device cùng lúc thì nên dùng session storage bạn ơi, điểm yếu của jwt là ko thể thu hồi token được, phải chờ hết expire time.
Phần mềm vẽ anh dùng là gì cho e xin với ạ?
Draw.io nha em
@@anonystick Không, ý e hỏi cái phần mềm a vẽ ảnh như paint ấy ạ. A dùng để khoanh khoanh vẽ ấy ạ
@@duyhoangta7988 À, anh hiểu. Epic nha em
@@anonystick Em cám ơn ạ
em cảm ơn
Quá hay
anh toàn nói kiến trúc mà để javascipts tý nữa em bỏ rơi mất những cái hay ho anh nói rồi hic hic :< T.T. Nhờ 1 người bạn giới thiệu anh truyền bà những tư tưởng tà đạo, em đã chửi lộn với nó javasprict có gì mà tà đạo, coi xong em phải xin lỗi nó anh quá là tà đào (")>.
hà hà, comment của em cũng tà đạo nha.
Chúng ta có thể khai thác được bất kỳ hệ thống nào nếu chúng ta hiểu rõ cách vận hành của hệ thống đó.
Anh triển khai thành code đi ạ
"Mẹ của anh thì nói không" =))
trình bày dài dòng
hy vọng clip sau ad nói câu cú nó rõ ràng không ngắt quảng mà liền mạch , và đừng chêm chuyện nhậu nhẹt vào , vì ở đây ngta click vô coi 1 cái Clip ( coi tại nhà hoặc quán cf ) chứ có phải là đang tham gia 1 cái lớp học offline đâu ... ngồi nghe giải thích mà cứ chêm mấy cái linh tinh vào rõ ràng là gây mất thời gian và cũng chả muốn nghe thêm bác giải thích thêm...
Có lẽ văn phong của tôi không hợp với Cậu.
Thì cứ out thôi. Lớp học offline người ta đóng tiền nên 100% thời gian phải dùng cho việc dạy kiến thức mới đúng, nói chuyện ngoài lề là đánh cắp thời gian và tiền bạc của người đóng tiền. Còn đây kênh cá nhân, người ta muốn nói gì thì nói, ai thik nghe thì nghe, lên giọng bố đời cái gì?
@@trangiang4127 Đanh đá :v
Không nghe được thì đừng nghe nữa bạn nhé !!! Quan trọng cách người ta giảng dạy bạn có hiểu hay không, ở đây nghiêm túc quá cũng không tốt đâu nha bạn? thoải mái đi bạn ơi !! với bạn mất thời gian nhưng với mọi người thì xứng đáng nhé !!
không coi thì té chỗ khác thôi, đã coi chùa còn ý kiến