Сообщений в теме: 3

[Diosat]

Всем доброго времени суток. Встал такой вопрос: какие поставить ограничения на логин и пароль?
С минимумом я более менее определился это 6 символов на пароль , а логин без ограничения, хотя имхо и тут надо наложить ограничения как минимум 6-7 символов.
А как быть с максимальным количеством символов и паролей? Мои разработчики предлагают не ограничивать, но я наслышан что это один из видов уязвимостей, которые следует устранять.
Заранее спасибо.

[Лелик32]

Всем доброго времени суток. Встал такой вопрос: какие поставить ограничения на логин и пароль?
С минимумом я более менее определился это 6 символов на пароль , а логин без ограничения, хотя имхо и тут надо наложить ограничения как минимум 6-7 символов.
А как быть с максимальным количеством символов и паролей? Мои разработчики предлагают не ограничивать, но я наслышан что это один из видов уязвимостей, которые следует устранять.
Заранее спасибо.

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

С минимумом я более менее определился это 6 символов на пароль

Каким образом вы определились? А почему минимум - это не 10 символов? Ок, на многих сервисах используется именно 6, но из какого принципа исходят они, вы не задумывались?

А как быть с максимальным количеством символов и паролей? Мои разработчики предлагают не ограничивать, но я наслышан что это один из видов уязвимостей, которые следует устранять.

Длина все равно будет ограничена как минимум длинной типа данных, который используется для логина/пароля.
Также не введя ограничение на логин, впоследствии, возможно, придется столкнуться с корявостью отображения слишком длинного логина в UI + могут вылезти глюки еще в других местах.

[Diosat]

Спасибо за ответ.

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

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

Каким образом вы определились? А почему минимум - это не 10 символов? Ок, на многих сервисах используется именно 6, но из какого принципа исходят они, вы не задумывались?

Тут я не полностью описал ситуацию, сам дурак,у нас в качестве логина используется адрес электронной почты, следовательно минимальный адрес будет a@rf.ru следовательно 7 символов, я знаю что домен может быть и односимвольным и тогда минимальное ограничение будет 6 символов, но тут уже мне сказали что такая вероятность минимальна, и потом в зоне .ru минимальный домен может быть 2 символа не меньше. Насчет пароля, ограничение в 6 символов как раз и появилось из сравнения с другими сервисами.

Насчет максимальных размеров, спасибо за уточнение, приведу их в качестве аргумента.

[owasp]

Мысль об ограниченности строки не является совсем верной. Формально в базе данных унжно будет хранить лишь хеш пароля. В зависимости от функции хеширования, для хранения надо будет зарезервировать 256 или 512 байт.
А каким же может быть сам пароль:

• Классический, человеческий.
• Машинно-сгенерированный (который не запонимается, а берётся из менеджера паролей).

Если отбросить факт использования менеджеров паролей, то максимальная длина может быть любой. А если не отбрасывать, и обратить внимание на документацию этих программ (ссылки можно посмотреть в статье http://habrahabr.ru/post/125248/), то можно заметить, что распространено использование в качестве паролей хешей. Длиной 256-bit (32 байта, 64 символа, при отображении набором символов для 16-ти ричной системы), реже 512-bit (64 байта, 128 символов, при отображении набором символов для 16-ти ричной системы: [a-f, 0-9]).

То есть, ограничивая максимальную длину пароля, оставьте возможность использования программно-генерируемых паролей длиной порядка 64 символа (можно и 128).

И правильно было замечено, что слишком большое ограничение на пароль может привести к появлению слабого места в системе.
Например, на веб-сайте максимальная длина пароля = 1048576 байт (1 МБайт), и известно, что:

• передача такого длинного пакета от клиента к серверу занимает 4 секунды.
• вычисление хеша для такого пароля, используемой функцией хеширования занимает 6 секунд (и при том загружает процессор сервера на 100% и потребляет на сервере 38 МБайт оперативной пмяти) - цифра выдуманная и нереальная, но допустим используется такой кривой алгоритм хеширования.
• на сайте не предусмотрена защита от брутфорса (например, при вводе 5-ти неверный паролей подряд, доступ к сайте не блокируется для IP-адреса или логина)
• вычисление хеша вычисляется на этом же сервере, не используются очереди операций и другие "разгружающие" подходы в архитектуре системы

Тогда злоумышленник может сделать DoS (отказ в отслуживании), просто послая (в одиночку) по 10 запросов в минуту к сайту. Сайт будет постоянно загружен и потребит всю память. В отличие от DDoS (Распределённый отказ в отслуживании), злоумышленник может в одиночку положить сервер, ему не нужно 1000000 ботов.

Но в реальности, хеши вычисляются быстро. Думаю даже 1 МБайт для пароля - не является проблемой, если сервер достаточно новый. Кроме того, можно вынести все трудоёмкие операции в очередь. А также предусмотреть защиту от брутфорса. Тогда можно использовать в качестве пароля, что угодно, любого размера (например, аутентификация по уникальному файлу размером 4 МБайта со случайным содержимым, или просто уникальным содержимым - фотография или звукозапись).