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

Question

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

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

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

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

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

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

Answer 1

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

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

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

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

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

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

Answer 2

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

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

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

Answer 3

У меня было 4 идеи. Пока я печатал, 3 из них уже были предложены (поэтому я проголосовал за них)

Вариант идеи 3 - олицетворение:

Чтобы сделать это "идентичным, насколько это возможно", обычному входу в систему с минимальными изменениями кода, вы можете добавить возможность олицетворения непосредственно при входе в систему путем предоставления учетных данных администратора плюс альтернативное имя пользователя, например Войдите в систему как администратор: пользователь, пароль администратора. Система будет воспринимать это как вход в систему как пользователь с паролем пользователя.

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

Answer 4

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

Answer 5

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

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

Answer 6

Решение, которое мы использовали в наших веб-приложениях, заключается в том, чтобы 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

Answer 7

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

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

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