Современные методы проверки подлинности клиента/сервера

Question

Я создаю приложение без сервера браузера (XULRunner-CherryPy), использующее HTTP для связи. Область, о которой я сейчас размышляю, - это аутентификация пользователя. Поскольку у меня нет существенных знаний в области безопасности, я бы предпочел использовать проверенные подходы и готовые библиотеки, пытаясь придумать и/или создать что-то самостоятельно.

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

То, что я думаю, что мне нужно:

• Безопасное хранение паролей в базе данных (адаптивное хеширование?)
• Безопасная передача провода учетных данных пользователей (аутентификация SSL?)
• Secure лексема аутентификация для последующих запросов (не уверена об этом)

Итак, вопрос: каковы современные (не имеющие головной боли) техники и/или библиотеки, которые реализуют t его? (Никакая конфиденциальная информация, например номера кредитных карт, не будет сохранена).

Я смотрел на OAuth, и у них есть новая редакция, которую они настоятельно рекомендуют использовать. Проблема в том, что документы все еще находятся в разработке, и нет библиотек, реализующих новую редакцию (?).

Answer 1

После того, как я много думал и пытался написать собственный прототип, основанный на дизайне Amazon S3, который (я думал) был довольно безопасным, я нашел этот отличный веб-сайт, на котором есть ответы на все мои вопросы, инструментарий Enterprise Security API Toolkit, и многое, многое другое: OWASP.

Answer 2

Это не может быть полный ответ, но я хотел бы предложить некоторые обнадеживающие новости о радужных столах и в Интернете. Я не стал бы слишком беспокоиться о Rainbow Tables в отношении Интернета по следующим причинам:

(1) Трещины раковины работают, исследуя хешированный пароль. В Интернете хешированный пароль хранится в вашей базе данных, чтобы даже рассмотреть использование таблиц радуги. сначала нужно взломать всю базу данных.

(2) Если вы используете salt, как это делают большинство систем хранения паролей, то радужные таблицы быстро становятся неосуществимыми. В основном соль добавляет ряд дополнительных бит в конец заданного пароля. Чтобы использовать радужный стол, ему нужно было бы разместить дополнительные биты в каждом открытом текстовом пароле. Например, у первой ссылки, которую вы показали нам, была реализована реализация радужного стола, в которой может быть пароль до 14 символов. Поэтому, если у вас было больше 14 байт соли, система была бы бесполезной.

Answer 3

Веб-службы Amazon, OpenID и OAuth имеют примеры подписи запроса. Amazon Web Services - простой пример для того, чтобы следовать, потому что между взаимодействиями нет более сложного протокола. Они в основном связаны с тем, что клиент или сервер подписывают запрос, с помощью хэширования всех своих полей с ранее установленным ключом (или keypair), а другой конец подтверждает подпись, делая то же самое. Воспроизведение хэша предотвращается включением в поля метки nonce или timestamp.

Настройка ключей или других учетных данных, позволяющих это сделать через SSL, и следует отметить, что одной из мотиваций OAuth WRAP является замена некоторых или всех этих запросов на подписание SSL, что упрощает их реализацию.