Nếu khách hàng cần khả năng lấy lại mật khẩu thì sao?

Hiện tại tôi đã thừa hưởng một ứng dụng tại nơi làm việc và đến lúc mất tinh thần, tôi đã nhận ra rằng mật khẩu người dùng được lưu trữ trong cơ sở dữ liệu được mã hóa bằng chức năng mã hóa nội bộ, bao gồm khả năng giải mã.

Vì vậy, tất cả những ai thực sự cần làm là sao chép bảng người dùng và sao chép cụm mã hóa (bất kỳ ai có quyền truy cập sản xuất cơ sở dữ liệu) và sau đó họ sẽ có quyền truy cập tới 100.000 địa chỉ email và mật khẩu tiềm năng cho họ.

Tôi đang cố gắng giải thích cho doanh nghiệp lý do tại sao đây không phải là một ý tưởng hay, nhưng các khái niệm bảo mật dường như đi qua đầu họ vì họ không có đầu óc kỹ thuật (nó dành cho chính phủ). Thêm vào đó, thực sự có chức năng hiện có trong ứng dụng để người dùng quản trị truy xuất mật khẩu của người dùng để đăng nhập như họ và làm công cụ (mà họ đã nói, họ yêu cầu).

Vì vậy, họ không hiểu ý nghĩa bảo mật. Và để thực hiện chính sách bảo mật mạnh mẽ hơn (băm mật khẩu để chúng không thể truy xuất được), tôi phải xóa chức năng hiện có cho chúng.

Tôi nên làm gì? Tôi đã không xây dựng hệ thống mật khẩu ngay từ đầu, vì vậy tôi không thể đổ lỗi nếu có gì sai. Mặt khác, tôi không cảm thấy tốt về điều đó và tôi cũng không muốn có quyền truy cập vào 100.000 đăng nhập email tiềm năng.

Thực hiện các chức năng họ cần một cách an toàn. Quản trị viên đăng nhập với tư cách người dùng khác có thể được thực hiện mà không cần họ biết mật khẩu của người dùng. Họ có thể đăng nhập như chính họ và sau đó có sẵn một số chức năng 'nhận dạng thay đổi'.

Bảo mật cơ sở dữ liệu mật khẩu không phải là mối quan tâm kinh doanh, nó là một mối quan tâm kỹ thuật. Không làm như vậy là một lỗi. Nếu doanh nghiệp nghĩ rằng bảo mật là một sự đánh đổi chức năng, bảo mật sẽ mất. Bạn không nên cho họ bất kỳ lý do nào để nghĩ về nó theo cách này.

Bạn cần thuyết phục họ rằng họ thực sự không cần phải chịu trách nhiệm dân sự trong trường hợp máy chủ của họ bị đột nhập. Họ cũng không cần phản ứng dữ dội từ một cơ sở người dùng có thông tin nhận ra rằng họ đang sơ suất.

Đôi khi có những trường hợp rõ ràng trong đó một bên sai và bên kia đúng. Đây là một trong những thời điểm.

Hãy nhìn vào những gì vừa xảy ra với Sony. Ngoài ra, trang web của chúng tôi đã bị hack gần đây và một trong những điều khiến nó không phải là một thảm họa chưa được giải quyết là chúng tôi đã sử dụng chức năng băm một chiều (tương đối) tốt (SHA512). Kể từ đó, chúng tôi đã chuyển sang bcrypt để ngăn chặn các cuộc tấn công từ điển / từ điển vũ phu (hoặc ít nhất là làm cho chúng không thể truy cập được). Tôi chỉ đơn giản là không tìm thấy bất cứ điều gì khác.

Sự thật: mọi người sử dụng cùng một mật khẩu trên nhiều trang web

Sếp của bạn có thể không nhận ra rằng mọi người thường sử dụng một mật khẩu duy nhất (hoặc một bộ rất hạn chế) cho tất cả các loại dịch vụ (bao gồm ngân hàng hoặc Facebook và tương tự). Nếu người dùng có thể thay đổi mật khẩu trong hệ thống của bạn thì rất có thể họ sẽ sử dụng cùng một mật khẩu như những nơi khác.

Nếu sếp của bạn nghĩ rằng việc truy cập mật khẩu này không phải là vấn đề, bạn cũng nên nói với họ sự thật này và có thể họ sẽ bắt đầu suy nghĩ khác đi. Ngay cả khi ứng dụng của bạn đứng sau tường và không thể truy cập công khai, nó có thể gây ra mối đe dọa bảo mật trên các dịch vụ trực tuyến khác. Tên người dùng (đặc biệt là khi chúng là email) khá dễ đoán. Tôi không thể tưởng tượng được sẽ buồn cười thế nào khi đăng nhập vào tài khoản Facebook của ông chủ và đặt một cái gì đó lên tường của họ.

Mật khẩu người dùng phải luôn được coi là thông tin riêng tư / bí mật hàng đầu mà chỉ một số người giới hạn có quyền truy cập. Tốt nhất là tránh lưu trữ thông tin dễ bay hơi như vậy. Và ngay cả khi bạn làm, bạn nên được cấp mỗi quyền truy cập vào thông tin này. Giống như nhận được một tờ giấy bí mật từ một két an toàn cao chỉ có thể được mở bằng nhiều phím. Vì vậy, mọi người biết ai đã được cấp quyền truy cập và khi nào.

Cách triển khai ủy quyền tài khoản

Phân quyền tài khoản trong ứng dụng của bạn nên được thực hiện khác nhau.

1. Quản trị viên nên đăng nhập như chính họ và sau đó
2. hoặc (vì họ là người dùng đặc quyền)
   • chỉ nhập UserName hay
   • chọn một người dùng nhất định từ danh sách để đăng nhập

Điều này chắc chắn không nên được thực hiện bằng cách đăng nhập bằng tổ hợp Tên người dùng + Mật khẩu .

Đúng là màn hình mới nên được phát triển để cho phép đăng nhập được ủy quyền, nhưng vẫn vậy.

Tại sao ủy nhiệm đăng nhập tốt hơn?

Bạn cũng có thể cung cấp chức năng bổ sung để làm rõ rằng một số hành động đã được Quản trị viên thực hiện thay mặt cho một số người dùng (mà bây giờ bạn không thể biết vì Quản trị viên đóng vai trò là Thần và đăng nhập như bất kỳ ai và có thể làm những việc có thể gây tổn thương danh tiếng nhân viên thực sự).

Bạn phải đồng ý rằng mọi người phạm sai lầm. Quản trị viên cũng là người. Và nếu họ phạm lỗi thay cho người khác, họ sẽ cố đổ lỗi cho họ. Tôi chắc chắn 100% về nó. Điều này sẽ giúp an toàn hơn cho những người dùng không phải là quản trị viên, vì vậy danh tiếng trong thế giới thực của họ sẽ không phải chịu những sai lầm của người khác.

Bạn không đề cập đến những gì ứng dụng làm. Nếu đó là các ứng dụng hộ chiếu, có đầy đủ thông tin trộm cắp danh tính phải được bảo vệ, nó xứng đáng được bảo vệ tối đa. Nhưng nếu đó là "cho tôi biết các vụ tai nạn giao thông trên đường về nhà" thì hậu quả của việc vi phạm mật khẩu là gì? Một số hệ thống tôi đã viết thậm chí không có mật khẩu - bạn chỉ cần nhập email hoặc số sinh viên của bạn hoặc một số định danh khác mà mọi người thường biết về nhau và chủ sở hữu của hệ thống đánh giá cao sự dễ sử dụng và không thể bị khóa vượt quá khả năng vi phạm quyền riêng tư nếu mọi người mạo danh nhau. Tôi cũng không có vấn đề gì với điều đó. Ví dụ tại sao tôi cần mật khẩu để thiết lập lịch trình các phiên ưa thích tại một hội nghị?

Vì vậy, nếu tôi được đưa vào để xem xét mã và bạn đã đưa nó cho tôi, đó là nơi chúng tôi sẽ bắt đầu. Bạn đang bảo vệ cái gì? Hậu quả tiêu cực của một người quản lý để đăng nhập như một người khác là gì? Hậu quả tiêu cực của dữ liệu lưu trữ của mọi người bị phơi bày là gì? Có lẽ họ khủng khiếp. Bạn sẽ liệt kê chúng cho tôi. Sau đó, hậu quả của việc mọi người không thể nhấp vào "gửi email cho tôi mật khẩu của tôi" mà thay vào đó phải nhấp vào "đặt lại mật khẩu của tôi" là gì? Họ sẽ ngừng sử dụng trang web? Và những gì về các nhân viên đăng nhập như người? Đó có phải là tiết kiệm thời gian, tiền bạc, mất doanh thu hay không?

Phần cuối cùng của câu chuyện chi phí / lợi ích, và câu chuyện bạn chỉ nhận được nếu có sự khác biệt thực sự lớn giữa những tiêu cực bạn gặp phải bây giờ và những tiêu cực bạn sẽ nhận được khi xóa chức năng, là chi phí để khắc phục nó. Tôi có thể chi một triệu để dành cho tôi cơ hội tiếp xúc hàng ngàn đô la không? Không. Còn cách khác thì sao? Tôi phụ thuộc vào tỷ lệ cược, tôi đoán, nhưng câu trả lời đầu tiên của tôi sẽ là có.

ps - chính phủ Canada đã ra mắt với một trang web áp dụng cho hộ chiếu của bạn có ID trong URL: nếu bạn chỉnh sửa URL bằng một ID khác, bạn đã thấy hình thức hoàn thành một nửa của một công dân ngẫu nhiên khác. Và tôi có những khách hàng đăng nhập với tư cách là khách hàng của họ vì mục đích phục vụ khách hàng vì hạnh phúc chung, vì vậy tôi thấy mặt tốt của nó, mặc dù tôi sẽ không ủng hộ nếu dữ liệu đằng sau mật khẩu thực sự quan trọng đối với người lạ.

Nó có thể trái pháp luật và có thể mở ra để bị kiện. Nếu họ lưu giữ bất kỳ loại thông tin cá nhân nào về người dùng hoặc hệ thống tương tác với các hệ thống khác với tư cách là người dùng bạn có thể cần kiểm tra xem hệ thống có thuộc bất kỳ Đạo luật hoặc Luật riêng tư nào của Tiểu bang hoặc Liên bang hay không. I E. Sarbanes / Oxley, OOPA California, v.v.

Ngoài các vấn đề pháp lý tiềm ẩn, bạn cũng có thể chỉ ra rằng bất kỳ quản trị viên nào cũng có thể đổ toàn bộ bảng vào một thanh dữ liệu di động và để lại khả năng đăng nhập như bất kỳ người dùng nào và gây ra sự tàn phá hoặc bán dữ liệu.

Ngay cả khi bạn cho rằng tất cả các quản trị viên đều đáng tin cậy, nó cũng làm cho sự thỏa hiệp của mật khẩu quản trị viên bị tàn phá.

Bạn cũng không cần mật khẩu người dùng để thực hiện các thao tác như họ. Bạn có thể thực hiện một sudotính năng giống như.

Đây có thể không phải là một hệ thống của chính phủ liên bang vì các yêu cầu của Trin và FISMA sẽ cấm mã hóa đảo ngược đối với mật khẩu và bộ phận phụ huynh sẽ tát chúng lên mặt trăng.

Và để thực hiện chính sách bảo mật mạnh mẽ hơn (băm mật khẩu để chúng không thể truy xuất được), tôi phải xóa chức năng hiện có cho chúng.

Đối với công ty trước đây của tôi, tôi tiếp tục đấu tranh cho khả năng gửi email đặt lại mật khẩu để khắc phục vấn đề này. Và tôi tiếp tục bị ghi đè. Cuối cùng, tôi cảm thấy mệt mỏi với việc xúc phân chống lại thủy triều, vì vậy tôi đã rời đi. Đây cũng là một ông chủ tóc nhọn, người nghĩ rằng những câu hỏi ngu ngốc mà một số trang web ngân hàng yêu cầu được tính là "xác thực 2 yếu tố". Tranh cãi với anh ta giống như một phim hoạt hình Dilbert (anh ta có hình dạng giống PHB).

Thêm vào đó, thực sự có chức năng hiện có trong ứng dụng để người dùng quản trị truy xuất mật khẩu của người dùng để đăng nhập như họ và làm công cụ (mà họ đã nói, họ yêu cầu).

Tôi đã thấy điều này được thực hiện tại một tổ chức tài chính. Những người trong khu vực hỗ trợ khách hàng sẽ đăng nhập bằng thông tin đăng nhập của riêng họ và nếu họ có quyền làm như vậy, có thể giả vờ đăng nhập với tư cách là khách hàng. Điều này đã không đăng nhập họ với tư cách là khách hàng, chỉ là mạo danh khách hàng . Theo cách đó, nếu đại diện dịch vụ khách hàng quyết định rút tiền, nó sẽ không hiển thị khi khách hàng thực hiện việc đó trong nhật ký: nó sẽ hiển thị đại diện dịch vụ khách hàng đang cố gắng thực hiện (cũng như gửi thông báo để họ bị đuổi việc ngay khi Rentacop có thể lên sàn của họ).

Hoàn thành kém, nó sẽ làm cho nhân viên hỗ trợ khách hàng có thể làm cho người dùng cuối tham gia vào một số hoạt động có thể dẫn đến các khoản nợ pháp lý hoặc pháp lý nghiêm trọng.

Trang web liên bang cuối cùng tôi làm việc đã thu được 1/4 tỷ đô la Mỹ mỗi năm từ người dùng cuối (trong đó có khoảng 400 người dùng), vì vậy việc đăng nhập phải rất chặt chẽ và chỉ người dùng cuối được ủy quyền mới được phép chạm vào các trang web nơi họ báo cáo những thứ họ đã trả thuế tiêu thụ đặc biệt trên.

Sony là một trong những công ty có vi phạm bảo mật mới nhất. Đó không chỉ là mạng PS3, đó cũng là mạng trò chơi MMORPG của họ, tổng cộng ở đâu đó vượt quá 25.000.000 tên, địa chỉ, số thẻ tín dụng, tên người dùng và mật khẩu. Bạn có thể tin rằng tôi không hạnh phúc chút nào (tôi muốn sự bế tắc của mình!).

Tôi tham khảo Quy tắc đạo đức công nghệ phần mềm về những lo ngại như thế này. Theo giải thích của tôi, ưu tiên hàng đầu của bạn là không làm suy yếu lợi ích công cộng (không có khả năng bị xâm phạm mật khẩu giống như ví dụ này ở đây , nơi một công ty sửa đổi máy tính xách tay Dell để công ty cho thuê có thể theo dõi người thuê mà họ không biết). Sau đó, trách nhiệm của bạn là thông báo cho khách hàng về những rủi ro tiềm ẩn và để họ cân nhắc. Tất nhiên đó là đường cơ sở tối thiểu. Bạn phải sử dụng phán đoán của riêng bạn cho dù bạn cảm thấy rằng điều này vẫn còn nhiều hơn bạn có thể đứng và cho phép.

Tất nhiên khi bạn đề cập đến một dự án của chính phủ, nếu thông tin cá nhân của công dân gặp rủi ro vì những thực tiễn này, thì điều đó sẽ làm suy yếu lợi ích công cộng.

Bạn có thể in ra danh sách email và mật khẩu được giải mã và đặt nó lên bàn của sếp, với một cảnh báo lớn trên trang bìa: "Bí mật"

Làm cho phông chữ nhỏ để không lãng phí giấy mặc dù.

Bạn cũng có thể chỉ cho họ cách bugzilla cho phép quản trị viên mạo danh mọi người mà không cần sử dụng mật khẩu của họ.

Trước hết, tôi đồng ý với các câu trả lời khác chỉ ra rằng việc tránh điều này sẽ an toàn hơn nhiều và chỉ lưu trữ băm mật khẩu, không phải mật khẩu hoặc bất cứ điều gì có thể chuyển đổi thành mật khẩu.

Tuy nhiên, có những lúc bạn cần ít nhiều cho phép phục hồi. Trong trường hợp mật khẩu, bạn thường muốn khôi phục bằng cách đơn giản cho phép quản trị viên thay đổi mật khẩu khi / nếu cần thay vì khôi phục mật khẩu hiện có.

Tuy nhiên, một khả năng khác là bạn cho phép người dùng lưu trữ dữ liệu trên máy chủ được mã hóa bằng mật khẩu của riêng họ. Trong trường hợp này, chỉ cần cho phép quản trị viên thay đổi mật khẩu là không đủ. Mật khẩu mới sẽ không hoạt động để giải mã dữ liệu và hầu hết người dùng sẽ thấy không thể chấp nhận được khi tất cả dữ liệu được mã hóa của họ không thể truy cập được khi / nếu họ quên / mất mật khẩu. Đối với tình huống này, có một giải pháp thay thế hợp lý an toàn và vẫn cho phép phục hồi khi thực sự cần thiết.

Thay vì sử dụng mật khẩu của người dùng để mã hóa dữ liệu, bạn tạo một khóa ngẫu nhiên để mã hóa chính dữ liệu đó. Sau đó, bạn lưu trữ khóa đó, ở một vài nơi: một lần được mã hóa bằng mật khẩu của người dùng và ở một nơi khác được mã hóa bằng mật khẩu quản trị viên. Sau đó, khi (không thực sự nếu) người dùng mất mật khẩu và không thể truy cập dữ liệu trực tiếp nữa, bạn có thể sử dụng mật khẩu quản trị viên để giải mã khóa thực và sử dụng để khôi phục dữ liệu và / hoặc mã hóa lại khóa với mật khẩu mới của người dùng.

Nếu bạn không muốn tin tưởng hoàn toàn vào một quản trị viên, bạn cũng có thể quản lý điều đó. Ví dụ: bạn có thể quyết định rằng 5 người sẽ có khóa quản trị viên và bạn muốn ít nhất ba người trong số họ đồng ý trước khi khóa có thể được phục hồi. Trong trường hợp này, khi bạn lưu trữ mật khẩu được mã hóa cho mục đích quản trị, bạn lưu trữ nó nhiều lần, mỗi lần cho mỗi bộ trong số ba quản trị viên (không chiếm nhiều dung lượng, vì bạn chỉ lưu trữ nhiều khóa , vì bạn chỉ lưu trữ nhiều khóa , tại ~ 256 bit mỗi lần, không phải nhiều bản sao của dữ liệu). Mỗi bản sao đó được mã hóa liên tiếp với (băm) từng mật khẩu cho ba quản trị viên đó.

Để giải mã nó, bạn cần xác định ba quản trị viên đang nhập mật khẩu của họ và chọn khóa được mã hóa phù hợp cho bộ ba đó, sau đó giải mã bằng cách sử dụng một trong ba mật khẩu để cuối cùng nhận được khóa gốc. Sau đó, bạn có thể sử dụng dữ liệu đó để tự phục hồi dữ liệu hoặc bạn chỉ có thể mã hóa lại bằng mật khẩu mới (hàm băm) của người dùng để họ vẫn có thể truy cập dữ liệu của họ.

Tuy nhiên, khi bạn làm điều này, bạn thực sự cần phải sử dụng một thuật toán mã hóa tiêu chuẩn và (theo sở thích mạnh mẽ), một triển khai tiêu chuẩn, nổi tiếng, được nghiên cứu kỹ lưỡng về nó.

Điều này làm tôi lo lắng, cho rằng đó là một dự án của chính phủ. Lấy mật khẩu của người dùng để thực hiện một hành động theo ID của họ làm cho mọi thứ trở nên vô nghĩa đối với bất kỳ loại kiểm toán bảo mật nào. Lý do duy nhất tôi có thể thấy cho việc này là để tạo ra một dấu vết kiểm toán giả mạo.

Thực sự không cần sử dụng mã hóa đảo ngược cho mật khẩu. Nếu có một lý do chính đáng để giả mạo ID người dùng, điều đó có thể được thực hiện bằng cách:

• Lưu trữ mật khẩu băm hiện tại
• Thay thế bằng một giá trị đã biết
• (Hoạt động kiểm toán giả mạo, ví dụ: Chuyển tiền vào tài khoản nước ngoài)
• Thay thế mật khẩu ban đầu băm

Tôi sẽ không thoải mái với bước cuối cùng - bất cứ ai bị mạo danh trên hệ thống nên biết điều đó đã xảy ra. Có lẽ bạn có thể thuyết phục doanh nghiệp bằng cách nói "Giống như ngân hàng của bạn cho phép tôi truy cập vào tài khoản của bạn mà bạn không biết, vì tôi đã nói rằng tôi thực sự cần phải"

Niềm tin của họ vào một hệ thống mật khẩu tốt hơn không phải là vấn đề. Tạo một giải pháp để cho phép quản trị viên / bộ phận hỗ trợ mạo danh tài khoản người dùng và cung cấp bản sửa lỗi cho mật khẩu của bạn. An ninh thường bị ảnh hưởng cho sự thuận tiện. Làm cho nó thuận tiện và an toàn.

Chỉnh sửa: Họ sẽ không bao giờ hiểu được vấn đề bảo mật mật khẩu, nhưng họ hiểu mất chức năng. Đưa ra đề xuất này và xem liệu bạn có thể có được sự chấp thuận để thực hiện các thay đổi cần thiết hay không. Họ thậm chí không biết sẽ mất một giờ hay một năm. Đó là một sự thay đổi tính năng và không phải là một bản dựng lại hoàn chỉnh.

Xem xét các sự kiện hiện tại (rò rỉ dữ liệu Epsilon và rò rỉ dữ liệu Mạng Playstation), người ta sẽ hy vọng các vấn đề sẽ rõ ràng rõ ràng.

Tuy nhiên, đôi khi, là một nhà phát triển, bạn chỉ đơn giản là không thể ảnh hưởng đến chính sách.

Tôi sẽ làm hết sức mình để thể hiện tiềm năng của vụ bê bối và chi phí, điều này sẽ dễ dàng, một lần nữa xem xét các sự kiện hiện tại. Nhưng nếu điều đó không thành công, bạn thực sự có thể làm gì. Không nhiều. Thoát khỏi sự phản kháng, chứng minh lỗ hổng để tăng sự chú ý. Không có âm thanh như lựa chọn tuyệt vời.

Tôi khuyên bạn nên chống lại điều này, nhưng nếu bạn hoàn toàn phải có khả năng giải mã mật khẩu, bạn nên sử dụng mã hóa khóa công khai. Bằng cách đó, bạn có thể mã hóa tất cả mật khẩu bằng khóa chung. Bạn có thể xác minh mật khẩu bằng cách mã hóa bằng khóa chung và so sánh, và bạn có thể giữ khóa riêng ở một nơi khác (không phải trên máy tính sản xuất).

Thông thường lý do để Quản trị viên thấy mật khẩu người dùng là trong trường hợp họ mất mật khẩu, họ có thể cung cấp cho người dùng. Theo như tôi có thể nói, Windows cũng không cho phép Quản trị viên nhìn thấy mật khẩu - vậy tại sao ứng dụng của bạn phải như vậy? Bất kỳ thư viện mã hóa nội bộ nào cũng chắc chắn bị phá vỡ bởi vì tôi chắc chắn bất cứ ai đã viết nó đều không hoạt động cho NSA.