Mã hóa AES của T-SQL so với Hashing/Salting để đăng nhập người dùng vào trang web

Question

Tôi có một dự án và dường như các nhà thiết kế phần mềm đã không đưa vấn đề bảo mật vào xem xét.

Mật khẩu được lưu trữ ở dạng văn bản thuần túy và được truyền qua văn bản thuần túy. Vì vậy, tôi còn lại với nhiệm vụ sửa lỗi này.

Tôi hơi bị đe dọa về an ninh, vì vậy câu hỏi của tôi là: để xác thực mật khẩu người dùng trực tuyến tốt hơn là sử dụng kỹ thuật băm/muối hay sử dụng mã hóa AES tốt hơn? Tôi có thể có những ưu và khuyết điểm.

Sẽ tốt hơn nếu bạn sử dụng nhà cung cấp thành viên ASP.NET? Điều này có dễ dàng không? Tôi đã sử dụng nó trước đây, nhưng phần mềm gọi trên các bảng riêng của nó, vì vậy tôi không chắc liệu đó có phải là rắc rối hơn ở đó không.

Nếu điều này đã được trả lời thì ai đó có thể hướng dẫn tôi ở đó, bởi vì tôi không tìm thấy so sánh.

Answer 1

Bạn KHÔNG BAO GIỜ lưu trữ mật khẩu bằng cách sử dụng mã hóa đối xứng.

Muối ngẫu nhiên cho mỗi người dùng, băm mật khẩu của họ, lưu trữ cả muối và băm trong cơ sở dữ liệu. Sau đó, trên các yêu cầu đăng nhập bạn nhận được người dùng qua email/tên người dùng/id, v.v, sau đó sử dụng muối gắn với người dùng đó và băm mật khẩu được cung cấp của họ và sau đó so khớp nó với băm được lưu trữ. Nếu phù hợp, đăng nhập, mật khẩu khác xấu.

Nếu bạn sử dụng nhà cung cấp thành viên ASP.NET được xây dựng, nó sẽ làm điều này cho bạn.

Answer 2

Tôi đề nghị bạn nên băm nhiều mật khẩu muối. Hơn 10 lần hoặc một cái gì đó. Vậy tại sao? Bởi vì cho bạn băm một mật khẩu muối sẽ không nhận ra lâu hơn. Nhưng đối với một anh chàng ác cố gắng kết hợp khác nhau để brutefocre một mật khẩu, phải mất 10 lần nhiều thời gian mỗi lần thử. Và anh ta không thể chắc chắn nếu bạn đã làm nó 10 hoặc 1000 lần.

Tôi sử dụng cá nhân này làm tăng bảo mật giá rẻ.

Xem ở đây: Stackoverflow Salting Your Password: Best Practices?

hoặc có Secure hash and salt for PHP passwords

Chúc may mắn :)

Harry

Answer 3

Nó phụ thuộc vào việc hay không muốn để có thể khôi phục mật khẩu người dùng cho một số hoạt động. Nếu bạn đi với hashing/salting, điều đó có nghĩa là mỗi khi người dùng quên mật khẩu của họ, bạn sẽ phải có ứng dụng tạo ra một mật khẩu mới, an toàn. Nếu bạn đi với mã hóa đối xứng, sau đó bạn ít nhất cung cấp cho người dùng một cơ hội để khôi phục lại mật khẩu hiện tại của họ và thay đổi nó sau này lúc thuận tiện của họ.

Tôi không thể trả lời liệu có tăng cường bảo mật theo cách nào hay không. Một người có kiến ​​thức nhiều hơn tôi sẽ phải trả lời có hay không ít khả thi hơn để crack một thuật toán băm/băm như trái ngược với một thuật toán mã hóa đối xứng. Trên bề mặt, băm/muối có vẻ an toàn hơn vì kẻ tấn công phải tìm ra thuật toán trước khi anh ta có thể bắt đầu bẻ mật khẩu. Nhưng cũng có thể nói nếu bạn quyết định sử dụng một thuật toán mã hóa đối xứng khác. Bạn cũng có thể kết hợp các thuật toán khóa đối xứng trong trường hợp bạn cho rằng AES không đủ an toàn.

Answer 4

Việc sử dụng tư cách thành viên không nên gây khó khăn nhiều cho việc tự mình thực hiện toàn bộ nội dung và có thể an toàn hơn.Chỉ cần sử dụng tên người dùng hiện tại của người dùng làm tên người dùng, buộc người dùng phải đặt lại mật khẩu của họ (sửa hệ thống bảo mật sẽ yêu cầu bạn xóa mật khẩu cũ bất kể) và thay đổi tất cả các móc của bạn để kiểm tra người dùng sử dụng Membership.GetUser() hoặc tương tự.

Sẽ có một chút bất tiện nếu bạn hỗ trợ khả năng thay đổi tên người dùng. Thay đổi tên người dùng có thể giới thiệu một lỗ hổng bảo mật nếu không được thực hiện cẩn thận vì tư cách thành viên dựa vào tên người dùng và người dùng theo cách có thể gây ra lỗ hổng (mặc dù điều này yêu cầu người dùng không độc hại thay đổi tên riêng của họ, vì vậy nó không phải là một lỗ hổng lớn).