2016-03-25 19 views
6

Tôi đang làm việc trên một ứng dụng web đang xem xét cách giữ danh tính của người dùng hoàn toàn ẩn danh.Giữ người dùng ẩn danh - Tùy chọn chỉ dành cho DB an toàn - Suy nghĩ chung?

Tuy nhiên tôi đã đến kết luận, không có quá nhiều tôi có thể làm - trừ tập trung vào việc đảm bảo cơ sở dữ liệu khỏi bị hack.

Đây có phải là sự đồng thuận chung ở đây trên StackOverflow hoặc có bất kỳ phương pháp nào tôi có thể đã bỏ qua không?

Vì vậy, tôi nghĩ về:

  • Một băm bcrypt thẳng và muối tuy nhiên điều này sau đó dẫn đến tiếp xúc với người sử dụng vì nhiều lý do.
  • Đặt lại mật khẩu. Tôi có thể lưu câu hỏi/trả lời phục hồi nhưng sau đó tất nhiên các câu trả lời sẽ cần phải có thể đọc được để đánh bại mọi thứ.
  • Một điểm khác là họ quên mất các câu hỏi bảo mật hoặc tên người dùng mà tôi đã tạo khi đăng ký. Không có cách nào để liên kết chúng với một tài khoản.
  • Ngoài ra những gì đến tâm trí (giả sử tôi chinh phục ở trên) hạn chế người dùng trùng lặp. Nếu tôi băm/muối tìm kiếm thông qua sẽ là khá 'nặng' về chế biến? Tôi chỉ có thể giữ một danh sách dài các email được sử dụng nhưng sau đó vấn đề lại liên kết với một tài khoản hiện có?

Quan tâm để nghe suy nghĩ của bạn.

Cảm ơn.

+0

Tôi có đúng khi nghĩ rằng bạn muốn người dùng đăng nhập bằng email/mật khẩu và sau đó bạn muốn hệ thống của mình mã hóa tất cả thông tin cá nhân của họ để chúng không thể nhận dạng được? –

+0

Bạn có thể xem xét sử dụng Sqrl để xác thực người dùng. https://www.grc.com/sqrl/sqrl.htm. Hệ thống sử dụng mật mã khóa công khai để ký phiên người dùng thay vì mật khẩu. Bạn xác định người dùng dựa trên khóa xuất phát từ bí mật ứng dụng khách. Bằng cách này bạn không phải lo lắng về việc mất mật khẩu. vì không có mật khẩu nào bị mất. Tôi đã không thử nó, nhưng từ nghe Steve Gibson trên podcast của mình nó có vẻ khó khăn ra. –

+0

@AaronFranco đúng vậy. – userMod2

Trả lời

3

Tôi nghĩ rằng kịch bản bạn mô tả có thể thực hiện được. Bạn có thể cung cấp cho người dùng mã thông báo giải mã khi họ đăng nhập. Mã thông báo có thể được gán cho một biến trong ứng dụng trên giao diện người dùng, vì vậy nếu họ rời khỏi trang web hoặc trang, mã thông báo sẽ bị mất và họ sẽ phải đăng nhập lại.

Sử dụng mã thông báo, ứng dụng có thể giải mã dữ liệu được mã hóa đến từ máy chủ. Vì vậy, tất cả dữ liệu có thể được mã hóa bằng mã thông báo. Sau đó, nếu yêu cầu thay đổi mật khẩu, bạn có thể tạo mã thông báo mới khi tạo mật khẩu mới và máy chủ của bạn sẽ phải giải mã rồi mã hóa lại tất cả dữ liệu của họ bằng mã thông báo mới. Bằng cách này, bạn có thể có tất cả các tệp máy chủ, mã và cơ sở dữ liệu được mã hóa trong khi sử dụng SSL để tất cả dữ liệu sẽ ẩn danh cho đến khi nó đến được người dùng để hiển thị. Người dùng đăng nhập sẽ là cách duy nhất để lấy mã thông báo để giải mã mọi dữ liệu đến từ máy chủ. Điều này sẽ làm giảm hiệu suất máy chủ đáng kể.

Kỹ thuật này được Atmel sử dụng trong vi mạch của họ để mã hóa 100% từ thiết bị sang đám mây. Điều này có ý nghĩa đối với chip vì người dùng không phải tương tác trực quan với chip đó. Trong trường hợp của một webapp, cần phải có một số cách để giải mã dữ liệu để hiển thị. Điều này hạn chế khả năng.

Dưới đây là một vài liên kết có thể có ích trong việc này: https://www.jamesward.com/2013/05/13/securing-single-page-apps-and-rest-services https://www.fourmilab.ch/javascrypt/javascrypt.html

Dưới đây là một liên kết đến chip Atmel có sử dụng phương pháp an ninh nêu trên. http://www.atmel.com/products/security-ics/cryptoauthentication/

+0

Thú vị - có thể thấy cách thức này sẽ hoạt động tuy nhiên người dùng sẽ phải nhớ mã thông báo - thay vì email/điện thoại di động của họ. Tôi đoán rằng mã thông báo có thể được thực hiện thành một đơn giản? – userMod2

+0

Người dùng không bao giờ thấy mã thông báo. Họ chỉ sử dụng Email & Mật khẩu, để tìm mã thông báo từ máy chủ của bạn. Mã thông báo sẽ là thứ duy nhất được gửi từ máy chủ không được mã hóa. –

+0

Ah ok - nhưng ở phía máy chủ/DB vẫn còn một liên kết từ mã thông báo cho người dùng đúng không? – userMod2

2

Đầu tiên, cách duy nhất để ẩn danh hoàn toàn là không bao giờ truy cập trực tuyến. Không có gì, và tôi không có ý nghĩa gì cả, hoàn toàn được bảo đảm. Bất kỳ băm, mã hóa, DB, vv có thể bị nứt. Nếu một "hacker" độc hại thực sự muốn thông tin họ sẽ tìm thấy một cách để có được nó không có vấn đề làm thế nào khó bạn thử.

Bây giờ bạn có thể nói rằng, những gì bạn mô tả là có thể, ví dụ như nhìn vào Tor, proxy, VPN ... nếu bạn mã hóa hoàn toàn mọi thông tin được lấy từ người dùng. Tuy nhiên, điều này có thể trở thành một vấn đề nếu có điều gì đó sai, ví dụ như bạn băm ba, và đa muối tất cả các băm và đi qua một vấn đề mà bạn cần giải mã thông tin người dùng (vì lợi ích của đối số, FBI yêu cầu nó) băm muối duy nhất với mã hóa MD5 có thể mất từ ​​2 đến 5 giờ để giải mã/crack. Bạn đã mã hóa tất cả thông tin bao gồm IP, tên người dùng, mật khẩu, email, tên, v.v ... bây giờ bạn đang xem xét khả năng nhiều hơn một ngày để giải mã một người dùng.

Tuy nhiên, bạn có thể làm điều gì đó dọc theo đường tạo đường hầm được mã hóa vào trình duyệt mà người dùng CÓ THỂ truy cập để chạy trình duyệt (giống như VPN), sau đó từ đó ném proxy vào URL trình duyệt để tiếp tục sự bất thường. Bằng cách đó, người dùng đang ở trong một đường hầm được mã hóa với một IP khác và sử dụng một IP khác, sau đó là đường hầm được cung cấp thông qua đường hầm. Bạn thậm chí có thể đi xa như thường xuyên nhảy IP thường xuyên, và thay đổi proxy.

Bây giờ hãy bắt đầu bảo mật cơ sở dữ liệu, tôi sẽ đề xuất nhiều lần băm nhỏ, bảo mật chúng bằng cụm từ mật khẩu và xóa cụm từ mật khẩu từ máy tính mà cơ sở dữ liệu đang bật. Điều này cũng có thể chứng minh phiền hà nếu bạn cần truy cập các băm để giải mã.

Tôi nói đi, điều tồi tệ nhất sẽ xảy ra là bạn sẽ có một dấu vết nhỏ của người dùng. Nhưng hãy nhớ, nếu bạn tạo thành công điều này, những người có ý định xấu sẽ cố gắng khai thác nó, chỉ để xem họ có thể làm được không.

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