Có đáng để băm mật khẩu ở phía khách hàng không

Khi tôi muốn đặt một hệ thống đăng nhập, tôi luôn so sánh MD5 của mật khẩu đã cho với giá trị của nó trong bảng người dùng ở phía máy chủ.

Tuy nhiên, một người bạn của tôi nói với tôi rằng mật khẩu "rõ ràng" có thể bị phần mềm mạng đánh hơi.

Vì vậy, câu hỏi của tôi là: nó có phải là một ý tưởng tốt để băm mật khẩu ở phía khách hàng? Có tốt hơn băm nó ở phía máy chủ không?

Về cơ bản, bạn của bạn là đúng. Nhưng chỉ đơn giản là băm mật khẩu ở phía máy khách chỉ tốt hơn là gửi nó dưới dạng văn bản thuần túy đến máy chủ. Ai đó, những người có thể nghe mật khẩu văn bản đơn giản của bạn chắc chắn cũng có thể nghe mật khẩu băm và sử dụng các hàm băm bị bắt này để xác thực với máy chủ của bạn.

Đối với vấn đề này, các giao thức xác thực an toàn hơn thường nhảy qua một số vòng để đảm bảo rằng một cuộc tấn công phát lại như vậy không thể hoạt động, thông thường, bằng cách cho phép khách hàng chọn một loạt các bit ngẫu nhiên, được băm cùng với mật khẩu , và cũng được gửi rõ ràng đến máy chủ.

Trên máy chủ:

• tạo ra một vài bit ngẫu nhiên
• gửi các bit này (bằng văn bản rõ ràng) cho khách hàng

Trên máy khách:

• tạo ra một vài bit ngẫu nhiên
• nối mật khẩu, bit ngẫu nhiên của máy chủ và bit ngẫu nhiên của máy khách
• tạo hàm băm ở trên
• gửi các bit ngẫu nhiên (bằng văn bản rõ ràng) và băm đến máy chủ

Vì máy chủ biết thông tin ngẫu nhiên của riêng mình cũng như các bit ngẫu nhiên của khách hàng (nó có chúng dưới dạng văn bản rõ ràng), nên về cơ bản nó có thể thực hiện chuyển đổi tương tự. Giao thức này đảm bảo rằng không ai nghe trong cuộc hội thoại này có thể sử dụng thông tin sau này để xác thực bằng cách sử dụng thông tin được ghi lại (trừ khi sử dụng thuật toán rất yếu ...), miễn là cả hai bên tạo ra các "bit nhiễu" khác nhau mỗi lần, lắc tay được thực hiện.

Chỉnh sửa Tất cả điều này là dễ bị lỗi và tẻ nhạt và hơi khó để có được đúng (đọc: an toàn). Nếu có thể, hãy cân nhắc sử dụng các triển khai giao thức xác thực đã được viết bởi những người có kiến ​​thức (không giống tôi! Phần trên chỉ là từ bộ nhớ của cuốn sách tôi đọc cách đây một thời gian.) Bạn thực sự không muốn tự mình viết nó.

Trước hết, điều này KHÔNG cải thiện tính bảo mật của ứng dụng của bạn (giả sử đó là một ứng dụng web).

Sử dụng SSL (Hoặc thực tế là TLS, thường được gọi là SSL), nó không thực sự tốn kém (Đo thời gian bạn đang sử dụng để tìm cách xoay quanh nó và nhân nó với mức lương tối thiểu, mua chứng chỉ thắng hầu như luôn luôn).

Tại sao điều này là đơn giản. TLS giải quyết một vấn đề (khi được sử dụng với các chứng chỉ đã mua, không tự ký) khá lớn về mật mã: Làm thế nào để tôi biết máy chủ mà tôi đang nói chuyện là máy chủ mà tôi nghĩ tôi đang nói chuyện? Chứng chỉ TLS là một cách để nói: "Tôi, cơ quan cấp chứng chỉ, được trình duyệt của bạn tin cậy, xác nhận rằng trang web tại [url] có khóa chung này, với khóa riêng tương ứng, chỉ (khóa riêng) mà máy chủ biết, nhìn Tôi đã ký chữ ký của mình trên tất cả các tài liệu, nếu có ai thay đổi nó, bạn có thể thấy ".

Không có TLS, mọi mã hóa đều trở nên vô nghĩa, bởi vì nếu tôi ngồi cạnh bạn trong một quán cà phê, tôi có thể khiến máy tính xách tay / điện thoại thông minh của bạn nghĩ rằng tôi là máy chủ và MiTM (Người đàn ông ở giữa). Với TLS, máy tính xách tay / điện thoại thông minh của bạn sẽ hét lên "KẾT NỐI KHÔNG GIỚI HẠN", vì tôi không có giấy chứng nhận đã ký chứng nhận phù hợp với trang web của bạn. (Mã hóa so với xác thực).

Tuyên bố miễn trừ trách nhiệm: người dùng có xu hướng nhấp chuột phải qua các cảnh báo sau: "Kết nối không tin cậy? Cái gì? Tôi chỉ muốn hình ảnh của tôi về mèo con! Thêm ngoại lệ Nhấp vào Xác nhận Nhấp vào YAY! Mèo con!"

Tuy nhiên, nếu bạn thực sự không muốn mua chứng chỉ, vẫn KHÔNG thực hiện băm javascript phía máy khách (và sử dụng thư viện standford (SJCL) cho điều đó, KHÔNG BAO GIỜ THỰC HIỆN CRYPTO CỦA BẠN ).

Tại sao? Sử dụng lại mật khẩu! Tôi có thể đánh cắp cookie phiên của bạn (cho phép tôi giả vờ với máy chủ của bạn rằng tôi là bạn) mà không cần HTTPS một cách dễ dàng (xem Firesheep). Tuy nhiên, nếu bạn thêm javascript vào trang đăng nhập, trước khi gửi, băm mật khẩu của bạn (sử dụng SHA256 hoặc thậm chí tốt hơn, hãy sử dụng SHA256, gửi cho họ khóa công khai mà bạn đã tạo và sau đó mã hóa mật khẩu băm bằng mật khẩu đó, bạn không thể sử dụng muối với điều này), và sau đó gửi mật khẩu băm / mã hóa đến máy chủ. REHASH băm trên máy chủ của bạn bằng một muối và so sánh nó với những gì được lưu trữ trong cơ sở dữ liệu của bạn (lưu trữ mật khẩu như thế này:

(SHA256(SHA256(password)+salt))

(cũng lưu muối dưới dạng văn bản gốc trong cơ sở dữ liệu)). Và gửi mật khẩu của bạn như thế này:

RSA_With_Public_Key(SHA256(password))

và kiểm tra mật khẩu của bạn như thế này:

if SHA256(RSA_With_Private_Key(SHA256(sent_password))+salt_for_username) == stored_pass: login = ok

Bởi vì, NẾU ai đó đang đánh hơi khách hàng của bạn, họ sẽ có thể đăng nhập như khách hàng của bạn (phiên hijacking) nhưng họ sẽ không bao giờ nhìn thấy các mật khẩu chữ thô (trừ khi họ thay đổi javascript của bạn, tuy nhiên, một Starbucks của hacker có thể sẽ không biết howto / được quan tâm trong này.) Vì vậy, họ sẽ có quyền truy cập vào ứng dụng web của bạn, nhưng không truy cập email / facebook / của họ. (người dùng của bạn có thể sẽ sử dụng cùng một mật khẩu). (Địa chỉ email sẽ là tên đăng nhập của họ hoặc sẽ được tìm thấy trong hồ sơ / cài đặt của họ trên ứng dụng web của bạn).

Bạn có thể không lo lắng về điều này - vì Dirk đề cập ngay cả khi bạn băm mật khẩu, một người dùng độc hại có thể ở trên mạng và thấy hàm băm được gửi và chỉ có thể tự gửi chính hàm băm đó.

Nó tốt hơn một chút , ở chỗ nó ngăn người dùng độc hại biết mật khẩu là gì, nhưng vì họ vẫn có thể đăng nhập (hoặc có khả năng xây dựng lại mật khẩu gốc ), điều đó không hữu ích.

Nói chung, nếu bạn lo lắng về sự an toàn của mật khẩu và dữ liệu của người dùng (và bạn nên như vậy!), Bạn sẽ muốn sử dụng máy chủ SSL an toàn. Nếu đây không phải là mối quan tâm của bạn vì bất kỳ lý do gì bạn có thể không bận tâm đến việc băm; nó chỉ bảo mật thông qua che khuất .

Chỉnh sửa tháng 8 năm 2014: Google đang thúc đẩy ngày càng mạnh mẽ hơn để các trang web chuyển sang HTTPS ở mọi nơi , bởi vì bảo mật thông tin liên lạc là cách duy nhất để ngăn chặn các cuộc tấn công đánh hơi mạng. Nỗ lực che giấu dữ liệu được truyền sẽ chỉ cản trở, không dừng lại, một kẻ tấn công chuyên dụng và có thể mang lại cho các nhà phát triển cảm giác an toàn sai lầm nguy hiểm.

Trên thực tế tôi không đồng ý rằng băm phía khách hàng an toàn hơn trong trường hợp này. Tôi nghĩ nó kém an toàn.

Toàn bộ điểm lưu trữ băm mật khẩu trong cơ sở dữ liệu của bạn trái ngược với mật khẩu thật (hoặc thậm chí là mật khẩu được mã hóa) là về mặt toán học không thể lấy được mật khẩu ban đầu từ hàm băm (mặc dù về mặt lý thuyết là có thể có được sự va chạm đầu vào băm, độ khó của nó phụ thuộc vào cường độ bảo mật của thuật toán băm). Vectơ tấn công có thể xảy ra ở đây là nếu kẻ tấn công tiềm năng bằng cách nào đó đã xâm phạm cơ sở dữ liệu lưu trữ mật khẩu của bạn, anh ta / cô ta vẫn không thể lấy được mật khẩu gốc của người dùng.

Nếu cơ chế xác thực của bạn gửi băm mật khẩu, thì trong trường hợp vi phạm bảo mật này, kẻ tấn công không cần biết mật khẩu thực - họ chỉ cần gửi băm mà họ có và xin chào, họ có quyền truy cập vào tài khoản người dùng cụ thể, và bằng cách mở rộng, toàn bộ hệ thống của bạn. Điều này hoàn toàn đánh bại điểm lưu trữ mật khẩu băm ở nơi đầu tiên!

Cách thực sự an toàn là gửi cho khách hàng một khóa công khai một lần để họ mã hóa mật khẩu, sau đó bạn giải mã và băm lại nó ở phía máy chủ.

Nhân tiện, loại câu hỏi này có thể sẽ nhận được nhiều câu trả lời của chuyên gia hơn về Security StackExchange.

Lưu ý rằng việc giữ mật khẩu an toàn trước các bên thứ ba không phải là tất cả.

Ngay khi có quyền riêng tư (và bao giờ thì không, ngày nay?) Bạn không muốn biết mật khẩu. Bạn không thể lạm dụng hoặc rò rỉ những gì bạn không có , vì vậy cả bạn và khách hàng của bạn đều có thể ngủ ngon hơn nếu bạn chưa bao giờ thấy mật khẩu văn bản rõ ràng của họ.

Do đó, băm / mã hóa phía máy khách có ý nghĩa.

Nó phụ thuộc, bạn có thể sử dụng băm phía máy khách, nhưng muối phía máy chủ sẽ không thể thực hiện được.

hãy xem liên kết Mã hóa mật khẩu ở phía khách hàng

Gần đây tôi đã làm rất nhiều việc, IRL có hai vấn đề với mã hóa băm / đối xứng phía máy khách thực sự giết chết ý tưởng: 1. Bạn phải lấy lại muối cho máy chủ SOMEHOW ... và để mã hóa phía khách hàng bạn cần một mật khẩu ... đánh bại mục đích. 2. Bạn phơi bày việc thực hiện băm của mình (không phải là một thỏa thuận HUGE vì hầu hết các trang web sử dụng một trong 3 hoặc 4 thuật toán băm), điều này làm cho cuộc tấn công dễ dàng hơn (vì chỉ cần thử một lần thay vì n).

Điều cuối cùng tôi đã đi đến là mã hóa bất đối xứng trên máy khách bằng cách sử dụng OpenPGP.js hoặc tương tự ... Điều này phụ thuộc vào khóa được nhập hoặc phía máy khách được tạo trên máy khách và máy chủ gửi khóa công khai. Chỉ khóa công khai của khách hàng có thể được gửi trở lại máy chủ. Điều này bảo vệ chống lại các cuộc tấn công MIM và an toàn như thiết bị (Tôi hiện lưu trữ khóa riêng của khách hàng theo mặc định trong localStore, đây là bản demo).

Ưu điểm CHÍNH của điều này là tôi không bao giờ phải lưu trữ dữ liệu người dùng / ngay cả trong bộ nhớ không được mã hóa trên máy chủ / kho dữ liệu của tôi (và khóa riêng của máy chủ của tôi là riêng biệt)

Cơ sở của việc này là cung cấp cho mọi người cách liên lạc an toàn khi HTTPS bị hạn chế (ví dụ: Iran / N. Korea atc ​​...) và cũng chỉ là một thử nghiệm thú vị.

Tôi là FAR từ người đầu tiên nghĩ về điều này, http://www.mail phong.com / sử dụng cái này

Nếu ai đó có thể thấy dữ liệu vào và ra trên kết nối của bạn thì xác thực sẽ không cứu bạn. Thay vào đó tôi sẽ làm như sau cho những thứ siêu bí mật.

Mật khẩu được cài sẵn ở phía máy khách trước khi gửi đến máy chủ. (Máy chủ lưu trữ một giá trị băm và muối khác của hàm băm đó được gửi từ trình duyệt).

Vì vậy, một cuộc tấn công của người trung gian có thể cho phép họ gửi cùng một giá trị băm để đăng nhập như họ, nhưng mật khẩu người dùng sẽ không được biết. Điều này sẽ ngăn họ thử các dịch vụ khác có cùng thông tin đăng nhập ở nơi khác.

Dữ liệu người dùng cũng được mã hóa ở phía trình duyệt.

À, vậy một cuộc tấn công của người trung gian sẽ lấy được dữ liệu được mã hóa, nhưng sẽ không thể giải mã nó nếu không có mật khẩu thực tế được sử dụng để đăng nhập. (mật khẩu người dùng được lưu trong DOM trên trình duyệt khi họ đăng nhập). Vì vậy, người dùng thực sự sẽ thấy nội dung được giải mã nhưng người trung gian thì không thể. Điều này cũng có nghĩa là bất kỳ NSA hoặc cơ quan nào khác sẽ không thể yêu cầu bạn / công ty / nhà cung cấp dịch vụ lưu trữ giải mã dữ liệu này vì họ cũng không thể làm như vậy.

Một số ví dụ nhỏ về cả hai phương pháp này đều có trên blog của tôi http://glynrob.com/javascript/client-side-hashing-and-encoding/

Gần đây, cả GitHub và Twitter đều thông báo rằng mật khẩu được lưu trữ trong nhật ký nội bộ. Tôi đã vô tình xảy ra trong các báo cáo lỗi và các nhật ký khác tìm thấy sự cố của mình, v.v. Đối với twitter nếu mật khẩu của Trump có trong nhật ký thì đó có thể là một vấn đề lớn đối với một quản trị viên để "xem", đối với các trang web khác có thể không phải là một thỏa thuận lớn vì các quản trị viên sẽ không sử dụng nhiều cho nó. Bất kể là quản trị viên, chúng tôi không muốn nhìn thấy mật khẩu.

Vì vậy, câu hỏi thực sự là liệu băm có xảy ra phía máy khách để bảo mật hay không, nhưng làm thế nào chúng ta có thể bảo vệ mật khẩu trước khi nó bị băm và so sánh bởi phía máy chủ để nó không bị đăng nhập.

Mã hóa không phải là ý tưởng tồi vì ít nhất các nhà phát triển phải vượt qua một số vòng và nếu bạn thấy mật khẩu đã vào nhật ký, bạn có thể thay đổi khóa mã hóa, phá hủy bản gốc và dữ liệu đó trở nên vô dụng. Tốt hơn là xoay các phím hàng đêm và nó có thể làm giảm các cửa sổ rất nhiều.

Bạn cũng có thể băm một hàm băm trong hồ sơ người dùng của bạn. Các mật khẩu bị rò rỉ sẽ được băm mật khẩu văn bản đơn giản. Máy chủ sẽ lưu trữ một phiên bản băm của hàm băm. Chắc chắn hàm băm trở thành mật khẩu, nhưng trừ khi bạn có bộ nhớ ảnh, bạn sẽ không nhớ 60 char bcyrpt. Muối với tên người dùng. Nếu bạn có thể thu thập một cái gì đó về người dùng trong quá trình đăng nhập (trong khi không tiết lộ rằng hồ sơ người dùng tồn tại), bạn có thể tạo muối với điều đó cũng như tạo ra một hàm băm mạnh mẽ hơn không thể chia sẻ giữa các trang web. Không có người đàn ông nào ở giữa có thể chỉ cần cắt và dán băm đã chụp giữa các trang web.

Kết hợp với một cookie không được gửi trở lại máy chủ và bạn có thể vào một cái gì đó. Theo yêu cầu đầu tiên, hãy gửi cookie cho khách hàng bằng một khóa, sau đó đảm bảo rằng cookie không quay trở lại dịch vụ đăng nhập để có rất ít cơ hội được đăng nhập. Lưu trữ khóa trong một cửa hàng phiên, và sau đó xóa nó ngay sau khi đăng nhập xảy ra hoặc khi phiên hết hạn ... điều này đòi hỏi trạng thái cho các bạn JWT, nhưng có lẽ chỉ cần sử dụng dịch vụ nosql cho nó.

Vì vậy, một quản trị viên bắt gặp một trong những mật khẩu được băm và mã hóa trong splunk hoặc một công cụ báo cáo lỗi. Nó sẽ vô dụng với họ vì họ không thể tìm thấy khóa mã hóa nữa, và ngay cả khi họ đã làm thì họ cũng phải dùng vũ lực băm. Ngoài ra, người dùng cuối không gửi bất kỳ nội dung rõ ràng nào dọc theo đường dây để bất kỳ người đàn ông nào ở giữa ít nhất cũng có thời gian khó khăn hơn và bạn không thể nhảy đến một trang web khác và đăng nhập.

Xem xét điều này:-

Khách hàng gửi yêu cầu đến máy chủ "Tôi có mật khẩu để xác thực".

Máy chủ gửi cho khách hàng một chuỗi ngẫu nhiên một lần duy nhất. R $

Máy khách nhúng mật khẩu của người dùng trong chuỗi này (dựa trên bất kỳ quy tắc (biến) nào bạn muốn áp dụng).

Máy khách gửi chuỗi đến máy chủ và nếu mật khẩu OK, máy chủ sẽ đăng nhập người dùng.

Nếu máy chủ nhận được yêu cầu đăng nhập khác bằng R $, người dùng đã đăng xuất và tài khoản bị đóng băng đang chờ điều tra.

Rõ ràng tất cả các biện pháp phòng ngừa an ninh (bình thường) khác sẽ được thực hiện.

Ý tưởng băm phía khách hàng này là để bảo vệ người dùng, không phải trang web của bạn. Như đã đề cập nhiều lần, cả văn bản đơn giản hoặc mật khẩu băm đều có quyền truy cập vào trang web của bạn như nhau. Bạn không nhận được một lợi ích bảo mật.

Nhưng người dùng của bạn thực sự, văn bản đơn giản, mật khẩu chỉ nên được biết bởi họ. Biết những gì họ chọn làm mật khẩu là thông tin có thể được sử dụng để chống lại họ trên các trang web và hệ thống khác. Bạn đang là một trang web tập trung vào khách hàng bằng cách bảo vệ họ khỏi sự lựa chọn mật khẩu của họ được phát hiện bởi các nhà phát triển máy chủ của bạn hoặc bởi các bên thứ ba.