Безопасность на хабре

Старая поговорка «Все замкИ — от добрых людей».
Битва меча и щита не нами начата и не при нас завершится, и в случаях, если выбирать между безопасностью и удобством пользования, ИМХО, стоит все-таки думать об удобстве (безотносительно к этому способу).
А за бдительность — респект :)

Занятно.

Но если бы я был Васей, я поставил бы кейлоггер.

Храни хеш IP

Я в своем проекте храню в куках идентификатор сессии, а на стороне сервера в сессии прописан хэш IP и user-agent. Таким образом, на другом компе или в другом браузере сессия не будет действительна.

setcookie('remember', $user['id'].'|'.md5($user['email'].$user['pass'].$user['name']), ...);

я так делаю :)

Галочки «запомнить мой IP» теперь нету — безопасность ниже. Но спасает постоянная привязка к почтовому ящику.

Долгое время я работал с mysql сессиями.
Но на одном небольшом проекте решил использовать php сессии и озадачился проблемой безопастности.
Нарисовалось такое решение
if($_SESSION['user_browser']!=$_SERVER['HTTP_USER_AGENT'])
{
//$_SESSION = array();
session_unset();
//session_destroy();
session_regenerate_id();
//$ids=session_id();
$_SESSION['last_time']=time();
$_SESSION['user_ip']=$_SERVER['REMOTE_ADDR'];
$_SESSION['user_browser']=$_SERVER['HTTP_USER_AGENT'];
$_SESSION['count'] = 1;
}
сравнивать можно и другие параметры, но мне важнее браузер.

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

Для своего проекта я однозначно решил — можно использовать аккаунт одновременно только с одного компьютера (в отличии от того же вконтакта). Именно поэтому при ре-логине прописывается новое значение сессии.
А в куках хранится только ID и значение сессии.
Проверяется просто — значение сессии и IP в БД в записи с ID из куков.

А-ля
select * from table where session = '...' and ip = '...' where id = '...'

Но у меня все немножко сложнее организовано, сессии хранятся в файлах, сложный механизм, к базе не всегда необходимо обращаться, и работает в разы быстрее.

Даже при использовании соли в хеше, имея несколько хешей от паролей, есть теоритическая возможность достать пароли. Вопрос во времени. Если организовать динамическую соль — невозможно достать пароль, не зная механизм образования соли.
ИМХО, все равно хранение пароля в куках не приводит ни к чему хорошему.

А разве продолжительное хранение сессии на сервере в течении месяца это просто и лаконично??? Особенно если к сессии какие-нибудь объекты привязаны… По идее за такое должны по рукам бить.

Да, обычно в куку/сессию кладут какой-нить уник юзера(id, например), и обязательно USER_AGENT. Опционально в голову приходила идея вытаскивать с помощью whois подсеть текущего ip-адреса и хранить эту подсеть вместо ip, таким образом злоумышленнику помимо знания значения куки нужно будет иметь идентичный user agent и при этом находится в той же подсети, что и юзер. А это уже почти что «ломом ломать».

красота.

Иногда еще полезно хранить не просто IP, а еще вдобавок и X-FORWARDED-FOR ибо буквально недавно наткнулся что например nichost.ru REMOTE_ADDR указывает на какой-то IP их внутренней сети (да еще и с динамическим портом каждый запрос). И если хранить просто ip — для всех сессий он будет совпадать.

Я тоже когда то так завис. Сделал просто:
1. Генерится рандомный хеш
2. Хеш заносится в базу данных и в куку
3. Если не существует сессионной переменной, из куки вытягивается хеш, сравнивается с хешем из базы данных.
4. Все ок! Создается новый хеш. Не ок — отсылаешься на страничку логина.

Как то так

https + любая аутентификация (даже тупейшая basic) или куки спасут отца русской демократии

http по-дефолту лох

Такие параноики как я делают например так:

$hash1=md5($login+microtime(true));
$hash2=crypt($uid+$_SERVER['REMOTE_ADDR'],$uid+$_SERVER['REMOTE_ADDR']);

$db = myPDO:: getInstance();

$query = $db->prepare('UPDATE `users` SET `user_hash`=: user_hash, `last_ip`=: last_ip WHERE id=: uid');
$query->bindParam(': uid',$uid);
$query->bindParam(': user_hash',$hash1);
$query->bindParam(': last_ip', $_SERVER['REMOTE_ADDR']);

if ($query->xcute(null,'update_user_data',__LINE__,__FILE__))
{
setcookie('uid', $uid,(time()+24*14*3600), '/','.'.SITE_DOMAIN);
setcookie('unh', $hash1,(time()+24*14*3600),'/','.'.SITE_DOMAIN);
setcookie('uih', $hash2,(time()+24*14*3600),'/','.'.SITE_DOMAIN);
}

Надо просто вводить двойной пароль(PIN и PUK вроде). Один закрытый, другой открытый. По открытому осуществляться авторизация, по закрытому изменение критичных настроек(те настройки, с помощью которых можно получить закрытый пароль) и открытого пароля. Закрытый пароль нигде, на стороне клиента не храниться. Даже если открытий пароль похищен, это можно исправить залогиневшись по закрытому паролю.

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

Хранить в куке только идентификатор сессии это нормально. Это из моего программистского детства ) Но если от пользователя пришла кука с сессией, а в базе ее нет, то звиняйте, вводите пароль. Ввели пароль — получите НОВУЮ сессию с НОВЫМ идентификатором и, соответственно, НОВУЮ куку. Этот велосипед я для себя открыл сам. phpBB хранил и хранит, наверное, логин и пароль пользователя (шифрованный), а когда получает куку, логинит пользователя автоматом. Не оживляет сессию, а именно логинит. Я это не одобрил и придумал свое. А так как не понимал как работает встроенный в РНР механизм сессий, то придумал свой.

Если вы не ошиблись и хабр работает именно так, то это просто пипец.

Интересно.
Ещё интересней было бы узнать, как с этим борются другие крупные сервисы и движки CMS/форумов, фреймворки.

Радует, что разработчики на Хабре постепенно погружаются в темы и начинают выкапывать вещи, которые всем надо бы знать. Фактически, сообщество повторяет эволюционный путь развития Программирования вцелом. Англоязычный интернет ушёл далеко вперёд, теперь русскоязычный идёт следом :-)
Кажется Хабр становится полезней ))

PS: Кстати, хорошим тоном является передача информации разработчикам за день-два до публикации уязвимости (а это на мой взгляд таки уязвимость).

ШОЙТАНАМА!!!
Тут интересная дискуссия проскочила, и я там показательно спалил свой пароль )
Кто-то решил проверить. Зашел под моим аккаунтом и написал коммент.
Вся шутка в том, что меня не выкинуло, моя сессия не обнулилась.
Товарищи!!! Так нельзя!!!