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

Это сообщение отредактировал(а) baldina - 19.3.2013, 21:40

Неважный выбор. Сей алгоритм есть во многих программах-подборщиков. Лучше придумать что-то свое, нестандартное. Можно ориентироваться, например, на генератор хэшей на сайте insidepro.
В hashcat, например, есть (или была) опция подбора пароля к соленому хэшу по известному алгоритму, даже если нет самой соли. Если соль короткая, ее отсутствие в БД лишь отсрочит взлом.
PS. Юзайте нестандартные алгоритмы хэширования или криптования, какой-нить Blowfish или AES с достаточной длиной ключа.
PPS. Соль лучше всего хранить в солонке 

Это я уже понял. Теперь будет комбинация sha1+md5+еще кое что.



А перец? 

У меня в базе соль хранится рядом с самим хешем, генерация примерно такая  md5(md5(_filter($password)) . $salt);
По сути можно сделать примерно такую приблуду:

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

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

Мммм.... а 6 перл попробовать, скомпилить?