2012-05-15 34 views
5

Tôi đang làm việc trên ứng dụng javascript mã nguồn mở Tôi đang cố gắng giao tiếp với API của bên thứ ba (github cụ thể). Tôi đang cố giữ toàn bộ ứng dụng phía máy khách của mình, vì vậy tôi thực sự sẽ không có máy chủ để quay lại hoặc lưu trữ các tệp ẩn. Là một phần của quy trình OAuth, tôi cần phải cung cấp khóa bí mật được cung cấp cho khóa api của mình. Tôi không được phép xuất bản hoặc chia sẻ khóa này.Ẩn khóa bí mật trong kho công cộng

tôi đã đưa ra các giải pháp sau đây:

  1. Mã hóa khóa bí mật sử dụng triple-DES và cụm từ mật khẩu.
  2. Đặt phiên bản được mã hóa vào kho của tôi ở đâu đó.
  3. Khi tôi cần xác thực qua Oauth, hãy nhắc cụm mật khẩu và khôi phục khóa bí mật.
  4. Khi đã biết, lưu trữ bí mật trong bộ nhớ cục bộ để tránh các lời nhắc trong tương lai.

Tôi chủ yếu lưu trữ phiên bản đã thay đổi của khóa bí mật thứ. Tôi đoán tất cả điều này mua cho tôi là tôi phải nhận được mật khẩu từ người dùng thay vì chìa khóa đầy đủ. Nó sẽ dễ nhớ hơn một chút so với các byte ngẫu nhiên.

Tính năng này có đủ an toàn không? Nó không phải là một ứng dụng siêu quan trọng, nhưng tôi muốn làm hết sức mình để bảo vệ những điều mà tôi được bảo không chia sẻ. Có cách nào tốt hơn 3DES để mã hóa khóa theo cách ngược lại không?

+0

Tắt OAuth phía máy khách không thực sự được hỗ trợ bởi github vì lý do này. Họ không muốn các khóa bí mật được hiển thị. Vẫn có thể hữu ích nếu giao dịch với apis ít picky mặc dù. – captncraig

+0

Tôi thực sự không hiểu kịch bản. Bạn đang cố gắng để ẩn chìa khóa để github từ người sử dụng, mặc dù họ đang chạy các khách hàng sử dụng phím? Nếu vậy, bạn không thể làm điều đó một cách an toàn; người dùng được xác định sẽ luôn có thể khôi phục khóa này và từ quan điểm đạo đức, bạn không nên cố giấu thông tin được lưu trữ trên máy từ chủ sở hữu của nó. Nếu mỗi người dùng có khóa github riêng của họ và bạn chỉ đang tìm kiếm một cách thuận tiện hơn để ghi nhớ nó, giải pháp của bạn là tốt. – erickson

Trả lời

2

Điều đó nghe có vẻ đủ để giữ bí mật điều gì đó; mặc dù Triple DES là một ít ngày.

Tôi sẽ sử dụng vòng X của SHA-256 để băm cụm mật khẩu, sau đó sử dụng hàm băm đó làm khóa AES-256.

+0

Hoặc chỉ sử dụng thư viện như [SJCL] (https://crypto.stanford.edu/sjcl/) cung cấp thuật toán hoạt động như bạn đã trình bày. Khi nói đến mật mã thực hiện một cái gì đó chính mình thường dẫn đến các vấn đề an ninh. – Robert

+1

Không chỉ sử dụng SHA-256, sử dụng thuật toán dẫn xuất khóa thực (như PBKDF2) được thiết kế và đánh giá tốt. Ví dụ, dẫn xuất quan trọng nên sử dụng muối. – erickson

5

Vấn đề với giải pháp này là ứng dụng phải chứa mã (và có thể là khóa) để giải mã nó. Giải pháp tốt nhất là không đưa vào kho lưu trữ.

Hầu hết các ứng dụng lưu trữ loại dữ liệu này trong tệp cấu hình bị bỏ qua bởi phần mềm điều khiển phiên bản. Sau đó bao gồm một tập tin cấu hình ví dụ với một khóa giả và hướng dẫn về cách đổi tên tập tin và có được một khóa api của riêng mình.

Một ví dụ điển hình về điều này là ở số wordpress's config file trong "Xác thực khóa và muối duy nhất". phần.

+0

Khi lưu trữ trên trang github, kho lưu trữ là triển khai. Không có cách nào để tách cả hai. – captncraig

+0

Thats một vấn đề thú vị, tôi đoán không có cách nào tốt để đảm bảo key.Điều đó có nghĩa là bạn còn lại với giảm nhẹ. Giữ một khóa riêng cho ứng dụng này.Nếu nó bị xâm phạm, bạn có thể hủy bỏ nó mà không ảnh hưởng đến các ứng dụng khác. – AaronAsAChimp

Các vấn đề liên quan