Как Вы добавили бы соль к своим хешам текущего пароля?
Чтобы проверить ненулевую / ненулевую строковую переменную, т.е. если она установлена, используйте
if [ -n "$1" ]
Это противоположно -z. Я использую -n больше, чем -z.
Вы бы использовали это как:
if [ -n "$1" ]; then
echo "You supplied the first parameter!"
else
echo "First parameter not supplied."
fi
8 ответов
Конечно, можете. Просто добавьте соль к существующему хешу и снова его. Конечно, это потребует, чтобы любые будущие входы в систему проходили через один и тот же процесс, что означает необходимость вызова двух хэш-функций, но многие законные шаблоны все равно это делают, поэтому это не так. Пахнет так плохо, как вы думаете.
Придание пароля - это попытка защитить себя от радужных таблиц. В этом случае соль не обязательно должна быть секретом.
http://en.wikipedia.org/wiki/Rainbow_tables#Defense_against_rainbow_tables
Фактически вы можете увидеть в статье
hash = MD5 (MD5 (password) . salt)
Это тот же самый метод вы бы использовали. (За исключением другой функции хеширования.)
В качестве быстрого исправления вы можете создать столбец соли в базе данных, и когда пользователь входит в систему, правильно совпадая со старым хешем, вы можете затем использовать этот пароль, который он ввел с солью и создать новый хеш.
Вы можете добавить столбец, состоящий из флага, показывающего, есть ли у пользователя старый (без соли) или новый (с солью) hash.
На этом этапе неплохо было бы заставить всех пользователей изменить свои пароли при входе в систему. Таким образом, вы можете в конечном итоге избавиться от этого столбца.
Здесь есть несколько способов , которые могут вам помочь.
Помните, что любой постоянный шаблон, который вы добавляете в существующий хэш, бесполезен (одна из уловок по этой ссылке предлагает нечто подобное). Не должно быть идентифицируемого шаблона, который можно было бы использовать для выделения соли.
Конечно, лучшим способом было бы перейти на соленую хеш-таблицу.
Создайте новое поле в вашей базе данных с именем «соленый» с типом истина / ложь (или любым другим эквивалентом в вашей СУБД). Установите все значения в false для существующих хэшей. Каждый раз, когда добавляется новый, соленый, хэш, устанавливайте для поля "salted" значение true.
Затем все, что вам нужно сделать, это по-разному обрабатывать два типа хешей в вашем коде.
Это больше общего решение, чем конкретное, но оно должно решить вашу проблему.
Если вы сохраняете соль внутри хэша, вам должно быть довольно просто определить, включена ли соль, проверив длину хеша. Если нет соли, просто хешируйте пароль, если есть соль, хешируйте пароль + соль.
Вам не нужен логический столбец в вашей базе данных.
Лучший способ хранения соли - это встраивание значения соли в только что созданный хэш пароля + соль. Я не добавляю соль в начало или конец хеша, я буквально вставляю соль в хеш.
Я имел дело с похожей проблемой, связанной с множественными техниками хэширования. Я также использовал подход кодирования типа хэш-метода в БД (т.е. 'альфа', 'бета', 'гамма', 'дельта'). Я пометил все текущие хэши соответствующим уровнем. Как пользователи, вошедшие в систему, я проверил их пароли и заново хэшировал их, используя обновленные методы. Срок действия наших паролей истекает через 90 дней, так что это был всего лишь вопрос удержания в течение 3 месяцев, пока все пароли, использующие старые методы, не будут сброшены.