2009-07-16 42 views
8

Tôi có một chương trình, trong đó mật khẩu cho cơ sở dữ liệu được thiết lập bởi người dùng từ xa. Chương trình sẽ lưu tên người dùng và mật khẩu vào một chuỗi được mã hóa trong một tệp xml mà nếu không sẽ có thể đọc được. Bây giờ, điều này hoạt động tốt, tôi sử dụng mã hóa C# DES với một khóa, và nó được mã hóa và giải mã. Bây giờ, vấn đề là bất cứ ai có thể sử dụng phản xạ để xem chìa khóa. Ngay cả với obfuscation, chìa khóa nên được dễ dàng rõ ràng. Vì vậy, làm thế nào để đối phó với điều này? Bây giờ, tôi không cần điều này để được NSA an toàn, nhưng tôi thực sự muốn ngăn chặn bất cứ ai nhìn trộm. Cảm ơn.Mã hóa C# trong độ tuổi phản xạ

EDIT: Cảm ơn tất cả các lời khuyên cho đến nay, thông tin về loại điều này không phải là rất phổ biến, và tôi thực sự đánh giá cao lời khuyên chung cũng như câu trả lời cụ thể.

+1

Bạn đang đặt câu hỏi bảo mật. Bạn đã xác định được _vulnerable resource_ - cơ sở dữ liệu. Bạn đã xác định _vulnerability_ - thiếu mã hóa hiệu quả trên tệp mật khẩu. Bạn chưa xác định được _threat_. Đó là nguy hiểm phản tác dụng để cố gắng tìm ra các giảm nhẹ đối với lỗ hổng mà không xác định được mối đe dọa đầu tiên! Ai đang đe dọa tài nguyên của bạn và làm cách nào? –

+0

Vâng, không có ai cụ thể, tôi muốn viết mã cho ứng dụng của mình để bảo mật và không có phương pháp hay nhất nào. – Steve

+2

Cách thực hành tốt nhất # 1 để mã hóa các ứng dụng bảo mật là xác định THREATS. Bạn không thể an toàn nếu bạn thậm chí không biết những mối đe dọa bạn đang bảo vệ mã chống lại. Ý tôi là, giả sử tôi yêu cầu bạn thiết kế cho tôi một ngôi nhà an toàn.Có thể bạn sẽ bắt đầu bằng cách đưa ra một danh sách các mối đe dọa cho những người cư ngụ của ngôi nhà như là bước đầu tiên, phải không? –

Trả lời

8

Hãy thử sử dụng DPAPI (System.Security.ProtectedData class). Điều này bảo vệ dữ liệu được mã hóa của bạn bằng thông tin người dùng hoặc máy. Vì vậy, chỉ có tài khoản người dùng đang truy cập dữ liệu (thông tin người dùng) hoặc người dùng có thể đăng nhập vào máy (thông tin đăng nhập máy) sẽ có thể giải mã dữ liệu của bạn.

+0

cách tiếp cận này hoạt động tốt cho các chương trình phía máy chủ, nhưng không mở rộng tốt cho phía máy khách –

+0

@Scott bạn có thể làm rõ –

+2

Điều này làm việc đặc biệt tốt cho mã phía máy khách. Thật khó để sử dụng DPAPI trên một ứng dụng phía máy chủ (mạo danh, truy cập tài khoản dịch vụ vào các cấu hình, v.v.). Trên máy khách, người dùng chỉ định mật khẩu của họ vào lần chạy đầu tiên của ứng dụng được mã hóa bằng khóa DPAPI của họ. Dữ liệu được mã hóa được lưu trữ trên hệ thống của họ để chỉ họ (hoặc quản trị viên) mới có thể giải mã dữ liệu đó. Khi người dùng khởi động lại ứng dụng, DPAPI sử dụng các khóa của họ để giải mã mật khẩu. Bạn nhận được lợi ích của việc không lưu trữ một khóa mã hóa phổ biến trong hội đồng nơi nó có thể dễ dàng bị nứt. –

5

Đây không thực sự là vấn đề về người quan tâm hay không. Đó là về quản lý chủ chốt. DES và bất kỳ chương trình mã hóa nào khác dựa trên các khóa được thay đổi thường xuyên. Khó mã hóa khóa trong mã rõ ràng là vi phạm điều này. Để giải quyết vấn đề này, bạn nên xem xét việc quản lý khóa.

EDIT: Để xây dựng một chút: Tùy thuộc vào bạn thiết lập, bạn có thể lưu trữ mật khẩu băm trong hệ thống tệp và dựa vào hệ thống tệp/bảo mật người dùng hoặc trong cơ sở dữ liệu.

+4

bạn có thể cụ thể hơn về cách xử lý khóa hoặc mật khẩu này không? – Steve

+0

Hãy bình luận khi bỏ phiếu xuống. Cảm ơn. –

2

Thật không may, không bao giờ có cách an toàn 100% để thực hiện việc này. Bạn có thể làm xáo trộn mã, sử dụng mã không được quản lý cho các khu vực bí mật, nhưng vì ứng dụng của bạn có thể đọc lại mật khẩu, nên bất kỳ kẻ tấn công nào có đủ nỗ lực vào nó.

1

Bạn không nên lưu trữ mật khẩu được mã hóa. Bạn nên lưu trữ nó băm thay vào đó, với hàm băm một chiều. Xem:

http://www.codinghorror.com/blog/archives/000953.html

+1

Không giúp đỡ trong tình huống của OP, nơi anh ta cần mật khẩu để truy cập tài nguyên bên ngoài (cơ sở dữ liệu). – Joe

+1

Và làm thế nào chính xác bạn sẽ trình bày một * băm * trong một chuỗi kết nối? –

1

Chúng tôi đã có một tình huống tương tự. Chúng tôi đã kết thúc việc đưa khóa vào một tệp và yêu cầu người dùng nhập một số loại mật khẩu (hoặc sử dụng khóa băm) để có thể đọc tệp. Đó là nỗi đau khiến người dùng nhập thêm thông tin, nhưng nó sẽ xóa khóa khỏi chương trình.

4

Bạn không nên mã hóa mật khẩu của mình bằng bí mật được nhúng trong ứng dụng của bạn, đó là gốc rễ của những rắc rối của bạn. Cho dù mã hóa của bạn mạnh đến mức nào, khóa được hiển thị rõ ràng trong mã của bạn.

Bạn nên yêu cầu người dùng xác thực, lưu trữ người dùng/tên và mật khẩu db trong phần cấu hình thông thường trong app.config của bạn và dựa vào lớp DPAPI được hỗ trợ DpapiProtectedConfigurationProvider để mã hóa và giải mã phần cho bạn, bằng cách sử dụng các phím máy hoặc khóa người dùng cụ thể. Xem liên kết tôi đã cung cấp cho một ví dụ đầy đủ làm thế nào để làm điều này.