Bảo vệ chống tấn công phát lại bằng nonce

Bảo vệ chống tấn công phát lại bằng nonce là gì?

Bảo vệ chống tấn công phát lại bằng nonce là phương thức bảo mật ngăn một giao dịch, thông điệp, giấy phép, lệnh ủy quyền hoặc hành động hợp đồng thông minh hợp lệ được sử dụng lại nhiều lần.

Nonce là một con số hoặc giá trị duy nhất được thiết kế để chỉ sử dụng một lần trong một ngữ cảnh cụ thể.

Bảo vệ chống phát lại có nghĩa là sau khi hành động đã ký được sử dụng, mạng, ví, hợp đồng hoặc ứng dụng sẽ từ chối hành động đã ký đó nếu có người gửi lại.

Trong crypto, bảo vệ chống tấn công phát lại bằng nonce rất cần thiết vì chữ ký số có thể được sao chép chính xác.

Nếu người dùng ký một giao dịch hoặc thông điệp nhưng hệ thống không theo dõi xem hành động đó đã được sử dụng hay chưa, kẻ tấn công có thể phát lại chính chữ ký đó để lặp lại hành động.

Hành động lặp lại có thể chuyển tiền thêm một lần, cấp quyền chi tiêu token thêm một lần, thực thi lại lệnh gọi hợp đồng thông minh, bỏ phiếu lại, nhận thưởng lại hoặc kích hoạt lại lệnh ủy quyền.

Tài liệu về tài khoản của Ethereum giải thích rằng tài khoản Ethereum có trường nonce và mỗi tài khoản chỉ có thể thực thi một giao dịch với một nonce nhất định.

Tài liệu này cũng nêu rằng cơ chế đó bảo vệ khỏi các cuộc tấn công phát lại, trong đó giao dịch đã ký liên tục được phát lên mạng và thực thi lại.

Vì vậy, bảo vệ chống tấn công phát lại bằng nonce là một trong những lớp an toàn cơ bản giúp chữ ký blockchain có thể được sử dụng cho các giao dịch giá trị thực.

Những điểm chính về bảo vệ chống tấn công phát lại bằng nonce

• • Bảo vệ chống tấn công phát lại bằng nonce ngăn cùng một hành động crypto đã ký được chấp nhận nhiều lần.
  • Nonce có thể được tạo theo thứ tự tăng dần, ngẫu nhiên, theo domain, tài khoản, hợp đồng hoặc lane.
  • Tài khoản Ethereum do người dùng trực tiếp kiểm soát sử dụng nonce giao dịch tuần tự để ngăn giao dịch bị thực thi lặp lại.
  • EIP-155 thêm chain ID vào dữ liệu giao dịch đã ký để giảm nguy cơ phát lại giữa các chain.
  • Dữ liệu định kiểu EIP-712 vẫn cần cơ chế bảo vệ chống phát lại ở cấp ứng dụng vì chữ ký định kiểu có thể bị gửi nhiều lần nếu hợp đồng không từ chối các lần gửi lặp.
  • ERC-2612 permit sử dụng nonce của chủ sở hữu và thời hạn để ngăn chữ ký phê duyệt token bị tái sử dụng vô thời hạn.
  • ERC-3009 sử dụng nonce ngẫu nhiên 32 byte và trạng thái ủy quyền để ngăn các giao dịch chuyển token đã ký bị lặp lại.
  • Tài khoản thông minh ERC-4337 sử dụng thiết kế nonce linh hoạt hơn cho trừu tượng hóa tài khoản và các quy trình song song.
  • Cơ chế bảo vệ chống phát lại cũng nên ràng buộc chữ ký với đúng chain, hợp đồng, hàm, người dùng, thời hạn và hành động dự kiến.
  • Thiết kế nonce yếu có thể dẫn đến chi tiêu hai lần, phê duyệt lặp lại, giao dịch bị kẹt, thiệt hại do đánh cắp chữ ký, giao dịch meta thất bại và tấn công phát lại giữa các chain.

Vì sao các cuộc tấn công phát lại đáng lưu ý trong crypto?

Tấn công phát lại xảy ra khi ai đó lấy một hành động đã ký hợp lệ rồi gửi lại ở nơi hành động đó vẫn được chấp nhận.

Chữ ký crypto không giống chữ ký viết tay trên giấy vì chúng có thể được sao chép và phát lại chính xác.

Nếu một giao dịch đã ký hợp lệ một lần nhưng giao thức không đánh dấu giao dịch đó là đã được sử dụng, giao dịch ấy có thể tiếp tục hợp lệ.

Điều này nguy hiểm vì blockchain thường xem chữ ký hợp lệ là sự ủy quyền.

Giao dịch chuyển tiền bị phát lại có thể chuyển tiền thêm lần nữa.

Phê duyệt bị phát lại có thể cấp lại quyền chi tiêu.

Yêu cầu nhận thưởng bị phát lại có thể làm cạn pool phần thưởng.

Phiếu bầu quản trị bị phát lại có thể làm sai lệch kết quả nếu hợp đồng không theo dõi trạng thái bỏ phiếu.

Thông điệp bridge bị phát lại có thể khiến tài sản được mint hoặc giải ngân không chính xác.

Bảo vệ chống tấn công phát lại bằng nonce biến chữ ký có thể tái sử dụng thành lệnh ủy quyền chỉ dùng một lần.

Nonce ngăn tấn công phát lại như thế nào?

Nonce ngăn tấn công phát lại bằng cách giúp mỗi hành động đã ký trở nên duy nhất và có thể theo dõi.

Khi người dùng ký một hành động, nonce được đưa vào dữ liệu đã ký.

Khi hành động được thực thi, giao thức kiểm tra nonce có hợp lệ và chưa được sử dụng hay không.

Nếu vượt qua bước kiểm tra, hành động sẽ được thực thi và nonce được tiêu thụ, tăng lên hoặc đánh dấu là đã sử dụng.

Nếu ai đó thử gửi lại cùng hành động đã ký, bước kiểm tra nonce sẽ thất bại.

Chữ ký vẫn có thể hợp lệ về mặt toán học, nhưng hệ thống từ chối vì nonce đã được sử dụng.

Điểm khác biệt này rất quan trọng.

Tính hợp lệ của chữ ký chứng minh rằng người dùng đã ủy quyền thông điệp.

Tính mới của nonce chứng minh rằng quyền ủy quyền chưa được sử dụng.

Một hệ thống an toàn cần cả hai yếu tố.

Nonce tuần tự

Nonce tuần tự là một bộ đếm tăng lên sau mỗi hành động được chấp nhận.

Tài khoản Ethereum do người dùng trực tiếp kiểm soát sử dụng mô hình này cho các giao dịch thông thường.

Nếu tài khoản có nonce 10, giao dịch hợp lệ tiếp theo từ tài khoản đó thường cần nonce 10.

Sau khi giao dịch đó được đưa vào blockchain, giao dịch hợp lệ tiếp theo cần nonce 11.

Cơ chế này ngăn hai giao dịch khác nhau có cùng nonce tài khoản cùng được thực thi.

Cơ chế này cũng tạo thứ tự vì giao dịch có nonce cao hơn thường không thể được xử lý trước khi các nonce thấp hơn được sử dụng.

Nonce tuần tự đơn giản và hiệu quả đối với các giao dịch thông thường của tài khoản.

Chúng có thể gây bất tiện cho giao dịch meta, quy trình theo lô, nhiều thiết bị, phiên tự động và hệ thống trừu tượng hóa tài khoản.

Đó là lý do một số thiết kế mới hơn sử dụng nonce ngẫu nhiên, nonce lane hoặc ánh xạ nonce riêng cho từng ứng dụng.

Nonce ngẫu nhiên

Nonce ngẫu nhiên là một giá trị duy nhất được tạo ngẫu nhiên thay vì tạo bằng cách tăng dần bộ đếm.

Nonce ngẫu nhiên thường được sử dụng trong các lệnh ủy quyền đã ký và hệ thống giao dịch meta không yêu cầu thứ tự giao dịch nghiêm ngặt.

ERC-3009 sử dụng nonce 32 byte được tạo ngẫu nhiên và có tính duy nhất đối với địa chỉ bên ủy quyền.

Tiêu chuẩn ERC-3009 định nghĩa hàm trạng thái ủy quyền và các sự kiện ghi nhận nonce ủy quyền đã được sử dụng hay hủy hay chưa.

Mô hình này cho phép tồn tại đồng thời nhiều lệnh ủy quyền đã ký độc lập.

Nó tránh tình trạng một nonce tuần tự đang chờ xử lý chặn các lệnh ủy quyền tiếp theo.

Đổi lại, hợp đồng phải lưu trữ hoặc kiểm tra các nonce ngẫu nhiên đã dùng để ngăn cùng một lệnh ủy quyền bị lặp lại.

Nonce ngẫu nhiên cần có tính ngẫu nhiên mạnh.

Nếu nonce có thể đoán trước hoặc vô tình được dùng lại, khả năng bảo vệ chống phát lại có thể suy yếu.

Nonce tài khoản

Nonce tài khoản bảo vệ giao dịch từ cùng một tài khoản.

Đối với tài khoản do người dùng trực tiếp kiểm soát, nonce giúp mỗi giao dịch trở nên duy nhất và kiểm soát thứ tự giao dịch.

Nếu người dùng gửi hai giao dịch có cùng nonce tài khoản, theo quy tắc thông thường chỉ một giao dịch có thể được đưa vào blockchain.

Giao dịch còn lại có thể bị từ chối, bị thay thế hoặc vẫn không hợp lệ, tùy theo mạng và cách xử lý phí.

Đó là lý do ví cần theo dõi cẩn thận nonce tài khoản tiếp theo.

Nếu ví sử dụng nonce quá thấp, giao dịch có thể đã được sử dụng và sẽ thất bại.

Nếu ví sử dụng nonce quá cao, giao dịch có thể phải chờ cho đến khi các nonce còn thiếu trước đó được xác nhận.

Nếu người dùng phát giao dịch thay thế có cùng nonce nhưng phí cao hơn, giao dịch thay thế có thể thay thế giao dịch đang chờ trước đó, tùy theo chính sách của node.

Nonce tài khoản bảo vệ khỏi tấn công phát lại nhưng cũng gây ra các vấn đề thực tế trong quản lý giao dịch.

Người dùng có thể gặp các vấn đề đó dưới dạng giao dịch bị kẹt, hàng đợi đang chờ, giao dịch thay thế hoặc yêu cầu hủy giao dịch.

Bảo vệ chống phát lại bằng chain ID

Bảo vệ chống phát lại bằng chain ID ngăn giao dịch được ký cho một chain hợp lệ trên một chain khác sử dụng định dạng giao dịch tương tự.

Cơ chế này trở nên đặc biệt quan trọng sau các đợt phân tách chain và khi nhiều mạng tương thích EVM phát triển.

EIP-155 đã thêm chain ID vào dữ liệu giao dịch Ethereum được ký.

Mục đích là để giao dịch chỉ hợp lệ trên một chain và không hợp lệ trên chain khác có chain ID khác.

Nếu không có biện pháp bảo vệ này, giao dịch được phát trên một chain có thể bị sao chép và gửi trên chain khác nếu tài khoản, nonce và định dạng giao dịch trùng khớp.

Bảo vệ chống phát lại bằng chain ID khác với bảo vệ chống phát lại bằng nonce tài khoản.

Nonce tài khoản ngăn lặp lại cùng một giao dịch trên cùng chain.

Chain ID giúp ngăn cùng giao dịch đã ký được sử dụng trên chain khác.

Thông thường, cần kết hợp cả hai để có khả năng bảo vệ chống phát lại mạnh.

Tách biệt domain

Tách biệt domain là việc ràng buộc chữ ký với một ngữ cảnh ký cụ thể.

Ngữ cảnh đó có thể bao gồm chain ID, địa chỉ hợp đồng, tên giao thức, phiên bản, loại hàm, địa chỉ người dùng, nonce và thời hạn.

EIP-712 định nghĩa việc ký dữ liệu có cấu trúc theo kiểu và bao gồm các trường domain như name, version, chainId và verifyingContract.

Tách biệt domain giúp ngăn chữ ký dành cho một ứng dụng được ứng dụng khác chấp nhận.

Ví dụ, người dùng có thể muốn ký thông điệp cho một hợp đồng trên một chain nhất định.

Nếu chữ ký không bao gồm chain và hợp đồng xác minh, một hợp đồng hoặc chain khác có thể hiểu chữ ký đó là hợp lệ.

Đây là rủi ro phát lại vì cùng chữ ký có thể được chuyển sang các ngữ cảnh khác.

Nonce ngăn việc sử dụng lặp lại trong cùng một ngữ cảnh.

Tách biệt domain giúp ngăn chữ ký được sử dụng sai ngữ cảnh.

Cả hai biện pháp đều cần thiết để chữ ký off-chain an toàn.

Bảo vệ chống tấn công phát lại với thông điệp EIP-712

EIP-712 giúp ví và người dùng dễ hiểu thông điệp hơn, nhưng không tự động khiến mọi thông điệp đã ký chỉ được sử dụng một lần.

Phần bảo mật của EIP-712 cảnh báo rằng ứng dụng phải xử lý đúng trường hợp cùng một thông điệp đã ký xuất hiện hai lần.

Điều đó có nghĩa là hợp đồng hoặc ứng dụng phải từ chối thông điệp đã ký bị lặp lại hoặc đảm bảo hành động lặp lại không gây hại.

Thông điệp định kiểu có thể chứa nonce, nhưng hợp đồng nhận thông điệp phải kiểm tra và tiêu thụ nonce đó.

Thông điệp định kiểu có thể chứa thời hạn, nhưng thời hạn đó phải được thực thi on-chain.

Thông điệp định kiểu có thể chứa hợp đồng xác minh, nhưng hợp đồng phải xác minh domain separator chính xác.

Dữ liệu định kiểu giúp thông điệp rõ ràng hơn, chứ bản thân nó không bảo vệ khỏi phát lại.

Khả năng chống phát lại phụ thuộc vào toàn bộ thiết kế.

Quy trình EIP-712 an toàn kết hợp tách biệt domain, theo dõi nonce, xác thực chữ ký, ràng buộc hành động và kiểm tra thời hạn.

Thiếu bất kỳ yếu tố nào trong số này đều có thể tạo ra rủi ro phát lại.

Bảo vệ chống tấn công phát lại với ERC-2612 permit

ERC-2612 permit cho phép chủ sở hữu token phê duyệt việc chi tiêu token bằng thông điệp đã ký thay vì giao dịch phê duyệt trực tiếp on-chain.

Cơ chế này cải thiện trải nghiệm người dùng vì bên khác có thể gửi permit đã ký thay mặt chủ sở hữu.

Tiêu chuẩn ERC-2612 yêu cầu có hàm nonces và quy định rằng permit phải tăng nonce của chủ sở hữu nếu permit thành công.

Tiêu chuẩn này cũng nêu rằng ánh xạ nonces được cung cấp để bảo vệ chống phát lại.

Cơ chế này ngăn cùng chữ ký permit bị sử dụng nhiều lần.

ERC-2612 cũng bao gồm tham số deadline.

Deadline giới hạn khoảng thời gian permit đã ký còn hiệu lực.

Điều này quan trọng vì bên chuyển tiếp nhận được permit có thể chọn thời điểm gửi permit trước khi hết hạn.

Deadline ngắn có thể giảm nguy cơ chữ ký cũ bị sử dụng sau này.

Permit không được xử lý nonce và deadline đúng cách có thể tạo ra rủi ro nghiêm trọng đối với việc phê duyệt token.

Bảo vệ chống tấn công phát lại với ERC-3009

ERC-3009 là một mô hình ủy quyền chuyển token bằng chữ ký.

Thay vì phê duyệt spender trước, chủ sở hữu token ký lệnh ủy quyền cho một giao dịch chuyển cụ thể.

Sau đó, hợp đồng kiểm tra chữ ký, khoảng thời gian hiệu lực và nonce trước khi thực thi.

ERC-3009 sử dụng ánh xạ authorizationState để theo dõi nonce đã được sử dụng hay chưa.

Tiêu chuẩn này đánh dấu nonce là đã sử dụng sau khi lệnh ủy quyền chuyển tiền thành công.

Cơ chế này ngăn cùng giao dịch chuyển tiền đã ký bị thực thi lại.

Một số triển khai ERC-3009 cũng hỗ trợ hủy lệnh ủy quyền.

Tiêu chuẩn này bao gồm các trường validAfter và validBefore để xác định thời điểm lệnh ủy quyền có hiệu lực.

Thiết kế này hữu ích cho quy trình chuyển token không cần gas hoặc có bên chuyển tiếp.

Thiết kế này cũng cho thấy bảo vệ chống phát lại không chỉ đơn giản là một bộ đếm.

Lệnh ủy quyền an toàn cần có nonce duy nhất, khoảng thời gian hiệu lực, người nhận rõ ràng, giá trị chính xác và domain phù hợp.

Bảo vệ chống tấn công phát lại với tài khoản thông minh ERC-4337

ERC-4337 triển khai trừu tượng hóa tài khoản thông qua UserOperation và tài khoản hợp đồng thông minh.

Tiêu chuẩn ERC-4337 định nghĩa nonce của UserOperation là tham số chống phát lại.

Tiêu chuẩn này cũng yêu cầu chữ ký phụ thuộc vào chain ID và địa chỉ EntryPoint để ngăn phát lại giữa các chain hoặc các EntryPoint.

ERC-4337 sử dụng mô hình nonce bán trừu tượng.

Nonce có thể được xem là kết hợp giữa một khóa và một chuỗi tuần tự.

Điều này cho phép tài khoản thông minh hỗ trợ nhiều nonce lane.

Ví dụ, ví có thể sử dụng một lane cho giao dịch thông thường và lane khác cho các thao tác quản trị.

Cách thiết kế này giúp trừu tượng hóa tài khoản hỗ trợ các quy trình song song mà vẫn bảo vệ chống phát lại.

Thiết kế này linh hoạt hơn một nonce tuần tự duy nhất.

Tính linh hoạt cao hơn cũng đồng nghĩa nhà phát triển ví phải quản lý nonce lane cẩn thận.

Nonce lane

Nonce lane là một luồng giá trị nonce độc lập.

Thay vì buộc mọi hành động của một tài khoản phải theo cùng một chuỗi, nonce lane cho phép các nhóm hành động khác nhau tiến triển độc lập.

Cơ chế này hữu ích cho tài khoản thông minh, khóa phiên, thanh toán tự động, đăng ký định kỳ, thao tác khôi phục, nước đi trong trò chơi và ví có plugin.

Ví dụ, người dùng có thể có một lane cho chi tiêu hằng ngày và một lane khác cho các thao tác khôi phục.

Giao dịch trong lane khôi phục không nên chặn giao dịch trong lane chi tiêu hằng ngày.

Nonce lane có thể tăng tính linh hoạt và cải thiện trải nghiệm người dùng.

Chúng cũng có thể làm tăng độ phức tạp nếu ví không hiển thị rõ ràng.

Nếu ví ký bằng lane không đúng, hành động có thể thất bại hoặc tạo ra thứ tự ngoài dự kiến.

Nếu hợp đồng không xác thực lane chính xác, cơ chế bảo vệ chống phát lại có thể không đầy đủ.

Nonce lane chỉ phát huy hiệu quả khi các quy tắc dễ hiểu.

Bảo vệ chống phát lại cho hợp đồng thông minh

Hợp đồng thông minh thường cần cơ chế bảo vệ chống phát lại bằng nonce riêng vì nonce tài khoản thông thường không bảo vệ mọi lệnh ủy quyền ở cấp hợp đồng.

Nếu hợp đồng chấp nhận chữ ký, hợp đồng phải xác định chữ ký đó đã được sử dụng hay chưa.

Ví dụ, hợp đồng nhận airdrop có thể sử dụng một ánh xạ đánh dấu người dùng đã nhận thưởng.

Hợp đồng quản trị có thể ghi nhận một địa chỉ đã bỏ phiếu cho đề xuất hay chưa.

Hợp đồng permit có thể lưu nonce cho từng chủ sở hữu.

Hợp đồng bridge có thể lưu ID thông điệp đã xử lý.

Hợp đồng escrow kiểu marketplace có thể lưu hash của các lệnh đã được khớp hoặc hủy.

Tất cả những cơ chế này đều là hình thức bảo vệ chống phát lại.

Cấu trúc dữ liệu cụ thể có thể khác nhau, nhưng mục tiêu vẫn giống nhau.

Hợp đồng phải ngăn cùng một lệnh ủy quyền tạo ra các thay đổi trạng thái lặp lại.

Bảo vệ chống phát lại cho bridge

Bridge cần cơ chế bảo vệ chống phát lại mạnh vì chúng chuyển giá trị hoặc thông điệp giữa các chain.

Thông điệp bridge có thể cho biết tài sản đã bị khóa trên một chain và cần được mint hoặc giải ngân trên chain khác.

Nếu cùng một thông điệp bridge có thể được xử lý hai lần, chain đích có thể giải ngân quá nhiều tài sản.

Cơ chế bảo vệ chống phát lại cho bridge thường sử dụng ID thông điệp, chain ID nguồn, chain ID đích, địa chỉ hợp đồng nguồn, số thứ tự và ánh xạ thông điệp đã xử lý.

Hợp đồng đích nên đánh dấu mỗi thông điệp hợp lệ là đã được xử lý.

Hợp đồng cần từ chối thông điệp nếu thông điệp đó được gửi lại.

Rủi ro phát lại liên chuỗi cao hơn vì các chain có thể dùng chung định dạng địa chỉ, ký hiệu token và giao diện hợp đồng thông minh.

Bridge phải ràng buộc mỗi thông điệp với chain nguồn, chain đích, hợp đồng bridge, người gửi, người nhận, số lượng và nonce dự kiến.

Cơ chế bảo vệ chống phát lại yếu cho bridge có thể dẫn đến lỗi mint token, mất tiền hoặc rủi ro thanh khoản mang tính hệ thống.

Bảo vệ chống phát lại cho giao dịch meta

Giao dịch meta là chỉ thị đã ký của người dùng được một bên khác gửi đi.

Người dùng ký off-chain, còn bên chuyển tiếp gửi giao dịch lên blockchain.

Cách này có thể giúp ứng dụng dễ sử dụng hơn vì người dùng có thể không cần trực tiếp trả phí gas bằng tài sản gốc.

Giao dịch meta cần cơ chế bảo vệ chống phát lại bằng nonce được thiết kế cẩn thận.

Nếu chỉ thị đã ký có thể được gửi nhiều lần, bên chuyển tiếp hoặc kẻ tấn công có thể lặp lại hành động đó.

Nonce tuần tự có thể gây vấn đề khi người dùng ký nhiều giao dịch meta trên các ứng dụng khác nhau cùng lúc.

Nonce ngẫu nhiên hoặc không gian nonce riêng cho từng ứng dụng có thể giảm tình trạng trùng lặp đó.

Deadline có thể giảm nguy cơ từ các chỉ thị đã ký cũ.

Tách biệt domain có thể ngăn chữ ký giao dịch meta của một ứng dụng bị sử dụng trên ứng dụng khác.

Bảo mật giao dịch meta phụ thuộc vào cơ chế bảo vệ chống phát lại cũng như xác minh chữ ký.

Bảo vệ chống phát lại cho thông điệp đăng nhập ví

Nhiều ứng dụng crypto yêu cầu người dùng ký thông điệp để chứng minh quyền sở hữu ví.

Đây là cách thường dùng để đăng nhập, liên kết tài khoản, cập nhật hồ sơ và xác thực off-chain.

Chữ ký đăng nhập nên bao gồm nonce hoặc thử thách do máy chủ tạo.

Sau khi đăng nhập thành công, máy chủ nên đánh dấu thử thách đó là đã được sử dụng.

Nếu có thể, thông điệp cũng nên bao gồm domain, chain, thời điểm phát hành, thời điểm hết hạn và hành động dự kiến.

Nếu thông điệp đăng nhập không có thử thách mới, kẻ tấn công có thể phát lại chữ ký cũ để mạo danh người dùng.

Nếu thông điệp đăng nhập không có domain chính xác, chữ ký từ một trang web có thể bị sử dụng trên trang web khác.

Đăng nhập ví thường diễn ra off-chain, nhưng bảo vệ chống phát lại vẫn rất quan trọng.

Chữ ký chứng minh quyền sở hữu ví không nên trở thành mật khẩu có thể tái sử dụng vĩnh viễn.

Chữ ký đăng nhập an toàn nhất là chữ ký cụ thể, mới, có giới hạn và dễ đọc.

Bảo vệ chống phát lại cho quản trị

Hệ thống quản trị cần cơ chế bảo vệ chống phát lại vì phiếu bầu và quyền ủy quyền không nên được tính nhiều lần hơn dự kiến.

Hợp đồng bỏ phiếu có thể lưu thông tin một địa chỉ đã bỏ phiếu cho đề xuất hay chưa.

Hợp đồng ủy quyền bằng chữ ký có thể sử dụng nonce để ngăn cùng chữ ký ủy quyền bị dùng lặp lại.

Hệ thống thực thi đề xuất có thể đánh dấu đề xuất là đã thực thi sau khi thực thi thành công.

Bảo vệ chống phát lại cũng rất quan trọng giữa các chain nếu quyết định quản trị được phản chiếu lên nhiều mạng.

Thông điệp quản trị được ký cho một chain không nên tự động được thực thi trên chain khác, trừ khi đó là chủ đích rõ ràng.

Lỗi bảo vệ chống phát lại trong quản trị có thể gây hậu quả nghiêm trọng vì chúng có thể thay đổi tham số giao thức, chuyển tiền từ quỹ dự trữ, nâng cấp hợp đồng hoặc điều chỉnh biện pháp kiểm soát rủi ro.

Hợp đồng quản trị tốt sẽ xử lý cẩn thận ID đề xuất, chain ID, địa chỉ hợp đồng, thời gian bỏ phiếu, nonce và trạng thái thực thi.

Phiếu bầu chỉ nên được sử dụng lại nếu hệ thống chủ động cho phép thay đổi phiếu trước thời hạn.

Ngay cả trong trường hợp đó, quy tắc tính phiếu cuối cùng vẫn phải rõ ràng.

Bảo vệ chống phát lại cho airdrop và yêu cầu nhận thưởng

Hợp đồng nhận airdrop và phần thưởng thường sử dụng cơ chế bảo vệ chống phát lại để ngăn người dùng nhận nhiều lần.

Hệ thống nhận thưởng đơn giản có thể lưu trạng thái đã nhận cho từng địa chỉ đủ điều kiện.

Airdrop Merkle có thể xác minh bằng chứng của người dùng rồi đánh dấu địa chỉ hoặc chỉ số nhận thưởng là đã sử dụng.

Yêu cầu nhận thưởng bằng chữ ký có thể bao gồm nonce, ID yêu cầu, ID chiến dịch, deadline và địa chỉ người dùng.

Nếu không có cơ chế bảo vệ chống phát lại, bằng chứng nhận thưởng hợp lệ có thể bị sử dụng lại cho đến khi pool cạn.

Cơ chế bảo vệ chống phát lại cũng cần tính đến việc tách biệt chiến dịch.

Chữ ký nhận thưởng cho Chiến dịch A không nên có hiệu lực với Chiến dịch B.

Yêu cầu nhận thưởng trên một chain không nên có hiệu lực trên chain khác, trừ khi được thiết kế rõ ràng để làm vậy.

Yêu cầu nhận một token không nên ủy quyền cho một token khác.

Thiết kế nhận thưởng tốt sẽ ràng buộc bằng chứng với đúng người dùng, chiến dịch, chain, token, số lượng và nonce.

Bảo vệ chống phát lại và deadline

Deadline là giới hạn thời gian của một lệnh ủy quyền đã ký.

Deadline không thay thế nonce, nhưng giúp rút ngắn khoảng thời gian chữ ký bị đánh cắp hoặc trì hoãn có thể được sử dụng.

ERC-2612 permit sử dụng trường deadline.

ERC-3009 sử dụng các trường validAfter và validBefore.

UserOperation của ERC-4337 có thể bao gồm phạm vi thời gian hiệu lực thông qua dữ liệu xác thực.

Deadline đặc biệt hữu ích khi người dùng cung cấp chữ ký cho bên chuyển tiếp hoặc ứng dụng có thể chọn thời điểm gửi chữ ký.

Nếu không có deadline, lệnh ủy quyền đã ký cũ có thể còn hữu dụng lâu hơn nhiều so với dự kiến của người dùng.

Khi có deadline, chữ ký sẽ hết hiệu lực sau một thời điểm xác định.

Deadline ngắn có thể tăng mức độ an toàn nhưng cũng làm tăng nguy cơ giao dịch thất bại khi mạng bị tắc nghẽn.

Deadline phù hợp nhất phụ thuộc vào giá trị, rủi ro, mức độ khẩn cấp và thời gian hoàn tất dự kiến của hành động.

Bảo vệ chống phát lại và tính lặp an toàn

Tính lặp an toàn (idempotency) có nghĩa là lặp lại cùng một hành động sẽ tạo ra kết quả cuối cùng giống như chỉ thực hiện hành động đó một lần.

EIP-712 lưu ý rằng ứng dụng nên từ chối thông điệp đã ký bị lặp lại hoặc khiến hành động được ủy quyền có tính lặp an toàn.

Ví dụ, đặt tên hồ sơ người dùng thành cùng một giá trị hai lần có thể không gây hại.

Chuyển 100 token hai lần thì không vô hại.

Phê duyệt spender hai lần có thể gây hại hoặc không, tùy thuộc vào số lượng và hạn mức hiện tại.

Bỏ phiếu quản trị hai lần có thể gây hại nếu cả hai phiếu đều được tính.

Nhận thưởng hai lần sẽ gây hại nếu người dùng nhận thưởng gấp đôi.

Nhà thiết kế nên quyết định liệu việc thực thi lặp lại sẽ bị từ chối hay được xử lý theo cách không gây hại.

Hầu hết hành động chuyển giá trị nên từ chối việc thực thi lặp lại.

Tính lặp an toàn có thể hữu ích cho các cập nhật trạng thái ít rủi ro, nhưng không nên áp dụng tùy tiện cho các hành động tài chính.

Bảo vệ chống phát lại và ràng buộc chữ ký

Chữ ký cần ràng buộc với chính xác hành động mà người dùng dự định thực hiện.

Điều này có nghĩa là thông điệp đã ký nên bao gồm người nhận, số lượng, token, hợp đồng, chain ID, mục đích của hàm, nonce, deadline và mọi tham số quan trọng.

Nếu chữ ký chỉ phê duyệt một nội dung mơ hồ, kẻ tấn công có thể tái sử dụng chữ ký trong ngữ cảnh rộng hơn.

Nếu chữ ký chỉ ký một con số mà không có địa chỉ token, con số đó có thể được diễn giải cho nhầm token.

Nếu chữ ký chỉ ký một địa chỉ đích mà không có chain ID, chữ ký có thể bị phát lại trên chain khác.

Nếu chữ ký chỉ ký địa chỉ người dùng mà không có địa chỉ hợp đồng, hợp đồng khác có thể chấp nhận chữ ký đó.

Cơ chế bảo vệ chống phát lại hiệu quả nhất khi chữ ký có phạm vi hẹp.

Chữ ký có phạm vi hẹp nêu chính xác điều gì được phép và không cho phép gì khác.

Chữ ký có phạm vi rộng tạo điều kiện cho việc phát lại, lạm dụng và gây nhầm lẫn cho người dùng.

Ví nên hiển thị rõ những chi tiết này trước khi người dùng ký.

Bảo vệ chống phát lại và phishing

Bảo vệ chống tấn công phát lại bằng nonce không thể bảo vệ người dùng hoàn toàn khỏi phishing.

Nếu người dùng ký một thông điệp độc hại với nonce hợp lệ, kẻ tấn công có thể sử dụng thông điệp đó một lần.

Nonce có thể ngăn việc sử dụng lặp lại, nhưng lần sử dụng đầu tiên vẫn có thể gây hại.

Ví dụ, trang phishing có thể yêu cầu người dùng ký permit cấp quyền chi tiêu token.

Permit có thể bao gồm nonce và deadline hợp lệ.

Sau khi được gửi, kẻ tấn công vẫn có thể sử dụng lệnh ủy quyền hợp lệ đó một lần.

Bảo vệ chống phát lại ngăn việc nhân bản, chứ không ngăn ý đồ xấu.

Người dùng vẫn cần xem xét nội dung mình ký.

Ví vẫn cần hiển thị cảnh báo rõ ràng, dễ hiểu.

Hợp đồng vẫn cần giới hạn quyền của chữ ký trong các hành động cụ thể.

Bảo vệ chống phát lại và front-running

Front-running xảy ra khi một bên khác nhìn thấy giao dịch hoặc chữ ký rồi gửi giao dịch của họ trước.

Bảo vệ chống tấn công phát lại bằng nonce có thể hạn chế thiệt hại bằng cách chỉ cho phép sử dụng chữ ký một lần.

Tuy nhiên, cơ chế này không phải lúc nào cũng ngăn được kẻ front-runner trở thành bên đầu tiên sử dụng chữ ký.

ERC-2612 lưu ý rằng bên khác có thể front-run lệnh gọi permit trước khi bên dự định gửi lệnh, dù kết quả phê duyệt cuối cùng đối với người ký có thể giống nhau.

ERC-3009 bao gồm receiveWithAuthorization để giảm một số vấn đề front-running bằng cách đảm bảo người nhận thanh toán khớp với bên gọi.

Điều này cho thấy bảo vệ chống phát lại và bảo vệ chống front-running có liên quan nhưng không giống nhau.

Nonce ngăn việc thực thi lặp lại.

Các biện pháp kiểm soát front-running xác định ai được phép gửi hoặc hưởng lợi từ lần thực thi đầu tiên.

Chữ ký có giá trị cao nên ràng buộc người nhận, deadline và ý định cụ thể của hàm.

Nhà thiết kế không nên cho rằng chỉ kiểm tra nonce là đủ để giải quyết mọi cuộc tấn công mempool.

Bảo vệ chống phát lại và tái sử dụng giữa các hợp đồng

Tấn công phát lại giữa các hợp đồng xảy ra khi chữ ký dành cho một hợp đồng được một hợp đồng khác chấp nhận.

Điều này có thể xảy ra nếu dữ liệu đã ký không bao gồm địa chỉ hợp đồng xác minh.

Tách biệt domain của EIP-712 giúp giảm rủi ro này bằng cách đưa verifyingContract vào domain.

ERC-2612 khuyến nghị sử dụng domain separator duy nhất cho hợp đồng và chain.

Tấn công phát lại giữa các hợp đồng cũng có thể xảy ra khi nhiều hợp đồng sử dụng cùng một lược đồ chữ ký nhưng không có domain riêng cho từng hợp đồng.

Ví dụ, hai hợp đồng token có thể cùng chấp nhận thông điệp dạng permit nếu dữ liệu đã ký quá chung chung.

Người dùng có thể định phê duyệt một token nhưng cùng chữ ký đó lại được token khác diễn giải.

Đó là lý do việc ràng buộc với địa chỉ hợp đồng là thiết yếu.

Chữ ký hợp lệ không nên được tự do sử dụng ở bất kỳ hợp đồng nào.

Chữ ký cần thuộc về một domain xác minh cụ thể.

Bảo vệ chống phát lại và tái sử dụng giữa các chain

Tấn công phát lại giữa các chain xảy ra khi giao dịch hoặc thông điệp được ký cho một chain được chain khác chấp nhận.

EIP-155 giảm rủi ro này đối với giao dịch theo chuẩn Ethereum bằng cách thêm chain ID vào hash giao dịch đã ký.

Dữ liệu định kiểu EIP-712 cũng hỗ trợ chainId trong domain ký.

Rủi ro phát lại giữa các chain vẫn có thể xuất hiện trong thông điệp cấp ứng dụng nếu dữ liệu đã ký bỏ qua chain ID.

Ví dụ, bridge, DAO, permit token hoặc chữ ký đăng nhập nên nêu rõ chain dự kiến khi ngữ cảnh chain có liên quan.

Chain ID đặc biệt quan trọng với các mạng tương thích EVM vì địa chỉ và bytecode hợp đồng có thể trông giống nhau trên các chain.

Người dùng có thể kiểm soát cùng một địa chỉ trên nhiều chain.

Hợp đồng có thể được triển khai tại cùng một địa chỉ trên nhiều chain thông qua triển khai xác định.

Nếu không ràng buộc với chain, chữ ký có thể được chuyển sang chain khác một cách nguy hiểm.

Thiết kế an toàn phải xác định rõ chain.

Bảo vệ chống phát lại và thay thế giao dịch

Thay thế giao dịch là khi người dùng phát một giao dịch mới có cùng nonce tài khoản nhưng phí cao hơn để thay thế giao dịch đang chờ.

Bản thân việc này không phải là một cuộc tấn công phát lại.

Đây là kỹ thuật quản lý giao dịch thông thường trong nhiều quy trình kiểu Ethereum.

Điểm mấu chốt là cuối cùng chỉ một giao dịch có nonce đó có thể được thực thi.

Người dùng có thể thay thế một giao dịch chậm bằng phiên bản nhanh hơn.

Người dùng có thể gửi giao dịch giá trị bằng 0 đến chính mình với cùng nonce để hủy giao dịch đang chờ.

Giao dịch thay thế phải tuân theo quy tắc tăng phí của mạng để được các node chấp nhận.

Bảo vệ chống tấn công phát lại bằng nonce là yếu tố giúp việc thay thế có ý nghĩa.

Nonce buộc mạng phải chọn một giao dịch cho vị trí đó.

Người dùng nên cẩn thận vì thay thế nhầm nonce có thể hủy hoặc thay thế hành động mà họ vẫn muốn thực hiện.

Bảo vệ chống phát lại và giao dịch bị kẹt

Giao dịch có thể bị kẹt khi giao dịch có phí thấp vẫn ở trạng thái chờ.

Nếu giao dịch đó sử dụng nonce tiếp theo được yêu cầu, các giao dịch sau từ cùng tài khoản cũng có thể bị chặn phía sau.

Đây là tác dụng phụ của nonce tuần tự.

Trong thứ tự giao dịch thông thường, tài khoản không thể bỏ qua nonce còn thiếu.

Người dùng có thể cần tăng tốc hoặc hủy giao dịch bị kẹt bằng cách gửi giao dịch thay thế có cùng nonce.

Ví thường tự động quản lý việc này, nhưng thiết lập nonce thủ công có thể gây nhầm lẫn.

Nếu người dùng đặt nonce quá cao, giao dịch có thể không được xác nhận cho đến khi các nonce trước đó được sử dụng.

Nếu người dùng đặt nonce quá thấp, giao dịch có thể thất bại vì nonce đó đã được sử dụng.

Bảo vệ chống tấn công phát lại bằng nonce bảo vệ tài khoản nhưng cũng đòi hỏi phải sắp xếp cẩn thận.

Người dùng nâng cao nên hiểu trạng thái nonce trước khi tự chỉnh nonce giao dịch.

Bảo vệ chống phát lại và khóa phiên

Khóa phiên là khóa có phạm vi sử dụng giới hạn, có thể ủy quyền một số hành động nhất định trong một khoảng thời gian.

Khóa này hữu ích cho trò chơi, đăng ký định kỳ, chiến lược tự động và ví trừu tượng hóa tài khoản.

Khóa phiên cần cơ chế bảo vệ chống phát lại bằng nonce mạnh vì chúng có thể ký nhiều hành động nhỏ.

Lệnh ủy quyền bằng khóa phiên nên bao gồm các giới hạn như hàm được phép, hạn mức chi tiêu, hợp đồng đích, thời điểm hết hạn, chain ID và quy tắc nonce.

Nếu không có bảo vệ nonce, kẻ tấn công lấy được một chữ ký khóa phiên có thể phát lại chữ ký đó nhiều lần.

Nếu không giới hạn hành động, khóa phiên có thể trở nên quá quyền hạn.

Nonce lane có thể giúp tách hành động của khóa phiên khỏi hành động của ví chính.

Điều này có thể giúp trải nghiệm người dùng mượt mà hơn mà vẫn bảo vệ chống phát lại.

Khóa phiên cần dễ thu hồi.

Phạm vi của chúng cũng cần đủ hẹp để hạn chế thiệt hại nếu bị phát lại.

Bảo vệ chống phát lại và ví multisig

Ví multisig cũng cần cơ chế bảo vệ chống phát lại.

Giao dịch multisig thường có nonce nội bộ để theo dõi các hành động ví đã thực thi.

Người ký phê duyệt hash giao dịch cụ thể có chứa nonce của ví và thông tin chi tiết về hành động.

Sau khi multisig thực thi giao dịch, nonce sẽ tăng lên hoặc hash giao dịch được đánh dấu là đã thực thi.

Cơ chế này ngăn cùng nhóm chữ ký bị sử dụng lại để thực thi cùng một hành động hai lần.

Cơ chế bảo vệ chống phát lại cho multisig nên ràng buộc chữ ký với địa chỉ ví, chain ID, địa chỉ đích, giá trị, dữ liệu, loại thao tác và nonce.

Nếu ví multisig được triển khai trên nhiều chain, bảo vệ chống phát lại giữa các chain càng trở nên quan trọng.

Người ký nên xác nhận chain và địa chỉ ví trước khi phê duyệt.

Không nên xem chữ ký multisig là an toàn chỉ vì có nhiều người ký.

Dữ liệu được ký vẫn cần cụ thể và có khả năng chống phát lại.

Bảo vệ chống phát lại và oracle

Hệ thống oracle có thể ký các bản cập nhật giá, xác nhận dữ liệu, báo cáo dự trữ, kết quả ngẫu nhiên hoặc thông điệp liên chuỗi.

Các gói dữ liệu đã ký đó cần có cơ chế bảo vệ chống phát lại.

Bản cập nhật giá cũ không nên được chấp nhận vô thời hạn.

Kết quả ngẫu nhiên không nên được tái sử dụng ở một vòng chơi khác.

Không nên phát lại xác nhận dự trữ sau khi hết hạn.

Thông điệp oracle nên bao gồm ID nguồn dữ liệu, ID vòng, dấu thời gian, số thứ tự, chain ID và hợp đồng đích khi phù hợp.

Hợp đồng nên từ chối thông điệp oracle cũ hoặc đã được sử dụng.

Bảo vệ chống phát lại rất quan trọng vì hợp đồng thông minh có thể tự động hoạt động dựa trên dữ liệu oracle.

Nếu dữ liệu cũ có thể bị phát lại, việc thanh lý, tất toán, mint, quy đổi hoặc chi trả có thể sai lệch.

Tính mới của dữ liệu oracle và kiểm soát nonce đều là một phần của bảo mật hợp đồng thông minh.

Chữ ký chính xác vẫn chưa đủ nếu dữ liệu đã cũ hoặc bị sử dụng lại.

Bảo vệ chống phát lại và phê duyệt token

Phê duyệt token là một trong những lĩnh vực nhạy cảm nhất về bảo vệ chống phát lại.

Lệnh phê duyệt on-chain thông thường sử dụng nonce tài khoản của giao dịch và cập nhật trạng thái hạn mức chi tiêu.

Permit đã ký sử dụng nonce cấp hợp đồng và deadline để ủy quyền phê duyệt mà không cần giao dịch trực tiếp từ chủ sở hữu.

Nếu chữ ký permit có thể bị phát lại, spender có thể lấy lại hạn mức chi tiêu sau khi người dùng nghĩ rằng quyền phê duyệt đã hết.

Nếu permit bỏ qua spender, token, giá trị, nonce, deadline hoặc domain, chữ ký có thể bị lạm dụng.

Người dùng nên xem phê duyệt đã ký là lệnh ủy quyền tài chính nghiêm túc.

Ví nên hiển thị rõ spender, token, số lượng, deadline và ứng dụng.

Hợp đồng nên từ chối ngay nonce permit đã được sử dụng.

Ứng dụng nên tránh yêu cầu phê duyệt không giới hạn, trừ khi thực sự cần thiết.

Thiết kế phê duyệt chống phát lại giúp giảm một trong những con đường phổ biến nhất dẫn đến tấn công rút tài sản khỏi ví.

Bảo vệ chống phát lại và nâng cấp hợp đồng thông minh

Hợp đồng có thể nâng cấp tạo thêm các vấn đề cần cân nhắc về phát lại.

Nếu hợp đồng được nâng cấp, chữ ký cũ vẫn có thể hợp lệ trừ khi phiên bản domain, logic nonce hoặc quy tắc xác thực thay đổi.

EIP-712 bao gồm trường version trong domain ký vì lý do này.

Khi nâng cấp hợp đồng lớn, cần xem xét liệu các lệnh ủy quyền cũ có còn an toàn hay không.

Nếu chữ ký cũ không nên hoạt động sau khi nâng cấp, hợp đồng có thể cần phiên bản domain mới hoặc phương thức vô hiệu hóa nonce.

Nếu chữ ký cũ vẫn cần tiếp tục hoạt động, quá trình nâng cấp phải duy trì chính xác trạng thái nonce.

Không chuyển đổi trạng thái nonce đúng cách có thể khiến chữ ký cũ bị phát lại hoặc làm chữ ký hợp lệ không thể sử dụng.

Kế hoạch nâng cấp nên bao gồm việc chuyển đổi chữ ký, thay đổi domain, bố cục lưu trữ nonce và thông tin gửi đến người dùng.

Bảo vệ chống phát lại không chỉ là vấn đề tại thời điểm triển khai.

Cơ chế này phải tiếp tục hoạt động qua các lần nâng cấp và di chuyển.

Bảo vệ chống phát lại và fork

Fork chain có thể tạo ra rủi ro phát lại nếu cả hai nhánh chấp nhận cùng định dạng giao dịch và trạng thái.

Nếu người dùng giữ cùng khóa riêng tư và trạng thái tài khoản trên cả hai chain, giao dịch trên một nhánh có thể bị phát lại trên nhánh còn lại, trừ khi có biện pháp bảo vệ khác nhau.

Cơ chế bảo vệ chain ID của EIP-155 được thiết kế để giảm rủi ro này đối với giao dịch Ethereum.

Tuy nhiên, chữ ký ở cấp ứng dụng vẫn cần được ràng buộc với chain.

Permit, phiếu bầu quản trị, thông điệp bridge hoặc lệnh off-chain được ký trước hoặc sau fork có thể hoạt động ngoài dự kiến nếu ngữ cảnh chain không rõ ràng.

Người dùng nên thận trọng khi xảy ra fork và phân tách chain.

Ví và ứng dụng nên cập nhật chain ID và domain separator chính xác.

Hợp đồng nên tránh lưu bộ nhớ đệm chain ID theo cách tạo ra rủi ro phát lại sau khi chain bị chia tách, trừ khi thiết kế xử lý an toàn tình huống đó.

Bảo vệ chống phát lại khi fork vừa là vấn đề của giao thức, vừa là vấn đề của ứng dụng.

Cần chú ý đến cả hai lớp.

Lợi ích của bảo vệ chống tấn công phát lại bằng nonce

Lợi ích đầu tiên là ủy quyền chỉ sử dụng một lần.

Hành động đã ký có thể được sử dụng một lần rồi bị từ chối trong các lần sau.

Lợi ích thứ hai là giao dịch có tính duy nhất.

Giao dịch từ cùng một tài khoản có thể được phân biệt bằng các giá trị nonce.

Lợi ích thứ ba là khả năng sắp xếp thứ tự.

Nonce tuần tự giúp xác định thứ tự hợp lệ của các giao dịch tài khoản.

Lợi ích thứ tư là an toàn liên chuỗi khi kết hợp với chain ID.

Chữ ký có thể được ràng buộc với mạng dự kiến.

Lợi ích thứ năm là tăng cường bảo mật hợp đồng thông minh.

Hợp đồng có thể ngăn permit, yêu cầu nhận thưởng, phiếu bầu, giao dịch chuyển tiền và thông điệp bridge bị lặp lại.

Lợi ích thứ sáu là trải nghiệm người dùng an toàn hơn.

Ví có thể phát hiện hành động đang chờ, giao dịch bị kẹt và giao dịch thay thế đáng tin cậy hơn.

Rủi ro và hạn chế của bảo vệ chống tấn công phát lại bằng nonce

Hạn chế đầu tiên là bảo vệ bằng nonce không ngăn lần đầu tiên sử dụng thông điệp độc hại.

Nếu người dùng ký một lệnh ủy quyền gây hại, nonce chỉ ngăn việc sử dụng lặp lại sau lần thực thi đầu tiên.

Hạn chế thứ hai là sự phức tạp trong quản lý giao dịch.

Nonce tuần tự có thể khiến giao dịch bị kẹt và hàng đợi bị chặn.

Hạn chế thứ ba là chi phí lưu trữ.

Hợp đồng lưu nonce ngẫu nhiên đã dùng có thể làm tăng mức sử dụng lưu trữ on-chain.

Hạn chế thứ tư là rủi ro triển khai.

Thiếu bước kiểm tra nonce có thể khiến chữ ký bị phát lại.

Hạn chế thứ năm là sự phức tạp giữa các domain.

Nonce có thể bảo vệ một hợp đồng nhưng không bảo vệ hợp đồng hoặc chain khác.

Hạn chế thứ sáu là rủi ro nâng cấp.

Trạng thái nonce có thể bị lỗi trong quá trình di chuyển hợp đồng nếu không được xử lý cẩn thận.

Các lỗi thường gặp với cơ chế bảo vệ chống tấn công phát lại bằng nonce

Một lỗi thường gặp là xác minh chữ ký nhưng không kiểm tra nonce.

Một lỗi khác là kiểm tra nonce nhưng quên tăng nonce hoặc đánh dấu nonce là đã sử dụng.

Lỗi thứ ba là dùng một nonce toàn cục cho tất cả người dùng thay vì nonce riêng cho từng người dùng.

Lỗi thứ tư là bỏ chain ID khỏi dữ liệu đã ký.

Lỗi thứ năm là bỏ địa chỉ hợp đồng xác minh khỏi dữ liệu định kiểu.

Lỗi thứ sáu là chấp nhận chữ ký không có deadline.

Lỗi thứ bảy là cho phép sử dụng cùng một nonce cho các loại hành động khác nhau.

Lỗi thứ tám là không di chuyển dữ liệu lưu trữ nonce khi nâng cấp.

Lỗi thứ chín là sử dụng nonce ngẫu nhiên có thể đoán trước.

Lỗi thứ mười là cho rằng EIP-712 tự động ngăn mọi cuộc tấn công phát lại.

Thực hành tốt nhất dành cho nhà phát triển

Thêm nonce vào mọi lệnh ủy quyền off-chain có thể làm thay đổi giá trị hoặc trạng thái.

Theo dõi nonce theo từng người ký thay vì dùng chung nonce toàn cục, trừ khi thiết kế yêu cầu rõ ràng một chuỗi toàn cục.

Tăng nonce hoặc đánh dấu nonce là đã sử dụng trước hoặc trong quá trình thực thi theo cách không thể bị vượt qua.

Đưa chain ID vào domain đã ký khi ngữ cảnh chain có liên quan.

Đưa địa chỉ hợp đồng xác minh vào domain đã ký.

Đưa ý định chính xác của hàm, người nhận, số lượng, token, deadline và các tham số liên quan vào thông điệp đã ký.

Sử dụng deadline hoặc khoảng thời gian hiệu lực cho chữ ký được chuyển tiếp.

Tách không gian nonce cho các quy trình không liên quan khi cần thực thi song song.

Phát sự kiện khi lệnh ủy quyền được sử dụng hoặc hủy.

Kiểm thử các trường hợp phát lại, chữ ký liên chuỗi, nâng cấp hợp đồng, hủy và đường dẫn thực thi thất bại trước khi triển khai.

Thực hành tốt nhất dành cho ví và ứng dụng

Hiển thị cho người dùng chain, hợp đồng, spender, số lượng, deadline, ngữ cảnh nonce và loại hành động trước khi họ ký.

Cảnh báo người dùng khi chữ ký cấp quyền chi tiêu hoặc lệnh ủy quyền dài hạn.

Sử dụng thử thách đăng nhập mới cho quy trình xác thực ví.

Đánh dấu thử thách xác thực là đã sử dụng sau khi đăng nhập.

Tránh yêu cầu người dùng ký thông điệp mơ hồ hoặc khó đọc.

Khi có thể, hãy sử dụng dữ liệu định kiểu EIP-712 để ký dữ liệu có cấu trúc.

Xử lý nonce giao dịch bị kẹt bằng các tùy chọn tăng tốc và hủy rõ ràng.

Không che giấu cách thức thay thế giao dịch với người dùng.

Chỉ hỗ trợ nonce lane của trừu tượng hóa tài khoản khi giao diện có thể giải thích chúng an toàn.

Bảo vệ người dùng khỏi yêu cầu ký cũ, hết hạn hoặc không đúng chain.

Thực hành tốt nhất dành cho người dùng

Đọc lời nhắc trong ví trước khi ký bất kỳ thông điệp hoặc giao dịch nào.

Kiểm tra chain trước khi ký.

Kiểm tra hợp đồng hoặc ứng dụng yêu cầu chữ ký.

Kiểm tra token, spender, số lượng và deadline trong các phê duyệt dạng permit.

Từ chối chữ ký mơ hồ, không giới hạn hoặc không liên quan đến hành động bạn đang thực hiện.

Không ký thông điệp đăng nhập từ domain đáng ngờ.

Đừng cho rằng nonce khiến chữ ký độc hại trở nên an toàn.

Nếu khả thi, hãy dùng ví phần cứng hoặc multisig để lưu trữ số dư lớn.

Thu hồi các phê duyệt token không cần thiết khi phù hợp.

Thận trọng khi cài nonce thủ công, trừ khi bạn hiểu trạng thái giao dịch đang chờ.

Khi nào bảo vệ chống tấn công phát lại bằng nonce quan trọng nhất?

Bảo vệ chống tấn công phát lại bằng nonce quan trọng nhất khi chữ ký ủy quyền việc chuyển giá trị.

Cơ chế này quan trọng với các giao dịch blockchain thông thường.

Cơ chế này quan trọng với phê duyệt permit.

Cơ chế này quan trọng với giao dịch chuyển token không cần gas.

Cơ chế này quan trọng với thông điệp bridge.

Cơ chế này quan trọng với phiếu bầu và ủy quyền quản trị.

Cơ chế này quan trọng với yêu cầu nhận airdrop và phần thưởng.

Cơ chế này quan trọng với thử thách đăng nhập ví.

Cơ chế này quan trọng với giao dịch multisig và UserOperation của trừu tượng hóa tài khoản.

Cơ chế này quan trọng ở mọi nơi mà chữ ký bị sao chép có thể gây ra tác động lặp lại hoặc ngoài ý muốn.

Bảo vệ chống tấn công phát lại bằng nonce trong một câu

Bảo vệ chống tấn công phát lại bằng nonce là việc sử dụng các giá trị nonce duy nhất, được theo dõi và ràng buộc với ngữ cảnh để đảm bảo giao dịch, thông điệp hoặc lệnh ủy quyền crypto đã ký chỉ có thể được thực thi một lần trong đúng ngữ cảnh chain, hợp đồng và ứng dụng dự kiến.

Câu hỏi thường gặp

Bảo vệ chống tấn công phát lại bằng nonce có nghĩa là gì?

Bảo vệ chống tấn công phát lại bằng nonce là ngăn cùng một hành động crypto đã ký được chấp nhận nhiều lần bằng cách kiểm tra và tiêu thụ nonce duy nhất.

Nonce trong crypto là gì?

Nonce là một con số hoặc giá trị duy nhất chỉ được sử dụng một lần trong một ngữ cảnh cụ thể để giúp giao dịch, thông điệp hoặc lệnh ủy quyền trở nên duy nhất.

Tấn công phát lại là gì?

Tấn công phát lại xảy ra khi ai đó sao chép một hành động đã ký hợp lệ rồi gửi lại để lặp lại hoặc lạm dụng lệnh ủy quyền.

Ethereum sử dụng nonce như thế nào?

Tài khoản Ethereum sử dụng bộ đếm nonce để mỗi tài khoản chỉ có thể thực thi một giao dịch với một nonce nhất định.

Bảo vệ chống phát lại bằng chain ID là gì?

Bảo vệ chống phát lại bằng chain ID ràng buộc giao dịch hoặc thông điệp với một blockchain cụ thể để hạn chế khả năng tái sử dụng trên chain khác.

EIP-712 có tự động ngăn tấn công phát lại không?

Không. EIP-712 cấu trúc dữ liệu đã ký, nhưng ứng dụng vẫn cần kiểm tra nonce, deadline và tách biệt domain chính xác.

Tại sao permit cần nonce?

Permit cần nonce để cùng một phê duyệt token đã ký không thể bị gửi nhiều lần.

Nonce khác deadline như thế nào?

Nonce khiến chữ ký chỉ được sử dụng một lần, còn deadline giới hạn khoảng thời gian chữ ký còn hiệu lực.

Bảo vệ chống phát lại có ngăn được phishing không?

Không. Bảo vệ chống phát lại có thể ngăn việc sử dụng lặp lại nhưng không thể ngăn lần đầu sử dụng gây hại nếu người dùng ký lệnh ủy quyền độc hại.

Điều gì xảy ra nếu nonce được sử dụng lại?

Nếu cơ chế xử lý nonce hoạt động chính xác, lần sử dụng thứ hai sẽ thất bại. Tuy nhiên, nếu hệ thống được thiết kế kém, việc dùng lại nonce có thể gây ra vấn đề phát lại hoặc giao dịch thất bại.

Tại sao hợp đồng thông minh cần tự kiểm tra nonce?

Hợp đồng thông minh cần kiểm tra nonce vì nonce tài khoản thông thường không tự động bảo vệ chữ ký off-chain, permit, yêu cầu nhận thưởng, phiếu bầu hoặc thông điệp bridge.

Thiết kế bảo vệ chống phát lại an toàn nhất là gì?

Thiết kế an toàn nhất kết hợp nonce theo từng người ký, chain ID, hợp đồng xác minh, thông tin hành động chính xác, deadline, theo dõi trạng thái đã sử dụng và xác thực chữ ký cẩn thận.

Kết luận

Bảo vệ chống tấn công phát lại bằng nonce là một trong những nền tảng bảo mật thầm lặng của tiền mã hóa.

Cơ chế này đảm bảo chữ ký hợp lệ không trở thành một tấm séc khống có thể tái sử dụng.

Chữ ký blockchain chứng minh khóa riêng tư đã phê duyệt một thông điệp, nhưng không tự động chứng minh rằng sự phê duyệt đó còn mới, chưa được sử dụng hoặc chỉ giới hạn trong một lần thực thi.

Nonce bổ sung lớp bảo vệ về tính mới đó.

Khi nonce được kiểm tra và tiêu thụ chính xác, cùng một hành động đã ký không thể được thực thi lại.

Cơ chế này bảo vệ giao dịch thông thường, permit token, giao dịch chuyển tiền không cần gas, thao tác tài khoản thông minh, phê duyệt multisig, thông điệp bridge, phiếu bầu quản trị, thử thách đăng nhập, yêu cầu nhận phần thưởng và nhiều quy trình crypto khác.

Cơ chế bảo vệ chống phát lại hiện đại không chỉ là một bộ đếm.

Cơ chế này thường kết hợp nonce tài khoản, nonce cấp hợp đồng, ID ủy quyền ngẫu nhiên, chain ID, địa chỉ hợp đồng xác minh, deadline, khoảng thời gian hiệu lực, nonce lane và ánh xạ thông điệp đã xử lý.

Mỗi lớp giải quyết một vấn đề phát lại khác nhau.

Nonce tài khoản ngăn giao dịch từ cùng tài khoản bị lặp lại trên cùng chain.

Chain ID ngăn giao dịch bị sao chép sang các chain khác.

Nonce hợp đồng ngăn thông điệp đã ký bị tái sử dụng trong ứng dụng.

Deadline ngăn chữ ký cũ còn hiệu lực vô thời hạn.

Tách biệt domain ngăn chữ ký bị chuyển sang nhầm hợp đồng hoặc ứng dụng.

Nonce lane cho phép tài khoản thông minh hỗ trợ quy trình song song mà vẫn bảo vệ chống phát lại.

Rủi ro có thể nghiêm trọng nếu thiếu các biện pháp kiểm soát này.

Chữ ký có thể bị phát lại có thể làm cạn tiền, lặp lại phê duyệt, nhân đôi yêu cầu nhận thưởng, thực thi thông điệp bridge hai lần hoặc làm sai lệch hoạt động quản trị.

Ngay cả khi có bảo vệ bằng nonce, người dùng vẫn có thể bị phishing gây hại nếu ký lệnh ủy quyền độc hại một lần.

Đó là lý do cần kết hợp bảo vệ chống phát lại với lời nhắc rõ ràng trong ví, phạm vi chữ ký hẹp, thiết kế hợp đồng chặt chẽ và hành vi cẩn trọng của người dùng.

Quy tắc dành cho nhà phát triển rất đơn giản.

Mọi chữ ký có thể chuyển giá trị hoặc thay đổi trạng thái quan trọng đều cần nonce, domain và quy tắc tiêu thụ rõ ràng.

Quy tắc dành cho ví là hiển thị chính xác nội dung người dùng đang ủy quyền trước khi họ ký.

Quy tắc dành cho người dùng là xem mỗi chữ ký như một hành động thực sự, không phải xác nhận vô hại.

Bảo vệ chống tấn công phát lại bằng nonce không khiến crypto không có rủi ro.

Cơ chế này giúp việc ủy quyền bằng chữ ký trở nên thiết thực bằng cách đảm bảo một lần phê duyệt chỉ tương ứng với một lần sử dụng dự kiến, trong một ngữ cảnh dự kiến, chứ không phải vô số lần phát lại trong tương lai.