Чтобы не говорили, но атомную энергетику не закроют в ближайшие 100 лет точно. Все альтернативы это конечно хорошо, но вот когда вам нужно сразу и много энергии то ветряками особо не помашешь и прочими альтернативами.
Я ссылку вашу прочитал, решение хорошее да. Я ниже описал, что рассматриваю ситуацию когда нужно взломать 1го конкретного пользователя, тогда особо хранение соли рядом с паролем не поможет, я считаю что соль должна динамически генерироваться. ладно тут и так слишком много моих комментов, мне ваша позиция ясна :)
Естественно, я спорил про ситуацию когда нужено получить пароль конкретного пользователя, а тут сразу «специ криптозащиты» заминусовали, ппц. Редко когда хакеру нужно получить пароли именно _всех_ пользователей, почти всегда интересует кто-либо конкретный скорее всего.
>>На моем скромном ноутбуке, скриптом на PHP у меня генерируется примерно 1,7 млн. MD5-хэшей в секунду
>>Т.е. если у нас одна соль на всех, и хакер может генерировать радужную таблицу для словаря и недлинных алфавитно-цифровых паролей за 7 дней
что-то как то слабо кореллирует одно с другим. я спрашиваю не про всех пользователей а про одного конктретного, пусть хакере интересует 1 конкретный польз. а не все, выигрыш в хранении в поле БД динамической соли в данном случае сомнителен. Щас опять заминусуют специалисты криптозащиты из школы :D
Вы опять отвечаете на то что понятно любому, я рассматриваю ситуацию для разных пользователей у которых разные пароли. поэтому случай 3 странный совсем, хранить соль рядом с паролем. соль лучше вычислять динамически взависимости от каких либо данных, а не хранить рядом в поле, а то смысл 3его пункта тогда совсем теряется, т.к. зная соль и алгоритм можно тупо перебирать по таблицам так же как и всегда.
и что дальше? вы радужную таблицу сами будете генерировать? хм, сомневаюсь. пункт 1 ясен всем, пункт 3 — единственное преимущество это только выигрыш времени в брутфорсе каждого отдельно взятого пользователя, т.е. фактически как я и описал выше все сводится к: узнать алгоритм применения соли + сам пароль, так? поэтому как-то совсем не выигрышно, ну будет 2 польз. с разной солью, но одинаковыми паролями и что? зная алгоритм как соль применяется в пароле тут они абсолютно ничем не защищены.
эм… немного не понял, ну будет у вас в таблице еще одно боле с солью (обычное нехешированое поле) и в чем тогда выигрыш? т.е. слив базу злоумышленник получает связки пароль + соль для пароля, остается только разгадать алгоритм как соль участвует в получении пароля + сам пароль, разве не так?
Блин, я вам в предыдущих сообщениях все подробно расписывал и ссылки приводил, а у вас на любой мой ответ только одно «не вижу доводов», ну круто че. Вообщем лучше закрыть тему, а то это будут взаимные притензии и оскорбления еще не дай бог :) каждый при своем :)
Я же описал выше, что сессию придется кидать не в «файлы», а как минимум в БД, что естественно накладывает и свои ограничения, специфические для реализации сессии через БД(так что ваш вопрос звучит немного непонятно), особенно когда несколько серверов, вообщем это долгая тема. По поводу куки кстати, в Yii так сделано :) там токен генерируется 1 раз и ставится в куки, потом из них забирается если что, решение сомнительное но все же :)
Ну например, приложение находится на нескольких доменах это уже значит что токен приходится хранить в куки(недостаток существенный), если у вас сессия не в БД конечно, хотя и это накладывает свой гемор, дальше как я уже указал, если сбрасывать каждый раз после post-запроса например, то это уже проблемы с ajax и прочими подобными вещами. Скомпрометировать те же куки и узнать токен ведь проще(неважно как, сейчас не рассматриваем как украсть куки) на стороне клиента, чем как-то на стороне сервера его подделать? С другой стороны можно было бы анализировать реферер но и он может быть подделан(в ссылках описано), поэтому ни то ни то не спасает полностью, и приходится выбирать в зависимости от нужд. попытался описать кратко, не ввязываясь в особую демагогию :)
Хм, да основная проблема состоит именно при авторизации, когда собственно и происходит генерация токена, проблемы с токеном могут вскрыться потом, например при AJAX(если не хранить один и тот же токен для всей сессии, а сбрасывать его при каждом пост запросе), плюс если почитаете ссылку вторую до конца там тоже описываются ситуации другие.
>>Т.е. если у нас одна соль на всех, и хакер может генерировать радужную таблицу для словаря и недлинных алфавитно-цифровых паролей за 7 дней
что-то как то слабо кореллирует одно с другим. я спрашиваю не про всех пользователей а про одного конктретного, пусть хакере интересует 1 конкретный польз. а не все, выигрыш в хранении в поле БД динамической соли в данном случае сомнителен. Щас опять заминусуют специалисты криптозащиты из школы :D