Mật khẩu ứng dụng và bảo mật SQLite

Question

Tôi đã tìm kiếm trên google để biết thông tin về mật khẩu ứng dụng và bảo mật SQLite trong một thời gian, và không có gì tôi tìm thấy đã thực sự trả lời câu hỏi của tôi.

Dưới đây là những gì tôi đang cố gắng tìm ra:

1) Ứng dụng của tôi sẽ có một hoạt động mật khẩu tùy chọn sẽ được gọi khi ứng dụng được đầu tiên khai trương. Câu hỏi của tôi cho điều này là a) Nếu tôi lưu trữ mật khẩu thông qua sở thích Android hoặc cơ sở dữ liệu SQLite, làm cách nào để đảm bảo bảo mật và quyền riêng tư cho mật khẩu và b) cách xử lý khôi phục mật khẩu?

Về b) từ trên cao, tôi đã nghĩ đến việc yêu cầu địa chỉ email khi tính năng mật khẩu được bật và cũng là câu hỏi gợi ý mật khẩu để sử dụng khi yêu cầu khôi phục mật khẩu. Khi trả lời thành công câu hỏi gợi ý, mật khẩu sẽ được gửi qua email đến địa chỉ email đã được gửi. Tôi không hoàn toàn tự tin vào tính bảo mật và quyền riêng tư của phương pháp email, đặc biệt nếu email được gửi khi người dùng được kết nối với mạng không dây công cộng mở.

2) Ứng dụng của tôi sẽ sử dụng cơ sở dữ liệu SQLite, sẽ được lưu trữ trên thẻ SD nếu người dùng có. Bất kể nó được lưu trữ trên điện thoại hay thẻ SD, tôi có những tùy chọn nào để mã hóa dữ liệu và điều đó ảnh hưởng đến hiệu suất của ứng dụng như thế nào?

Cảm ơn bạn đã dành thời gian để trả lời những câu hỏi này. Tôi nghĩ rằng có thể có các nhà phát triển khác đang phải vật lộn với những lo ngại tương tự.

Answer 1

1) Khôi phục mật khẩu rất nguy hiểm. Sức mạnh của mật khẩu bị suy yếu bởi câu trả lời cho một câu hỏi, đây là hiệu trưởng của liên kết yếu nhất. Sara Palin's email hack được thực hiện vì tính năng này (rất) không an toàn. Ngoài ra nếu bạn lưu trữ mật khẩu trong một "định dạng có thể phục hồi" như trong một mật mã khối như AES hoặc mật mã dòng như RC4 hoặc mật mã không đối xứng như RSA thì bạn đang vi phạm rõ ràng CWE-257. Nếu bạn thực sự cần tính năng này, bạn phải yêu cầu người dùng đặt lại mật khẩu của họ, nếu họ không biết, thì tại sao bạn cần nói cho họ biết?

Mật khẩu luôn phải được băm bằng cách sử dụng thông báo bảo mật. Hiện tại nhiều chức năng thông báo tiêu hóa không an toàn, md4, md5, sha0 và sha1 đều bị hỏng và không bao giờ được sử dụng cho mật khẩu. Hiện tại bất kỳ thành viên nào của gia đình sha2 đều là chức năng tốt nhất để sử dụng, tôi khuyên bạn nên sử dụng SHA-256. NIST hiện đang tổ chức một cuộc thi cho sha3 và nó sẽ không được hoàn thành cho đến khi vào năm 2012.

Mật khẩu cũng phải được "muối" với một giá trị ngẫu nhiên lớn. Đây có thể là một cột khác trong cơ sở dữ liệu của bạn, sau đó được thêm vào mật khẩu văn bản thuần tuý trước khi chuyển nó vào chức năng thông báo của bạn. Điều này làm cho các cuộc tấn công từ điển không thể trừ khi kẻ tấn công có thể có được muối, nó cũng làm cho các cuộc tấn công được tính toán trước nhiều tài nguyên hơn để tiến hành thành công. Mặc dù phổ biến kiến ​​thức, muối không dừng bảng cầu vồng, nó chỉ có nghĩa là bạn cần một MUCH LARGER thiết lập các bảng cầu vồng.

2) Bạn sẽ đặt khóa cho cơ sở dữ liệu được mã hóa ở đâu? Sqlite chỉ là một tập tin bạn có thể mã hóa này và sau đó giải mã nó khi bạn khởi động ứng dụng, điều này chỉ thêm một số thời gian tải nhưng khi chạy nó sẽ nhanh như vậy. Vấn đề thực sự là có hoàn toàn không có nơi bạn có thể đặt một bí mật trên thiết bị mà kẻ tấn công không thể có được. Kẻ tấn công có quyền kiểm soát nhiều hơn so với thiết bị của bạn, kẻ tấn công có thể bẻ khóa thiết bị và làm bất cứ điều gì họ muốn.Ngay cả khi khóa được chuyển vào thời gian chạy nó vẫn có thể thu được bằng cách nhìn vào bộ nhớ của thiết bị. Bất kỳ nỗ lực nào để mã hóa cơ sở dữ liệu có thể bị phá hoại, nó có thể làm cho nó khó khăn hơn nhưng nó sẽ không ngăn chặn một hacker có kỹ năng.