E đang làm 1 dự án thực tế và đang áp dụng cách này , client em viết bằng vuejs và em đang băn khoăn 1 điều là thuật toán tạo chữ kí có thể bị đọc , anh có thể chia sẻ 1 thư viện dùng để Obfuscate đoạn js này để làm khó khăn cho hacker trong việc dò ra cách tạo chữ kí dưới client của mình được không anh ? Cám ơn anh
em ko hiểu phần nói về chữ kí của anh là đang giải quyết vấn đề replay attack hay middle man attack vì phần mã hóa dữ liệu đã có ssl lo >> cái chữ kí anh nói em thấy hơi thừa em thấy cốt lõi của cái chữ kí chính là thuật toán mã hóa/giải mã , => nếu hacker đang ở middle thì ko thể đọc đc dữ liệu >> chả cần chữ kí như anh cho phức tạp, vì đã có ssl lo => nếu hacker lúc này đóng vai trò là enduser, lúc này họ nắm giữ thuật toán mã hóa thì họ làm gì chả đc ,cái này tùy trình độ, nhưng về lý thuyết thì họ hoàn toàn có thể tự tạo request và mã hóa bằng cái chữ kí kia >> cái giải pháp anh đưa ra có lẽ để làm khó khăn thôi chứ ko phải là giải quyết vấn đề, chống spam api từ phía end user p/s : em thấy phần câu hỏi đưa ra có hơi hướng là muốn ngăn người dùng tự tạo request để viết bot/auto , nên em nghĩ ko có giải pháp nào cho cái việc ngăn enduser viết bot/auto cả, chỉ có làm họ khó khăn trong việc tìm hiểu thôi
Cảm ơn bạn đã đặt câu hỏi. Video tói đây sẽ giải đáp cho bạn hai câu hỏi chính "mã hóa và sign khác nhau thế nào?" và "Các trao đổi keySecret không qua internet..."
do sử dụng redis phải cần có server (tốn kém) để lưu lại thì em đang sử dung JWT và check thêm IP máy nữa thì có thay thế cái Nonce được không anh, em cảm ơn anh.
dùng nonce có chú ý đến bộ nhớ ko anh? vì mỗi ngày cả triệu request, lưu hoài lưu mãi cho chết bộ nhớ à anh, đó là server web, chứ server app hoặc game, gửi request dạng tcp , thì cả trăm triệu packet được gửi đi nên em nghĩ phải có kĩ thuật khác tốt hơn nonce chứ nhỉ vd: em làm 1 con game , có packet là cộng tiền, nó sài replay để hack cộng tiền, đặc thù của game là nó sài kết nối bền vững tcp , nên có thể trong 1phut lượng request giữa client và server là rất lớn (vd: 1000) , chưa kể có thể có cả nghìn chục nghìn account cùng hoạt động trên server , thì tốn rất nhiều bộ nhớ, cứ cho là anh sẽ xóa bộ nhớ để chứa key đi sau mỗi 1 phut, thì việc xử lý xóa đồng thời nhiều thread cùng xóa như vậy cũng tốn nhiều tài nguyên và thời gian
99/00 was sotNice tutorialng called Vision DSP or DST or sotNice tutorialng and didn't quite work the way soft soft does, but tNice tutorials video helped so
@@anonystick xem video theo hiểu là cái private key đó phải lưu ở client và server mà client là react chẳng hạn làm SPA, thì tải toàn bộ source về trình duyệt bao gôm luôn private key
@nhan Vâng! Tải toàn bộ source là lộ hết. Nguy hiểm quá. Do đồng chí không xem hết video cũng như các video trước. Nếu hệ thống của bạn đơn giản thì có thể sử dụng "hmac hashed signature". Ngược lại, nếu là findtech thì phức tạp hơn và đặt những câu hỏi sau? Đồng chí nhận key khi nào? Ai được phép phép cấp key? Và key được cấp chung cho toàn bộ user hay sao? Và mỗi ip đều sinh ra một key?? Xem lại đoạn cuối video. Thêm nữa cho bạn là . Key được nhúng trong chứng chỉ đã được ký điện tử bởi tổ chức phát hành chứng chỉ được công nhận để đảm bảo rằng đó là khóa hợp pháp được tạo bởi người nhận dự kiến (CA). Nếu chưa biết CA vui lòng sử dụng Mr. Google. Và điều quan trọng tất cả mọi thứ đều không an toàn 100%. Tks
anh ơii ! cho em hỏi là mình có thể sài redis làm database tạm đc không , như là những vấn đề update data thường xuyên nhưng vẫn sử dụng redis, và chạy cron cuối ngày update ngược lại vào data chính
Hi anh. Em đang tìm hiểu về cơ chế tách hệ thống lớn thành các hệ thông con. A có thể cho em xin vài đường quyền giải quyết vụ này không? Cụ thể Input e cần giải quyết như sau: Input: Người dùng khi vào 1 subdomain thì nó sẽ kiểm tra tài khoản đó có quyền được truy xuất đến database nào. Nếu họ có dùng account đó vào subdomain khác thì sẽ báo ko có quyền truy cập. Hoặc củng có trường hợp 1 tài khoản vào được đến 2-3 subdomain. Em bản chất em đang muốn clone database riêng biệt nhưng chức năng vẫn trên 1 source. Mong anh giúp đỡ, em cảm ơn anh.
@@anonystick ước gì được anh chỉ giáo.. có mà sướng run người 🤣. Em củng tìm hiểu theo hướng proxy config và authen DB mà vẫn chưa rõ cách hoạt động chính xác là như nào
@@anonystick ak với 1 cái nữa a ơii. Mấy keywords nào tiếng anh, anh có thể ghi thêm scripts cho nó không anh. Em nghe cách đọc được nhưng mà spell ra như thế nào để search em vẫn chưa spell ra được từ đó
Em thắc mâc là cái key mình để ở client, nó đọc được source nên lộ key ra, nó hiểu đc cơ chế tạo ra cái chữ ký mình nên nó cũng sẽ giả đc chữ ký. Em cũng đang viết api cho bên game unity, cũng đang tìm hiểu cách làm sao chặn request ko đến từ game mà đến từ postman hoặc tool gì đó. Hiện tại e cũng làm hơi giống anh một tí là để logic tạo key ở phía client (Ingmame) nên cũng nghĩ là bọ nó sẽ decode game ra đọc đc cách tạo ra cái key này. Còn logic sinh key thì em dùng jwt, mỗi khi gọi api thì ở dưới client sinh ra key dựa vào secret key và có tgian hết hạn 30bs, trên backemd sẽ validate dựa vào secret key. Nói chung secret key đang bỏ cả backend và client nên em nghĩ nếu bọn mó.muốn hack thì sẽ tìm đc cái key này. Anh có góp ý gì cho em không ạ? Cảm ơn anh với những video bổ ích ạ.
@@TungNguyen-wy7dz vậy có sợ hacker nó cũng gọi api lấy key không ạ? em chỉ làm ở mức bình thường chứ cũng ko phưc tạp như kiểu zalo hay video anh nói về cơ chế e2e ấy ạ.
Hello bạn, theo kiến thức của mình với bên Android thì hdh sẽ có các api để quản lý key riêng và nó thuộc về hdh an toàn hay không là do thiết bị cũng như các lỗ hổng của android. Bên web cũng tương tự như vậy, key do browser quản lý vì vậy nếu bạn làm đúng theo các case study của web hoặc android thì dù hacker có khai thác được source code cũng không thể nào biết được key của các người dùng khác. Thứ hai về chữ kí số thì thường người ta sẽ dùng mã hóa bất đối xứng ( asymmetric cryptography) để mã. Bạn có thể tìm hiểu thêm về mã hóa bđ xứng và chữ ký số. Còn về việc hacker gọi được api lấy key hay không thì nếu api của bạn là public thì hacker cũng sẽ như những người dùng bình thường sẽ có được key nhưng key đó chỉ dùng để giao tiếp giữ client của hacker và server. Và nếu các thiết kế api áp dụng các kiểu bảo mật như trên video thì khả năng hacker khai thác được server của bạn là rất thấp.
Anh đưa ra giải pháp cho vấn đề thiết thực, học như vầy nhớ lâu hơn nhiều á anh. Cám ơn anh!
học ở trường làm gì có ai chỉ như vầy :))
tuyệt vời quá anh ạ, hôm qua cô mới bắt về nhà tìm hiểu cách bảo mật lẫn nhau giữa các tài khoản xong hôm nay có video của anh luôn.
Chuẩn bị thực hành nha!
Làm về OS, single threat của js khác vs các ngôn ngữ khác multi-thread đi anh , rồi thì thread và process, even loop để hiểu sau về js hơn đc k anh
Cảm ơn anh, là kênh em mới theo dõi nhưng không bỏ sót video nào
em có dọc vs api của binance họ cũng bảo mật kiểu này nhưng ko nắm rõ lắm cảm ơn anh xem clip em mới hiểu hết đc
Em nói chuẩn. Anh cũng làm đầu tiên 2013 với paymentwall.
Cảm ơn bác e hiểu vấn đề r
E đang làm 1 dự án thực tế và đang áp dụng cách này , client em viết bằng vuejs và em đang băn khoăn 1 điều là thuật toán tạo chữ kí có thể bị đọc , anh có thể chia sẻ 1 thư viện dùng để Obfuscate đoạn js này để làm khó khăn cho hacker trong việc dò ra cách tạo chữ kí dưới client của mình được không anh ? Cám ơn anh
em ko hiểu phần nói về chữ kí của anh là đang giải quyết vấn đề replay attack hay middle man attack
vì phần mã hóa dữ liệu đã có ssl lo >> cái chữ kí anh nói em thấy hơi thừa
em thấy cốt lõi của cái chữ kí chính là thuật toán mã hóa/giải mã ,
=> nếu hacker đang ở middle thì ko thể đọc đc dữ liệu >> chả cần chữ kí như anh cho phức tạp, vì đã có ssl lo
=> nếu hacker lúc này đóng vai trò là enduser, lúc này họ nắm giữ thuật toán mã hóa thì họ làm gì chả đc ,cái này tùy trình độ, nhưng về lý thuyết thì họ hoàn toàn có thể tự tạo request và mã hóa bằng cái chữ kí kia >> cái giải pháp anh đưa ra có lẽ để làm khó khăn thôi chứ ko phải là giải quyết vấn đề, chống spam api từ phía end user
p/s : em thấy phần câu hỏi đưa ra có hơi hướng là muốn ngăn người dùng tự tạo request để viết bot/auto , nên em nghĩ ko có giải pháp nào cho cái việc ngăn enduser viết bot/auto cả, chỉ có làm họ khó khăn trong việc tìm hiểu thôi
Cảm ơn bạn đã đặt câu hỏi. Video tói đây sẽ giải đáp cho bạn hai câu hỏi chính "mã hóa và sign khác nhau thế nào?" và "Các trao đổi keySecret không qua internet..."
nếu để key trên FE để mã hoá thì có khả năng bị sử dụng Reverse Engineering để lấy đc key thì phải làm như nào v a
a mãi đỉnh
"Ông cha ta, mấy cái ông dev lúc trước" :v :v :v
rất cảm ơn anh ạ !
vấn đề là cái key lưu như thế nào ở client, còn nếu key mà lưu trong source ở FE thì hacker đọc cũng ra mà
Tất nhiên rồi em, BO DTO, VO...
do sử dụng redis phải cần có server (tốn kém) để lưu lại thì em đang sử dung JWT và check thêm IP máy nữa thì có thay thế cái Nonce được không anh, em cảm ơn anh.
Sao mình không dùng UTC +0 luôn mà phải get time từ server vậy a.
Cám ơn anh vì những video này nhiều nhé.
dùng nonce có chú ý đến bộ nhớ ko anh? vì mỗi ngày cả triệu request, lưu hoài lưu mãi cho chết bộ nhớ à anh, đó là server web, chứ server app hoặc game, gửi request dạng tcp , thì cả trăm triệu packet được gửi đi nên em nghĩ phải có kĩ thuật khác tốt hơn nonce chứ nhỉ
vd: em làm 1 con game , có packet là cộng tiền, nó sài replay để hack cộng tiền, đặc thù của game là nó sài kết nối bền vững tcp , nên có thể trong 1phut lượng request giữa client và server là rất lớn (vd: 1000) , chưa kể có thể có cả nghìn chục nghìn account cùng hoạt động trên server , thì tốn rất nhiều bộ nhớ, cứ cho là anh sẽ xóa bộ nhớ để chứa key đi sau mỗi 1 phut, thì việc xử lý xóa đồng thời nhiều thread cùng xóa như vậy cũng tốn nhiều tài nguyên và thời gian
Em cảm ơn a
liệu Json webtoken có thay thế dc cách này không ạ e cảm ơn thầy
Được em! Em thêm jti, dạng jwt id. Em tham khảo keyword đó
99/00 was sotNice tutorialng called Vision DSP or DST or sotNice tutorialng and didn't quite work the way soft soft does, but tNice tutorials video helped so
có dạy kèm không ạ?
Vượng ơi, chưa có idea này nha Vương. Tks bạn!
Trường hợp client là react thì có thể bị dò ra private key đúng hk nhỉ
Vậy đặt câu hỏi dò ra token thì sao??? Bạn đã khắc phục thế nào?
@@anonystick ơ kìa, gì mà token nữa. Đang thắc mắc mà chứ có ý bắt lỗi gì đâu
@@anonystick xem video theo hiểu là cái private key đó phải lưu ở client và server mà client là react chẳng hạn làm SPA, thì tải toàn bộ source về trình duyệt bao gôm luôn private key
@nhan Vâng! Tải toàn bộ source là lộ hết. Nguy hiểm quá. Do đồng chí không xem hết video cũng như các video trước. Nếu hệ thống của bạn đơn giản thì có thể sử dụng "hmac hashed signature". Ngược lại, nếu là findtech thì phức tạp hơn và đặt những câu hỏi sau? Đồng chí nhận key khi nào? Ai được phép phép cấp key? Và key được cấp chung cho toàn bộ user hay sao? Và mỗi ip đều sinh ra một key?? Xem lại đoạn cuối video. Thêm nữa cho bạn là . Key được nhúng trong chứng chỉ đã được ký điện tử bởi tổ chức phát hành chứng chỉ được công nhận để đảm bảo rằng đó là khóa hợp pháp được tạo bởi người nhận dự kiến (CA). Nếu chưa biết CA vui lòng sử dụng Mr. Google. Và điều quan trọng tất cả mọi thứ đều không an toàn 100%. Tks
anh ơii ! cho em hỏi là mình có thể sài redis làm database tạm đc không , như là những vấn đề update data thường xuyên nhưng vẫn sử dụng redis, và chạy cron cuối ngày update ngược lại vào data chính
Chuẩn em. Không cần góp ý thêm
Anh có nghĩ là tương lai golang sẽ chiếm ưu thế Backend của nodejs không anh?
@@anonystick backend vẫn xoay quanh hai cái này mà anh. Chứ golang thì sao so được với Javascipt phía frontend anh ơi.
Anh hiểu sai câu hỏi của em. Sr em. Golang thật sự đáng quan tâm hơn đó em.
Hi anh. Em đang tìm hiểu về cơ chế tách hệ thống lớn thành các hệ thông con. A có thể cho em xin vài đường quyền giải quyết vụ này không?
Cụ thể Input e cần giải quyết như sau:
Input: Người dùng khi vào 1 subdomain thì nó sẽ kiểm tra tài khoản đó có quyền được truy xuất đến database nào. Nếu họ có dùng account đó vào subdomain khác thì sẽ báo ko có quyền truy cập. Hoặc củng có trường hợp 1 tài khoản vào được đến 2-3 subdomain.
Em bản chất em đang muốn clone database riêng biệt nhưng chức năng vẫn trên 1 source. Mong anh giúp đỡ, em cảm ơn anh.
Sao giống anh hồi xưa giữ vậy trời :)
@@anonystick ước gì được anh chỉ giáo.. có mà sướng run người 🤣. Em củng tìm hiểu theo hướng proxy config và authen DB mà vẫn chưa rõ cách hoạt động chính xác là như nào
@@anonystick sao em thấy bạn trên hỏi giống làm microservices vậy a. Anh làm 1 video microservices cho expressjs cho 1 dự án mini được ko a
@@hautran7559 Đang làm đó em. Chò hén.
@@anonystick ak với 1 cái nữa a ơii. Mấy keywords nào tiếng anh, anh có thể ghi thêm scripts cho nó không anh. Em nghe cách đọc được nhưng mà spell ra như thế nào để search em vẫn chưa spell ra được từ đó
Cho em hỏi https sinh ra làm gì ạ :D
Https không phải là tình huống reply attack và spoofing. Đọc kỹ bro.
Có phải vừa có time vừa có nounce là thừa ko anh, vì 1 khi bắt session-id chỉ cho sử dụng 1 lần thì time đâu còn ý nghĩa nữa ạ
giống như OTP có hạn 5p, ví dụ trong 5p đó người ta ko xài, thì sau 5p cũng ko xài đc
@@hoangloc1108 thks bạn
em newbie ko hiểu gì
Từ từ rồi hiểu nha em. Chỗ này hơi đòi hỏi chút..
Em thắc mâc là cái key mình để ở client, nó đọc được source nên lộ key ra, nó hiểu đc cơ chế tạo ra cái chữ ký mình nên nó cũng sẽ giả đc chữ ký.
Em cũng đang viết api cho bên game unity, cũng đang tìm hiểu cách làm sao chặn request ko đến từ game mà đến từ postman hoặc tool gì đó.
Hiện tại e cũng làm hơi giống anh một tí là để logic tạo key ở phía client (Ingmame) nên cũng nghĩ là bọ nó sẽ decode game ra đọc đc cách tạo ra cái key này.
Còn logic sinh key thì em dùng jwt, mỗi khi gọi api thì ở dưới client sinh ra key dựa vào secret key và có tgian hết hạn 30bs, trên backemd sẽ validate dựa vào secret key.
Nói chung secret key đang bỏ cả backend và client nên em nghĩ nếu bọn mó.muốn hack thì sẽ tìm đc cái key này.
Anh có góp ý gì cho em không ạ?
Cảm ơn anh với những video bổ ích ạ.
vậy là bann chưa xem video trước. Không thể nào tạo key ở client. mỗi phiên có một key mà server cấp cho...
@@TungNguyen-wy7dz vậy có sợ hacker nó cũng gọi api lấy key không ạ? em chỉ làm ở mức bình thường chứ cũng ko phưc tạp như kiểu zalo hay video anh nói về cơ chế e2e ấy ạ.
Hello bạn, theo kiến thức của mình với bên Android thì hdh sẽ có các api để quản lý key riêng và nó thuộc về hdh an toàn hay không là do thiết bị cũng như các lỗ hổng của android. Bên web cũng tương tự như vậy, key do browser quản lý vì vậy nếu bạn làm đúng theo các case study của web hoặc android thì dù hacker có khai thác được source code cũng không thể nào biết được key của các người dùng khác.
Thứ hai về chữ kí số thì thường người ta sẽ dùng mã hóa bất đối xứng ( asymmetric cryptography) để mã. Bạn có thể tìm hiểu thêm về mã hóa bđ xứng và chữ ký số.
Còn về việc hacker gọi được api lấy key hay không thì nếu api của bạn là public thì hacker cũng sẽ như những người dùng bình thường sẽ có được key nhưng key đó chỉ dùng để giao tiếp giữ client của hacker và server. Và nếu các thiết kế api áp dụng các kiểu bảo mật như trên video thì khả năng hacker khai thác được server của bạn là rất thấp.
Chuẩn bị có video giair thích vể cách trao đổi key bảo mật nhất hén.
@@anonystick Dạ, tuyệt vời quá anh, hóng video của anh ạ?