информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Сетевые кракеры и правда о деле ЛевинаПортрет посетителя
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 С наступающим 
 Серьезная уязвимость в Apache Log4j 
 Крупный взлом GoDaddy 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / programming
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
ИМХО даже уменьшит стойкость 03.06.05 11:15  Число просмотров: 2034
Автор: Garick <Yuriy> Статус: Elderman
Отредактировано 03.06.05 11:20  Количество правок: 1
<"чистая" ссылка>
Допущение: алгоритм криптования и обрезания известен. Подбор возможен только брутефорс.
Обрезание хеша приведет к увеличению поверхности прошедших проверку паролей. А при полном использовании - есть только один пароль соответствующий хешу.
Те в первом случае будет несколько паролей которые пройдут проверку, во втором - только один.
<programming>
[Perl, PHP] Шифрование паролей 23.04.05 01:45  
Автор: n0xi0uzz <Черкасов Виктор> Статус: Member
<"чистая" ссылка>
Имеется: пароль пользователя; портальная система, которая пишется на PHP; форум, который пишется на Perl.
Требуется: найти способ шифрования паролей пользователей (в одностороннем порядке), чтобы результат шифрования одной и той же строки (пароля) был одинаков и в портальной системе (на PHP), и на форуме (на Perl) и записывался в одну и ту же базу данных.
Что подскажете?
[Perl, PHP] MD5? 23.04.05 02:21  
Автор: HandleX <Александр М.> Статус: The Elderman
<"чистая" ссылка>
А как же... 23.04.05 05:49  
Автор: n0xi0uzz <Черкасов Виктор> Статус: Member
<"чистая" ссылка>
Так ведь " Найден способ нахождения коллизии для MD5 за 8 часов на 1.6 GHz компьютере". Или этого можно не боятся?
В любом случае, можно ли выбрать алгоритм шифрования и, воспользововавшись средствами для работы с ним как Perl, так и PHP, шифровать пароли им (несилен в криптографии)?
Ну и что? 08.06.05 14:59  
Автор: KUV Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> Так ведь " Найден способ нахождения коллизии для MD5 за 8
> часов на 1.6 GHz компьютере". Или этого можно не боятся?
> В любом случае, можно ли выбрать алгоритм шифрования и,
> воспользововавшись средствами для работы с ним как Perl,
> так и PHP, шифровать пароли им (несилен в криптографии)?
Поиск коллизии - это поиск пары паролей с одинаковым хэшем, а не поиск пароля с таким же хэшем как данный. Так что если я дам вам хэш, то вам понадобится чтото порядка этих 8ми часов домножить на количество всех хэшей. Короче говоря много=)
И еще - если так уж хочется иметь 100% надежность, почему не использовать SHA1? Он более стойкий.
Можно. А в чём проблема-то? 23.04.05 12:13  
Автор: Heller <Heller> Статус: Elderman
<"чистая" ссылка>
Используешь на PHP и на Perl одну и ту же функцию и всё.
А насчёт коллизий в MD5 можно не беспокоиться - если память мне не изменяет, то она позволяет найти ещё один исходный текст по уже заданному исходному тексту, для которого хеш-функция будет выдавать то же значение. Так как изначально заданного значения нет, а есть только хеш, то беспокоиться не о чем. Хотя я могу и ошибаться - в подробности не вникал.
Всё, проблемы больше нет. Всем спасибо :). 24.04.05 01:44  
Автор: n0xi0uzz <Черкасов Виктор> Статус: Member
<"чистая" ссылка>
Решено шифровать в MD5 и обрезать несколько символов, - так вроде безопасно.
А зачем обрезать несколько символов? 24.04.05 13:01  
Автор: Heller <Heller> Статус: Elderman
<"чистая" ссылка>
Ну чтобы точно исключить вариант дешифровки ;). Или я... 03.06.05 10:17  
Автор: n0xi0uzz <Черкасов Виктор> Статус: Member
<"чистая" ссылка>
Ну чтобы точно исключить вариант дешифровки ;). Или я ошибаюсь?
ИМХО даже уменьшит стойкость 03.06.05 11:15  
Автор: Garick <Yuriy> Статус: Elderman
Отредактировано 03.06.05 11:20  Количество правок: 1
<"чистая" ссылка>
Допущение: алгоритм криптования и обрезания известен. Подбор возможен только брутефорс.
Обрезание хеша приведет к увеличению поверхности прошедших проверку паролей. А при полном использовании - есть только один пароль соответствующий хешу.
Те в первом случае будет несколько паролей которые пройдут проверку, во втором - только один.
Возможен ли вариант - при "обрезании" на 1 байт количество... 03.06.05 13:35  
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
<"чистая" ссылка>
> Допущение: алгоритм криптования и обрезания известен.
> Подбор возможен только брутефорс.
> Обрезание хеша приведет к увеличению поверхности прошедших
> проверку паролей. А при полном использовании - есть только

Возможен ли вариант - при "обрезании" на 1 байт количество паролей, которые пройдут проверку увеличится, скажем, в 256 раз, но 255 из них будут содержать символ, который невозможно ввести?

> один пароль соответствующий хешу.
> Те в первом случае будет несколько паролей которые пройдут
> проверку, во втором - только один.
Случай то возможен, но для его анализа необходимо досконально изучить алгоритм шифрования. 03.06.05 13:55  
Автор: Garick <Yuriy> Статус: Elderman
<"чистая" ссылка>
> Возможен ли вариант - при "обрезании" на 1 байт количество
> паролей, которые пройдут проверку увеличится, скажем, в 256
> раз, но 255 из них будут содержать символ, который
> невозможно ввести?
Если в алгоритме программы стоит проверка на допустимость символов - тогда "невозможно ввести", а так строке ввода можно скормить практически любой, даже не печатный, символ. Описание есть в инете.
Надежные криптоалгоритмы не подвержены статистическому анализу и определить какой набор символов в определенном знакоместе пароля выдаст одинаковые (хеш-1байт) последовательности тяжело. ИМХО проверять опять же брутефорсом.
В итоге проверка надежности/ненадежности решения по убиранию байт может стать невыполнимой.
1






Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2022 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach