Cảm ơn anh, là kênh em mới theo dõi nhưng không bỏ sót video nào

rất cảm ơn anh ạ !

Cảm ơn bác e hiểu vấn đề r

a mãi đỉnh

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!

@huongsenongthap478

Жыл бұрын

học ở trường làm gì có ai chỉ như vầy :))

Em cảm ơn a

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.

@anonystick

Жыл бұрын

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

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

@anonystick

Жыл бұрын

Em nói chuẩn. Anh cũng làm đầu tiên 2013 với paymentwall.

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

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

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

@anonystick

Жыл бұрын

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

"Ông cha ta, mấy cái ông dev lúc trước" :v :v :v

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

@anonystick

Жыл бұрын

Chuẩn em. Không cần góp ý thêm

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

có dạy kèm không ạ?

@anonystick

Жыл бұрын

Vượng ơi, chưa có idea này nha Vương. Tks bạn!

liệu Json webtoken có thay thế dc cách này không ạ e cảm ơn thầy

@anonystick

Жыл бұрын

Được em! Em thêm jti, dạng jwt id. Em tham khảo keyword đó

Trường hợp client là react thì có thể bị dò ra private key đúng hk nhỉ

@anonystick

Жыл бұрын

Vậy đặt câu hỏi dò ra token thì sao??? Bạn đã khắc phục thế nào?

@nhan5370

Жыл бұрын

@@anonystick ơ kìa, gì mà token nữa. Đang thắc mắc mà chứ có ý bắt lỗi gì đâu

@nhan5370

Жыл бұрын

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

@anonystick

Жыл бұрын

@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 có nghĩ là tương lai golang sẽ chiếm ưu thế Backend của nodejs không anh?

@ThaiNguyen-gg8xj

Жыл бұрын

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

@anonystick

Жыл бұрын

Anh hiểu sai câu hỏi của em. Sr em. Golang thật sự đáng quan tâm hơn đó em.

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 ạ

@hoangloc1108

Жыл бұрын

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

@TakanNick

Жыл бұрын

@@hoangloc1108 thks bạn

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

Жыл бұрын

Sao giống anh hồi xưa giữ vậy trời :)

@thanhvan1200

Жыл бұрын

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

@hautran7559

Жыл бұрын

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

@anonystick

Жыл бұрын

@@hautran7559 Đang làm đó em. Chò hén.

@hautran7559

Жыл бұрын

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

@anonystick

Жыл бұрын

Https không phải là tình huống reply attack và spoofing. Đọc kỹ bro.

em newbie ko hiểu gì

@anonystick

Жыл бұрын

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

@TungNguyen-wy7dz

Жыл бұрын

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

@cheng6630

Жыл бұрын

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

@nguyenhuynhle1423

Жыл бұрын

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.

@anonystick

Жыл бұрын

Chuẩn bị có video giair thích vể cách trao đổi key bảo mật nhất hén.

@cheng6630

Жыл бұрын

@@anonystick Dạ, tuyệt vời quá anh, hóng video của anh ạ?