Điểm:0

Làm thế nào an toàn là thủ tục bút danh của tôi?

lá cờ cn

Tôi làm việc cho một tổ chức thu thập dữ liệu bệnh nhân và tôi phải mã hóa nó. Hiện tại tôi làm các bước sau (với r):

  • Chỉ định ngẫu nhiên một ID cho mỗi bệnh nhân. Quy trình tránh trùng lặp (sử dụng vật mẫu(), trong số những người khác)
  • Tạo muối cho mỗi bệnh nhân (sử dụng muối <- bcrypt::gensalt(log_rounds= 5))
  • Tạo ID băm cho từng bệnh nhân bằng cách sử dụng ID và muối (sử dụng id_hashed <- bcrypt::hashpw(id, muối = muối))

Tôi lưu dữ liệu trong ba tệp khác nhau

  • tệp đầu tiên chứa các cặp dữ liệu bệnh nhân (tên và ngày sinh) và ID được mã hóa/băm
  • tệp thứ hai chứa các cặp ID và muối không được mã hóa/băm
  • tệp thứ ba là cơ sở dữ liệu thực tế có ID và một số biến quan tâm (ví dụ:hút thuốc, cân nặng,...)

Trong thực tế, điều này sẽ được sử dụng như sau:

  • Trong khi làm việc với cơ sở dữ liệu (tệp thứ ba), chúng tôi biết ID nhưng không biết tên của bệnh nhân. Đôi khi chúng ta cần tìm hiểu xem ID của một người là gì. Tôi đã viết một ứng dụng (ứng dụng sáng bóng) nơi chúng tôi có thể nhập ID và ứng dụng sẽ trả về tên và ngày sinh. Đối với điều này, ứng dụng đi vào tệp thứ hai, lấy ID và muối tương ứng và tạo ID băm. ID đã băm này được so sánh với ID trong tệp một. Ứng dụng trả về tên và ngày sinh của bệnh nhân có cùng ID được băm như vừa tạo.
  • Nếu một bệnh nhân đến với chúng tôi và chúng tôi muốn thu thập dữ liệu mới, chúng tôi biết tên và ngày sinh của anh ấy nhưng chúng tôi không biết ID của anh ấy. Trong trường hợp này, chúng tôi có thể nhập tên và ngày sinh vào ứng dụng và tìm ID tương ứng. Đối với điều này, ứng dụng chuyển đến tệp thứ hai và sử dụng ID và muối để tạo ID băm. Trong khi làm như vậy, ứng dụng sẽ so sánh xem ID đã băm có tương ứng với một trong các ID trong tệp một hay không. Nếu có, chúng tôi đã tìm thấy ID bệnh nhân có. Quá trình này mất một khoảng thời gian vì ứng dụng cần đi qua từng cặp ID và muối cho đến khi tìm thấy ID băm chính xác.
  • Nếu chúng tôi có một bệnh nhân mới, chúng tôi có thể nhập tên và ngày sinh của anh ấy vào ứng dụng. Thao tác này sẽ tự động tạo mục nhập trong tệp một (tên + ngày sinh và ID băm) và trong tệp hai (ID và muối).

Câu hỏi: Có một số cạm bẫy rõ ràng trong thủ tục này? Nếu bạn có thể đặt tên cho một điểm yếu và cách giải quyết vấn đề này thì thật tuyệt. Tôi vui lòng nhẹ nhàng vì tôi chưa quen với điều này.

Ghi chú:

  • Tôi biết rằng về mặt lý thuyết, không cần ID được tạo ngẫu nhiên vì chúng tôi có thể sử dụng dữ liệu bệnh nhân (tên và ngày sinh) và muối để tạo ID băm. Chúng tôi không muốn cách tiếp cận này vì đồng nghiệp của tôi không thích có ID được băm rất dài trong cơ sở dữ liệu thực tế (tệp ba).
  • mô tả của bcrypt::hashpw() nói "Bcrypt được sử dụng để băm mật khẩu an toàn. Sự khác biệt chính với các thuật toán thông báo thông thường chẳng hạn như MD5 hoặc SHA256 là thuật toán bcrypt được thiết kế đặc biệt để sử dụng nhiều CPU trong để bảo vệ chống lại các cuộc tấn công vũ phu. Độ phức tạp chính xác của thuật toán có thể định cấu hình thông qua tham số log_rounds. Giao diện hoàn toàn tương thích với giao diện Python." (xem đây ).
Điểm:1
lá cờ ng

Điểm yếu tồi tệ nhất là quyền truy cập đọc vào tệp đầu tiên tiết lộ tên và ngày sinh của bệnh nhân.

Và sau đó, quyền truy cập đọc vào các tệp khác của một đối thủ có kiến ​​thức về hệ thống (như giả định trong mật mã học) cho phép lấy dữ liệu y tế cho từng bệnh nhân được xác định theo tên và ngày sinh, với chi phí tính toán có thể chấp nhận được.

Đây là sự cố bảo mật CNTT không có giải pháp mã hóa hoàn chỉnh. Giải pháp tiêu chuẩn là hạn chế quyền truy cập đọc vào tệp. Điều tốt nhất mà tôi thấy trên thực tế có thể thực hiện được mà không bị hạn chế như vậy là việc biết/đoán chính xác tên và ngày sinh của bệnh nhân là cần thiết để khử ẩn danh dữ liệu của họ và có chi phí tính toán để xác minh dự đoán. Ý tưởng chung là hoặc

  • hoàn toàn không lưu tên và ngày sinh; điều này dường như có thể thực hiện được mà không cần thay đổi chức năng như đã nêu trong "trong thực tế", nhưng chúng tôi không còn có thể hủy ẩn danh hoặc phát hiện rằng tên/ngày sinh nhập sai đã tạo ra các mục nhập trùng lặp cho cùng một bệnh nhân.
  • lưu trữ tên và ngày sinh được mã hóa bằng khóa chung, với khóa riêng được lưu giữ với các biện pháp phòng ngừa bổ sung và chỉ được sử dụng (để giải mã) trong trường hợp ngoại lệ là dữ liệu bệnh nhân phải được ẩn danh.

Ngoài một khía cạnh tương đối nhỏ, việc "Gán ngẫu nhiên một ID cho từng bệnh nhân" yêu cầu một điều gì đó không được nêu rõ để tránh các ID trùng lặp và một điểm yếu có thể xuất hiện ở đó.

Igor stands with Ukraine avatar
lá cờ cn
"Điểm yếu tồi tệ nhất là quyền truy cập đọc vào tệp đầu tiên tiết lộ tên và ngày sinh của bệnh nhân." - Các nguyên tắc khuyến nghị sử dụng bút danh trong ngữ cảnh của chúng tôi, tức là mã hóa có thể đảo ngược (ngược lại với ẩn danh khi không ai có nghĩa vụ khôi phục dữ liệu gốc). Do đó, tôi cần lưu dữ liệu cá nhân thực tế vào một lúc nào đó. Ít nhất tôi không biết liệu có một sự thay thế?
caveman avatar
lá cờ in
Bằng chứng không có kiến ​​​​thức sẽ giúp ích gì?

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.