it-swarm-vi.com

Đặt lại mật khẩu - những dịch vụ web nào nên tuân theo?

Nhiều người trong số các bạn có thể đã thấy Cách Apple và lỗ hổng bảo mật của Amazon dẫn đến hack My Epic , trong đó tài khoản Amazon, Apple, Gmail và Twitter của một phóng viên có dây đã bị hack thành công Tin tặc đã thực hiện theo một chuỗi các bước phức tạp, ở mỗi bước sử dụng quy trình khôi phục mật khẩu tại một dịch vụ web để lấy thông tin cần thiết để tấn công tài khoản của phóng viên trên dịch vụ web tiếp theo. Kẻ tấn công có thể khai thác thành công biến thể giữa các dịch vụ khác nhau ' yêu cầu cho những gì họ yêu cầu để thực hiện thiết lập lại mật khẩu, để xâu chuỗi cuộc tấn công của anh ta và cuối cùng thực hiện thành công một cuộc tấn công thảm khốc vào phóng viên Wired tội nghiệp.

Trước vấn đề này, các dịch vụ web nên tuân theo những thực hành nào, để bảo vệ chức năng đặt lại mật khẩu của họ và ngăn ngừa sự tái diễn của một lỗi như vậy? Ngành công nghiệp cần phải làm gì để đảm bảo điều này không xảy ra nữa?

26
D.W.

Tôi thực sự đã làm việc với một số ý tưởng xung quanh khu vực này, vì vậy đây là một đống suy nghĩ của tôi cho đến nay. Tôi xin lỗi trước vì độ dài vô lý của câu trả lời này.

Các cơ chế đặt lại mật khẩu phải được thiết kế với ba mục tiêu chính:

  • Bảo vệ
  • Khả năng sử dụng
  • Độ tin cậy

Để có một cơ chế tốt, chúng ta cần đạt được sự cân bằng giữa ba.

Một vài khẳng định mà tôi muốn đưa ra trước khi bắt đầu:

Phải, vào câu trả lời thực tế!


1. Xác thực đa yếu tố

Xác thực đa yếu tố (MFA) là một trong những phương pháp an toàn nhất để khôi phục tài khoản và xác thực con người nói chung. Đối với những người không quen thuộc với MFA, nó hoạt động theo nguyên tắc bạn phải có nhiều hơn một thông tin để xác thực:

  • Một cái gì đó bạn biết (ví dụ: mật khẩu, câu trả lời bí mật)
  • Một cái gì đó bạn có (ví dụ: khóa, mã thông báo phần cứng, v.v.)
  • Một cái gì đó bạn là (ví dụ: dấu vân tay)

Lưu ý rằng có nhiều loại của một loại, ví dụ: hai mật khẩu, hoặc mật khẩu và mã pin, không không được tính là MFA. Tôi đang nhìn bạn, các trang web ngân hàng trực tuyến.

1.1. Một cái gì đó bạn biết

Khi đặt lại mật khẩu, một cách phổ biến để xác thực người dùng là hỏi họ một số câu hỏi . Thật không may, những câu hỏi này thường là những câu như "Bạn đã học trường nào?" và "Tên thời con gái của mẹ bạn là gì?", những kẻ tấn công cực kỳ dễ dàng tìm ra thông qua mạng xã hội. Hơn nữa, nhiều người dùng không thích trả lời những câu hỏi này khi đăng ký, vì vậy họ chỉ nhấn một loạt các khóa và làm mất hiệu lực mục đích của câu hỏi.

Đối với các ứng dụng web thương mại điện tử và các ứng dụng web khác lưu trữ thông tin cá nhân riêng tư (ví dụ: địa chỉ/số điện thoại), người ta có thể yêu cầu thông tin đó. Tuy nhiên, hãy nhớ rằng thông tin này cũng có thể được tìm thấy trực tuyến.

Một cách khác là đặt câu hỏi theo ngữ cảnh, dựa trên trải nghiệm của người dùng trên trang web. Ví dụ: Hotmail yêu cầu một địa chỉ email mà bạn đã liên lạc gần đây, cũng như một số thông tin khác về hoạt động trên tài khoản của bạn. Điều này khá thích ứng với hầu hết các loại webapp, nhưng không phải lúc nào cũng có thể áp dụng được.

1.2. Một cái gì đó bạn có

Thông thường các trang web sẽ mô tả gửi email một liên kết hoặc mật khẩu một lần đến địa chỉ email của bạn dưới dạng MFA. Tôi khẳng định rằng đây là một giả định sai. Người dùng chia sẻ mật khẩu giữa các tài khoản. Đây là một thực tế tuyệt đối, và bạn không thể ngăn chặn nó. Như vậy, bạn phải cho rằng kẻ tấn công đã có quyền truy cập vào địa chỉ email của người dùng. Chúng tôi sẽ đề cập đến ý nghĩa của việc này sau.

Sự phổ biến của điện thoại di động đã biến chúng thành một cơ chế tuyệt vời để xác thực hai yếu tố, như một hình thức kiểm tra ngoài băng tần. SMS mã thông báo đặt lại dễ dàng cho người dùng hiểu và sử dụng, và kẻ tấn công có quyền truy cập vào điện thoại là không thể. Tuy nhiên, phương pháp này không phải là không có lỗi. Vấn đề lớn nhất là khi người dùng mất điện thoại của họ hoặc nhà cung cấp thay đổi. Điều này hoàn toàn vô hiệu hóa điện thoại như một thiết bị đặt lại có thể sử dụng được. Một vấn đề khác là người dùng không luôn có điện thoại bên mình.

Sử dụng một ứng dụng trên điện thoại thông minh sẽ khắc phục một phần vấn đề này. Nếu người dùng thay đổi nhà cung cấp của họ, ứng dụng vẫn còn trên điện thoại. Cho phép đặt lại cả dựa trên SMS và dựa trên ứng dụng cho phép kỳ vọng hợp lý về độ tin cậy.

Ngoài ra, cho phép người dùng liên kết tài khoản nhà cung cấp đăng nhập (ví dụ: OpenID) và sử dụng thông tin đăng nhập hợp lệ cho tài khoản đó làm bằng chứng "điều bạn biết".

Các cơ chế tiềm năng khác:

  • Mã thông báo vật lý (ví dụ: RSA SecurID , mã thông báo USB) - không chính xác cho hầu hết các địa điểm, nhưng hữu ích cho ngân hàng, hệ thống công ty nội bộ và các tình huống bảo mật cao khác.
  • Tệp - Tệp được tạo ngẫu nhiên cho người dùng khi đăng ký. Hash được lưu trữ trong cơ sở dữ liệu. Khi thiết lập lại, người dùng yêu cầu cung cấp tệp. Không phải là khả năng sử dụng tốt nhất hoặc bảo mật, nhưng có khả năng hữu ích.

1.3. Một cái gì đó bạn là

Đây là nơi mọi thứ trở nên thú vị và khoa học viễn tưởng. Xác thực sinh trắc học là thứ đã trở nên phổ biến gần đây. Khá nhiều máy tính xách tay bao gồm máy quét dấu vân tay và bạn có thể chọn những chiếc USB giá rẻ với chi phí khá nhỏ. Một cơ chế sinh trắc học phổ biến khác là nhận dạng khuôn mặt, thông qua webcam. Cả hai đều tuyệt vời về bảo mật khi được thực hiện đúng, nhưng cả hai đều có một vài vấn đề:

  • Hầu hết các triển khai là xác suất, và do đó không an toàn. Điều gì ngăn kẻ tấn công giữ một bức ảnh khuôn mặt của bạn lên máy ảnh?
  • Bạn không thể dựa vào mọi người dùng có máy quét dấu vân tay và những người không tương thích với nhau. Hơn nữa, bạn đang can thiệp vào phần cứng, do đó cần có ứng dụng gốc để nói chuyện với ứng dụng web của bạn.
  • Lĩnh vực sinh trắc học tương đối mới, do đó, không có bất kỳ triển khai nào được nghiên cứu đúng cách với các mô hình bảo mật được hiểu đầy đủ.

Nói chung, mô hình "một cái gì đó bạn là" hoạt động để nhận dạng cá nhân, nhưng không thực sự khả thi cho các ứng dụng web trừ khi bạn cung cấp cho khách hàng của mình máy quét vân tay và phần mềm phù hợp.

1.4. Thực hành tốt nhất MFA

Xác thực một yếu tố là không đủ. Như chúng ta đã thấy từ tất cảthegần đâyvi phạm thật khó để giữ mật khẩu an toàn và ngay cả khi chúng ' băm lại họ vẫn có thể bị phá vỡ. MFA là cần thiết cho cả hai khôi phục đăng nhập và mật khẩu. Xác thực di động cho mục đích khôi phục giải quyết hầu hết các vấn đề, miễn là thiết bị di động vẫn có thể sử dụng được. Trong trường hợp không thể xác thực di động, bạn phải có quy trình xác minh thủ công, tại đó họ phải thuyết phục một người rằng họ là thật thỏa thuận.


2. Đặt lại cơ chế

Có vô số phương pháp đặt lại mật khẩu khác nhau, nhiều phương pháp bị tụt hậu về mặt bảo mật. Tôi sẽ thảo luận về một số điều mà tôi đã thấy trong tự nhiên, giải thích những điểm tốt và xấu của họ, và đề xuất một số điểm tốt hơn.

2.1. Gửi lại mật khẩu

Cơ chế cơ bản nhất là chỉ gửi email mật khẩu của người dùng cho họ. Làm ơn đừng bao giờ làm điều này . Thật kinh khủng không thể đo lường được . Đầu tiên, nó yêu cầu bạn lưu trữ mật khẩu ở dạng văn bản rõ ràng hoặc ít nhất là ở định dạng có thể đảo ngược. Bạn phải băm mật khẩu đúng cách và làm theo cách thực hành tốt nhất để tạo muối . Thứ hai, bạn đang gửi email mật khẩu của người dùng bằng văn bản rõ ràng, qua giao thức Cleartext qua internet. Có một cấp độ địa ngục đặc biệt dành riêng cho những người làm việc này.

2.2. Tạo mật khẩu mới

Một số trang web tạo mật khẩu ngẫu nhiên mới, băm mật khẩu, sau đó gửi email cho người dùng. Đây không phải là một ý tưởng tốt vì nhiều lý do, mặc dù hầu hết chúng có thể được giảm nhẹ theo một cách nào đó. Vấn đề cơ bản nhất là bạn đang gửi email mật khẩu có thể sử dụng cho người dùng bằng văn bản gốc. Các vấn đề khác với phương pháp này bao gồm:

  • Nhiều người dùng lười biếng, khá nhiều người sẽ thiết lập lại và chỉ cần cho trình duyệt nhớ mật khẩu ngẫu nhiên.
  • Rất nhiều trang web không buộc bạn phải thay đổi mật khẩu khi sử dụng mật khẩu lần đầu tiên.
  • Kẻ tấn công có quyền truy cập vào tài khoản email có quyền truy cập vào mật khẩu, bất kể bạn sử dụng cơ chế nào để xác thực người dùng ở nơi đầu tiên.

2.3. Liên kết đặt lại

Đây là một trong những cơ chế tốt hơn (và, rất may, phổ biến hơn). Nó liên quan đến việc xác thực người dùng, sau đó gửi email cho họ liên kết đặt lại một lần. Khi liên kết đặt lại được sử dụng, người dùng sẽ được nhắc đặt mật khẩu mới. Khi đã xong, liên kết không hợp lệ. Bảo mật hơn nữa có thể được cung cấp bằng cách bao gồm thời gian hết hạn trên các liên kết và thực thi rằng liên kết đó không hợp lệ sau khi mật khẩu được đặt hoặc sau khi hết phiên của người dùng.

Sự sụp đổ của phương pháp này là khi chúng ta nhớ giả định trước đó của chúng tôi. Tài khoản email của người dùng không an toàn. Nó không được tính là "một cái gì đó bạn biết". Trong khi cửa sổ thời gian của kẻ tấn công ngắn, chúng vẫn có thể xâm nhập. Tất nhiên, tất cả những điều này sẽ bị vô hiệu hóa thêm nếu (hoặc, đúng hơn là khi) người dùng quên mật khẩu email của họ.

2.4. Không bao giờ rời khỏi trang web

Đây thực sự là chén thánh, nhưng chỉ có thể được sử dụng cùng với xác thực đa yếu tố mạnh mẽ. Khi người dùng tự xác thực bằng cách sử dụng kết hợp các câu hỏi bảo mật, kiểm tra ngoài băng tần (ví dụ: điện thoại di động), tệp chính, sinh trắc học, xác minh con người, v.v., họ ngay lập tức được chuyển hướng đến một hình thức thay đổi mật khẩu. Điều này hoàn toàn bỏ qua nhu cầu sử dụng địa chỉ email.

Nếu bạn thực sự tin rằng việc sử dụng địa chỉ email để gửi liên kết đến là cần thiết, hãy xem xét việc cung cấp tùy chọn đặt lại không có email làm tăng số lượng kiểm tra mà bạn yêu cầu phải vượt qua.


3. Kết luận

Thật khó để cân bằng giữa bảo mật, tính khả dụng và độ tin cậy vào thời điểm tốt nhất, nhưng tình huống này là trực tiếp xử lý một người dùng có đã chứng tỏ mình không đáng tin cậy. Tôi không nói điều này theo bất kỳ ý nghĩa phản đối nào, mà đúng hơn là tất cả chúng ta đều có thể sai lầm.

Điều quan trọng là giữ cho hệ thống đặt lại mật khẩu có thể sử dụng được và đơn giản, không bỏ qua bảo mật. Trước khi thực hiện quy trình xác thực 3 yếu tố lớn trên mọi khía cạnh của ứng dụng web của bạn, hãy suy nghĩ về những gì bạn đang bảo vệ. Nếu bạn chỉ là một công ty nhỏ bán đồ trực tuyến, có lẽ bạn có thể thoát khỏi với 2 yếu tố cơ bản về phục hồi. Nếu bạn là nhà bán lẻ, ngân hàng hoặc trang mạng xã hội lớn, bạn nên sử dụng 2 yếu tố mạnh để phục hồi (nhiều loại mỗi loại) và 2 yếu tố trên thông tin đăng nhập từ các nguồn không được nhận dạng.

Trong một câu: giữ cho nó đơn giản, suy nghĩ về khán giả của bạn.

27
Polynomial

Vấn đề với "hack hoành tráng" là nhiều tài khoản (Twitter, gmail) đã được liên kết với một tài khoản (icloud) sau đó bị xâm phạm, cho phép tin tặc yêu cầu và chặn liên kết đặt lại mật khẩu cho các tài khoản được liên kết.

Nếu bạn muốn bảo vệ chống lại kịch bản như vậy (trong đó tài khoản email được sử dụng làm tài liệu tham khảo cho các tài khoản khác bị xâm phạm), không có cách nào khác ngoài việc sử dụng xác thực 2factor, như được cung cấp bởi Google . Nếu mật khẩu tạm thời có được thông qua kỹ thuật xã hội sẽ được gửi đến điện thoại di động của chủ sở hữu tài khoản icloud, thì điều này sẽ không xảy ra.

7
twobeers

Theo tôi, không có gì hơn một dịch vụ web có thể làm để bảo vệ chức năng đặt lại mật khẩu vì một lý do đơn giản, người dùng.

Hãy xem xét những gì tôi thấy là hình thức đặt lại mật khẩu phổ biến nhất: câu hỏi bí mật. Có 2 kịch bản thường diễn ra.

1) Trả lời trung thực câu hỏi - nhiều người dùng chọn tuyến đường này. Thật không may, câu trả lời cho hầu hết các câu hỏi bí mật là cực kỳ dễ dàng để đào lên từ internet. Thông tin như trường học đầu tiên của bạn hoặc tên thời con gái của mẹ bạn hầu như không phải là một bí mật. Kẻ tấn công có thể dễ dàng Khai thác thông tin như vậy bằng cách thực hiện các tìm kiếm trực tuyến đơn giản. Điều này làm cho câu hỏi bí mật tốt như vô dụng.

2) Trả lời câu hỏi với rác, sau đó quên câu trả lời - hầu hết những người tôi biết làm điều này, bao gồm cả tôi. Điều này làm cho câu hỏi bí mật trở nên vô dụng vì nó không thể được sử dụng để xác nhận tính hợp pháp của yêu cầu đặt lại mật khẩu.

Cách tốt nhất để xử lý câu hỏi bí mật là trả lời bằng rác, nhưng hãy viết nó xuống một nơi nào đó để bạn không quên. Tuy nhiên, hầu hết người dùng sẽ không làm điều này, chủ yếu là do thực tế là họ không quan tâm đến bảo mật cho đến khi có điều gì đó xảy ra.

Một số cách phổ biến khác để kích hoạt thiết lập lại mật khẩu là gì?

Email - nhiều dịch vụ liên kết tài khoản của bạn với email "khôi phục". Tuy nhiên, điều gì xảy ra nếu bạn quên mật khẩu vào email khôi phục? Đó là một chuỗi không bao giờ kết thúc.

Nhiều phương pháp an toàn hơn như xác thực hai yếu tố là một rắc rối cho người dùng. Các dịch vụ web phải xem xét khả năng sử dụng so với bảo mật. Rốt cuộc, việc có một dịch vụ web không thể thiếu là gì nếu không có ai sử dụng nó?

Lỗ hổng chính trong bài viết đó là tác giả có nhiều tài khoản được liên kết với một email, cho phép kẻ tấn công thỏa hiệp tất cả các tài khoản trực tuyến của mình một cách dễ dàng. Cố gắng, càng nhiều càng tốt, để phân cấp danh tính trực tuyến của bạn. Tuy nhiên, điều này trở thành trách nhiệm của người dùng.

Nhiều như chúng tôi muốn nghĩ rằng bảo mật nên là mối quan tâm chính của các dịch vụ web, chúng tôi phải xem xét quan điểm về tính khả dụng. Bảo mật tổng thể sẽ không cải thiện cho đến khi người dùng cuối nhận ra tầm quan trọng của nó và thực hiện các bước để tự bảo vệ mình. Rốt cuộc, chỉ có rất nhiều nhà cung cấp dịch vụ có thể làm.

6
user10211

Trong thực tế, họ đã sử dụng email của mình để hack mọi thứ. Vì vậy, giữ an toàn cho email của bạn, tốt nhất, với phát hiện xâm nhập thông minh và được bảo vệ khỏi khôi phục mật khẩu, sẽ ngăn chặn các vụ hack như vậy trong trường hợp này.

Dữ liệu của bạn trong đám mây cũng vậy. Mã hóa thông minh và bảo vệ hệ thống, như quản lý khóa rất quan trọng đối với bạn để giữ an toàn cộng với các bản sao lưu và ảnh chụp nhanh từ xa, vì vậy đơn giản là không thể tạo chuỗi.

Hai tài liệu và giao tiếp quan trọng này phải được bảo mật, do đó nó không phù hợp với đám mây cho mục đích sử dụng chuyên nghiệp, bởi vì ai đó sẽ xóa nó và đó là nó. Vì vậy, tốt nhất là sử dụng một tên miền doanh nghiệp/cá nhân, mà bạn có thể phục hồi hợp pháp.

Để nó được bảo vệ một cách hợp pháp, về mặt vật lý, với tự động hóa thông minh, bạn có thể sử dụng nó cho mục đích kinh doanh và nếu bạn bị hack, về cơ bản bạn cần phải biết việc khôi phục mật khẩu qua email, về cơ bản trong webmail, bạn nên lọc phục hồi mật khẩu sang hộp thư khác cần truy cập qua ssh, để được an toàn.

Còn táo thì sao? Điều này xảy ra khi bạn sử dụng phần cứng cho trẻ em với Apple điều khiển từ xa. Đây là giải pháp tốt cho iPod, nhưng nó không hoạt động trong thế giới PC thực. Mọi người đều khó chịu khi Microsoft thu thập dữ liệu, nhưng now Apple có tất cả các ứng dụng được kiểm soát và ở một mức độ nào đó, nhưng chủ yếu là để giải trí và giải trí tại nhà, không phải là một công việc chuyên nghiệp. Bước nhảy vọt về bảo mật của OSX là rất lớn và không có gì đáng ngạc nhiên OSX đã bị hack theo cách đa nền tảng.

Đối với một email an toàn, tốt nhất cũng là có tên miền trong công ty có uy tín, vì vậy nó cũng không thể bị hack.

2
Andrew Smith