[ Поиск ] - [ Пользователи ] - [ Календарь ]
Полная Версия: И снова пароли! + Твиттер я был удивлен!
Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9
twin
Michael
Цитата
постарайся читать правильно, я использовал слово недоДУМКА....
Прошу пардона, техника скорочтения не всегда приносит положительные результаты))

Цитата
Тебе выше про эти причины говорили уже, вот только ты никак не догонишь мысль.
Говорили, да. Но почему то не слушали контр-аргументов.
Цитата
1) нет разницы от чего я составлю хэш, если исходный пароль не сохраняется, от всех введенных знаков или по какой то схеме - например с обрезанными пробелами. Разницы для пользователя нет, может же вводить и с пробелами если кулхацкер такой.
Разница есть. И я её привел неоднократно. Если нет предупреждения, что пароль неприемлит пробелов по краям, то разница просто огромна. Хэш привести для сравнения? И постарайся вникнуть в то, что я приводил контраргументом: Уж коли ты принял пароль с пробелами, ты не должен пускать в аккаунт без них. Ибо это другой пароль.

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

Цитата
3) Наличие пробелов по бокам ПРИНИМАЕТСЯ как ошибочный ввод и система обработает его сама, а не положит это на пользователя, типа неверный пароль. Это решение не программистов, а специалистов по Юзабилити и подобных, программисту чисто реализовать, разницы то технической особой нет. Мнение программистов тут как бы никто и не спрашивает.
Специалисты по юзабилити должны сделать удобным интерфейс, а не решать за меня, какие символы использовать. Запрети, порекомендуй, но не смей трогать мою собственность. А в данном случае ( с друпалом) я с огромной вероятностью могу сказать, что никакие специалисты юзабилити этого не касались. Это простая привычка программиста - резать пробелы. Только в поле "пароль" она не уместна. И вообще, такие вещи как пароль, должны регламентироваться специалистами по БЕЗОПАСНОСТИ, а не юзабильщиками. А если безопасник понимает, что тут возможно коллизия, ни кто никогда не посмеет ему возразить про удобство.

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

user posted image
Michael
Вот ты много чего написал, а сути так и не коснулся. sad.gif
Того что это сделано для удобства пользователей.
По твоей схеме есть следующие недостатки людям:
1) регаться с паролем с хвостовыми пробелами запрещено например. Когда будут авторизироваться и будет пробел их будет не впускать, а они этот пробел не видят в поле ввода.
2) регаться с паролем с хвостовыми пробелами разрешено например. Если он зарегается с пробелом, по ошибке, при авторизации он может о нем и не знать.

Хвостовой пробел, визуально неотличим в поле ввода, есть он там или нет..
А обрезав, эти проблемы решаются, это решение против проблем 1 и 2.

И безопасность тут не причем.
Вводит например юзер пароль(* вместо пробела):
***кулхацкер***
Система сделает ему скидку (на его ошибку или на его кулхацкерство) и предположит что его пароль - кулхацкер.
И по этому уже паролю сделает подсказку безопасен он или нет.

Цитата (twin)
Не посмотришь. Ибо я так никогда не сделаю. Если есть желание хранить пароль в открытом виде - о чем мы вообще разговариваем.

а гугл говорили сохраняет. Возможности технические есть обеспечить безопасность. А твое уверование в этом алгоритме уже сыпется.

Цитата (twin)
Обоснуй целесообразность сего демарша

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

тут ты походу не понял код. Из базы берется путь к файлу с возможно другой логикой хэширования. Отличный ход имхо, для безопасности. wink.gif


_____________
There never was a struggle in the soul of a good man that was not hard
killer8080
Цитата (Michael @ 25.09.2012 - 14:00)
а гугл говорили сохраняет. Возможности технические есть обеспечить безопасность.

А кто может гарантировать, что все сотрудники гугла честные и порядочные люди? Кто может дать гарантию, что утечка не возможна? Это как раз говорит о гуле не в лучшую сторону, раз они хранят открытые пароли, значит они им зачем то нужны. Возникает логичный вопрос, зачем?
Michael
Цитата (killer8080 @ 25.09.2012 - 13:10)
Цитата (Michael @ 25.09.2012 - 14:00)
а гугл говорили сохраняет. Возможности технические есть обеспечить безопасность.

А кто может гарантировать, что все сотрудники гугла честные и порядочные люди? Кто может дать гарантию, что утечка не возможна? Это как раз говорит о гуле не в лучшую сторону, раз они хранят открытые пароли, значит они им зачем то нужны. Возникает логичный вопрос, зачем?

Для удобства пользователям.
Если призабыл пароль, тебе его напомнят, а не сгенеририруют. Ну тут понятно что в общем случае не годится, но дело имеет место быть.

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


_____________
There never was a struggle in the soul of a good man that was not hard
killer8080
Цитата (Michael @ 25.09.2012 - 14:29)
Насчет недобросовестного сотрудника, то если он может как то пробить доступ к тому суперсекретному серверу-ларцу в котором реализована логика получения исходного пароля, то он мог бы и так угнать учетку как нибудь полегче.

Для это и нужно использовать не обратимые алгоритмы wink.gif
Michael
Цитата (killer8080 @ 25.09.2012 - 13:45)
Цитата (Michael @ 25.09.2012 - 14:29)
Насчет недобросовестного сотрудника, то если он может как то пробить доступ к тому суперсекретному серверу-ларцу в котором реализована логика получения исходного пароля, то он мог бы и так угнать учетку как нибудь полегче.

Для это и нужно использовать не обратимые алгоритмы wink.gif

ты не понял, эти необратимые алгоритмы побоку если он имеет например доступ к БД на уровне сисадмина и прочее.

_____________
There never was a struggle in the soul of a good man that was not hard
killer8080
Цитата (Michael @ 25.09.2012 - 14:53)
ты не понял, эти необратимые алгоритмы побоку если он имеет например доступ к БД на уровне сисадмина и прочее.

Да нет, как раз наоборот, шифрование для того и применяется, если каким либо образом произойдет утечка, то вытащить пароль так просто не удастся. Если бы можно было сто процентно гарантировать не возможность утечки, шифрование не имело бы смысла, как таковое.
Michael
Ну очевидно некоторые небольшие конторки и их небольшой штат инженеров как в гугле не считают для себя нерешимой задачу предоставления пользователю его же старого пароля, при сохранении безопасности. Ну а тот кто считает эту задачу нерешимой, для того она и остается нерешимой. tongue.gif

_____________
There never was a struggle in the soul of a good man that was not hard
killer8080
Цитата (Michael @ 25.09.2012 - 15:05)
Ну очевидно некоторые небольшие конторки и их небольшой штат инженеров как в гугле не считают для себя нерешимой задачу предоставления пользователю его же старого пароля, при сохранении безопасности. Ну а тот кто считает эту задачу нерешимой, для того она и остается нерешимой.

Пряча голову в песок, страус то же так думает, что проблема решена biggrin.gif
Guest
Не понимаю, почему пробел считают недосимволом. То что какой то галимый Word тупо его вставляет. Это не аргумент. Правильно twin сказал, давайте и пунто свитчер предугадывать, это то же ведь относится к аспекту юзабилити, так ведь Michael
Только вот есть нужные области где юзабилити вполне допустимы, а есть где оно вообще и на фиг не надо, а именно в области персонализированных данных.
Я не могу понять почему оппоненты twin не могут прочуствовать аргумента: "Личные данные", где скрытое искажение приводит к неоднозначности и недопониманию между системой и пользователем.
Если пользователь не понимает что ему дают большую область действия в выборе и кричит что это такое, сделайте "обрезание", здесь на лицо управление свободой выбора, соответственно сознанием чисто на психологическом уровне.
Guest
Кстати я с самого начала написал, что самым лучшим действием между системой и пользователем будет сценарий предупреждения, оповещения и помощи при выборе пароля без искажения его в системе. Вот это нормальное юзабельное отношение к человеку.
Michael
Про страусов прятающих свою голову в песок уже давно известно что они так никогда не делают laugh.gif , хотя я не понял при чем тут страусы.

Guest, там выше 2 проблемы, вот и скажи как ты бы их решал.
Насчет предупреждения - это типа "В вашем пароле есть пробел, не забудьте об этом в будущем". Не маразм?
Вот какой смысл нормальному юзеру использовать пробелы в хвостовиках? Для сложности пароля? Ну если он такой кулхацкер, то других что ли символов нет? Пароль, если он у тебя записан в файле, это что то такое на что посмотрел и видишь - это твой пароль. А пробелы в хвостовиках ты не видишь.
И это именно задача юзабилити - взаимодействия пользователя с системой.

_____________
There never was a struggle in the soul of a good man that was not hard
inpost
Guest
Ты ворд называешь галимым, потому что все им пользуются?
Представь себе, завтра ты проснёшься, и 99,9% пользователей зашли на твой сайт с ИЕ6. Твои действия? Подсказка: Настоящий веб-разработчик сверстает под ИЕ6 сайт, потому что он делает сайт для ПОСЕТИТЕЛЕЙ. Посетители > тебя. Посетители > клиента. Посетители > владельца. Посетители - приоритет №1 для любого вида услуг!

_____________
Обучаю веб-программированию качественно и не дорого: http://school-php.com
Фрилансер, принимаю заказы: PHP, JS, AS (видео-чаты). Писать в ЛС (Личные сообщения на phpforum).
twin
Michael
Цитата
По твоей схеме есть следующие недостатки людям:
1) регаться с паролем с хвостовыми пробелами запрещено например. Когда будут авторизироваться и будет пробел их будет не впускать, а они этот пробел не видят в поле ввода.
2) регаться с паролем с хвостовыми пробелами разрешено например. Если он зарегается с пробелом, по ошибке, при авторизации он может о нем и не знать.

1. Если запрещено, то на авторизации режь сколько хочешь. Или предупреждай - использованы недопустимые символы.
2. Для этого существует повтор пароля. Если юзеру и этого недостаточно - его проблема. Я же говорил - не прикрывайте этот ляп заботой о юзерах. Иначе можно далеко зайти. Начать исправлять за ним раскладку с помощью транслитерации, капслок исправлять на стороне сервера. А чего, те же рассуждения - удобство пользователя. А на безопасность плевать.

Что там гугл в своих недрах творит - на его совести. Может и хранят открытые пароли. И даже скорее всего. Больше скажу - они наверняка анализируют их. Потому что такие монстры как гугл не могут работать сами по себе, ЦРУ там как у себя дома. Повторю - можете мартышничать за ними. Не исключаю, что и твой хваленый друпал мартышничает. Однако у гугла свои задачи, нам не известные. А у рядового сайта задача другая. В первую очередь обезопасить себя от казусов. По этому нельзя хранить пароли в открытом виде. И неоднозначностей допускать нельзя. Пароль должен быть таким, каким его ввел юзер. Точка. Иначе себе дороже.

Цитата
Ну а что из кода не видно - обрезать пробелы по краям емейла (им там делать нечего). Если вдруг клиентский код этой функции этого не сделал, например при программном сохранении юзера.
Видно. Я спросил не что делает этот код, а его целесообразность. Зачем резать пробелы там, где их не может быть по определению. Тоесть в функции сохранения пользовательских данных. Если и резать, то в валидаторе, после которого такое поползновение становится совершенно излишним.
Цитата
тут ты походу не понял код. Из базы берется путь к файлу с возможно другой логикой хэширования. Отличный ход имхо, для безопасности.
Всё я понял. Это ты не понял.)) Расширение .inc для исполняемых файлов давно уже считается плохим тоном. Ибо это обычный текстовый файл, который легко читается браузером. При использовании такого расширения мы становимся заложниками наличия .htaccess, а это никак не повышает безопасность.

И вообще. Ты реально считаешь друпал вершиной мироздания?
Смотрим функцию генерации пароля, раз уж тут речь о нем:
function user_password($length = 10) {
// This variable contains the list of allowable characters for the
// password. Note that the number 0 and the letter 'O' have been
// removed to avoid confusion between the two. The same is true
// of 'I', 1, and 'l'.

$allowable_characters = 'abcdefghijkmnopqrstuvwxyzABCDEFGHJKLMNPQRSTUVWXYZ23456789';

// Zero-based count of characters in the allowable list:
$len = strlen($allowable_characters) - 1;

// Declare the password as a blank string.
$pass = '';

// Loop the number of times specified by $length.
for ($i = 0; $i < $length; $i++) {

// Each iteration, pick a random character from the
// allowable string and append it to the password:

$pass .= $allowable_characters[mt_rand(0, $len)];
}

return $pass;
}

Это писали 450 человек и несколько тысяч тестили в течении нескольких лет... А это я сейчас написал на коленке. Код в два раза короче, работает в три раза быстрее. Если пренебречь повторами, то еще короче окажется, но если делать, то аналог.
function user_password($length = 10) {
// This variable contains the list of allowable characters for the
// password. Note that the number 0 and the letter 'O' have been
// removed to avoid confusion between the two. The same is true
// of 'I', 1, and 'l'.

$allowable_characters = 'abcdefghijkmnopqrstuvwxyzABCDEFGHJKLMNPQRSTUVWXYZ23456789';

// Increases string for a possible repeat of characters
$increases_string = str_pad('', 171, $allowable_characters);

// Shuffles a string
$shuffled_string = str_shuffle($increases_string);

// Returns $lenght number of characters
return substr($shuffled_string, 0, $length);
}
Неужели ты серьёзно считаешь, что ничего там нельзя найти, чего можно было бы улучшить?

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

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

user posted image
Быстрый ответ:

 Графические смайлики |  Показывать подпись
Здесь расположена полная версия этой страницы.
Invision Power Board © 2001-2025 Invision Power Services, Inc.