Nếu tôi tạo thông tin đăng nhập cho một ứng dụng có rủi ro bảo mật trung bình đến thấp (nói cách khác, đó không phải là ứng dụng ngân hàng hay bất cứ thứ gì), tôi có thể chấp nhận để xác minh mật khẩu do người dùng nhập bằng cách chỉ cần nói một cái gì đó như:

if(enteredPassword == verifiedPassword)
     SendToRestrictedArea();
else
     DisplayPasswordUnknownMessage();

Nó có vẻ dễ dàng để có hiệu quả, nhưng tôi chắc chắn sẽ không phiền nếu đó là tất cả những gì được yêu cầu. Là một kiểm tra đơn giản về tên người dùng / mật khẩu kết hợp đủ?

Cập nhật: Dự án cụ thể xảy ra là một dịch vụ web, xác minh hoàn toàn là phía máy chủ và nó không phải là nguồn mở. Có phải tên miền thay đổi cách bạn sẽ đối phó với điều này?

Không phải không có SSL

Điều này không an toàn nếu mật khẩu được gửi qua mạng bằng văn bản thuần túy. Băm mật khẩu ở phía máy chủ cũng không an toàn nếu mật khẩu được gửi qua mạng ở dạng văn bản thuần túy.

Vì <input type="password"/>thẻ HTML gửi nội dung của nó ở dạng văn bản đơn giản, đây sẽ là một vấn đề cho dù bạn lưu trữ mật khẩu trên máy chủ như thế nào, trừ khi trang web của bạn sử dụng SSL để truyền mật khẩu.

(Xác thực HTTP, bật lên hộp thoại trong trình duyệt yêu cầu mật khẩu, có thể có hoặc không có văn bản rõ ràng, tùy thuộc vào cơ chế xác thực nào mà máy chủ và trình duyệt có điểm chung. Vì vậy, đó có thể là một cách để tránh điều này mà không sử dụng SSL.)

Không, nếu quản trị viên trang web nghi ngờ

Bây giờ, giả sử bạn đang sử dụng HTTPS để làm trang web, điều này có thể an toàn nếu bạn tin tưởng quản trị viên trang web của mình (người có thể đọc mật khẩu văn bản đơn giản) và những người khác có quyền truy cập vào máy để hành xử đúng. Bây giờ, có thể rõ ràng là họ có thể làm bất cứ điều gì họ muốn với trang web của bạn (vì họ quản trị nó), nhưng nếu họ có thể đọc mật khẩu, họ cũng có thể sử dụng các cặp đăng nhập / mật khẩu bị đánh cắp trên các trang web của người khác.

Một cách giữ mật khẩu an toàn từ quản trị viên

Một cách an toàn để lưu trữ và kiểm tra mật khẩu như sau:

def change_password user, new_password
  salt = random(65536).to_s(16) #will be 4 characters long
  password_hash = salt + hash(salt + new_password)
  store(user,password_hash)
end

def does_password_match? user, entered_password
  correct_password_hash = retrieve(user)
  salt = correct_password_hash[0...4]
  entered_password_hash = salt + hash(salt + entered_password)
  return correct_password_hash == entered_password_hash
end

Đối với hàm băm, hãy thử sử dụng thứ gì đó mạnh và thứ gì đó chưa có bảng cầu vồng tốt trong tự nhiên. Bạn có thể thay đổi độ dài của muối nếu cần thiết xung quanh các bảng cầu vồng.

Tùy thuộc vào môi trường bạn đang ở, độ biến thiên trong độ trễ mạng của bạn và liệu tên người dùng có được biết đến công khai hay không, bạn có thể muốn tính toán một đường dẫn mã khác hash('0000'+entered_password)nếu người dùng không tồn tại, để ngăn chặn kẻ tấn công xác định tên người dùng nào là hợp lệ dựa trên thời gian xác định rằng mật khẩu không chính xác.

Điều đó sẽ gợi ý rằng bạn đang giữ mật khẩu ở dạng văn bản mở, điều này là không, ngay cả trong các tình huống bảo mật thấp.

Bạn nên có:

if(hash(enteredPassword) == storedHash)

Bạn có thể sử dụng hàm băm đơn giản như MD5

Tôi đồng tình với những người đề nghị băm, nhưng cũng có một bánh xe bạn đang phát minh lại ở đây. Tùy thuộc vào nền tảng, bạn có thể tìm thấy một công cụ quản lý vai trò / người dùng bao gồm tất cả các công cụ quản lý người dùng một cách an toàn và bảo mật mà không cần quá nhiều sự can thiệp từ phía bạn.

Bảo mật là một chủ đề rất nhạy cảm, đặc biệt vì cần phải có sự cân bằng giữa việc làm phiền người dùng của bạn và đảm bảo thông tin của họ được an toàn. Thông thường, công thức cho mức độ bảo mật bạn cần là một chức năng về tầm quan trọng của dữ liệu. Nói ngắn gọn:

isSecuritySufficient = effortToBreak > rewardForBreaking

Một sự hiểu lầm phổ biến về những người làm điều xấu là những gì họ đang theo đuổi. Hầu hết trong số họ là ra để phá hủy lòng tin . Bạn phải luôn luôn làm mọi thứ có thể để bảo vệ lòng tin của người dùng. Một phần trong đó là thực hiện sự chuyên cần của bạn để đảm bảo danh tính của họ được an toàn. Họ có thể quan tâm ít hơn về dữ liệu họ lưu trữ, nhưng họ quan tâm đến danh tính của họ - ngay cả ở ngưỡng bảo mật thấp nhất.

Có sẵn một số tùy chọn chi phí thấp (để thực hiện và tác động đến người dùng). Một trong số đó là băm mật khẩu ở mức tối thiểu. Bất kỳ dịch vụ nào lưu trữ thứ gì đó nhạy cảm như mật khẩu trong văn bản đơn giản đều đáng bị bối rối khi bị hack.

Nguyên tắc chung để bảo vệ mật khẩu

• Không bao giờ lưu trữ mật khẩu trong văn bản đơn giản
• Băm sử dụng hàm băm an toàn như SHA-1 hoặc thậm chí SHA-512 (ngay cả MD5 cũng quá dễ dàng để tìm ra hàm băm phù hợp)
• Sử dụng một giá trị muối ứng dụng. Muối là các byte ngẫu nhiên hoặc được thêm vào mật khẩu để làm cho nó khó đoán hơn. Muối nên được tạo ra trong thời gian chạy và sử dụng thông tin về máy làm giá trị hạt giống thay vì được lưu trữ và tham chiếu theo bất kỳ cách nào.
• Sử dụng một giá trị muối cụ thể của người dùng. Sử dụng này kết hợp với muối ứng dụng của bạn.
• Mã hóa tất cả các yêu cầu xác thực đi qua một mạng. Điều đó có nghĩa là sử dụng SSL cho các ứng dụng web.

Vì bạn sẽ sử dụng SSL để xác thực, tối thiểu bạn cũng muốn mã hóa tất cả các trang liên quan đến tài khoản của người dùng. Điều này cho phép càng nhiều danh tính của người dùng được bảo vệ càng tốt.

Một lưu ý về quản lý mật khẩu : Đôi khi người dùng sẽ quên mật khẩu của họ. Điều tồi tệ nhất tuyệt đối bạn có thể làm là gửi cho họ mật khẩu của họ trong email. Nếu bạn thực hiện các nguyên tắc được nêu ở trên, bạn sẽ không thể làm điều đó bằng mọi cách. Sẽ tốt hơn nhiều nếu cung cấp cách đặt lại mật khẩu của họ bằng liên kết được gửi đến địa chỉ email đã đăng ký của họ. Liên kết đặt lại đó sẽ có mã sử dụng một lần để đảm bảo người truy cập trang là họ.

Điều đó tốt trừ khi mật khẩu được sử dụng cho bất cứ điều gì khác. Vẫn có nguy cơ người dùng quyết định rằng anh ta có thể sử dụng lại mật khẩu, vì vậy sẽ tốt hơn nữa với:

if(hash(enteredPassword) == hashOfValidPassword)

Nếu đó là cho chính bạn hoặc ai đó biết rằng mật khẩu được lưu trữ ở dạng văn bản thuần thì sẽ ổn thôi.

Là mã nguồn có sẵn? Ngay cả nếu không, tôi khá chắc chắn rằng mật khẩu có thể được tìm thấy trong hướng dẫn máy trong trường hợp nhị phân có sẵn. Tôi sẽ khuyên bạn nên làm một tổng kiểm tra và so sánh điều đó thay vào đó.

Không bao giờ bỏ qua bảo mật ngay cả khi nó không quan trọng trong quan điểm của bạn.

Tuyệt đối không. Hãy đọc điều này , nó mô tả cách tin tặc tấn công một trang web bảo mật. Bạn có kế hoạch sẽ có bạn là liên kết yếu nhất trong chuỗi.

Nó đã được ghi nhận trong một vài câu trả lời rằng bạn không nên lưu trữ mật khẩu mà là hàm băm - và bạn nên sử dụng SSL.

Bạn có thể nói, vấn đề lớn là gì? Nếu ứng dụng của tôi bị hack, đó là điều ít quan tâm. Vâng, đó là một mô hình khá phổ biến cho người dùng sử dụng lại cùng một mật khẩu trên tất cả các trang web. Là một hacker tấn công trang web của bạn và giành quyền truy cập vào mật khẩu của người dùng, tin tặc có thể mạo danh rất nhiều người dùng trên các trang web khác có tầm quan trọng lớn hơn đối với những người dùng đó. Vì vậy, việc hack trang web của bạn có thể là bước đầu tiên để tin tặc truy cập vào thông tin ngân hàng cho người dùng.

Và chỉ băm mật khẩu là không đủ. Bạn cần băm nó với một muối. Tin tặc có các bảng tra cứu băm ngược, vì vậy đối với một hàm băm nhất định, chúng có thể tìm thấy một mật khẩu phù hợp.

Nếu bạn chọn không triển khai các tính năng này, bạn nên thông báo cho người dùng về sự thiếu bảo mật này, khuyến khích họ không sử dụng cùng một mật khẩu mà họ sử dụng ở nơi khác.

Miễn là đây là phía máy chủ .. Sau đó, có.

Nếu bạn muốn bảo mật hơn một chút, hãy truy cập https và mã hóa \ băm mật khẩu trong DB.