Kỹ thuật tạo khóa API

Tôi đang thiết kế một api web cần cấp quyền truy cập vào các ứng dụng khách khác nhau thông qua khóa api được gửi dưới dạng tiêu đề http. Tôi biết, không thực sự nên làm như thế nào nhưng tôi không kiểm soát được phần này.

Thiết kế hiện tại của tôi cho khóa api: có 16 byte cho id ứng dụng (hướng dẫn) trong cơ sở dữ liệu + 16 byte được tạo ngẫu nhiên (keybyte). Do chính sách của công ty, tôi được yêu cầu không lưu trữ khóa api trong db nên tôi lưu trữ hàm băm sha256 của (client + keybytes + salt) và muối trong cơ sở dữ liệu.

Bất cứ khi nào có yêu cầu, tôi chia khóa api thành (id, keybyte), tra cứu ứng dụng khách trong cơ sở dữ liệu theo id, sau đó tính sha256 (id + keybyte + salt-from-db) và kiểm tra xem nó có khớp với hàm băm được lưu trữ trong cơ sở dữ liệu không . Các yêu cầu từ nhóm bảo mật của công ty là không lưu trữ khóa api trong db mà lưu trữ hàm băm của nó (giống như mật khẩu người dùng). Tôi cũng đã xem xét PBKDF2 (tôi đang sử dụng .net 5) nhưng có thể quá chậm để thực hiện mỗi lần truy cập đến (nó phải chạy cho từng yêu cầu vì tôi không thể thay đổi ứng dụng khách để đăng nhập thông qua lệnh gọi chậm rồi gửi mã thông báo, họ được cho là chỉ gửi khóa với mọi yêu cầu).

Về cơ bản, điều này giống như lưu trữ sha256(password+salt) trong db cho người dùng, vì vậy tôi thực sự không chắc liệu nó có "đủ tốt" hay không (với điều kiện mật khẩu là 16 byte ngẫu nhiên và id người dùng là 16 byte ngẫu nhiên khác - hướng dẫn ứng dụng và db là về mặt lý thuyết không truy cập được).

Một giải pháp thay thế mà tôi có cho các khóa api là sử dụng AES-GCM: tạo nonce ngẫu nhiên (iv) và mã hóa id ứng dụng (hướng dẫn) bằng khóa bí mật (chỉ được lưu trữ trong cài đặt webapi, không phải db) và sử dụng byte (nonce , mã hóa, thẻ) làm khóa api. Điều này có nghĩa là không tra cứu cơ sở dữ liệu trong trường hợp khóa api không hợp lệ. Tuy nhiên, tôi không chắc giải pháp này an toàn đến mức nào (xét cho cùng, tôi chỉ mã hóa một khối dữ liệu 128 bit - hướng dẫn appid - bằng một khóa, trong số tất cả các ứng dụng).

Cái nào là "chấp nhận được" (nếu là cả hai, tôi sẽ lấy cái đầu tiên vì nó đã được triển khai) trong trường hợp "vi phạm bảo mật (ví dụ như cơ sở dữ liệu bị đánh cắp)?

Tôi biết, nếu họ truy cập được db, khóa api là điều tôi ít quan tâm nhất, nhưng tôi vẫn muốn nghe ý kiến ​​​​....

Bất cứ khi nào có yêu cầu, tôi chia khóa api thành (id, keybyte), tra cứu ứng dụng khách trong cơ sở dữ liệu theo id, sau đó tính sha256 (id + keybyte + salt-from-db) và kiểm tra xem nó có khớp với hàm băm được lưu trữ trong cơ sở dữ liệu không . Các yêu cầu từ nhóm bảo mật của công ty là không lưu trữ khóa api trong db mà lưu trữ hàm băm của nó (giống như mật khẩu người dùng). Tôi cũng đã xem xét PBKDF2 (tôi đang sử dụng .net 5) nhưng có thể quá chậm để thực hiện mỗi lần truy cập đến (nó phải chạy cho từng yêu cầu vì tôi không thể thay đổi ứng dụng khách để đăng nhập thông qua lệnh gọi chậm rồi gửi mã thông báo, họ được cho là chỉ gửi khóa với mọi yêu cầu).

Nếu khóa vẫn là bí mật và bao gồm 16 byte hoàn toàn ngẫu nhiên thì không cần PBKDF2; hàm băm an toàn đã là một chiều và không thể cưỡng bức khóa 128 bit. 16 byte ngẫu nhiên khác trong UID thêm kem trên bánh, vì nó tránh được vấn đề sinh nhật.

Về cơ bản, điều này giống như lưu trữ sha256(password+salt) trong db cho người dùng, vì vậy tôi thực sự không chắc liệu nó có "đủ tốt" hay không (với điều kiện mật khẩu là 16 byte ngẫu nhiên và id người dùng là 16 byte ngẫu nhiên khác - app và db về mặt lý thuyết là không thể truy cập được).

Với khóa 128 bit, việc có bao nhiêu thông tin ngẫu nhiên khác trong đó không thực sự quan trọng. Tuy nhiên, có thể tốt hơn nếu sử dụng KBKDF thực (chức năng dẫn xuất khóa dựa trên khóa) hoặc HMAC, ở đó khóa được sử dụng làm vật liệu tạo khóa đầu vào. Bạn cũng nên đảm bảo rằng các đầu vào ở dạng mã hóa chuẩn - nhưng nếu tất cả các trường đều có kích thước được xác định trước thì bạn chỉ cần nối chúng.

Một giải pháp thay thế mà tôi có cho các khóa api là sử dụng AES-GCM: tạo nonce ngẫu nhiên (iv) và mã hóa id ứng dụng (hướng dẫn) bằng khóa bí mật (chỉ được lưu trữ trong cài đặt webapi, không phải db) và sử dụng byte (nonce , mã hóa, thẻ) làm khóa api. Điều này có nghĩa là không tra cứu cơ sở dữ liệu trong trường hợp khóa api không hợp lệ. Tuy nhiên, tôi không chắc giải pháp này an toàn đến mức nào (xét cho cùng, tôi chỉ mã hóa một khối dữ liệu 128 bit - hướng dẫn appid - bằng một khóa, trong số tất cả các ứng dụng).

Bạn không cần bảo mật ở đây, chỉ cần xác minh đầu vào. Vì vậy, mã hóa dường như là một sự phức tạp không cần thiết. Tuy nhiên, tôi có một câu hỏi cấp bách hơn: làm cách nào để bạn bảo vệ khóa và làm cách nào để chống lại các cuộc tấn công lặp lại?

Thông thường, bạn chỉ có thể lưu trữ một UID ngẫu nhiên dưới dạng mã thông báo và để TLS xử lý phần còn lại. Đó dường như là điều mà hầu hết mọi người làm, nhưng tôi không quen thuộc với trường hợp sử dụng của bạn. Điều đó cũng có nghĩa là bạn nên coi thường mọi lời khuyên này. Tôi khuyên bạn nên nhờ một chuyên gia bảo mật xem xét và bắt đầu bằng cách xác định những gì bạn cần, ai và những gì bạn cần bảo vệ.