Безопасность хранения паролей в БД

Почему?
Для этого вобще javascript не нужен... Да и вобще, это конечно мое мнение, но где речь идет о безопасности и хранении данных говорить о javascript-е вобще не уместно.

Банальный пример, в базе данных, в таблице с пользователями у нас всего 2 колонки: id и скажем data. Ну id понятно, а data - это все данные о пользователе, сохраненные в каком-то виде, скажем сереализованы, и зашифрованы. А вот ключ для шифровки/расшифровки генерируется исходя из пароля пользователя, можно пароля и логина, e-mail-а ну и т.д. Т.е. сам пароль мы нигде не храним и данные пользователя даже в случае утечки БД ничего не стоят... Единственные слабые места в такой схеме - это генерация ключа на базе пароля и невозможность востановления утраченого пароля...

-----
Все возражают против того, что я гений, хотя никто еще так меня не назвал. - Орсон Уэллс

DlTA, использовать для авторизации сторонние сервисы: OpenID или соц.сети

DlTA, ни в коем случае
(Добавление)
Саныч, http://habrahabr[dot]ru/blogs/web_security/121021/ я вот об этом, авторизация есть, хранения (передачи) пароля нет.

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

-----
Все возражают против того, что я гений, хотя никто еще так меня не назвал. - Орсон Уэллс

Саныч, если нужно хранить конфиденциальные данные, за советом на форумы не идут ;)

Да и если слили базу с паролями, то скорее всего база с данными могла тоже уйти(но не всегда).
Ведь одна из причин - препятствие зайти под логином/паролем человека, и выдавать себя за него.
(Добавление)

Хорошая схема. Восстановление можно сделать по ключевой фразе, но тут опять таки появляется уязвимость.

Можно, но ненадежно...
Я лично вижу в такой ситуации востановление пароля в таком виде:
0) делаем еще 3 столбец БД, в котором храним хеш всех данных пользователей
1) при запросе востановить пароль, просим ввести пользователя все его данные.
2) ну дальше все просто, хеширем и ищем такой хеш в БД. Если есть - перешифровываем его данные уже новым паролем.
Сделать вобще можно все. Таже самая генерация ключа на базе пароля после тщательной проработки становится вполне надежной.

При такой схеме самым уязвимым "местом" становится сам пользователь. Вернее то, как многие пользователи хранят свои пароли. Стикер на мониторе, текстовый файл на рабочем столе и т.д.

-----
Все возражают против того, что я гений, хотя никто еще так меня не назвал. - Орсон Уэллс

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