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ủ.

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?

hay anh ơi

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

@anonystick

Жыл бұрын

Anh hay đọc về gia đình vac hack news á em

Cám ơn a đã chia sẻ ạ! A ở HN hay HCM vậy ? a ra video Q&A đi ạ.

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 ?

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 ạ

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

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 đó ạ

@anonystick

Жыл бұрын

Uhm để anh bỏ lại cho đúng hén

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.

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.

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?

@anonystick

Жыл бұрын

Riêng em ơi. Chỗ đó để check reuse token nữa

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ỉ

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 ạ

@ADmDinhLuan909

Жыл бұрын

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 đủ

@truongkhang9926

11 ай бұрын

mình phân quyền trong config

em có thấy trên npm crypto trở thành thư viện built in của nodejs rồi

@anonystick

Жыл бұрын

Đúng rồi em!

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ỉ ?

@anhhoang7259

24 күн бұрын

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

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 ạ ?

@anonystick

Жыл бұрын

Socket or firebase nha em

@duyngo8608

Жыл бұрын

@@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

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.

@anonystick

Жыл бұрын

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...

A cho em hỏi làm thế nào để có cái recommend flags dưới terminal thế ạ.

@anonystick

Жыл бұрын

Fig nha em. Em search là thấy à

@nguyenthien720

Жыл бұрын

@@anonystick E làm được rồi. Cảm ơn a, ông lead nhìn lé mắt :)))

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?

@PawsPet.entertainment

Жыл бұрын

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ì

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

@anonystick

Жыл бұрын

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

@nuro14

Жыл бұрын

mình nghĩ là sẽ verify refresh token cũ với public key cũ, rồi sau đó tạo cặp key mới

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?

@anonystick

Жыл бұрын

Đúng em, về nguyên tắc khi em login thì phải cấp một pair token. Luôn là vậy.

@VuNguyen-hp8wn

Жыл бұрын

Cám ơn a

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 ạ

@anonystick

3 ай бұрын

Hay đấy. Để anh nếu ý kiến của anh hen

@inhvuvan5598

3 ай бұрын

@@anonystick dạ e cảm ơn ngồi hóng video của 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

@panadora_crewmate

Жыл бұрын

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

@Y-Nhu-Van-Su

8 ай бұрын

@@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

@panadora_crewmate

8 ай бұрын

​@@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.

@Y-Nhu-Van-Su

8 ай бұрын

@@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 .

@panadora_crewmate

8 ай бұрын

@@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 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.

@tieuyeuht91

Жыл бұрын

Private key tạo xong là bỏ luôn bạn, không cần lưu đâu hết.

@ManhTran-nw7ef

Жыл бұрын

@@tieuyeuht91 k lưu thì hash quần què

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

7 ай бұрын

Lấy được keySecret thì hacker có thể tuỳ ý tạo accesstoken để đăng nhập bất cứ lúc nào

@hautran7559

7 ай бұрын

@@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

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

@tieuyeuht91

Жыл бұрын

1. user không cầm private key.

@tieuyeuht91

Жыл бұрын

2. Verify thì ok, ở đây là chống không cho tạo token để access vào các API đó

@tuantech9943

9 ай бұрын

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

@atNguyen-cw1oh

6 ай бұрын

​@@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

@atNguyen-cw1oh

6 ай бұрын

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 😅😅😅

Làm thế nào để phát hiện rò rỉ token a ơi

@anonystick

Жыл бұрын

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.