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

https://stackoverflow.com/questions/263367

06-07-2019
|

Вопрос

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

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

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

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

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

Решение

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

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

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

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 и пароль администратора, объединенные двоеточием, поэтому войдите в систему как имя пользователя, если они являются правильным именем пользователя admin и пароль.

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

Другие советы

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

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

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

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

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

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

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

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

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

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

<Ол>

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

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

Может быть, у вас есть инструмент администратора для клонирования пользователя в демо-счет?

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

Лицензировано под: CC-BY-SA с атрибуция

Не связан с StackOverflow