Почему нельзя использовать в пассворде пробелы?

Добрый день!
Подскажите, кто знает, почему считается недопустимым использование в пароли пробелов? Очень интересно)
Спасибо

Добрый день!
Подскажите, кто знает, почему считается недопустимым использование в пароли пробелов? Очень интересно)
Спасибо

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

Ну вот мне и стало интересно почему так некоторые тестировщики советуют :)
Спасибо за ответ

Например при копипасте пароля, может в конце или в начале оказаться пробел, и пользователь долго будет думать, какого чёрт пароль не тот.
Поэтому при логине пробелы нужно обрезать молча, а при регистрации говорить, что пароль содержит недопустимый символ пробел.
Ещё бывали случаи, когда пароли при регистрации молча убирали, пользователь региструется, потом пытается залогиниться, а пароль не тот, потому что пробелы не сказав обрезали :)

В конце и в начале - это понятно, всегда на это проверяем тоже. :)
Вот тут к примеру я вычитала, что НЕЛЬЗЯ в середине использовать пробелы
http://testitquickly...-adnaklassni6i/
А пояснения, почему нельзя, нет.

В конце и в начале - это понятно, всегда на это проверяем тоже. :)
Вот тут к примеру я вычитала, что НЕЛЬЗЯ в середине использовать пробелы
http://testitquickly...-adnaklassni6i/
А пояснения, почему нельзя, нет.

Зачем такие сложности? Пробел в пароле или должен быть, или нет совсем. Было бы странно говорить пользователю, если он захочет создать пароль с пробелом в конце "Пробелы разрешены только в середине пароля." :)

хм...
мне просто было интересно, зачем не разрешать использовать пробел в середине. А именно: может существует какая-то возможность это использовать в плохих целях, раз так утверждают в статье и всё :)
Если это просто "от фанаря" в статье написали, то вопрос снят))

1
Не от "фанаря", а от "фонаря".

2
Не разрешать использовать пробел в середине потому, что некоторые разработчики пробелы ВЫРЕЗАЮТ, а некоторые ОБРЕЗАЮТ до пробела. Причем молча.

1
Не от "фанаря", а от "фонаря".

2
Не разрешать использовать пробел в середине потому, что некоторые разработчики пробелы ВЫРЕЗАЮТ, а некоторые ОБРЕЗАЮТ до пробела. Причем молча.

1.Я не в обиду писала Вам:)
2."от фанаря" - именно и имелось в виду, именно произношение подмечалось, поэтому и в кавычках
3.Хотелось получить четкий отчет, а не тупо следовать написанному :)
За ответ спасибо!

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

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

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

Пользователю указывать какой у него должен быть и пароль и что он должен туда вводить это его собственное желание и право(по крайней мере с точки зрения удобства использования продукта

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

В общем случае, чтобы понимать, является ли багом или полезной фичей запрет кириллицы, пробелов, простых паролей и т.д. надо знать ЦА этого сервиса

Пользователю указывать какой у него должен быть и пароль и что он должен туда вводить это его собственное желание и право(по крайней мере с точки зрения удобства использования продукта

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

В общем случае, чтобы понимать, является ли багом или полезной фичей запрет кириллицы, пробелов, простых паролей и т.д. надо знать ЦА этого сервиса

Целевая аудитория конечно правит. Кирилицу упоминул для описания разности методов составления пароля

Добрый день!
Подскажите, кто знает, почему считается недопустимым использование в пароли пробелов? Очень интересно)
Спасибо

1. connection string имеет свой формат
“Data Source=Server,Port; Network Library=DBMSSOCN; Initial Catalog=DataBase; User ID=Username; Password=pwd;”
использовать в пароле ; уже не получится, если разрешить пропскать в символы ; те же пробелы, то пользователь сможет изменить строку соедиения, добавить в неё свои параметры.

2. Ограничения существующих книптографических библиотек, которые просто не поддерживают обработку пробелов, кириллицы, ...
Много кода для почтовых систем написано на C/C++ и написано давно, обработка кириллицы там не предусмотрена. А пересобирать библиотеки не все хотят. И таких библиотек много, они используются во многих приложениях. Допустим, есть почтовый сервер, с веб-интерфейсом. И там введены такие ограничения на пароли, это сделано с заделом на будущее, вдруг придётся расширить функциональность, добавить к веб-интерфейсу ещё и FTP, социальную сеть, форум, персональные блоги, ... (как правило это лишь мечты). И чтобы при этом не было проблем интеграции (чтобы текущий пароль принимался везде), заранее делаются ограничения на логины и пароли. Ведь может быть так, что конкртный форумный движок не воспринимает логины на русским, и как тогда быть - заставить пользователей регистрироваться по новой? - можно конечно, но не все станут.

3. Для веб-приложений часто не все хотят разбираться в том, что +, %20 - это пробел, а также в прочих тонкостях с кодировками. Всё что пришло на запрос пароля подставляется в пароль, если пришло %20, то эти 3 (а не 1) символ будут считаться частью пароля. Довольно просто выделить символы, которые можно передавать без экранирования - латинские буквы, цифры, подчёркивание и ещё ряд символов.

Добрый день!
Подскажите, кто знает, почему считается недопустимым использование в пароли пробелов? Очень интересно)
Спасибо

1. connection string имеет свой формат
“Data Source=Server,Port; Network Library=DBMSSOCN; Initial Catalog=DataBase; User ID=Username; Password=pwd;”
использовать в пароле ; уже не получится, если разрешить пропскать в символы ; те же пробелы, то пользователь сможет изменить строку соедиения, добавить в неё свои параметры.

2. Ограничения существующих книптографических библиотек, которые просто не поддерживают обработку пробелов, кириллицы, ...
Много кода для почтовых систем написано на C/C++ и написано давно, обработка кириллицы там не предусмотрена. А пересобирать библиотеки не все хотят. И таких библиотек много, они используются во многих приложениях. Допустим, есть почтовый сервер, с веб-интерфейсом. И там введены такие ограничения на пароли, это сделано с заделом на будущее, вдруг придётся расширить функциональность, добавить к веб-интерфейсу ещё и FTP, социальную сеть, форум, персональные блоги, ... (как правило это лишь мечты). И чтобы при этом не было проблем интеграции (чтобы текущий пароль принимался везде), заранее делаются ограничения на логины и пароли. Ведь может быть так, что конкртный форумный движок не воспринимает логины на русским, и как тогда быть - заставить пользователей регистрироваться по новой? - можно конечно, но не все станут.

3. Для веб-приложений часто не все хотят разбираться в том, что +, %20 - это пробел, а также в прочих тонкостях с кодировками. Всё что пришло на запрос пароля подставляется в пароль, если пришло %20, то эти 3 (а не 1) символ будут считаться частью пароля. Довольно просто выделить символы, которые можно передавать без экранирования - латинские буквы, цифры, подчёркивание и ещё ряд символов.

Супер! Спасибо!

Супер! Спасибо!

А что спасибо?

1. connection string имеет свой формат
“Data Source=Server,Port; Network Library=DBMSSOCN; Initial Catalog=DataBase; User ID=Username; Password=pwd;”
использовать в пароле ; уже не получится, если разрешить пропскать в символы ; те же пробелы, то пользователь сможет изменить строку соедиения, добавить в неё свои параметры.

Частный случай работы с какой-то базой или что вообще это такое? Да и экранирование символов придумали давно с помощью \, например.

2. Ограничения существующих книптографических библиотек, которые просто не поддерживают обработку пробелов, кириллицы, ...
Много кода для почтовых систем написано на C/C++ и написано давно, обработка кириллицы там не предусмотрена. А пересобирать библиотеки не все хотят. И таких библиотек много, они используются во многих приложениях. Допустим, есть почтовый сервер, с веб-интерфейсом. И там введены такие ограничения на пароли, это сделано с заделом на будущее, вдруг придётся расширить функциональность, добавить к веб-интерфейсу ещё и FTP, социальную сеть, форум, персональные блоги, ... (как правило это лишь мечты). И чтобы при этом не было проблем интеграции (чтобы текущий пароль принимался везде), заранее делаются ограничения на логины и пароли. Ведь может быть так, что конкртный форумный движок не воспринимает логины на русским, и как тогда быть - заставить пользователей регистрироваться по новой? - можно конечно, но не все станут.

Какое отоношение кроптографические библиотеки имеют к паролю? Обычно пароли солят и хешируют. Хешу пофигу.
С ориентацией на другие сервисы могу согласиться, достойная причина, чтобы ограничивать пароль.

3. Для веб-приложений часто не все хотят разбираться в том, что +, %20 - это пробел, а также в прочих тонкостях с кодировками. Всё что пришло на запрос пароля подставляется в пароль, если пришло %20, то эти 3 (а не 1) символ будут считаться частью пароля. Довольно просто выделить символы, которые можно передавать без экранирования - латинские буквы, цифры, подчёркивание и ещё ряд символов.

Пароли не передают в урле, а передают как бинарные данные и при этом уже захешированные. Ну нормальные люди так делают. Поэтому если где-то пароль приехал с %20 - то это или 3 символа или отсутствие секьюрности пароля.

Какое отоношение кроптографические библиотеки имеют к паролю? Обычно пароли солят и хешируют. Хешу пофигу.

Пароли не передают в урле, а передают как бинарные данные и при этом уже захешированные. Ну нормальные люди так делают. Поэтому если где-то пароль приехал с %20 - то это или 3 символа или отсутствие секьюрности пароля.

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

Если веб-приложение с авторизацией через форму (а это очень распространено), и на стороне клиента веб-приложения нет javascript/flash, которые бы выполнили добавление соли и вычисление хеша перед отправкой пароля, то всё будет передаваться в открытом виде, то есть отсутсвие секьюрности пароля наблюдается сплошь и рядом. Едиснтвенное что спасает, так это SSL - шифрование трафика.
Алгоритм добавления соли (если он самописный) и саму "соль" выносить на клиента тоже не всегда правильно.

Пример того, что UTF-8 в PHP5 и UFT-8 в MySQL5 это разные UTF-8.
1. Создать в TestLink 1.9.2 пользователя с именем "Проверка" у него id получился = 37, также в TestLink есть предопределённый пользователь Admin с именем Testlink и id=1.
2. Сделать вычисление md5 из базы Testlink (которая в кодировке UTF8) и из PHP
3. Сохранить скрипт в кодировке UTF8 или в Windows-1251, выполнить скрипт.
<?php
$data = 'Testlink';
$md5 = md5(utf8_encode($data));
print("<p>PHP: {$md5} ({$data})</p>");

$data = 'Проверка';
$md5 = md5(utf8_encode($data));
print("<p>PHP: {$md5} ({$data})</p>");

$db = mysql_connect('localhost','root','*********') or die("Database error");
mysql_select_db('testlink', $db);

$result = mysql_query("set names 'utf8'");

$query = "select MD5(first) as MD5, first from testlink.users where id=1 or id=37";
$result = mysql_query($query);
if($result)
while( $row= mysql_fetch_assoc($result) )
print("<p>MySQL: {$row['MD5']} ({$row['first']})</p>");
?>

Получаем результат:
PHP: d4f68f4edfeb0ee1fd4aa3f7f249b0ef (Testlink)
PHP: 8b347e5fb127284457e8294226bd1cbe (Проверка)
MySQL: d4f68f4edfeb0ee1fd4aa3f7f249b0ef (Testlink)
MySQL: 25baf6240e126086b3b23f55a8dea830 (Проверка)

Если скрипт в кодировке UTF-8, то результат будет такой:
PHP: d4f68f4edfeb0ee1fd4aa3f7f249b0ef (Testlink)
PHP: d7473d0c3627deef383ae2d3aed819f7 (Проверка)
MySQL: d4f68f4edfeb0ee1fd4aa3f7f249b0ef (Testlink)
MySQL: 25baf6240e126086b3b23f55a8dea830 (Проверка)

Для русских символов, в кодировке UTF8, MySQL как-то по-особому выполняет вычисление MD5. Это пример для популярных языков и продуктов, причем их последних версий. А есть же и другие библиотеки, другие реализации алгоритмов.

К сожалению, не до конца понял ваш пример. Вы везде приводите все к UTF-8 и в UTF 8 работает. А в 1251 где-то не работает. Могу только прикинуть, что где-то кто-то все-время ожидает UTF-8, а ему прилетает что-то в 1251, вот отсюда и путаница.
MD5 должен быть один и тот же, иначе грош ему цена. А то, что 1251 и UTF-8 строки с одним и тем же русским словом будут разные - тут и к гадалке ходить не надо. А один и тотже хэш будет одинаково работать для одного и того же массива байтов.

Причем я не говорю, что тут не может быть багов. Именно багов реализации и использования. Я вовсе не являюсь сторонником паролей русскими буквами. Но к пробелу, все это, имхо, не имеет отношения.

К сожалению, не до конца понял ваш пример. Вы везде приводите все к UTF-8 и в UTF 8 работает. А в 1251 где-то не работает. Могу только прикинуть, что где-то кто-то все-время ожидает UTF-8, а ему прилетает что-то в 1251, вот отсюда и путаница.
MD5 должен быть один и тот же, иначе грош ему цена. А то, что 1251 и UTF-8 строки с одним и тем же русским словом будут разные - тут и к гадалке ходить не надо. А один и тотже хэш будет одинаково работать для одного и того же массива байтов.

Причем я не говорю, что тут не может быть багов. Именно багов реализации и использования. Я вовсе не являюсь сторонником паролей русскими буквами. Но к пробелу, все это, имхо, не имеет отношения.

Сравните:
PHP: d7473d0c3627deef383ae2d3aed819f7 (Проверка)
MySQL: 25baf6240e126086b3b23f55a8dea830 (Проверка)

До ":" написано кто вычисляет MD5, после ":" - значение MD5, а в скобках - строка, от которой берётся MD5.
Как видно значения разные d7473d0c3627deef383ae2d3aed819f7 != 25baf6240e126086b3b23f55a8dea830

И я не являюсь запретителем пробелов в паролях. Когда у службы поддержки NextMail выпытавал почему максимальная длина пароля = 16 символов и в нём нельзя использовать кирилицу + @ + \ + / + ... мне так ничего и не сказали. Но убеили, что пароли в явном виде в БД не хранятся и что всё как надо сделано. Тогда там был баг с символом @ - его можно было использовать в пароле. Я устанавливал пароль через Web-клиента, и символ @ попал в пароль как %40 и через веб-клиент вход осуществлялся, а через Mozilla Trunderbird вход не работал по причине - пароль неверный. Пришлось заменить все @ на A или a.

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

Сравните:
PHP: d7473d0c3627deef383ae2d3aed819f7 (Проверка)
MySQL: 25baf6240e126086b3b23f55a8dea830 (Проверка)

До ":" написано кто вычисляет MD5, после ":" - значение MD5, а в скобках - строка, от которой берётся MD5.
Как видно значения разные d7473d0c3627deef383ae2d3aed819f7 != 25baf6240e126086b3b23f55a8dea830

И я не являюсь запретителем пробелов в паролях. Когда у службы поддержки NextMail выпытавал почему максимальная длина пароля = 16 символов и в нём нельзя использовать кирилицу + @ + \ + / + ... мне так ничего и не сказали. Но убеили, что пароли в явном виде в БД не хранятся и что всё как надо сделано. Тогда там был баг с символом @ - его можно было использовать в пароле. Я устанавливал пароль через Web-клиента, и символ @ попал в пароль как %40 и через веб-клиент вход осуществлялся, а через Mozilla Trunderbird вход не работал по причине - пароль неверный. Пришлось заменить все @ на A или a.

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

Интересно, спасибо!