Пользовательское шифрование пароля не выполняется при обновлении, отличном от pw, в бэкэнде

У меня следующая ситуация:

Существующие пользователи полностью хранятся и поддерживаются в стороннем программном обеспечении, которое использует шифрование паролей, отличное от того, которое предоставляется с помощью saltedpasswords. Новый веб-сайт, который будет создан с помощью TYPO3, в будущем должен использоваться для управления пользователями. Поскольку данные также должны храниться в стороннем программном обеспечении, мы не можем просто обновить их при входе в систему. Они необходимы из-за API для запросов сертификатов. Итак, в TYPO3 пока перемещены лишь некоторые данные.

Так или иначе, пока ничего особенного. Я добавил новый метод соли, который в основном работает в следующих сценариях:

  • Создайте нового пользователя через BE
  • Создайте нового пользователя через FE (EXT:femanager)
  • Обновите PW существующего пользователя через BE
  • Обновление существующих пользовательских данных через FE (EXT:femanager)

В следующем сценарии это не работает:

  • При обновлении любых данных кроме пароля через ВЕ => пароль обновляется и начинается с "М".

Нужна ли для этого определенная конфигурация или крючок?

Я ценю любой намек. заранее спасибо

С наилучшими пожеланиями,

AMartinNo1


encryption backend typo3 password-encryption typo3-7.6.x
person AMartinNo1    schedule 27.06.2017    source источник

Ответы (1)


arrow_upward
-1
arrow_downward

временное решение:

Программное обеспечение сторонних производителей, содержащее пользователей, размещается самостоятельно и защищено брандмауэрами. Итак, в качестве первого шага мы будем использовать тот же механизм — md5-хэши.

EXT:saltedpasswords проверяет в TYPO3\CMS\Saltedpasswords\Evaluation\Evaluator::evaluateFieldValue($value, $is_in, &$set, является ли $value простым хэшем, и снова хэширует с соответствующим SaltFactory плюс префикс M.

Пока мы не переключимся на улучшенный механизм шифрования паролей (требует корректировок и в стороннем программном обеспечении), я просто комментирую «двойное хеширование» в методе sysext-core. Так что мы продолжаем разработку других функций.

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

person AMartinNo1    schedule 27.06.2017
comment
Это небезопасно, вы подвергаете своих пользователей риску из-за проблем с разработкой! Простого использования хэш-функции недостаточно, и простое добавление соли мало что дает для повышения безопасности. Вместо этого повторите HMAC со случайной солью в течение примерно 100 мс и сохраните соль с хэшем. Используйте такие функции, как PBKDF2, Rfc2898DeriveBytes, password_hash, Bcrypt или аналогичные функции. Смысл в том, чтобы заставить злоумышленника потратить много времени на поиск паролей методом перебора. - person zaph; 27.06.2017
comment
Как я уже сказал, это только во время разработки. Перед выходом в эфир будет изменено. - person AMartinNo1; 27.06.2017
comment
Таким образом, вы тратите время на временное решение безопасности, которое будет заменено позже, кажется пустой тратой усилий. Интересно, почему безопасность стоит на последнем месте, и у нас так много сбоев в системе безопасности. корреляция? Казалось бы, обеспечение безопасности на раннем этапе не влияет на проект, если только ... Итак, проблема в выгоде, выпуск продукта и получение денег - это выгода для компании, безопасность - это выгода для пользователей. Дилемма: на чем сосредоточиться — о, подождите, у нас есть ответ на этот вопрос. - person zaph; 27.06.2017
comment
Во-первых, было проще разработать собственную соль, которая сама делалась за несколько минут. Да, в конце концов это заняло больше времени, но это потому, что TYPO3 выполняет эту md5-проверку, о которой мы раньше не знали. И я никогда не говорил, что это будет выпущено. Мы переносим пользовательские данные, мы можем проверить на реальных данных, работает ли пользовательский интерфейс и т. д., а тем временем мы работаем над шифрованием паролей. - person AMartinNo1; 27.06.2017
comment
В целом пароль и шифрование не следует использовать вместе, обратите внимание, что хеширование не является шифрованием. PHP имеет безопасное и простое в использовании хэширование паролей: password_hash и password_verify, и можно утверждать, что их использование проще, чем хэш-решение. Если вы хотите создать лучшее место для следующих поколений, поставьте безопасность на первое место. - person zaph; 27.06.2017
comment
Это так, потому что в противном случае нам придется модифицировать стороннее программное обеспечение с точки зрения регистрации, обновления пользовательских данных и многого другого. Так что да, за тем, что мы хотели бы сделать, стоит усилие, пока мы уже можем протестировать новую систему с реальными данными. Итак, почему бы не импортировать данные и не позволить тестировщикам тестировать на реальных данных, а тем временем обновлять средства безопасности. - person AMartinNo1; 27.06.2017
comment
Всегда есть причина отложить охрану, ведь это PITA. - person zaph; 27.06.2017
comment
Давайте продолжим это обсуждение в чате. - person AMartinNo1; 27.06.2017
comment
Дальше нечего: я ставлю безопасность на первое место, ты нет. - person zaph; 27.06.2017