JWT thì anh không thể dùng từ đóng hộp và mở hộp được, vì payload của jwt ai cũng có thể đọc được, public key ở đây chỉ dùng để check để chắc chắn dữ liệu này là của private key đó tạo và nó chỉ đảm bảo là chưa bị thay đổi từ lúc nó được tạo ra, hay nói đơn giản là nó là chính chủ.
Cám ơn anh đã chia sẻ. Theo em hiểu là khi người dùng login sẽ phải tiến hành call api đăng kí để lấy pair key, lấy pair key đó mới call api login lấy token đúng không anh ?
Cám ơn anh nhiều. Dạ như anh đã chia sẽ thì public key sẽ lưu trong DB, vậy cho em hỏi là public key sẽ được lưu trong User collection hay một collection riêng cho public key vậy anh?
Có 2 vấn đề trong demo mong anh giải đáp: - private key và public key của anh sinh ra xong sẽ lưu vào đâu và lưu ntn để bảo mật - làm sao server biết được key nào của user nào
theo phân tích của mình sẽ là, lưu với token và public đã được JWT sign bất đối xứng và PublicKey của Crypto vừa đc gen ra. Thì lúc này khi gửi token lên server đối chiếu từ db, lúc này db sẽ tìm token đó và đồng thời get luôn cái publickey sau đó đi verify và trả result về browser user p/s: điều mình quan tâm ở video là cái publicKey vs privateKey nó ko phải dạng chuỗi, nên làm sao để lưu ở db
@@panadora_crewmate mình hỏi chút , vậy ban đầu ng dùng login tk và mk , thì hệ thống sẽ dựa vào đâu để phân biệt đúng hay sao để tạo token , và nếu hacker chiếm dc bảng user thì lúc này mấy key kia liệu quan trọng nữa k
@@Y-Nhu-Van-Su mình vẫn chưa hiểu câu hỏi của bạn, thì BE dựa vào Database chứa table user đã reg trước đó để check xem người dùng họ đang login vào TK nào sau đó Server sẽ regener 1 cặp token lưu vào table token với id người dùng đó để check đồng thời trả về client cái publickey, client chỉ việc quăn cái publickey lên headers request để server check publickey đó có trong db không và của id nào đã lưu và kiểm tra.
@@panadora_crewmate nhưng theo như video thì mục đích của việc sinh ra token dựa vào publickey và privatekey là để bảo mật , mình vẫn chưa hiểu chỗ này , vì khi hacker vào được database rồi , nó sẽ đi thẳng tới bảng user chứ quan tâm làm gì mấy cái key đó nữa .
@@Y-Nhu-Van-Su à tức là hacker chiếm quyền kiểm soát database, thì cái đấy là do bên BE setup truy vấn lỏng lẻo ko có 1 phương thức ràng buộc về đầu vào để hacker inject SQL thì cái đấy toan thôi, chỉ có nước mà trông chờ backup lại thôi, như bác nào đó đã tắt Server vì lộ config đó, còn Video này đang hướng đến là bảo mật thông tin người dùng khi đăng nhập từ browser để request lên server, còn vấn đề bạn đang nói đến là lỗ hổng bảo mật SQL bên Server. Còn về cái tiêu đề có thể là do hiểu sai, nếu mình ko nhầm thì kiểu đang nhắt tới vấn đề là hacker chiếm được cả publickey vs private của 1 người dùng, cái này thì chỉ có nước yêu cầu admin remove căp key đó đi để chặn truy câp
Anh hôm nào ra chủ đề xử lý permission có độ phức tạp lớn đi anh , tại em thấy vấn đề hầu như dự án nào cũng hay gặp , và em cũng đang gặp 😄 , Em có 1 bảng permission gòm như sau : role : admin , user ,usevip ,user pro , ... , tiếp đến là screen1,screen2 có rất nhiều screen và muốn có quyền vào screen thì phải có quyền đọc , của screen đó , tiếp đến là các quyền thêm xóa sửa . vậy thiết kế sao hiệu quả nhất ạ
Giả sử 1 ng dùng phần mềm trung gian theo dõi trong mạng tất cả các gói tin, kể cả gói tin lúc đăng nhập phá đc ssl và lấy pwd đã mã hoá rsa, nên các kịch bản về access token và fresher token, key đều bị hacker nắm hết , nếu có kịch bạn vậy thì xử lí thế nào anh, em thấy bên ngân hàng phát cho các đại gia 1 thiết bị riêng chứa cặp key rsa của server và clien , có cách khác nào giải quết triệt để bị nghe lén này ko anh
Mỗi user là sẽ có private key và public key riêng của nó. Chỉ lưa public key, khi hacker có public key nó sẽ không dùng để tạo được jwt của nó, trong khi mã hoá đối xứng hacker có thể dùng secretKey tạo jwt sau đó khai thác dữ liệu.
vậy nếu mỗi user sẽ có 1 cặp public, private key. thì khi 1 user A request, gửi token lên thì server làm sao biết dc token đó là của thằng A mà verify anh nhỉ ?
Public key được lưu lại (có thể ở db). Khi A gửi request kèm token thì hệ thống móc public key ra verify. Token có thể có thời gian sống nhất định (vd 1h), sau thời gian đó token sẽ expired. User phải login lại để tạo token mới hoặc hệ thống có cách để refresh lại token
Em đang hiện thực cả refreshToken, tuy nhiên khi gọi đến api /token để cấp lại accessToken và refreshToken mới thì cũng sẽ cần private key nhưng private key chỉ tồn tại khi thực hiện login và mất nên em không thể tạo ra 2 token mới nữa, vậy có cách nào giải quyết vấn đề này không ạ mong anh giải đáp ạ. Chỉnh sửa: Em cũng đã tham khảo thì người ta nói cặp key này tồn tại lâu nên em không chọn cách tạo mới 2 cặp key này nữa.
Theo lý thuyết anh nói thì có hai khóa là privateKey và publicKey. - privateKey để cho thằng user - publicKey để lưu vào db mà khi verify thì chỉ cần publicKey và token và theo cmt ở dưới của anh nói thì mỗi khi đăng nhập thì sẽ tạo một cặp key mới => có 2 vấn đề xảy ra là: 1. Nếu thằng user cầm cái privateKey thì khi gửi token lên server làm sao thằng server nhận dạng được đó là thằng user nào để lấy cái publicKey ra để verify. Vậy thì cái privateKey đưa thằng user sẽ giải quyết được gì ? 2. Theo như video thì thằng privateKey nó chỉ làm nhiệm vụ là tạo token và thằng publicKey mới làm nhiệm vụ là verify. Vậy thì thằng hacker nó lấy được cái publicKey thì nó cũng verify được đó thôi, cần gì đến privateKey trong lúc verify
Xác định người dùng thì quá đơn giản, hầu như đã dùng JWT đều biết, trong payload có userid mà. privatekey dùng để sign token... Chỉ sign được thôi nhé. Mỗi token thì sẽ chỉ có một cặp private/public key để verify nhau mà thôi. Nên hacker có lấy được, verify được thì trong thời gian sống của token (dưới 5 giây) thì làm được gì. Khi hết hạn thì server tạo căp key mới để refresh rồi thì dĩ nhiên thằng hacker cũng xanh mặt
@@tuantech9943sao mà xác định user từ payload được ông, muốn lấy được payload của JWT thì ông phải verify nó bằng public key, mà public key thì nó lưu trong db, và lấy ra bằng user id, nên trường hợp này phải gửi thêm user id ở ngoài nữa ông à, từ đó mới lấy được public key, rồi mới đi verify token được
Trường hợp này chắc chỉ có xác nhận user thông qua token thôi, sau khi gen ra public key với token thì lưu cả 2 vô db, ông user ổng gửi token xuống thì cầm token đó đi query db để lấy public key rồi verify token, còn muốn xác nhận kỹ hơn nữa thì sau khi verify lấy được cái user id từ payload, rồi cầm user id query tiếp db để lấy cái public key để so sánh 😅😅😅
Em chào anh, em có suy nghĩ thế này ạ, cách sử dụng private key và public key có thể bảo mật được trong trường hợp hacker không có quyền ghi vào db, nếu hacker có quyền ghi vào db thì họ có thể thay thế public key bằng public key do hacker tạo ra thì sẽ verify OK cho jwt mà hacker tạo ra bằng private key của hacker. Còn việc lưu private key vào client thì em chưa rõ mục đích để làm gì vì việc sign và verify đều diễn ra ở server.
Anh ơi cho em hỏi, tại sao hacker lấy được key secret thì lại toang vậy anh, ko có token thì cũng ko verify được đúng ko anh. Anh có thể ví dụ em một số trường hợp bị attack không anh
@@truongnguyenthanh3609 nhưng mình còn verify check payload xem đúng user hay không nữa mà, chứ chính chủ user thì có accessToken và đăng nhập nhiều lần thì có vấn đề gì không bạn
JWT thì anh không thể dùng từ đóng hộp và mở hộp được, vì payload của jwt ai cũng có thể đọc được, public key ở đây chỉ dùng để check để chắc chắn dữ liệu này là của private key đó tạo và nó chỉ đảm bảo là chưa bị thay đổi từ lúc nó được tạo ra, hay nói đơn giản là nó là chính chủ.
cám ơn admin chia sẻ, admin làm thêm clip review sách, nguồn tham khảo mà admin hay dùng, tâm đắc, thấy hay với, thanks
Anh hay đọc về gia đình vac hack news á em
Cảm ơn các kiến thức a chia sẻ, e có ý kiến tí là e thấy trong danh sách phát của a có nhiều clip này để nhầm qua danh sách phát khác đó ạ
Uhm để anh bỏ lại cho đúng hén
Cám ơn anh đã chia sẻ. Theo em hiểu là khi người dùng login sẽ phải tiến hành call api đăng kí để lấy pair key, lấy pair key đó mới call api login lấy token đúng không anh ?
Cám ơn a đã chia sẻ ạ! A ở HN hay HCM vậy ? a ra video Q&A đi ạ.
Cám ơn anh nhiều. Dạ như anh đã chia sẽ thì public key sẽ lưu trong DB, vậy cho em hỏi là public key sẽ được lưu trong User collection hay một collection riêng cho public key vậy anh?
Riêng em ơi. Chỗ đó để check reuse token nữa
Có 2 vấn đề trong demo mong anh giải đáp:
- private key và public key của anh sinh ra xong sẽ lưu vào đâu và lưu ntn để bảo mật
- làm sao server biết được key nào của user nào
theo phân tích của mình sẽ là, lưu với token và public đã được JWT sign bất đối xứng và PublicKey của Crypto vừa đc gen ra.
Thì lúc này khi gửi token lên server đối chiếu từ db, lúc này db sẽ tìm token đó và đồng thời get luôn cái publickey sau đó đi verify và trả result về browser user
p/s: điều mình quan tâm ở video là cái publicKey vs privateKey nó ko phải dạng chuỗi, nên làm sao để lưu ở db
@@panadora_crewmate mình hỏi chút , vậy ban đầu ng dùng login tk và mk , thì hệ thống sẽ dựa vào đâu để phân biệt đúng hay sao để tạo token , và nếu hacker chiếm dc bảng user thì lúc này mấy key kia liệu quan trọng nữa k
@@Y-Nhu-Van-Su mình vẫn chưa hiểu câu hỏi của bạn, thì BE dựa vào Database chứa table user đã reg trước đó để check xem người dùng họ đang login vào TK nào sau đó Server sẽ regener 1 cặp token lưu vào table token với id người dùng đó để check đồng thời trả về client cái publickey, client chỉ việc quăn cái publickey lên headers request để server check publickey đó có trong db không và của id nào đã lưu và kiểm tra.
@@panadora_crewmate nhưng theo như video thì mục đích của việc sinh ra token dựa vào publickey và privatekey là để bảo mật , mình vẫn chưa hiểu chỗ này , vì khi hacker vào được database rồi , nó sẽ đi thẳng tới bảng user chứ quan tâm làm gì mấy cái key đó nữa .
@@Y-Nhu-Van-Su à tức là hacker chiếm quyền kiểm soát database, thì cái đấy là do bên BE setup truy vấn lỏng lẻo ko có 1 phương thức ràng buộc về đầu vào để hacker inject SQL thì cái đấy toan thôi, chỉ có nước mà trông chờ backup lại thôi, như bác nào đó đã tắt Server vì lộ config đó, còn Video này đang hướng đến là bảo mật thông tin người dùng khi đăng nhập từ browser để request lên server, còn vấn đề bạn đang nói đến là lỗ hổng bảo mật SQL bên Server.
Còn về cái tiêu đề có thể là do hiểu sai, nếu mình ko nhầm thì kiểu đang nhắt tới vấn đề là hacker chiếm được cả publickey vs private của 1 người dùng, cái này thì chỉ có nước yêu cầu admin remove căp key đó đi để chặn truy câp
em có thấy trên npm crypto trở thành thư viện built in của nodejs rồi
Đúng rồi em!
anh ơi có cách thanh toán nào khác cho khoá ecommerce ngoài thanh toán qua thẻ tín dụng ko ạ
Cho e hỏi 1 số thắc mắc?
1. Tại sao public key lại cần save vào db?
2. Private key lại đưa cho người dùng?
public key chỉ có mục đích verify nên hacker hack được vào db và lấy được thì cũng không để làm gì
mới đây đang hot vụ mất tài khoản youtobe email a nói thêm về bảo mật của các ứng dụng lớn này đi ạ làm sao mà các hacker có thể giả mạo chủ tài khoản được ạ
Hay đấy. Để anh nếu ý kiến của anh hen
@@anonystick dạ e cảm ơn ngồi hóng video của a ạ
Anh hôm nào ra chủ đề xử lý permission có độ phức tạp lớn đi anh , tại em thấy vấn đề hầu như dự án nào cũng hay gặp , và em cũng đang gặp 😄 , Em có 1 bảng permission gòm như sau : role : admin , user ,usevip ,user pro , ... , tiếp đến là screen1,screen2 có rất nhiều screen và muốn có quyền vào screen thì phải có quyền đọc , của screen đó , tiếp đến là các quyền thêm xóa sửa . vậy thiết kế sao hiệu quả nhất ạ
bác tham khảo của thằng opensource này thử: nopcommerce ...Mấy cái ý bạn thắc mắc thằng này nó xử lý khác đầy đủ
mình phân quyền trong config
hay anh ơi
Giả sử 1 ng dùng phần mềm trung gian theo dõi trong mạng tất cả các gói tin, kể cả gói tin lúc đăng nhập phá đc ssl và lấy pwd đã mã hoá rsa, nên các kịch bản về access token và fresher token, key đều bị hacker nắm hết , nếu có kịch bạn vậy thì xử lí thế nào anh, em thấy bên ngân hàng phát cho các đại gia 1 thiết bị riêng chứa cặp key rsa của server và clien , có cách khác nào giải quết triệt để bị nghe lén này ko anh
Ko lưu private key vậy khi user khác đăng nhập thì lấy private key ở đâu để sinh token cho user mới login này?
Mỗi user là sẽ có private key và public key riêng của nó. Chỉ lưa public key, khi hacker có public key nó sẽ không dùng để tạo được jwt của nó, trong khi mã hoá đối xứng hacker có thể dùng secretKey tạo jwt sau đó khai thác dữ liệu.
access_token sinh ra tại server, vậy người dùng giữ kiểu gì. Server ko có thì lấy gì mà tạo token.
Hay tuyệt.
Anh ơi làm thế nào để message cho ng dùng như cách google thông báo ai đó like bài viết ạ ?
Socket or firebase nha em
@@anonystick Trc e có sử dụng socketio nhưng khi chạy nhiều instant = pm2 thì nó bị lỗi vì ko biết connect đến ID client nào.
pm2 start ???.js -i 4
bài toàn này giải quyết hay nhưng mà chỉ dùng có 1 user/ 1 device thôi nhỉ
vậy nếu mỗi user sẽ có 1 cặp public, private key. thì khi 1 user A request, gửi token lên thì server làm sao biết dc token đó là của thằng A mà verify anh nhỉ ?
Public key được lưu lại (có thể ở db). Khi A gửi request kèm token thì hệ thống móc public key ra verify. Token có thể có thời gian sống nhất định (vd 1h), sau thời gian đó token sẽ expired. User phải login lại để tạo token mới hoặc hệ thống có cách để refresh lại token
Em đang hiện thực cả refreshToken, tuy nhiên khi gọi đến api /token để cấp lại accessToken và refreshToken mới thì cũng sẽ cần private key nhưng private key chỉ tồn tại khi thực hiện login và mất nên em không thể tạo ra 2 token mới nữa, vậy có cách nào giải quyết vấn đề này không ạ mong anh giải đáp ạ.
Chỉnh sửa: Em cũng đã tham khảo thì người ta nói cặp key này tồn tại lâu nên em không chọn cách tạo mới 2 cặp key này nữa.
A cho em hỏi làm thế nào để có cái recommend flags dưới terminal thế ạ.
Fig nha em. Em search là thấy à
@@anonystick E làm được rồi. Cảm ơn a, ông lead nhìn lé mắt :)))
Nếu chỉ lưu lại public key, thì sử dụng với refresh token như thế nào vậy ạ ? Cảm ơn anh nhiều
Câu hỏi quá hay. Lý thuyết là vậy nhưng lưu vào db với rsa không phải đơn giản
mình nghĩ là sẽ verify refresh token cũ với public key cũ, rồi sau đó tạo cặp key mới
Mình đang thắc mắc là nếu public key mình lưu vào database thì việc mình lấy nó ra sẽ ảnh hưởng performace như thế nào.
Phải đánh đổi em ơi. Không có hệ thống nào 100% hoàn hảo. Nếu Bank thì ưu tiên bảo mật, nếu social thì ưu tiên nhanh...
Theo lý thuyết anh nói thì có hai khóa là privateKey và publicKey.
- privateKey để cho thằng user
- publicKey để lưu vào db
mà khi verify thì chỉ cần publicKey và token
và theo cmt ở dưới của anh nói thì mỗi khi đăng nhập thì sẽ tạo một cặp key mới
=> có 2 vấn đề xảy ra là:
1. Nếu thằng user cầm cái privateKey thì khi gửi token lên server làm sao thằng server nhận dạng được đó là thằng user nào để lấy cái publicKey ra để verify. Vậy thì cái privateKey đưa thằng user sẽ giải quyết được gì ?
2. Theo như video thì thằng privateKey nó chỉ làm nhiệm vụ là tạo token và thằng publicKey mới làm nhiệm vụ là verify. Vậy thì thằng hacker nó lấy được cái publicKey thì nó cũng verify được đó thôi, cần gì đến privateKey trong lúc verify
1. user không cầm private key.
2. Verify thì ok, ở đây là chống không cho tạo token để access vào các API đó
Xác định người dùng thì quá đơn giản, hầu như đã dùng JWT đều biết, trong payload có userid mà.
privatekey dùng để sign token... Chỉ sign được thôi nhé. Mỗi token thì sẽ chỉ có một cặp private/public key để verify nhau mà thôi. Nên hacker có lấy được, verify được thì trong thời gian sống của token (dưới 5 giây) thì làm được gì. Khi hết hạn thì server tạo căp key mới để refresh rồi thì dĩ nhiên thằng hacker cũng xanh mặt
@@tuantech9943sao mà xác định user từ payload được ông, muốn lấy được payload của JWT thì ông phải verify nó bằng public key, mà public key thì nó lưu trong db, và lấy ra bằng user id, nên trường hợp này phải gửi thêm user id ở ngoài nữa ông à, từ đó mới lấy được public key, rồi mới đi verify token được
Trường hợp này chắc chỉ có xác nhận user thông qua token thôi, sau khi gen ra public key với token thì lưu cả 2 vô db, ông user ổng gửi token xuống thì cầm token đó đi query db để lấy public key rồi verify token, còn muốn xác nhận kỹ hơn nữa thì sau khi verify lấy được cái user id từ payload, rồi cầm user id query tiếp db để lấy cái public key để so sánh 😅😅😅
Em chào anh, em có suy nghĩ thế này ạ, cách sử dụng private key và public key có thể bảo mật được trong trường hợp hacker không có quyền ghi vào db, nếu hacker có quyền ghi vào db thì họ có thể thay thế public key bằng public key do hacker tạo ra thì sẽ verify OK cho jwt mà hacker tạo ra bằng private key của hacker. Còn việc lưu private key vào client thì em chưa rõ mục đích để làm gì vì việc sign và verify đều diễn ra ở server.
Private key tạo xong là bỏ luôn bạn, không cần lưu đâu hết.
@@tieuyeuht91 k lưu thì hash quần què
E muốn hỏi là nếu mình gửi private key cho người dùng thì bên client sẽ lưu như nào ạ? Mỗi lần login mình sẽ tạo ra 1 cặp key mới hay sao?
Đúng em, về nguyên tắc khi em login thì phải cấp một pair token. Luôn là vậy.
Cám ơn a
Làm thế nào để phát hiện rò rỉ token a ơi
Lý thuyết nói rồi em. còn thực hành thì trong hội viên có backend ecommerce hoàn chỉnh.
Anh ơi cho em hỏi, tại sao hacker lấy được key secret thì lại toang vậy anh, ko có token thì cũng ko verify được đúng ko anh. Anh có thể ví dụ em một số trường hợp bị attack không anh
Lấy được keySecret thì hacker có thể tuỳ ý tạo accesstoken để đăng nhập bất cứ lúc nào
@@truongnguyenthanh3609 nhưng mình còn verify check payload xem đúng user hay không nữa mà, chứ chính chủ user thì có accessToken và đăng nhập nhiều lần thì có vấn đề gì không bạn