Pháp sư TRUNG HOA đã bảo mật API như thế nào

[@tientungo5857]

Nó là digital signature bác ơi. Làm về finance và thanh toán sẽ thường gặp =)))) Chẳng phải Trung Quốc, Việt Nam cũng khối cty dùng

[@nghiabasil]

hay lắm anh ạ

[@catmewmew482]

Mình thấy cũng thấy chả có cái gì khác hay bảo mật hơn những cái cơ bản đang có lắm. cũng đang làm cái connect với bọn ByteDance thấy chúng nó có cái hay là nó chơi cấp token cho key và secret theo thời gian ngắn thực set tầm 2 phút nói chung decode ra xong thì cũng :D die token đó r nên khả năng bị hack là ít hẳn chỉ mệt việc call 2 lần

[@softgreen8150]

ssl, hay https nó dùng phương pháp này😂😂😂 sha dùng public key mã hoa server dùng private key đễ giải mã, ai có kinh nghiệm bảo mạt đều biết, cần gì phải tq hay Việt nam😂😂😂

[@kidsgameschannel9002]

Theo mk thấy thì đây là kiểm tra tính toàn vẹn của dữ liệu

[@softgreen8150]

bảo mật, như ssl, https mã hoá sha😂😂😂

[@khanhtang4451]

Có 1 câu hỏi được đặt ra: Sau khi server decode làm sao để server có thể xác thực được thông tin đấy có đúng là được yêu cầu từ client chứ không phải 1 bên thứ 3 nào đó trong khi những thông tin như xKey hoàn toàn có thể được bên thứ 3 decode và sao chép nhằm mục đích giả làm client, những thông tin như timestamp hay UUID hoàn toàn có thể fake đc.

[@tuhocdev]

Cái secretkey là cái phải bảo mật bạn nhé. Hơn nữa là những data nào đưa vào hàm hmac thì cũng là secret mà, cho nên để review lại các thông tin trước đó cũng rất khó. Cũng giống như dịch vụ của google, khi mình dùng các api của họ cũng cần phải có 1 chuỗi tokenkey

[@khanhtang4451]

​@@tuhocdev Cơ chế nào để bạn bảo mật key đấy, hàm hmac mà bạn nói cũng chỉ là 1 phương thức encode hoặc hash, nó sẽ có cách để decode lại, nên thông thường người ta không truyền secret key từ client xuống, bên thứ 3 có thể làm middle ware giữa server và client để đọc những thông tin này và fake client. Về cơ bản cách bạn bảo mật nó có thể đã từng an toàn trong quá khứ nhưng ở thời điểm hiện tại nó quá dễ để crack

[@tuhocdev]

Thanks bạn. Đọc được gì thì mình chỉ chia sẻ lại thôi nhé, các bạn cứ để lại đóng góp ý kiến nhé

[@shaypatrickcormac2765]

@@tuhocdev Cái này dùng để mã hoá trước khi gửi sang một bên khác để xử lý. Ad nên thêm context vào đầu video để mọi người đỡ hiểu lầm nhé

[@nghianguyenba2517]

@@khanhtang4451 secretkey sẽ được client nắm giữ và không được trao đổi trong quá trình trao đổi dữ liệu với server, hmac là một cơ chế hash mà không thể bị đảo ngược. Phương pháp này là HMAC (Hash-based Message Authentication Code) authentication, đơn giản là ký số để đảm bảo tính toàn vẹn của dữ liệu.

[@daokhanh9814]

Theo mình thấy đây giống như là cơ chế của https vậy 😅

[@xutiTrinh]

Do dữ liệu cần được đọc bởi server nên server sẽ cần phải có cả private key. Do server cũng cần verify x-key nên server cũng phải lưu public key. Ngoài ra nếu như x-sign là dữ liệu server cần đọc thì nó sẽ phải được encrypt chứ ko phải bởi 1 thuật toán hash, thành ra cái model của bác em nghĩ chưa chính xác lắm vì hmac ko bao giờ được dùng như 1 phương thức encrypt cả. Em ngờ data được gửi ko phải từ x-sign đâu ạ. Bác có link gốc cho em xin với ạ, em xin cảm ơn

[@tuhocdev]

Theo nguyên lý này thì người ta sử dụng hmac, nhưng mình có thể tự mình define 1 hàm cũng được

[@nguyenvanviet456]

1. Do dữ liệu cần được đọc bởi server nên server sẽ cần phải có cả private key. Do server cũng cần verify x-key nên server cũng phải lưu public key. -> hmac dùng mật mã đối xứng để mã hóa và giải mã, nó dùng 1 khóa duy nhất secret_key thôi nhé hmac dùng duy nhất 1 secret_key (cả bên gửi và nhận để biết) để vừa tạo chữ ký x-sign 2. Ngoài ra nếu như x-sign là dữ liệu server cần đọc thì nó sẽ phải được encrypt chứ ko phải bởi 1 thuật toán hash, thành ra cái model của bác em nghĩ chưa chính xác lắm vì hmac ko bao giờ được dùng như 1 phương thức encrypt cả. -> hmac sẽ mã hóa giá trị hash của (message + secret_key) nhé, hmac ko phải thuật toán hash đâu nhé x-sign là chữ kí để bên nhận kiểm tra dữ liệu được bảo toàn và được gửi từ nguồn uy tín thôi. whitehat.vn/threads/thac-mac-giua-ma-hoa-va-ham-bam.5468/

[@xutiTrinh]

Có lẽ bác đang hiểu nhầm ý em. - hmac dùng mật mã đối xứng để mã hóa và giải mã, nó dùng 1 khóa duy nhất secret_key thôi nhé => em cũng ko rõ từ khi nào hmac lại có thể dùng để mã hóa và giải mã (encryption). - hmac sẽ mã hóa giá trị hash của (message + secret_key) nhé => em nghĩ ở chỗ này bác dùng từ mã hóa có vẻ không đúng lắm. - hmac ko phải thuật toán hash đâu nhé => cái này ai học qua về cryptographic đều hiểu, em xin phép ko comment

[@thientaiuinh3498]

Haha. Kiểu này tôi ở VN dùng bao năm rồi. Giờ thành cổ lỗ sĩ k dùng nữa rồi b ơi

[@tuhocdev]

Thế chúc mừng bạn :))

[@softgreen8150]

đang sài, ssl, https😂😂😂 bỏ bao giờ😂😂😂

[@zitechdev]

tôi xem lại 3 lần nhưng không hiểu cơ chế bạn chia sẻ bảo mật hơn thế nào, bạn có thể cung cấp nguồn tài liệu được không?

[@tuhocdev]

Thường cái này áp dụng cho thirdparty nhiều hơn. Nếu như google firebase hay chat GPT mình chỉ cần mỗi api key thì nếu bị hacker bắt request mà ssl ko tốt thì header bị open cả rồi. Nhưng nếu sử dụng pp này thì có bắt được request cũng vẫn còn bảo mật

[@doanvv]

Tôi cũng ko hiểu được ý của video này lắm, thường thì cái này mình thấy áp dụng cho kết nối server to server, hoặc mobile app. Tuy nhiên, người ta chỉ sử dụng public key để sign data, private key (secret key) luôn phải nằm phía server để decode encrypted data chứ chưa bao giờ mình thấy gửi cả secret key cho client như video này.

[@tuhocdev]

Chỉ là góc chia sẻ bạn nhé. Các bạn cứ đóng góp ý kiến nhé

[@trongdang5711]

Em vẫn chưa hiểu đoạn truyền secret key từ server tới client như thế nào để bảo mật, và xác thực đó chính là user thật sự chứ không phải là hacker. Với lại việc lưu trữ ở database như thế nào? raw hay encrypt Mong bác thông não e với ạ

[@softgreen8150]

đó là mã công khai thích thì lấy😂😂😂 ssl hay https cung như vậy😂😂😂

[@xuanquangnguyen4851]

b có tài liệu của phần này không. mk thắc mắc trên server sau đó sẽ verify như nào. giả sử mk lấy được xsign key và mk call thì vẫn được nhỉ. thắc mắc server sẽ verify như nào

[@tuhocdev]

Phần server sẽ decode lại chuỗi sign và khớp với các giá trị input của encryt thì khi đó sẽ hợp lệ bạn nhé. Bạn có thể tự định nghĩ hàm mã hóa riêng cho mình

[@xuanquangnguyen4851]

@@tuhocdev b có tài liệu phần này không cho mk xin tham khảo với

[@kidsgameschannel9002]

Khi gói tin đến server thì phải đi qua HmacSHA256 một lần nữa khi này sinh ra một đoạn mã và so sánh đoạn mã này với xsign. Nếu giống với xsign thì tiếp tục còn khác thì sẽ bỏ gói tin đó(vì khả năng đã bị thay đổi trên đường truyền)

[@duyopham520]

hiện tại e vẫn chưa hiểu là nó bảo mật cái gì, trong khi tất cả key thì nằm ở client đc mã hóa xong r chuyển về BO, BO mã hóa lại r check thông tin header có giống ko thì e ko bik là nó check cái j của thông tin header để bik đc đúng ng của mình đang truyền về cho mình hay ko , hi vọng ad giải đáp thắc mắc dùm e ạ, thanks ad nhiều

[@nguyenvantu1471]

Cái này giống kiểu kiểm tra sự toàn vẹn của dữ liệu giữa khi giao tiếp giữa Client và server hơn. Phần này sẽ cần bảo mật phần secretKey và cách mà 2 bên gửi secret key lần đầu tiên. Theo mình đang hiểu là như thế

[@duyopham520]

@@nguyenvantu1471 hiện tại theo e hiểu , thì trên client sẽ mã hóa cái thông tin trên thành 1 chuỗi secret để gửi cho BO, BO lúc này nhận đc thì mã hóa chuỗi đó ngược lại để kiểm tra thì e ko bik là nó sẽ kiểm tra cái j

[@duyopham520]

nếu mà kiểm tra cái secret kia thì ngay từ đầu chỉ có mỗi client là mã hóa chuỗi đó để gửi cho BO, mà BO thì chưa có chuỗi đó nên e ko bik BO decode lại chuỗi đó để kiểm tra dữ liệu j

[@duyopham520]

nếu mà như v thì e cug có thể copy cái header đó và tạo y chang cái secret key r gửi cho BO vẫn đc, hiện tại e chưa rõ là BO sẽ nhận bik đó có phải là client của mình ko bằng cái nào ạ

[@nguyenvantu1471]

@@duyopham520 Client mã hoá bằng secret key mà server cung cấp đó bạn. Để server kiểm tra đó có phải là thằng đang giao tiếp hay không dựa trên secret key đã ký vào header.

[@thanhthanhtungnguyen8536]

cái secretkey đó là cả client và server sử dụng chung luôn hả bác?

[@tuhocdev]

Cái này nó giống với mô hình của apikey cho been thứ 3 đấy em, hoặc là ứng dụng vào socket hoặc mqtt... Chứ ứng dụng cho web thì không phù hợp lắm