2010-01-03 24 views
7

Ứng dụng của tôi phải đọc url SSL từ bên thứ ba. Làm thế nào để lưu trữ tốt nhất thông tin đăng nhập của bên thứ ba trong cơ sở dữ liệu của riêng tôi, bảo vệ thông tin đăng nhập của bên thứ ba khỏi bị xâm nhập? Hãy xem xét cả an ninh tuyệt đối và tính thực tiễn. Một cách băm thông tin đăng nhập không hữu ích vì tôi phải khôi phục thông tin đăng nhập vào văn bản thuần túy cho cuộc gọi SSL. Tôi đang sử dụng python trên công cụ ứng dụng của google và ứng dụng của tôi xác thực bằng thông tin đăng nhập google.i * phải * lưu trữ thông tin đăng nhập của bên thứ ba trong cơ sở dữ liệu của tôi. cách tốt nhất?

  • bằng chứng xác thực mã hóa bằng cách sử dụng ví dụ: AES và lưu khóa mã hóa ở một nơi khác (chỉ cần di chuyển vấn đề) hoặc derive it from the credentials and keep the algorithm secret (chỉ cần di chuyển vấn đề)
  • thông tin mã hóa bằng cách sử dụng synchronous stream cipher, lấy entropy (không) từ thông tin xác thực và keep the algorithm secret (chỉ di chuyển vấn đề)
  • trên một ứng dụng web riêng biệt dành riêng cho lưu trữ thông tin đăng nhập của bên thứ ba, cung cấp url SSL để nhận thông tin đăng nhập của bên thứ ba, url này được truy cập bằng thông tin đăng nhập google (giống như ứng dụng của tôi) và có thể sử dụng authsub hoặc thứ gì đó để chuyển ủy quyền cho người khác ứng dụng web. điều này nghe có vẻ an toàn hơn bởi vì nó khó khăn hơn để hack một ứng dụng web đơn giản tầm thường và nếu ứng dụng chính phức tạp của tôi bị xâm phạm thì thông tin đăng nhập của bên thứ ba không được hiển thị.

bạn nghĩ gì về tất cả các phương pháp tiếp cận?

+0

không rõ bạn đang hỏi gì? URL SSL ở đó để mã hóa thông tin đăng nhập được gửi qua đó. –

+1

Tôi sợ lưu trữ thông tin đăng nhập bên ngoài trong cơ sở dữ liệu của mình –

+0

Tôi không thấy cách tiếp cận thứ ba cũng không di chuyển vấn đề. Nó chỉ di chuyển nó đến một ứng dụng khác, thay vì cùng một ứng dụng. –

Trả lời

2

Đó là một nhiệm vụ khó khăn và không có cách tiếp cận nào giúp bạn tránh được rắc rối để đảm bảo rằng không có liên kết yếu. Để bắt đầu, tôi sẽ không biết liệu lưu trữ trên Google có phải là cách tốt nhất hay không, bởi vì bạn sẽ mất quyền kiểm soát (Tôi thực sự không biết liệu App Engine có được thiết kế với mức độ bảo mật cần thiết hay không, bạn nên tìm ra ngoài) và có lẽ không thể làm thử nghiệm thâm nhập (mà bạn nên.)

Có một ứng dụng nhỏ riêng biệt có lẽ là một ý tưởng hay, nhưng điều đó không giúp bạn tránh phải mã hóa một chiều hoặc các thông tin đăng nhập khác ứng dụng nhỏ hơn. Nó chỉ giúp bạn đơn giản hóa, điều này làm cho mọi việc dễ dàng hơn để phân tích.

Cá nhân tôi sẽ cố gắng thiết kế ứng dụng để các thay đổi chính ngẫu nhiên sau mỗi lần sử dụng, có cách tiếp cận one time pad. Bạn không chỉ định ứng dụng đủ chi tiết để xem liệu điều này có khả thi hay không.

2

Nếu bạn cần lưu trữ ngược thông tin xác thực, đơn giản là không có giải pháp. Sử dụng AES và giữ bí mật khóa dưới sự bảo vệ vũ trang được trả lương tốt.

Nếu bạn sử dụng cửa sổ, tôi sẽ kiểm tra API Cred * Win32 (advapi32.dll) ít nhất nó sẽ cho phép bạn quản lý khóa vào cửa sổ syskey nơi TPM và mật khẩu khởi động có thể bảo vệ chống lại mức độ thỏa hiệp thấp (bị đánh cắp ổ đĩa)

Rõ ràng là nếu ứng dụng của bạn hoặc bối cảnh bảo mật mà nó chạy bị xâm phạm thì không có phần nào ở trên sẽ giúp ích nhiều.

3

Thông tin đăng nhập được sử dụng như thế nào? Nếu việc sử dụng của họ chỉ được kích hoạt bởi chủ sở hữu ban đầu (ví dụ: bạn đang lưu trữ số thẻ ngân hàng và họ đang thực hiện giao dịch mua thứ 2) thì họ có thể cung cấp mật khẩu tại thời điểm đó được sử dụng làm khóa mã hóa của bạn. Sau đó bạn sẽ không bao giờ cần phải lưu trữ khóa đó tại địa phương và nội dung cơ sở dữ liệu một mình là vô dụng đối với kẻ tấn công.

+0

creds được gọi khi ứng dụng của tôi nhận được một email (thực sự là một tin nhắn SMS) từ địa chỉ đã đăng ký và sau đó ứng dụng của tôi phản hồi địa chỉ đó. Vì vậy, im khá chắc chắn họ cần phải được lưu trữ. –

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