1.1, AnonuS (?), 23:23, 16/02/2013 [ответить] [﹢﹢﹢] [ · · · ]
| –3 +/– |
Интересно, кто предложит лучший вариант? Может россияне отличатся на этот раз.
| |
|
2.2, Онаним (?), 23:31, 16/02/2013 [^] [^^] [^^^] [ответить]
| –3 +/– |
Россияне уже отличалтсь, ГОСТ-овский (не помню номер) метод хэширования давно считается гораздо лучше MD5.
| |
|
3.7, Fufyrka (?), 01:01, 17/02/2013 [^] [^^] [^^^] [ответить]
| +4 +/– |
В сравнении с MD5 сейчас всё что угодно лучше =) Там и коллизий найдено. Там и либы построены для ломания на GPU. Думаю, можно надыбать даже пару сотен гигов таблиц =)
| |
|
2.3, BoVe (?), 23:35, 16/02/2013 [^] [^^] [^^^] [ответить]
| +/– |
> Может россияне отличатся на этот раз.
Даешь ГОСТ Р 34.11-2014
| |
2.26, фыфа (?), 13:48, 17/02/2013 [^] [^^] [^^^] [ответить]
| +2 +/– |
Вам не все равно из какой страны предложат лучший вариант?
| |
|
|
|
|
6.63, pilat (ok), 17:53, 19/02/2013 [^] [^^] [^^^] [ответить]
| +/– |
Мышление метрополита не может быть внутри- или забугорным ;-)
| |
|
|
|
|
|
|
|
3.48, Аноним (-), 11:58, 18/02/2013 [^] [^^] [^^^] [ответить]
| +/– |
википедии хватило чтобы понять что это не хеш-функции, а криптофункции.
| |
|
4.54, Мимо ракодил (?), 18:34, 18/02/2013 [^] [^^] [^^^] [ответить]
| +/– |
Ну, DES, какбэ, тоже не хэш, и ничего, столько лет использовали в UNIX'овом crypt() (сиречь, passwd) без всяких проблем.
| |
|
5.59, sdfsfsf (?), 21:08, 18/02/2013 [^] [^^] [^^^] [ответить]
| +/– |
Не надо путать "DES-блочный шифр" и "DES-хеш" на основе "DES-блочного шифра".
| |
|
6.64, Мимокрок (?), 21:01, 19/02/2013 [^] [^^] [^^^] [ответить]
| +/– |
ЕМНИП, из любого блочного шифра можно получить криптографическую хэш-функцию.
Правда не все будут качественными.
| |
|
|
|
|
|
1.8, Нанобот (?), 01:09, 17/02/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +6 +/– |
> Текущее состояние в области защиты паролей оценивается как неприемлемое - web-сервисы зачастую хранят пароли пользователей в открытом виде
они наверно думают, что как только разработают новые методы хеширования, все эти веб-сервисы волшебным способом перестанут использовать старые способы хранения паролей и начнут использовать новые
| |
|
2.25, x0r (??), 13:27, 17/02/2013 [^] [^^] [^^^] [ответить]
| +/– |
лечить такое наверно можно только предоставлением функционала из коробки в языке...
и бейсбольной битой по рукам...
| |
|
1.9, Аноним (-), 01:16, 17/02/2013 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
Откуда такая уверенность, что пароли для веб сервисов хранятся в открытом виде.
| |
|
2.10, AnonuS (?), 01:21, 17/02/2013 [^] [^^] [^^^] [ответить]
| +7 +/– |
А уверенность это основана на таком казалось бы пустяшном факте - как не умыкнут базу с паролями, так они все не зашифрованные :-)
| |
2.12, angra (ok), 01:27, 17/02/2013 [^] [^^] [^^^] [ответить]
| +4 +/– |
Практически во всех местах с регистрацией есть функция восстановления забытого пароля. Где-то при использовании данной возможности генерируют новый пароль, но многие сайты просто присылают старый. Как вы думаете, они его из при помощи сильного колдунства получают или все-таки хранят в открытом виде?
| |
|
3.14, Аноним (-), 02:29, 17/02/2013 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Практически во всех местах с регистрацией есть функция восстановления забытого пароля.
> Где-то при использовании данной возможности генерируют новый пароль, но многие сайты
> просто присылают старый. Как вы думаете, они его из при помощи
> сильного колдунства получают или все-таки хранят в открытом виде?
С таким же успехом, можно использовать самый хороший дверной замок, и при этом не закрывать его. Кто-то не использует шифрование паролей, но это же не говорит о том, что это, потому что алгоритм плахой.
| |
|
4.29, Аноним (-), 17:31, 17/02/2013 [^] [^^] [^^^] [ответить]
| +1 +/– |
плОхой.
если замок лежит на полочке, то закрывать его бессмысленно.
| |
|
3.15, Lain_13 (ok), 02:29, 17/02/2013 [^] [^^] [^^^] [ответить]
| +1 +/– |
Вообще лично я такое довольно редко видел. Обычно просят указать новый пароль.
| |
|
4.17, qqq (??), 02:49, 17/02/2013 [^] [^^] [^^^] [ответить]
| +/– |
Первое время на вконтактике высылали старый пароль на почту.
| |
|
5.18, Lain_13 (ok), 03:13, 17/02/2013 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Первое время на вконтактике высылали старый пароль на почту.
/me фейспальмирует
| |
|
6.28, ОоН (?), 16:23, 17/02/2013 [^] [^^] [^^^] [ответить]
| +/– |
Контактик помнит скомпрометироанные пароли, такая штука.
| |
|
7.30, Аноним (-), 17:33, 17/02/2013 [^] [^^] [^^^] [ответить]
| +/– |
> Контактик помнит скомпрометироанные пароли, такая штука.
может он помнит не пароли а хеши?
| |
|
|
|
|
3.32, Аноним (-), 19:14, 17/02/2013 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Практически во всех местах с регистрацией есть функция восстановления забытого пароля.
> Где-то при использовании данной возможности генерируют новый пароль, но многие сайты
> просто присылают старый. Как вы думаете, они его из при помощи
> сильного колдунства получают или все-таки хранят в открытом виде?
Ну не совсем в открытом. Это же не файловое хранилище одного известного отечественного сервиса. Хранится, вернее всего, в базе данных MySQL, в зашифрованном виде, причем к базе доступ есть только с localhost. Забраться не так уж легко.
| |
|
|
1.11, torvn77 (ok), 01:24, 17/02/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
>>технических требований к выставляемым на конкурс работам отмечается как минимум поддержка хэширования паролей размером от 0 до 128 символов
Это уже не пароль слово.а пароль фраза подобрать которую будет гораздо проще.
Пора делать массовое внедрение смарткарт или в качестве костыля выпустить стандарт на флешку,на которой будет хранится пароль.
Шифровать флешку целиком или только файл с паролем не знаю.
| |
|
|
3.16, Аноним (-), 02:34, 17/02/2013 [^] [^^] [^^^] [ответить]
| –2 +/– |
> etoken, rutoken и прочие....
Верно, говорите, есть веб сервисы, которые вообще по отпечатку пальца работают, и давно забыли уже о паролях. Пару лет назад на фоне этого даже к нотбукам прилепляли сканеры отпечатков. Сразу сканер шел от производителя, бук не работал без отпечатка, Этим же сканером можно было пользоваться и в других сервисах.
| |
|
4.23, Аноним (-), 11:51, 17/02/2013 [^] [^^] [^^^] [ответить]
| +2 +/– |
И как это поможет для web? В чем разница хранить пароль или скан отпечатка пальца?
| |
4.57, Michael Shigorin (ok), 19:36, 18/02/2013 [^] [^^] [^^^] [ответить]
| +/– |
> Пару лет назад на фоне этого даже к нотбукам прилепляли сканеры отпечатков.
Ах вот оно что, а я-то думал, что это для аутентификации юзера непосредственно на буке (ну или где там сложили образцовые отпечатки при тренировке, помимо полированной мебели).
Но теперь мы с двумя thinkpad'ами будем знать, что они на самом деле без fprintd не работали.
| |
|
3.46, 4ertus2 (ok), 11:37, 18/02/2013 [^] [^^] [^^^] [ответить]
| +/– |
Скачивал я как-то SDK для etoken-ов. Там вместо метровой библиотечки и пары примеров - гигабайта полтора какого-то неструктурированного непортируемого хлама, в котором можно закопаться на месяц. Пол дня посмотрел и плюнул. Не хотят они, чтобы их использовали.
| |
|
|
1.19, fi (ok), 04:03, 17/02/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
а вот интересно, появится ли алгоритм с челенжом где на сервере не будет храниться пароль открытым текстом? Например, как это делается в несимметричном ключе.
| |
1.22, exn (??), 11:02, 17/02/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
А почему такая уверенность что кто-то что-то вообще пришлет ?
| |
1.24, Аноним (-), 12:34, 17/02/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
>трудность распараллеливания подбора
Это вообще как?
Что мешает пробовать пароли на букву А на одной машине, на Б на другой? Операция подбора параллельна сама по себе.
| |
|
2.33, Аноним (-), 19:18, 17/02/2013 [^] [^^] [^^^] [ответить]
| –2 +/– |
>>трудность распараллеливания подбора
> Это вообще как?
> Что мешает пробовать пароли на букву А на одной машине, на Б
> на другой? Операция подбора параллельна сама по себе
ну можно тайм-аут сделать минут 15 после неправильного ввода пароля. Неудобство для пользователя, конечно, но, во-первых, это стимулирует использование утилит - связок ключей, а, во-вторых, пользователь раз посидит минут 15, потом более внимательным будет.
| |
|
3.34, Аноним (-), 20:20, 17/02/2013 [^] [^^] [^^^] [ответить]
| +1 +/– |
> а, во-вторых, пользователь раз посидит минут 15, потом более внимательным будет
Скорее поменяет пароль на трехбуквенный, в котором не ошибешься
| |
3.39, KT315 (ok), 23:12, 17/02/2013 [^] [^^] [^^^] [ответить]
| +/– |
Ага-ага, застопорит разработку брутфорс-механизма в лучшем случае на 10 минут.
Система должна быть открытой, а значит легко будет отследить func(delay) и остается стащить хеш или подменить уже модифицированный бинарник c delay = 0;
| |
3.45, другой аноним (?), 11:07, 18/02/2013 [^] [^^] [^^^] [ответить]
| +/– |
не путайте специфику работы алгоритма и системы, которая использует этот алгоритм нужным ей образом.
под подбором в данном случае понимается просто подбор данных под известный злоумышленнику хэш (локально), а не обращение к какой-то удаленной системе, которая проверяет пароли и в случае неправильности блокирует систему. Зачем, имея на руках хэши, перебирать пароли на удаленной системе? Ведь конкурс заявлен просто на алгоритм, а не какой-нибудь сервер а-ля керберос или библиотеки PAM-аутентификации. Аутентификационные сервисы, конечно, могут придумывать разные приемчики типа таймаутов и блокировок, уровни сложности паролей или расписания, когда пользователь может работать в системе, но это не имеет никакого отношения к алгоритмам хэширования (приемчикам манипулирования с массивами байт). Хэширование не имеет никакого отношения к протоколам взаимодействия программных комплексов, это протоколы в своей работе на разных этапах могут использовать алгоритмы хэширования.
| |
|
|
1.35, Аноним (-), 21:37, 17/02/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Лучше бы придумали надежного приемника MSCHAPv2, т.е. когда пароль в базе хранится в виде хеша и пароль с клиента для проверки передается в виде другого посоленого хеша, а соль генерирует сам сервер. За это люди реально скажут *огромное* спасибо и с радостью включат в будущие стандарты.
http://deployingradius.com/documents/protocols/compatibility.html - Табличка, демонстрирующая проблему на примере радиуса и WPA-Enterprise (хотя можно тоже самое нарисать и для SMTP AUTH, IMAP4, etc, etc):
В целом впечатления от новости -- обострение NIH-синдрома.
| |
|
2.36, XPEH (?), 21:59, 17/02/2013 [^] [^^] [^^^] [ответить]
| +/– |
> когда пароль в базе хранится в виде хеша и пароль с клиента для проверки передается в виде другого посоленого хеша, а соль генерирует сам сервер
Вы из анабиоза восстали что-ли ? Вашим условиям даже древний CRAM-MD5 удовлетворяет.
| |
|
3.37, Аноним (-), 22:32, 17/02/2013 [^] [^^] [^^^] [ответить]
| +/– |
Бред сивой кобылы.
CRAM-MD5 -- это тот дырявый алгоритм, который или требует plaintext пароля на сервере, или же промежуточный md5-хеш в базе + специально модифицированный сервер, который пользуется этим промежуточных хешем. В результате, угон или пароля или его хеша позволяет успешно проходить CRAM-MD5 аутентификацию.
Следующий!
| |
|
4.47, XPEH (?), 11:52, 18/02/2013 [^] [^^] [^^^] [ответить]
| +1 +/– |
А ничего что угон NTLM хеша, используемого в вашем любимом MSCHAPv2, приводит ровно к тому же результату ?
Не говоря уже о том что NTLM хеш сам по себе ископаемое убожество.
| |
|
|
2.56, Мимо ракодил (?), 18:47, 18/02/2013 [^] [^^] [^^^] [ответить]
| +/– |
> Лучше бы придумали надежного приемника MSCHAPv2
Да придумано все, и очень давно. EAP-TLS, пароли не нужны.
Только заставьте теперь дедушку Ляо это в роутеры запихать.
| |
|
1.38, KT315 (ok), 23:09, 17/02/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
Боюсь показаться КЭПом, но конкурс направлен на реализацию системы управления ключами. ИМХО, недавно завершился конкурс хеш-функции на звание SHA-3 и есть достаточно хорошие twofish, aes, serpent блочные шифры.
Нужен лишь механизм, как эти управлять (правильно организовать генерацию соли, правильный механизм раздутия области хранения инфы, учитывать тип носителя информации и тому подобное) ;-)
PS: на языке оригинала, как-то все прозрачней и понятней о чем речь, чем перевод.
| |
1.40, ILYA INDIGO (ok), 23:49, 17/02/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
>...такие как MD5 или SHA-1...
Почему все всегда говоря о хэшировании паролей упоминают сразу эти алгоритмы, принимая их за эталонные. и вываливают их недостатки?
Про sha512 никто не слышал что ли?
| |
1.44, Аноним (-), 10:22, 18/02/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
А в чем плох метод хранения с солью хэша SHA-2, полученного на основе хэша SHA-2 от пароля ? Словарный перебор как понимаю исключается, а на полный перебор несколько лет понадобится. Или есть какой-то подвох и современные GPU позволяют свести время такого перебора до дней/месяцев ?
| |
|
2.60, sdfsfsf (?), 21:37, 18/02/2013 [^] [^^] [^^^] [ответить]
| +2 +/– |
С чего это вдруг словарный перебор исключается?! Не исключается он. Это первое.
Второе. Солёный sha2 - это, конечно, хорошо, Но:
Конкурс направлен не столько на разработку хеш-функции, сколько на систему, использующую в основе хеш-функцию, и предназначенную для безопасного хранения паролей.
И эта система должна обеспечивать: применимость к данным довольно большого развмера (до 128 байт), использование соли с большой энтропией, желательно опциональное использование local-parameter (как вторая "соль"), уникального, например для сервера. Очень хотелось бы, что б функция не была сильно эффективна на gpu, fpga etc - для того, что б заведомо не давать атакующему фору (а тот же sha2 двольно быстр на gpu).
Также требуется возможность тюнинга - настраиваемное "CPU-hardness" (например через число раундов стретчинга, хотя, возможно, есть и другие варианты), "memory-hardness" (если используется). Кроме того, неплохо было бы обеспечить регулирование последних двух для уже посчитанных хешей, не зная при этом паролей.
Разумеется, нужно придумать удобный формат представления таких хешей, обеспечив портабельность и однозначность ...
И это далеко не всё, что требуется.
Исходя из всего этого, мне что-то не кажется, что удачные схемы для целей храниения паролей в данный момент существуют.
Что-то коммент в сторону ушёл, ну да ладно.
| |
|
|