юзать как взрослые SSL

Вроде бы ssl достаточно для этого.

Одно другому ж не мешает. Паранойи много не бывает.

Использую pwgen на с с бодунаслучайно выбранной машине. Открыть можно.... ч/з 2.5 лет, с использованием суперПК, ака топ500.

Но пароли мы меняем слишком часто, чтобы об этом беспокоиться.

А вот как с клиента на сервер пароль передавать

Ключ 1023 бит (в худшем случае)

Только физически. Либо ч/з 100500 раз защищеный канал. Но тогда в самом ключе должно быть написано, до каких пор он действует. Вариантов нет.

Одно другому ж не мешает. Паранойи много не бывает.

Бывает. Например, некоторые веб-разработчики наивно полагают, что к паролю можно применить 100 раз md5 и не париться с солью.

На всякий случай, уточняю, я делаю «форум», а не банк-клиент. Поэтому речь именно от «поролЯх на сайт»

Я не о том. Точнее, ты не о том) Истинный параноик и посолит и прохэширует сотню раз.

Не надо пожалуйста общие рассуждения предлагать. У меня вполне конкретный вопрос. Надо ли хешировать на клиенте, если для передачи используется SSL. Для остального есть bcrypt.

Надо ли хешировать на клиенте, если для передачи используется SSL.

Не надо. Либо первое, либо второе. Но так как использовать SSL itself - проще, то лучше его и использовать.

Надо ли хешировать на клиенте, если для передачи используется SSL.

SSL достаточно секурен, необходимости дополнительно хэшировать пароль нет, в OAuth 2.0, к примеру, модель безопасности базируется на SSL передавая чувствительную информацию в открытом виде.

Логично. Спасибо.

Вот тут утверждают, что ssl легко взламывается - http://habrahabr.ru/post/128833/

Британские учоные в треде! Нас взломали!

Так пардон, хеширование паролей с помощью JS на стороне клиента в данной ситуации не спасёт. Отака направлена на то, чтобы скомуниздить пользовательскую печеньку.

Как правильно хранить пароли от сайта

Vit

Всякие там усиления, соления и т.п. Если кратко, ответ звучит «используй на сервере bcrypt со сложностью 10 и не парься».

В основном согласен.

Как думаешь, Vit, а что если хранить соли в текстовом файлике отдельно от БД?

Таким образом, хеши паролей хранятся в MySQL, а соли для хеширования в текстовом файле, который расположен вне папки DocumentRoot.

Тогда для подбора паролей потребуется не только взломать БД, но и украсть с сервера текстовый файл с солями.

Или проще «не париться» и хранить хеш вместе с солью в БД?

P.S. тоже пишу мини-форум, поэтому интересуюсь

Предлагаю поступить так: пароли не хранить вообще.

Вы сможете обеспечить безопасность, какую обеспечивает google аккаунтам своих пользователей? Дву-ступенчатую авторизацию и так далее? - Тогда даже и не пытайтесь иметь дело с паролями.

Не нужно плодить лишних сущностей типа логина. Предпочительно же использовать e-mail, — он есть (должен быть?) у всех и каждого, ибо это самый простой элемент в интернете (легко доступен через публичные сервисы, можно поднять локально). Мобильный телефон тоже может быть не у всех (я не пользуюсь, хорошо быть свободным). Регистрироваться в социальных сетях это уже по желанию пользователя, — хорошо, если вы поддерживаете такую фичу на своем сервисе, но она не обязательна. Я все еще скептичен к социальным сетям, уж лучше старушка электропочта с мейллистами. OpenID/OAuth неплохая идея, когда их можно поднять локально (и хранить всю информацию в одном месте), либо так же как e-mail они доступны через публичный сервис, в остальном же не вижу других отличий от самого e-mail, — очередная сущность.

Так вот, еще лучше и для юзабилити (всего одно поле ввода) и для безопасности не использовать пароль на сайте вообще, а только e-mail. При входе на сайт вводишь e-mail, тебе на почту приходит секретная одноразовая ссылка, по которой нужно перейти и ты идентифицирован. Если утечет e-mail — будет не так страшно, как если бы утек пароль, который пользователь использует где-то еще помимо вашего сайта.

С нынешним развитием ПО есть desktop-клиенты и web 2.0 интерфейсы для почты на любой вкус и сделать несколько кликов (это максимум) чтобы переключиться туда-сюда за одноразовой ссылкой кажется легче, чем морочиться с секретным словом (паролем). Не нужно запоминать пароли для каждого сервиса и придумывать методики их хранения, защиты и т.п., поскольку защитить один единственный e-mail адрес и помнить один единственный пароль для него будет проще.

Пароль это нормально, но каждый сервис считает себя самым главным и все они требуют логин+пароль. Может быть даже такое, что мой логин (ник) на сайте кем-то занят, — неприятно. С e-mail такого не будет (в конце концов, можно поднять на своем домене почту, если ваше имя/ник вам (как и мне) так важно). Я же говорю о том, что необходимо запомнить и использовать только один пароль, для такого важного сервиса как e-mail, куда поступает вся информация со всех остальных ваших аккаунтов на сервисах в интернете. Для тех, у кого есть мобильные телефоны, можно сделать еще безопаснее и не использовать пароль, а вам каждый раз при желании зайти на почту будет приходить SMS с одноразовым кодом (паролем).

Просто я так вообще паролями не пользуюсь. Когда нужно идентифицироваться на сайте, каждый раз пользуюсь функцией «забыл пароль», чтобы мне выдали новый пароль на e-mail. Так действительно проще, чем запоминать пароль от каждого сайта персонально или придумывать методику их хранения, когда сайтов много, а вы один.

ssl

Интересная методика аутентификации, спасибо за информацию, Spoofing!

Может быть я не понял вопроса, но в чем разница между текстом пароля и хешем при передаче их по открытому каналу?

Если утечет e-mail — будет не так страшно, как если бы утек пароль, который пользователь использует где-то еще помимо вашего сайта.

Ок, тогда дайте доступ к вашему емейлу, а мы все дружно посмотрим где вы его используете, и попользуемся функцией «забыл пароль». Это же не так страшно.

мне показалось, или вы подменяете понятия слова «утечка», - вот к примеру, если утечет пароль, то что может с ним случиться? ничего, он просто _станет известен_ и им воспользуются для входа логин+пароль.
это же самое я и имею ввиду, говоря о e-mail, - что _не страшно_, если e-mail адрес станет известен. вы с ним ничего не сделаете, кроме рассылки спама. ведь войти в почту вы просто так не сможете, чтобы авторизироваться на сайте посредством e-mail.

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

я о чем и говорю, - пока вы явно не получите доступ к почтовому ящику, вы _ничего_ не сможете сделать с аккаунтом на сайте. а защитить всего-лишь один почтовый ящик, тем более на gmail с авторизацией через sms при каждом логине, согласитесь, куда проще, чем постоянно придумывать хитрые схемы генерации паролей и прочая-прочая-прочая, если в конечном счете сайт попросту окажется дырявым и уведут данные со всех аккаунтов сайта. не?

ну или опишите свое видение, шаг-за-шагом, - какой вы видите вариант развития событий «при утечке e-mail».

«Утечка емейла» означает доступ к почтовому ящику. Подарить доступ к почтовому ящику куда страшнее чем засветить пароль от лора. В данном случае, почтовый ящик это вроде как единая точка отказа, ведь имея доступ к нему, мы имеем всё что к нему привязано.

1. Бывает, люди теряют мыла. Например при смене работы. В этом случае без пароля доступ к аккаунту накроется.

2. Если у юзера слишком много прав (например, админ), то логинить по клику - не самая удачная идея.

Вообще, изобретатели счастья почему-то думают только о тех случаях, когда все хорошо. А про те, когда все плохо - забывают.