Cách thích hợp để triển khai hệ thống đăng nhập người dùng

Question

Tôi muốn tạo hệ thống đăng nhập người dùng cho mục đích học tập. Tôi có một số câu hỏi.

Tôi đã thực hiện một số nghiên cứu và thấy rằng cách thích hợp để triển khai hệ thống đăng nhập của người dùng là ghi nhớ tên người dùng/id và phiên bản mã hóa/băm được mã hóa trong cơ sở dữ liệu. Khi người dùng đăng nhập, mã phía máy khách sẽ mã hóa mật khẩu bằng MD5 hoặc SHA-1 hoặc một cái gì đó tương tự, và sau đó gửi mật khẩu được mã hóa này đến phía máy chủ và sau đó so sánh nó với mật khẩu trong cơ sở dữ liệu. Nếu chúng được khớp, người dùng đăng nhập thành công.

Cách triển khai này có thể ngăn chặn người quản trị cơ sở dữ liệu hoặc người lập trình thấy văn bản thực sự của mật khẩu trong cơ sở dữ liệu. Nó cũng có thể ngăn chặn tin tặc chặn mật khẩu thực trong quá trình chuyển trên Internet. Tuy nhiên, tôi có một cái gì đó mà tôi không hiểu.

1. câu hỏi đầu tiên của tôi là, những gì nếu hacker biết phiên bản băm/mã hóa mật khẩu (bằng cách hack cơ sở dữ liệu) hoặc DBA, các lập trình viên có được phiên bản hash của mật khẩu bằng cách chỉ đơn giản là nhìn thấy những văn bản trong cơ sở dữ liệu , sau đó họ có thể dễ dàng tạo một chương trình gửi phiên bản băm mật khẩu này tới phía máy chủ và sau đó thực hiện so sánh và sau đó đăng nhập thành công. Nếu họ có thể làm điều đó, việc mã hóa mật khẩu có vẻ không hữu ích. Tôi nghĩ tôi hiểu nhầm điều gì đó ở đây.

2. Câu hỏi thứ hai là, đây là cách tôi mô tả ở trên là cách phổ biến nhất và phù hợp để triển khai chức năng đăng nhập của người dùng trong ngành hiện tại? Tôi có phải làm tất cả mọi thứ theo cách thủ công hoặc một số cơ sở dữ liệu có một số khả năng tích hợp để làm điều tương tự không? Có cách nào phổ biến nhất/phương pháp đăng nhập người dùng cho trang web hoặc ứng dụng web không? Nếu có, vui lòng cung cấp cho tôi một số chi tiết.

3. Công ty cũ của tôi đã sử dụng couchDB để lưu trữ thông tin đăng nhập của người dùng bao gồm cả mật khẩu. Họ không làm quá nhiều về công cụ mã hóa. Họ nói couchDB sẽ tự động mã hóa mật khẩu và lưu trữ nó trong các tài liệu. Tôi không chắc đây có phải là cách an toàn hay không. Nếu vậy, sau đó nó là khá thuận tiện cho các lập trình viên vì nó tiết kiệm rất nhiều công việc.

4. Bằng cách này (điểm 3) có đủ an toàn để sử dụng bình thường không? Hệ thống cơ sở dữ liệu khác như mySQL có loại khả năng này có thể làm điều tương tự không? Nếu vậy, có nghĩa là sử dụng phương pháp tích hợp mySQL có đủ an toàn không?

Tôi không tìm cách bảo mật chức năng đăng nhập người dùng rất an toàn. Tôi đang tìm kiếm một cách phổ biến, dễ thực hiện, thích hợp, đủ an toàn cho hầu hết các ứng dụng web. Xin vui lòng cho tôi một lời khuyên. Chi tiết được cung cấp sẽ thực sự được đánh giá cao.

Answer 1

Một vài giải thích:

1. Không sử dụng MD5. Nó được coi là bị hỏng. Sử dụng SHA nhưng tôi khuyên bạn nên một cái gì đó tốt hơn một chút so với SHA1. - https://en.wikipedia.org/wiki/MD5
2. Bạn không đề cập đến bất cứ điều gì về việc nhập mật khẩu. Điều này là cần thiết để bảo vệ chống lại các bảng Rainbow. - https://en.wikipedia.org/wiki/Rainbow_tables
3. Ý tưởng về mật khẩu muối/băm không thực sự bảo vệ ứng dụng của riêng bạn. Đó là bởi vì hầu hết người dùng có một vài mật khẩu mà họ sử dụng cho vô số các trang web. Hashing/salting ngăn chặn bất cứ ai có quyền truy cập vào cơ sở dữ liệu của bạn từ việc học những mật khẩu này và sử dụng chúng để đăng nhập vào ứng dụng ngân hàng của họ hoặc một cái gì đó tương tự. Khi ai đó truy cập trực tiếp vào cơ sở dữ liệu, bảo mật của ứng dụng của bạn đã bị xâm phạm hoàn toàn. - http://nakedsecurity.sophos.com/2013/04/23/users-same-password-most-websites/
4. Không sử dụng tính năng bảo mật được tích hợp sẵn của cơ sở dữ liệu để xử lý thông tin đăng nhập của bạn. Đó là hacky và cung cấp cho họ cách truy cập ứng dụng nhiều hơn họ cần phải có. Sử dụng một bảng.
5. Bạn không đề cập gì về SSL. Ngay cả một hệ thống xác thực được thiết kế tốt là vô ích nếu mật khẩu được gửi qua dây trong văn bản thuần túy. Có những cách tiếp cận khác như Challenge/Response nhưng tiếc là mật khẩu vẫn phải được gửi trong văn bản thuần túy đến máy chủ khi người dùng đăng ký hoặc thay đổi mật khẩu của họ. SSL là cách tốt nhất để ngăn chặn điều này.

Answer 2

Khi người dùng đăng nhập, mã phía máy khách sẽ mã hóa mật khẩu bằng MD5 hoặc SHA-1 hoặc thứ gì đó tương tự và sau đó so sánh mật khẩu này với cơ sở dữ liệu. Nếu chúng được khớp, người dùng đăng nhập thành công.

Không, không, khách hàng cần gửi mật khẩu chưa được hủy. Nếu bạn băm mật khẩu ở phía máy khách thì băm đó thực sự là mật khẩu. Điều này sẽ vô hiệu hóa tính bảo mật của băm mật mã. Việc băm phải được thực hiện trên máy chủ .

Để bảo mật mật khẩu thô khi chuyển tiếp, cần phải gửi mật khẩu qua kênh bảo mật, chẳng hạn như kết nối TLS (SSL) được mã hóa.

---

Mật khẩu phải được muối với một phần dữ liệu bổ sung mà là khác nhau cho mỗi tài khoản. Salting ức chế tấn công bảng cầu vồng bằng cách loại bỏ mối tương quan trực tiếp giữa bản rõ và băm. Muối không cần phải bí mật, cũng không cần phải cực kỳ lớn. Ngay cả 4 byte ngẫu nhiên của muối sẽ làm tăng sự phức tạp của một cuộc tấn công bảng cầu vồng với hệ số 4 tỷ.

---

Các tiêu chuẩn vàng ngành công nghiệp ngay bây giờ là Bcrypt. Ngoài việc thêm muối, bcrypt còn tăng thêm sự bảo mật bằng cách thiết kế theo một hệ số suy giảm.

Bên cạnh việc kết hợp muối để bảo vệ chống lại các cuộc tấn công của bảng cầu vồng, bcrypt là một chức năng thích ứng: theo thời gian, số lần lặp lại có thể tăng lên, vì vậy nó vẫn chống lại các cuộc tấn công tìm kiếm bạo lực ngay cả khi tăng tính toán điện .... Cryptotheoretically, điều này là không mạnh hơn so với lịch trình tiêu chuẩn chính Blowfish, nhưng số vòng rekeying được cấu hình; quá trình này do đó có thể được thực hiện tùy ý chậm, giúp ngăn chặn các cuộc tấn công brute-force khi băm hoặc muối.