2009-04-20 23 views
18

Vì lý do bảo mật, có đáng để mã hóa email người dùng trước khi đưa chúng vào cơ sở dữ liệu không?Cách tốt nhất và an toàn nhất để lưu trữ địa chỉ email của người dùng trong cơ sở dữ liệu là gì?

Tôi biết mật khẩu băm và muối nhưng đó là một câu chuyện khác vì chúng tôi không thực sự cần bản gốc mật khẩu. Với email, nó khác.

Biết rằng khóa giải mã sẽ được đặt ở đâu đó gần cơ sở dữ liệu, có hợp lý để mã hóa email không? Tôi cho rằng nếu ai đó vào hệ thống, họ cũng sẽ tìm ra chìa khóa, nếu không ngay lập tức thì cuối cùng cũng vậy.

Thực tiễn tốt nhất là gì? Có bất kỳ tùy chọn nào khác có sẵn nếu tôi chạy máy chủ của riêng mình chứ không phải trên máy chủ lưu trữ được chia sẻ/ảo không?

EDIT: Tôi định sử dụng SQL Server. Và không, nó không phải là phần mềm của công ty với các yêu cầu bảo mật, chỉ là một số trang web giải trí mà tôi có trong đầu.

Trả lời

12

Nếu bạn cần địa chỉ email trong tương lai, bạn sẽ phải lưu trữ chúng ở dạng văn bản thuần túy.

Bạn có thể mã hóa chúng, tất nhiên, đây là bảo mật hiệu quả thông qua sự tối tăm trong trường hợp này. Về cơ bản, nếu chu vi của ứng dụng của bạn được an toàn, dữ liệu của bạn bên trong nó có thể là văn bản thuần túy. Mã hóa ở đây cho biết thêm sự phức tạp để bạn làm việc với dữ liệu, nhưng không thực sự ngăn kẻ tấn công lấy dữ liệu thô của bạn.

Như bạn nói, nếu anh ta vượt qua hàng rào phòng thủ của mình, anh ấy có thể dễ dàng lấy khóa giải mã của bạn để giải mã dữ liệu email. Mã hóa có thể làm chậm kẻ tấn công được xác định một chút, nhưng sẽ không thêm bất kỳ bảo mật thực nào vào dữ liệu của bạn.

Kịch bản tốt nhất là băm địa chỉ email (có muối!) Và lưu trữ. Điều này cho phép bạn kiểm tra địa chỉ email dựa vào giá trị đầu vào (ví dụ) và xác minh rằng đầu vào địa chỉ email giống như những gì bạn đã lưu trữ, tất nhiên, nhược điểm chính của việc này là bạn không thể biết email địa chỉ không có giá trị bổ sung đó, vì vậy nếu bạn muốn (ví dụ) thường xuyên gửi email cho người dùng của mình, bạn sẽ không may mắn.

Tôi nghi ngờ bạn đang lưu trữ địa chỉ email vì dữ liệu hữu ích và bạn sẽ muốn làm điều gì đó với nó (như gửi email :) trong trường hợp đó, mã hóa chỉ bổ sung thêm phí để làm việc với dữ liệu đó, trong khi thu được rất ít lợi nhuận.

Trong trường hợp này, tôi sẽ tập trung vào việc bảo mật truy cập cơ sở dữ liệu (nghĩa là "chu vi" của bạn) và đảm bảo chúng mạnh mẽ như có thể, trong khi để dữ liệu trong cơ sở dữ liệu ở dạng văn bản thuần túy.

13

Hy vọng câu trả lời này cũng sẽ trả lời câu hỏi của bạn.

Is it worth encrypting email addresses in the database?

Tóm lại, không có giá trị mã hóa địa chỉ email của người dùng. Bạn đúng khi nghĩ rằng một thỏa hiệp cơ sở dữ liệu có khả năng sẽ dẫn đến một ai đó cũng được truy cập vào các khóa cần thiết để phá vỡ mã hóa của bạn.

+0

Tôi đã thấy cái này nhưng nó có vẻ khá hẹp. Tôi muốn nghe bất kỳ suy nghĩ nào liên quan đến bảo mật email. – User

+1

Thỉnh thoảng máy chủ đột nhập chỉ cho phép kẻ tấn công tự xem nội dung cơ sở dữ liệu, tiết kiệm khóa và do đó bảo vệ dữ liệu. Nó sẽ là lố bịch, tuy nhiên, để dựa vào đó là trường hợp. – tylerl

+0

Tôi sẽ phải đồng ý với những người khác trả lời câu hỏi này sau đó. Hầu hết các địa chỉ email được gửi thư rác đến thiên đường cao bất kể. Những người thường không có tính năng chặn spam tại chỗ và không có số lượng mã hóa sẽ lưu người dùng nếu mật khẩu của họ là "mật khẩu" và ai đó tìm thấy địa chỉ email của họ. Tôi sẽ làm theo lời khuyên của @ MaxVT và vệ sinh/xác nhận địa chỉ email. Sử dụng mã hóa toàn bộ cơ sở dữ liệu như @ zoomzoom83 được đề xuất cũng là một ý tưởng hay nếu bạn vẫn lo ngại về bảo mật. –

1

Tùy thuộc vào tần suất bạn truy cập vào địa chỉ. Nếu bạn đọc chúng một lần trong một thời gian, nó có thể có ý nghĩa, nhưng điều này sẽ là một trong những vấn đề an ninh cuối cùng tôi sẽ dành nhiều thời gian trên.

1

Tôi không mã hóa e-mail của người dùng. Vấn đề là để bảo vệ cơ sở dữ liệu; các phím có thể truy cập được nếu bạn thực sự muốn sử dụng e-mail sau khi chúng được lưu trữ.

Tuy nhiên, hãy kiểm tra địa chỉ hợp lệ và có thể tiêm SQL.

1

Nếu máy chủ ứng dụng và cơ sở dữ liệu nằm trên các máy chủ riêng biệt, thường sẽ tăng cường bảo mật để có tất cả hoặc một phần của cơ sở dữ liệu được mã hóa.

Ngay cả khi chúng ở trên cùng một máy, tin tặc có thể không tìm ra nơi lưu mật khẩu của bạn (mặc dù tôi sẽ không dựa vào đó).

Tôi thường sẽ không mã hóa các email ở cấp ứng dụng, thay vào đó dựa vào mã hóa toàn bộ cơ sở dữ liệu được cung cấp bởi hầu hết các cơ sở dữ liệu doanh nghiệp.

Tất nhiên nếu bạn đang sử dụng một cái gì đó như MySQL, sau đó bạn không có lựa chọn nào khác ngoài thực hiện ở cấp ứng dụng.

Tôi thường nói với khách hàng của mình rằng không có vấn đề gì khi mã hóa cơ sở dữ liệu, tuy nhiên nếu bạn có yêu cầu về quyền riêng tư nghiêm ngặt hơn thì có thể làm như vậy.

3

Tôi nghĩ rằng khi người ta có thể đi vào cơ sở dữ liệu của bạn, bạn đang hơi say nào :)

Nó không làm cho rất nhiều ý nghĩa để chỉ mã hóa địa chỉ email của bạn. Bên cạnh đó sẽ có rất nhiều thông tin khác trong cơ sở dữ liệu của bạn mà bạn không muốn thu thập, khóa giải mã sẽ thực sự nằm trong tầm với của cơ sở dữ liệu của bạn.

Tôi muốn đề xuất tìm lớp bảo mật và toàn vẹn dữ liệu của bạn ở cấp cao hơn. Vì vậy, việc ngăn chặn những người vào cơ sở dữ liệu của bạn.

Và tại sao địa chỉ email lại quan trọng đến vậy? Hầu hết mọi người sẽ nhận được thư rác hoặc địa chỉ email của họ nếu không sẽ có sẵn ở đâu đó trên web.

1

Việc mã hóa nội dung cơ sở dữ liệu luôn là một vấn đề phức tạp. Rõ ràng nội dung là vô ích trừ khi nó có thể không được mã hóa, và nếu điều đó xảy ra mà không có sự can thiệp của con người, thì bạn đang lưu trữ cả hai cyphertext và chìa khóa ở đâu đó. Nếu điều đó ở đâu đó là trên cùng một máy, sau đó người ta có thể tự hỏi tại sao bạn thậm chí làm phiền.

Vâng, có một vài lý do khiến bạn có thể muốn thực hiện việc này. Một là vì bạn đang yêu cầu vì một số chính sách của công ty. Khác là có lẽ cơ sở dữ liệu của bạn được đặt trong một môi trường thù địch hơn so với máy truy cập nó.

Nói chung, mã hóa nội dung cơ sở dữ liệu sẽ không giúp bạn giành được bất kỳ giải thưởng nào, nhưng nếu bạn có thể biện minh, thì rõ ràng bạn có ít nhất một động lực để làm như vậy.

7

Nói chung, tôi đồng ý với những người khác nói rằng nó không đáng để nỗ lực. Tuy nhiên, tôi không đồng ý rằng bất cứ ai có thể truy cập cơ sở dữ liệu của bạn cũng có thể lấy chìa khóa của bạn. Điều đó chắc chắn không đúng đối với SQL Injection, và có thể không đúng đối với các bản sao lưu bị mất hoặc bị lãng quên. Và tôi cảm thấy một địa chỉ email là một chi tiết cá nhân, vì vậy tôi sẽ không quan tâm đến spam nhưng về những hậu quả cá nhân khi các địa chỉ được tiết lộ.

Tất nhiên, khi bạn sợ SQL Injection thì bạn nên đảm bảo việc tiêm như vậy bị cấm. Và bản sao lưu cần được mã hóa.

Tuy nhiên, đối với một số cộng đồng trực tuyến, các thành viên chắc chắn không muốn người khác biết rằng họ là thành viên (như liên quan đến chăm sóc sức khỏe tâm thần, trợ giúp tài chính, tư vấn y tế và tình dục, giải trí người lớn, chính trị, ...). Trong những trường hợp đó, lưu trữ càng ít chi tiết cá nhân càng tốt và mã hóa những thông tin cần thiết (lưu ý rằng mã hóa cấp cơ sở không ngăn các chi tiết hiển thị bằng cách sử dụng SQL Injection), có thể không phải là một ý tưởng tồi. Một lần nữa: xử lý một địa chỉ email như chi tiết cá nhân như vậy. Đối với trang web giải trí của bạn, điều này có thể không phải là trường hợp và bạn nên tập trung vào việc cấm SELECT * FROM thông qua SQL Injection và đảm bảo khách truy cập không thể truy cập thông tin cá nhân hoặc thông tin đặt hàng của người khác bằng cách thay đổi URL.

5

Một trong những truisms nhất thường được trích dẫn trong bảo mật máy tính là máy tính chỉ thực sự an toàn là một trong chôn trong bê tông, với sức mạnh tắt và cắt cáp mạng.

Xin lưu ý rằng cách tốt nhất để lưu trữ an toàn địa chỉ email? Không lưu trữ chúng ở tất cả!

tl; dr Bạn có cần địa chỉ email của họ hoặc cách gửi email không? Hoặc là tin tưởng ai đó sẽ làm tốt hơn bạn hoặc không sử dụng địa chỉ email.

Tại sao bạn cần lưu bản ghi địa chỉ email của khách hàng? Lý do duy nhất tôi đã chạy vào là:

  • xác nhận tài khoản & xác thực
  • giao dịch & Tiếp thị email

Chứng nhận & Xác thực

Cốt lõi của những gì chúng tôi muốn là hai bước xác thực: Một cái gì đó họ biết và một cái gì đó họ có. Một cái gì đó họ biết là một mật khẩu, và rất dễ dàng để chứng minh vì họ sẽ là người duy nhất biết điều đó. Một cái gì đó họ có là khó khăn hơn để chứng minh và theo truyền thống chúng tôi sử dụng một địa chỉ email vì nó rất dễ dàng để xác minh. Những ngày này mặc dù có những điều khác mà chúng tôi có thể sử dụng:

  • điện thoại di động
  • Một tài khoản với một trang web đáng tin cậy (Facebook, Google, Twitter)

xác minh điện thoại di động là đơn giản. Gửi cho họ một tin nhắn bằng cách sử dụng dịch vụ như twilio.com và yêu cầu họ nhắn tin lại mã xác nhận. Bây giờ chúng ta biết rằng điện thoại di động thuộc về khách hàng muốn đăng ký. Với OpenID, bạn có thể xác minh tài khoản hiện có với các trang web đáng tin cậy khác và quá trình xác nhận được xử lý bởi chúng.

Để khách hàng xác thực thì tất cả những gì họ cung cấp là số di động và mật khẩu của họ hoặc mã thông báo xác thực OpenID. Không yêu cầu địa chỉ email (nhà cung cấp OpenID có thể nhưng đó không phải là trách nhiệm của bạn).

Nếu đây không phải là tùy chọn thì bạn vẫn có thể xác nhận địa chỉ email và sau đó sử dụng địa chỉ đó để xác thực. Xác nhận chỉ yêu cầu một mã thông báo duy nhất được lưu trữ và một liên kết được gửi đến địa chỉ email. Lưu trữ một băm muối của địa chỉ email, và sử dụng nó để phù hợp với tài khoản trong cùng một cách chúng tôi làm mật khẩu.

giao dịch & Tiếp thị Email

Lý do thực sự tại sao chúng tôi muốn để lưu trữ các địa chỉ email! Vì vậy, chúng tôi có thể gửi cho họ những đề nghị về nội dung mà chúng tôi cho là họ cần để họ có thể xóa nội dung đó mà không cần đọc. Nghiêm túc là email là phương tiện tốt nhất cho việc này? Nếu chúng tôi có một tài khoản OpenID thì tại sao không sử dụng nó cho các thông báo? Gửi tin nhắn Facebook hoặc viết lên tường của họ, @mention chúng trên Twitter, gửi tin nhắn văn bản tới điện thoại di động của họ, tạo ứng dụng và đẩy thông báo vào họ. Có rất nhiều kênh hiệu quả hơn email.

Nếu bạn muốn sử dụng email, hãy sử dụng nền tảng email như MandrillMailChimp. Khi họ đăng ký tạo một thuê bao trong một danh sách gửi thư trên MailChimp. Lưu trữ id người đăng ký bằng tài khoản. Đối với email giao dịch (đặt lại mật khẩu, cập nhật tài khoản), hãy tìm người đăng ký và chuyển email đã lưu đến Mandrill để gửi email. Đối với tiếp thị đại chúng chỉ cần gửi đến danh sách gửi thư trong MailChimp.

Điều duy nhất được lưu trữ trong cơ sở dữ liệu là id người đăng ký. Nó cũng cung cấp tất cả các lợi ích của việc sử dụng nền tảng email, hủy đăng ký, mở và nhấp qua tỷ lệ, theo dõi thương mại điện tử, vv. Nền tảng email sẽ làm tốt hơn việc phân phối email mà bạn. Họ cũng sẽ làm tốt hơn trong việc bảo vệ sự riêng tư của dữ liệu của họ hơn bạn. Hãy để họ thực hiện công việc khó khăn về bảo mật cơ sở dữ liệu để bạn có thể tập trung vào việc có được nhiều khách hàng hơn.

0

vâng có thể hữu ích cho người dùng nếu bạn băm bằng muối. Tôi đã có một mã trước đó mà tôi sử dụng mà tôi sử dụng muối và băm sau đó tôi có thể giải mã nó. Lưu lượng là một khi người dùng sẽ đăng ký bạn sau đó băm và muối (quá trình mã hóa) nó. Sau đó, nếu bạn cần tìm nạp dữ liệu được mã hóa thì sẽ có giải mã.

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