Как вы поддерживаете веб-приложение с хешированными или зашифрованными паролями?

Question

При поддержке нового веб-приложения в корпоративной среде часто бывает необходимо войти в систему как конкретный пользователь, чтобы диагностировать реальную или предполагаемую проблему, с которой они сталкиваются. Два противоположных проблемы относятся здесь:

1. Лучшая практика заключается в использовании хэш-либо зашифрованные пароли, а не открытым текстом. Иногда в центре есть сторонний SSO (единый вход). Невозможно получить пароль пользователя. Если пользователь не предоставит его (не рекомендуется), невозможно войти в систему как этот пользователь.

2. У многих веб-приложений есть персонализация и комплексная авторизация. У разных пользователей разные роли (администратор, менеджер, пользователь) с разными разрешениями. Иногда пользователи могут видеть только свои данные - своих клиентов или задачи. Некоторые пользователи имеют доступ только для чтения, а другие могут редактировать. Таким образом, каждый пользовательский взгляд на веб-приложение уникален.

Предположим, что в корпоративной среде невозможно попасть на рабочий стол пользователя или напрямую подключиться к их машине.

Как вы справляетесь с этой ситуацией?

Редакция: Я хочу повторить, что в крупном финансовом учреждении или типичной компании Fortune 500 с сотнями тысяч сотрудников во всей стране и во всем мире невозможно, чтобы один разработчик в какой-то ИТ-подразделении иметь возможность прямого доступа к машине пользователя. Некоторые из них - это общедоступные веб-приложения, используемые клиентами (например, онлайн-банкинг и торговля акциями). И многие из них являются приложениями интрасети, использующими Active Directory или SSO, что означает, что учетные данные пользователей одинаковы для многих приложений. Я благодарю всех вас за ваши предложения; некоторые из них могут быть очень полезными в других средах.

Answer 1

Некоторые из этих идей создают неудобства для пользователя, либо заставляя их менять свой пароль, либо занимая рабочий стол для вашей отладки сессия.

Идея Markc является лучшей: добавьте логику аутентификации, чтобы позволить суперпользователям регистрироваться как конкретный пользователь, предоставляя не учетные данные пользователя, а имя пользователя и их учетные данные суперпользователя.

Я сделал это, как это в прошлом (псевдо-иш питона):

if is_user_authenticated(username, userpassword): 
    login the user 
else if ':' in userpassword: 
    supername, superpassword = userpassword.split(':') 
    if is_superuser_authenticated(supername, superpassword): 
     login the user 

Другими словами, если имя пользователя и пароль не аутентификации, если пароль содержит двоеточие, то, это фактическое имя пользователя и пароль администратора, соединенные двоеточием, поэтому войдите в систему как имя пользователя, если они являются правильным именем администратора и паролем.

Это значит, что вы можете войти в систему как пользователь, не зная своих секретов и не причинить им неудобств.

Answer 2

Администратор должен иметь возможность изменять пароль пользователя. Измените пароль для пользователя на то, что вам известно. Затем вы можете войти в систему как этот пользователь.

Сообщите пользователю о необходимости сбросить пароль после завершения отладки.

Answer 3

Обычно с помощью программного обеспечения дистанционного управления, которое можно использовать для просмотра рабочего стола. Если они находятся на сервере терминалов Windows, для этого можно использовать встроенные средства администрирования. В противном случае я бы использовал что-то вроде VNC во внутренней сети или внешнюю службу, такую ​​как LogMeIn (http://www.logmein.com/).

Answer 4

1. Может у вас есть среда тестирования, где есть регулярный покрой живых данных, скопированных (очевидно, продезинфицировать, чтобы удовлетворить любые вопросы безопасности или защиты данных). Пользователь, похожий по настройке на тот, у кого есть проблемы, может быть использован для устранения неполадок или даже самого пользователя, если это разрешено.

2. Используйте клиент удаленного рабочего стола, как указано в других ответах, но опять же это может оказаться для вас нецелесообразным. Если у вас есть эти права в домене, я слышал об обработке ошибок, даже делая скриншот и в том числе в журналах! но это звучит немного странно для меня.

3. У вас есть инструмент администратора для клонирования пользователя в демо-счете?

Answer 5

Для наших веб-приложений мы используем процесс, который из-за отсутствия лучшего термина определяется как «захват» учетной записи пользователя.

В принципе, администраторы могут «захватывать» учетную запись пользователя простым нажатием кнопки. В коде вы просто используете уникальный идентификатор (идентификатор пользователя работает в менее защищенной среде), который затем устанавливает необходимые учетные данные в сеансе, чтобы затем они могли работать в этом профиле пользователя. Для более безопасной среды вы можете использовать уникальный хеш для каждого пользователя.

Для обеспечения безопасности этого метода захвата он всегда сначала проверяет, выполняется ли запрос администратором, прошедшим проверку подлинности, с соответствующими правами. Из-за этого становится необходимым, чтобы либо сеанс администратора был захвачен, либо их учетные данные для аутентификации были захвачены, чтобы кто-либо использовал функцию захвата в приложении.

Answer 6

У меня было 4 идеи. В то время как я печатал 3 из них уже предложили (так я upvoted их)

Variant по идее 3 - олицетворения:

Чтобы сделать это как «идентично, насколько это возможно» до нормального входа в систему с минимальными изменениями кода, вы может добавить способность выдавать себя непосредственно при входе в систему, предоставив учетные данные администратора плюс альтернативное имя пользователя, например логин как Admin: пользователь, adminpassword. Система будет обрабатывать это точно так же, как войти в систему как пользователь с userpassword.

Идея 4: Вы можете получить доступ к хранилищу паролей? Если это так, временно замените хэш пользователя хэшем известного пароля. (пароли часто хранятся в Интернете в базе данных. Инструмент SQL Query может выполнять свопы)

Answer 7

Решение, которое мы использовали в наших веб-приложениях, состоит в том, чтобы authN/authZ возвращал желаемого пользователя в качестве эффективного пользователя. Мы делаем это, имея функцию администратора для установки маскарада, а затем, когда мы задаем для текущего пользователя (current_user), мы обрабатываем маскарад:

def current_user_with_effective_user 
    if masked? 
     current_user_without_effective_user.masquerade_as 
    else 
     current_user_without_effective_user 
    end 
    end 
    alias_method_chain, :current_user, :effective_user