але краще замість солі для hash використовувати user agent
Питання цікаво сформульований =) "Емуляція сесій". Теоретично, сесія - як MVC. Це просто ідея. А в PHP одна з її реалізацій. Причому, далеко не досконала, але на 99% подходящаяя 89% сайтів на PHP.
У PHP на цілком "законних" правах можна реалізувати свої власні сесії us2.php.net/manual/ru/function.session-set-save-ha. використовуючи при цьому нативні php-функції для роботи з ними.
1) Файли - найповільніший, що може бути для цієї мети. Майже будь-який пошук по сесіях (всі сесії учасників форуму?) - це самогубство. При 1млн користувачів - подвійне самогубство. Так як це відкривання і парсинг мільйонів файлів. Кнопочку "закрити інші мої сесії" точно не варто робити при сесіях на файлах.
40 рандомних сімвлов - нереал. Як бонус - при зміні пароля сесія автоматично недійсна, при зміні браузера те ж саме.
user-agent і, особливо, хеш пароля грають роль солі при хешуванні. Таким чином можна підібрати хеш сесії по райдужним таблицями.
Суть лише в тому, щоб не записувати в базу конфендіціальную інфу. Якщо знання id сесії дає майже ті ж права, що знання пароля, то просто не записуємо id в БД так само, як ніколи не записуємо пароль. І все.
А взагалі, БД дуже зручне і досить продуктивне рішення для сесій. БД дає величезну кількість можливостей по роботі з даними сесій.
Тоді в cookie потрібно зберігати ще й id користувача?
Інакше хеш пароля ми не дістанемо.
По-моєму якщо є дамп БД - то хеш сесії це найменше, про що потрібно турбуватися.
З одного боку зрозуміло, для чого це робиться, а з іншого боку якщо є доступ до БД - то і хеш пароля є.
Сесії в файлах це фу: проблеми з блокуваннями можуть бути (ось тут я писав про це toster.ru/q/54276#answer_198530) + що не масштабується цей варіант. Хоча для невеликого сайту і варіант на файлах цілком годиться.
Я вже давно перейшов на зберігання сесії в sql- або nosql-базі даних.