Tại sao mật khẩu phải được mã hóa nếu chúng đang được lưu trữ trong cơ sở dữ liệu an toàn?

Tôi có một dịch vụ web. Ngay bây giờ, tôi có mật khẩu được lưu trữ trong văn bản thuần trong bảng MySQL trên máy chủ của mình. Tôi biết đây không phải là cách thực hành tốt nhất và đó là lý do tại sao tôi đang thực hiện nó.

Tại sao mật khẩu phải được mã hóa nếu chúng đang được lưu trữ trong cơ sở dữ liệu an toàn? Tôi nhận ra rằng nếu ai đó xâm nhập vào cơ sở dữ liệu của tôi, họ sẽ nhận được mật khẩu của mọi người. Nhưng tôi có vấn đề khác nếu ai đó vào cơ sở dữ liệu của tôi, ví dụ như xóa dữ liệu.

Kịch bản tôi có thể nghĩ là bạn bị hack. Bạn khôi phục cơ sở dữ liệu từ vài giờ trước và mọi thứ đều ổn. Tuy nhiên, nếu mật khẩu của bạn là văn bản gốc ... Kẻ trộm có tất cả mật khẩu và bạn phải đặt lại tất cả. Hầm cho người dùng của bạn.

Nếu mật khẩu được mã hóa, bạn có thể khôi phục lại cơ sở dữ liệu trước đó. Đây có phải là suy nghĩ đúng?

Trước tiên, bạn nên tự do hơn với quyền truy cập chỉ đọc hơn đọc-ghi. Có thể tin tặc có quyền truy cập vào dữ liệu của bạn nhưng không thể chỉnh sửa dữ liệu.

Nhưng, quan trọng hơn nhiều, đây không phải là về bạn. Việc bạn có thể bị lừa nếu ai đó có toàn quyền truy cập vào cơ sở dữ liệu của bạn là không liên quan. Quan trọng hơn nhiều là dữ liệu người dùng của bạn .

Nếu bạn khôi phục cơ sở dữ liệu của mình, tin tặc vẫn có quyền truy cập vào tài khoản người dùng của bạn.

Và ai biết những gì khác? Nếu họ sử dụng cùng một mật khẩu tại Google thì sao? Hay PayPal? Điều gì sẽ xảy ra nếu điều đó cho phép tin tặc truy cập vào tên thời con gái của mẹ chúng hoặc 4 chữ số cuối của thẻ tín dụng của chúng?

Điều gì xảy ra nếu điều đó đưa họ vào các tài khoản khác? Đừng để tin tặc vượt qua hệ thống hỗ trợ người dùng và nhận thêm thông tin .

Chỉ là ... đừng. Đó là thông tin cá nhân của người dùng của bạn và bạn không cần phải xem thông tin đó. Đó cũng là danh tiếng của bạn. Mã hóa nó.

EDIT: Thêm một bình luận, để cứu bất kỳ độc giả nào trong tương lai khỏi việc đọc mọi câu trả lời và bình luận ...

Nếu bạn sẽ mã hóa (theo nghĩa chặt chẽ nhất) thì bạn cần sử dụng cặp khóa công khai / riêng , điều này tốt nhưng làm cho cuộc sống khó khăn hơn một chút cho cả bạn và người dùng của bạn.

Một giải pháp đơn giản và hiệu quả không kém là ngẫu nhiên - muối và băm mật khẩu. Băm một mình là không đủ; nếu người dùng của bạn sử dụng một mật khẩu phổ biến, nó sẽ xuất hiện trong các bảng băm ngược, có sẵn với một tìm kiếm internet đơn giản.

Nếu bạn bị hack, bạn có thể khôi phục trang web từ bản sao lưu và sửa nó. Nhưng tin tặc vẫn có mật khẩu cho tài khoản của mọi người! Có những ví dụ trong thế giới thực được ghi lại về điều này xảy ra (Sony, Linked-in), trong đó nếu các bảng mật khẩu được băm và muối đúng cách, việc đảm bảo và khôi phục dịch vụ nhanh chóng sẽ dễ dàng hơn nhiều.

Có lẽ là một ý tưởng tốt để cho rằng bạn sẽ bị hack và thiết kế chiến lược sao lưu của bạn và mã hóa bất kỳ dữ liệu nhạy cảm nào với giả định này. Và nó không chỉ là tin tặc bạn cần để bảo vệ chống lại. Những nhân viên bất mãn, không trung thực hoặc chỉ là không biết gì có thể cho đi mật khẩu văn bản đơn giản.

Nếu không băm, bạn sẽ phải vô hiệu hóa quyền truy cập cho mọi người cho đến khi họ thay đổi mật khẩu (điều này, ngay cả khi có thể, sẽ là một vấn đề đau đầu cho mọi người). Nếu mật khẩu đã được băm và muối, bạn có thể khôi phục dịch vụ web và kẻ tấn công sẽ khó truy cập vào tài khoản của mọi người hơn.

Một mật khẩu được băm và muối đúng cách về cơ bản là một chiều. Bạn không thể dễ dàng đoán mật khẩu từ mật khẩu băm. Ngay cả bạn, vì nhà cung cấp dịch vụ sẽ không thể đoán được, bạn chỉ có thể đặt lại.

Ngoài ra, như Elin đã nói, đừng thử và tự băm (hoặc mã hóa). Sử dụng một thư viện tiêu chuẩn.

Nhưng tôi có vấn đề khác nếu ai đó vào cơ sở dữ liệu của tôi, tức là xóa dữ liệu.

Đó không phải là về những vấn đề bạn gặp phải, mà là về những vấn đề có thể gây ra cho tất cả những người dùng khác của bạn. Đó là về việc loại bỏ cám dỗ (hoặc thậm chí tệ hơn, trách nhiệm tiềm năng) đối với những người làm việc trên trang web để lạm dụng dữ liệu được lưu trữ ở đó.

Hãy xem, mặc dù mọi người nên sử dụng các mật khẩu khác nhau trên các hệ thống khác nhau, nhưng thực tế là không .

... và vì việc băm mật khẩu rất dễ dàng, bạn không có lý do gì để không tuân theo các thực tiễn tốt nhất trong ngành.

Các cuộc tấn công đáng chú ý như xóa dữ liệu thường là công cụ của những người nghiệp dư và là mối lo lắng tối thiểu của bạn. Một trong những điều đầu tiên mà kẻ tấn công có kinh nghiệm sẽ làm là cố gắng giành quyền truy cập hợp pháp, vì vậy ngay cả khi bạn vá lỗ hổng ban đầu mà anh ta đã sử dụng, anh ta vẫn có thể vào được. Anh ta sẽ làm mọi cách để tránh gây sự chú ý cho đến khi anh ta hoàn thành những gì anh ấy mong muốn. Bằng cách để lại mật khẩu không bị xóa, bạn có khả năng làm cho công việc của anh ấy dễ dàng hơn rất nhiều. Bạn cũng làm cho việc phát hiện và cô lập hành vi độc hại trong tương lai của anh ta trở nên khó khăn hơn.

Ngoài ra, không phải tất cả các thỏa hiệp cung cấp cho bạn quyền truy cập toàn bộ. Điều gì xảy ra nếu lỗ hổng mà kẻ tấn công sử dụng chỉ là một SQL tiêm chỉ đọc trên usersbảng? Để lại mật khẩu không bị xóa chỉ giúp anh ta truy cập đầy đủ.

Đó là những lý do được đưa ra bởi các câu trả lời khác về trách nhiệm của bạn trong việc bảo vệ dữ liệu của người dùng. Quan điểm của tôi là, không chỉ người dùng của bạn có gì để mất.

Tôi phải đăng một câu trả lời ở đây về một ngụy biện trong chính câu hỏi. Bạn đang hỏi nếu mật khẩu nên được mã hóa. Không ai mã hóa mật khẩu; không ai, ngoại trừ các dịch vụ và chương trình như Firefox Sync và Roboform, với mục đích duy nhất là mã hóa mật khẩu.

Hãy xem xét các định nghĩa:

Trong mật mã, mã hóa là quá trình mã hóa tin nhắn (hoặc thông tin) theo cách mà chỉ các bên được ủy quyền mới có thể đọc được.

Và băm:

Hàm băm là bất kỳ thuật toán nào ánh xạ dữ liệu có độ dài tùy ý sang dữ liệu có độ dài cố định.

Nói cách khác, mã hóa là chuyển đổi hai chiều và băm là chuyển đổi một chiều , vì vậy trừ khi bạn giải mã để xem chúng sau này, đây không phải là mã hóa.

Ngoài ra, đừng chỉ băm, muối ! Đọc toàn bộ trang này trước khi bạn băm mật khẩu của bạn.

Đối với các thuật toán băm, mà OP hiện đang xem xét, tôi sẽ đề xuất bất kỳ biến số SHA-2 cao cấp nào, chẳng hạn như SHA-384 hoặc SHA-512.

Và hãy chắc chắn để sử dụng các vòng băm . Đừng băm một lần, băm nhiều lần.

Cân nhắc đọc trang này để đảm bảo quá trình đăng nhập của bạn nhiều hơn.

Thứ hai, cơ sở dữ liệu của bạn không bao giờ có thể đủ an toàn. Sẽ luôn có những lỗ hổng bảo mật và rủi ro không ngừng phát triển. Bạn nên tuân theo Luật Murphy và luôn chuẩn bị cho trường hợp xấu nhất.

Các điểm khác mà pdr đưa ra là chính xác những gì tôi sẽ nói: những người sử dụng cùng một mật khẩu cho mọi trang web, tin tặc sử dụng kỹ thuật xã hội để có thêm thông tin, v.v.

Có một nguyên tắc quan trọng đang bị đe dọa ở đây. Chỉ có một người có bất kỳ doanh nghiệp nào biết mật khẩu người dùng. Đó là người dùng. Không phải vợ / chồng, bác sĩ hay thậm chí là linh mục của họ.

Nó chắc chắn không bao gồm lập trình viên, quản trị viên cơ sở dữ liệu hoặc kỹ thuật viên hệ thống chịu trách nhiệm về dịch vụ họ đang sử dụng. Điều đó tạo ra một thách thức, vì lập trình viên có trách nhiệm nhận được chứng minh rằng người dùng thực sự biết mật khẩu, đây là một vấn đề không hề nhỏ để giải quyết một cách thuần túy.

Giải pháp thuần túy là có một cơ chế trong đó người dùng bị thách thức với một số dữ liệu mới và không thể đoán trước, sau đó phải trả lại phản hồi dựa trên dữ liệu này và mật khẩu của họ. Một cách thực hiện này là yêu cầu người dùng ký điện tử một số dữ liệu mới được tạo bằng chữ ký số của họ và chúng tôi có thể chứng minh một cách toán học rằng họ đã sử dụng cùng một cặp khóa mật mã mà họ đã sử dụng để tạo tài khoản ban đầu.

Trong thực tế, các giải pháp thuần túy đòi hỏi cơ sở hạ tầng và xử lý phía khách hàng đáng kể và đối với nhiều trang web, điều này thường không phù hợp với dữ liệu được bảo vệ.

Một giải pháp phổ biến hơn sẽ là:

Tại thời điểm mật khẩu được nhận lần đầu tiên trong ứng dụng, mật khẩu được chuyển sang chức năng băm, cùng với giá trị 'muối' ngẫu nhiên của ứng dụng vào hàm băm.

Chuỗi ban đầu sau đó được ghi đè trong bộ nhớ và từ thời điểm này, hàm băm được lưu trữ trong cơ sở dữ liệu hoặc được so sánh với bản ghi cơ sở dữ liệu.

Các khía cạnh chính cung cấp bảo mật ở đây là:

1. Kiến thức về hàm băm không trực tiếp cung cấp xác thực.
2. Tính toán ngược của mật khẩu từ hàm băm là không thực tế.
3. Việc sử dụng các bảng cầu vồng (danh sách dài các mật khẩu và các giá trị băm được tính toán của chúng) trở nên khó khăn hơn vì hàm băm kết quả phụ thuộc vào cả tên người dùng và mật khẩu.

Bạn cần "mã hóa" (thực ra là "băm", để có một khái niệm đúng về băm) mật khẩu như một lớp bảo vệ thứ hai : điều này có nghĩa là để ngăn kẻ tấn công, người có cái nhìn thoáng qua về cơ sở dữ liệu, chỉ leo thang rằng vào truy cập đọc-ghi và, chính xác, bắt đầu thay đổi dữ liệu. Vi phạm một phần chỉ đọc xảy ra trong thế giới thực, ví dụ như thông qua một số cuộc tấn công SQL SQL từ một tài khoản có quyền truy cập chỉ đọc hoặc bằng cách truy xuất một đĩa cứng bị loại bỏ hoặc băng dự phòng cũ từ một thùng rác. Tôi đã viết dài về chủ đề này ở đó .

Đối với các cách thích hợp để băm mật khẩu, xem câu trả lời này . Điều này liên quan đến muối, lặp đi lặp lại và, hầu hết, không phát minh ra thuật toán của riêng bạn (mật mã tự chế là một công thức chắc chắn cho thảm họa).

Tôi sẽ không lặp lại những gì người khác đã nói, nhưng giả sử bạn có PHP 5.3.8 trở lên, bạn nên sử dụng bản địa PHP bcryptđể lưu trữ mật khẩu của mình. Điều này được tích hợp vào PHP. Nếu bạn có PHP 5.5, bạn có thể sử dụng hằng số mật khẩu khả dụng tốt nhất. Bạn cũng có thể sử dụng thư viện để thực hiện 5.3.8 hoặc hoạt động tốt hơn như 5.5.

Câu hỏi về Stack Overflow Làm thế nào để bạn sử dụng bcrypt để băm mật khẩu trong PHP? giải thích nó, và các câu trả lời khác ở đó giải thích thêm. Xin đừng lộn xộn cố gắng tự làm điều này.

Tôi đồng ý với câu trả lời từ pdr, vì những lý do được nêu trong câu trả lời đó.

Tôi sẽ thêm vào như sau: bạn nên làm điều đó bởi vì nó dễ làm và thường được chấp nhận là cách thực hành tốt nhất cho bất kỳ ứng dụng nào. Cụ thể hơn, mật khẩu phải luôn được xử lý và băm trước khi ghi vào bất kỳ bộ lưu trữ liên tục nào. Dưới đây là một tài liệu tham khảo tốt về tầm quan trọng của việc tạo muối và chọn một hàm băm mật mã tốt (cũng cung cấp mã nguồn miễn phí trong một số ngôn ngữ phổ biến): https://crackstation.net/hashing-security.htmlm

Một lượng nhỏ thời gian phát triển thêm rất đáng để bảo vệ nó cung cấp cho người dùng của bạn và cho danh tiếng của bạn như là một nhà phát triển.

Kịch bản tôi có thể nghĩ là bạn bị hack.

Một kịch bản khác bạn cần nghĩ đến: ai đó đã trượt DBA của bạn (hoặc bất kỳ ai khác có thể chạy các truy vấn chọn trên DB của bạn) $ 100, để cung cấp cho họ mật khẩu của người dùng. Hoặc kỹ sư xã hội một số thực tập để làm điều đó.

Sau đó, họ sử dụng các mật khẩu đó để đăng nhập vào Gmail của người dùng ... hoặc trang web thương mại ... (vì chúng ta ... kém thông minh hơn chúng ta sẽ nói - và sử dụng cùng một mật khẩu trên các trang web).

Sau đó, người dùng giận dữ kiện công ty của bạn để lộ mật khẩu của họ.

NOBODY (bao gồm những người trong công ty của bạn) sẽ có thể đọc mật khẩu văn bản đơn giản. Không bao giờ. Không có nhu cầu kinh doanh hoặc kỹ thuật hợp pháp cho điều đó.

Đối với một, ngay cả quản trị viên cơ sở dữ liệu cũng không nên xem mật khẩu của người dùng. Băm chúng sẽ ngăn chặn điều này trong trường hợp quản trị viên quyết định xem mật khẩu và đăng nhập vào tài khoản của người dùng.

Vâng, đó là đáng ngạc nhiên không ai có đề cập này, tuy nhiên, nhưng những gì về THỂ an ninh của cơ sở dữ liệu của bạn?

Bạn có thể có bảo mật CNTT tốt nhất trên thế giới được thiết lập, nhưng điều đó không ngăn cản bất kỳ ai có thể truy cập vật lý vào phương tiện lưu trữ của bạn. Điều gì xảy ra khi nhóm của bạn giành được Superbowl vào chiều nay và một cuộc bạo loạn nhỏ nổ ra ở khu vực trung tâm thành phố của bạn nơi có nhà cung cấp văn phòng / lưu trữ của bạn? (Cho rằng đó là Seattle so với Denver, hai lĩnh vực CNTT lớn ở Hoa Kỳ, tôi không nghĩ điều đó không hợp lý). Đám đông đập vào tòa nhà của bạn và trong khi chính quyền tràn ngập, ai đó lấy một số phần cứng của bạn có DB trên đó có chứa mật khẩu văn bản rõ ràng?

Điều gì xảy ra khi Fed xuất hiện và tịch thu thiết bị của bạn bởi vì một số nhà điều hành cấp cao đang sử dụng vị trí của anh ta trong công ty để thực hiện giao dịch chứng khoán bất hợp pháp? Sau đó, Fed sử dụng các mật khẩu đó để điều tra khách hàng của bạn, mặc dù họ không làm gì sai. Sau đó, họ nhận ra rằng chính BẠN đã khiến họ dễ bị tổn thương.

Điều gì xảy ra khi bộ phận CNTT của bạn quên xóa các ổ RAID cũ chứa DB của bạn khi chúng thay thế theo lịch trình trước khi "giao" các ổ đĩa cũ cho thực tập viên, và sau đó bạn cùng phòng ký túc xá của họ tìm thấy những gì bị bỏ lại phía sau và tìm ra chúng có thể " bán "nó và không bao giờ có dấu vết trở lại với họ?

Điều gì xảy ra khi Máy chủ DB của bạn thổi bo mạch chủ, CNTT khôi phục hình ảnh cho máy chủ mới của bạn và "thân thịt" của máy chủ cũ bị ném vào đống tái chế? Những ổ đĩa đó vẫn còn tốt, và dữ liệu đó vẫn còn đó.

Bất kỳ kiến ​​trúc sư tử tế nào cũng biết rằng bảo mật không phải là thứ bạn "chốt" sau này bằng tường lửa và chính sách hoạt động. Bảo mật phải là một phần cơ bản của thiết kế ngay từ đầu, và điều đó có nghĩa là mật khẩu được băm một chiều, KHÔNG BAO GIỜ được truyền bằng mã hóa (ngay cả trong các trung tâm dữ liệu của riêng bạn) và không bao giờ có thể phục hồi được. Bất cứ điều gì có thể được lấy có thể được thỏa hiệp.

Đặt trường hợp cơ sở dữ liệu của bạn bị hack: Là một khách hàng, tôi sẽ không muốn BẠN biết mật khẩu của mình. Tôi biết rằng bạn có thể dễ dàng bắt được mật khẩu khi có yêu cầu, nhưng tôi có cảm giác tốt hơn khi bạn không có quyền đó để truy vấn bất cứ lúc nào bạn muốn.

Nếu mật khẩu được lưu trữ trong văn bản thuần, điều đó có nghĩa là chúng được người dùng biết đến và bất kỳ ai có quyền truy cập vào bảng đó. Toàn bộ ý tưởng về việc triển khai người dùng và mật khẩu là để đảm bảo rằng một phiên nhất định trong hệ thống của bạn thuộc về một người đã nói, cả vì lý do riêng tư và bảo mật.

Nếu một nhóm người biết tên người dùng / mật khẩu, việc xác định một người một cách dứt khoát sẽ trở nên vô dụng và điều đó tạo ra rất nhiều tình huống có thể xảy ra đối với hành vi trộm cắp danh tính, lừa đảo ...

Đó là lý do tại sao mật khẩu được lưu trữ bằng các giao thức mã hóa không đối xứng, để đảm bảo rằng bạn có thể xác thực chúng mà không có khả năng đọc chúng.

Tôi nghĩ rằng có một lỗ hổng cơ bản trong câu hỏi. Thực tế là, không có thứ gọi là "cơ sở dữ liệu an toàn". Cần phải xem xét rằng có một số lỗ hổng trong hệ thống của bạn ở đâu đó có thể cho phép người dùng độc hại truy cập vào dữ liệu tùy ý trên máy chủ của bạn. Heartbleed là một trường hợp xuất sắc, là một khai thác trong tự nhiên trong hơn hai năm trước khi nó được các nhà nghiên cứu chú ý. Bạn có thể đã làm mọi thứ bạn biết cách làm để bảo vệ dữ liệu, nhưng bạn không thể tính đến tất cả các phần mềm khác mà bạn đang sử dụng trên máy chủ của mình và những cách phức tạp mà chúng tương tác.

Nếu ai đó quan tâm đến bạn, bạn sẽ bị hack. Điều quan trọng là phải cố gắng hết sức để ngăn chặn việc bị tấn công ngay từ đầu, nhưng cũng để giảm thiểu thiệt hại xảy ra khi nó xảy ra bằng cách đặt càng nhiều chướng ngại vật càng tốt. Băm mật khẩu của bạn. Không khó để thiết lập và bạn đang làm cho người dùng của mình không hài lòng bằng cách không coi trọng quyền riêng tư của họ. Thật ngớ ngẩn khi nghĩ rằng bạn bằng cách nào đó được bảo vệ tốt hơn trước các cuộc tấn công độc hại so với các công ty như Yahoo , hoặc Sony hoặc Target , tất cả những người đã bị hack.