Знакомый прошел регистрацию на сайте, но тем не менее письмо ему не пришло. Как узнать, прошла ли его регистрация? Может список участников можно где-нибудь посмотреть?
Недостатки тут разве что в сложности: хэширование на клиенте через JS, по 2 запроса и ответа от сервера (опять таки, время). А в целом, Вы описали логику аутентификации по Kerberos :)
Кстати, если у злоумышленника есть таки возможность перехватывать Ваши пакеты, то и salt1, md5(salt+password), salt2 он может перехватить. Да, тут встаёт вопрос, может ли он это после обработки дописывать в ответ серверу или, грубо говоря, полностью сэмитировать сессию (в Kerberos ещё помимо проверок паролей идёт шифрование по открытым ключам и выдача всяких посторонних значений для идентификации пользователей и их сессий — не буду подробно расписывать т. к. темы вопроса это не касается :) ).
Но зачем всё усложнять — передавайте пароль по https и никаких лишних ухищрений делать не придётся. Не панацея, конечно, но усложнять веб-системы подобным образом — не самый разумный подход, помоему :)
Я бы этому «упырю» всё таки написал письмо, что логотип Вашей компании следует убрать с сайта — только порочит репутацию. Безотносительно к чьему-либо сарказму.
Дополнения к комментарию по поводу сайта компании Blackbox
Раздел «Компания»: «В разделе «о компании» принято использовать умные слова. Например, «реализация бизнес-функций». Или «построение вертикально интегрированной компании». Или, например, «множество разнообразных кейсов». Полезно использовать сочетание «креативный подход».
Мы знаем много умных слов, но предпочитаем что-нибудь попроще.»
Аналогичный раздел на artlebedev: «У нас аллергия на словосочетания «креативное решение» и «оптимизация бизнес-процессов».»
Не надо мне рассказывать, что «уникальных форм в природе не существует»(с).
Что «Мы можем»:
— Продвигать сайт — оптимизация сайта, контекстная и медийная реклама.
— Поддерживать сайт — размещать тексты и фотографии, обновлять и дописывать программную часть.
Список, наверное, должен выглядеть единообразно, а не «оптимизация сайта» (существительное) — «размещать тексты» (глагол). Это не есть работа с текстом, а набросанный «на скорую руку» черновик.
www.promekbank.ru/ — вы там что-то недоверстали? А почему он уже в портфолио?
Если «покопаться», то расхождений между тем, что пишется и что делается, можно найти ещё больше…
И, кстати, добиться уникальности, копируя чужое позиционирование и не обеспечивая аналогичного качества — это, как минимум, глупо. А Вы здесь, вроде, претендуете на звание умного человека.
А по теме выступления приведу пример: на СПИК-2008 Ромуальд Здебский (Microsoft) успел описать почти весь функционал Expression Studio за то же время, что и Вы объясняли, почему же всё таки поисковики сосут.
PS
Захочется поаппелировать к опыту и возрасту — лучше в личку, я Вам хоть резюме пришлю.
Вполне логично. В *nix системах так пароли и хэшируются — смысл в том, что пропадает необходимость хранить соль и хэш — достаточно хранить только хэш. А вот с «дальше на перебор в процессор» уже вряд ли что-то выйдет — основа метода как раз таки в md5($salt.$pass).
Как я говорил в статье, для этой соли ещё нужно сгенерировать свою Rainbow-таблицу — а это дело неблагодарное :)
Как сказал мой хороший знакомый (кстати, человек к 21 году уже заколачивал по $6к в месяц, правда администрированием) — «Нужно не пиз… ть, а работать».
Я откровенно сомневаюсь, что человек которому «было не лень посидеть в гуглодоксе пару недель и набросать монументальный труд написанный сухим академическим языком»(с) не занимался первым в ущерб второму.
>«с приевшимися примерами с грушами, которые наследуют абстрактый класс фрукт и агрегируют в себе десятки других объектов класса косточка.» — это велосипед, не так ли? Так зачем на него было убивать пару недель?
А учиться можно (и нужно) на реальных проектах, и не убивать «по два-три часа в день, которые я нашел благодаря тому, что стал уделять меньше времени всему, что меня окружало — друзьям, любимым, музыке.», а по 8 часов и при работе с реальными проектами. А после работы — друзья, любимые и музыка.
Не убивайте своё время на штудирование литературы от именитых авторов — там больше 80% информации вам не нужно. Увидел недавно книжку по AJAXу на аж 500 с чем-то страниц. Вопрос: Как можно написать столько текста про XMLHttpRequest?
Работодателю нахрен не упала ходячая библиотека, от которой пышет снобизмом и чрезмерной крутизной. Ему нужен человек, который может хорошо и в срок сделать проект. И для этого горы книжек не нужны, а нужны элементарные знания фреймворков и их различий (+ знание недостатков того или иного фреймворка и грамотный выбор оного под конкретную задачу).
Используйте фреймворки (также рекомендую смотреть на релизы и бакгфиксы) и справочники по языкам — научитесь куда быстрее. Здравый смысл и логику тоже никто не отменял, но книжек по ним, к сожалению, нет.
Во-первых, на вход алгоритма md5 всегда поступают блоки по 512 бит т. е. поток всегда не битовый, а блочный.
Во-вторых, это свойство (hash(pass1+salt) == hash(pass2+salt) если hash(pass1) == hash(pass2)) относиться не к удлинению сообщения, а к коллизиям алгоритма md5 хэширования, а точнее — к способу их отыскания (т. е. по найденной одной коллизии мы можем найти ещё их неограниченное число) (Глава «Коллизия при частичном хэшировании сообщения»)
В-третьих (и по теме «удлинения сообщения»), как Вы заметили, удлинение сообщения действительно является большим недостатком функций хэширования. Но посмотрим с другой стороны, что же практически необходимо сделать, что бы воспользоваться этим недостатком. Суть проблемы удлинения сообщения заключается как раз в «потоковости» алгоритма т. е. что на n-ом шаге алгоритма хэширования получается хэш (n-1) предыдущих блоков сообщения. Что это означает в теории: мы имеем hash(pass), далее, мы можем получить hash(pass+salt), не пробегая весь алгоритм хэширования, а запустив его с момента, когда алгоритм уже «предвычислил» до hash(pass) и осталось лишь «довычислить» salt. Вот и всё, что даёт этот «недостаток». К тому же соль мы дописываем в начало сообщения, а не в конец. (если бы она дописывалась в конец, то да — зная соль можно перехватить исходный, «незасоленный», пароль и попытаться отыскать его (или коллизию) в Rainbow-таблицах).
Теперь вернёмся с небес на землю и от теории перейдём к практике. Авторы сами указывают на то, что для реализации данного недостатка необходима система аутентификации, при которой злоумышленник может дописывать в исходное сообщение свой текст. Но для того, что бы это реализовать в веб-проектах, необходимо сломать веб-сервер и перехватывать сообщения на уровне исполнения функции md5 в PHP. Но если уж дело дошло до взлома сервера и получения к нему неограниченного доступа (ну или хотя бы перехвата сервисных сообщений интерпретатора PHP), то тут вряд ли помогут какие-либо ухищрения в шифровании информации и дальнейшие изыскания становятся бессмысленными ;)
Hybrid Rainbow таблицы составляют слова, которые могут быть паролем не из отдельных символов (как в классических), а с помощью словарей, что позволяет сделать по объему почти такие же таблицы, но уже отыскивать пароле и более 8-ми символов. Понятно, что если соль будет состоять из полной белеберды, то и не один словарь её воспроизвести не сможет.
>такой «пароль» будет вычислять его хэш и сравнивать с тем что в базе, и естественно разницы не заметит
Стоп. Получив такой «пароль» он будет сравнивать хэш отпароля с солью (он же для проверки пароля пропустит его через тот же алгоритм «засолки») и результат получиться совсем не такой.
А вообще, даже зная соль, для неё необходима генерация своих rainbow-таблиц. Сейчас такие таблицы существуют для «чистого» md5 и паролей до 8-ми символов. Создайте соль хотя бы из 7-ми символов и найти конструкцию соль+пароль в современных Rainbow-таблицах будет невозможно. Даже если использовать Hybrid Rainbow таблицы то добавлением соли, состоящей из большого числа случайных символов, можно также свести на нет вероятность его отыскания.
Всё дело в коллизиях т.е. это когда при разных, поданных на вход алгоритма, данных получается один и тот же результат (в нашем случае — md5-хэш). Т.е. на самом деле вероятность того, что с помощью Rainbow-таблицы найдётся именно пароль с солью довольно не велика (хотя исключать её не стоит), а вот вероятность найти коллизию куда больше и полученный результат уже ничего не даст.
>в том же ВКонтакте пароли хранятся в открытом виде
Вот это очень интересно… И зачем они тогда в куки их md5-хэш пишут?
>есть sha1 и еще куча других хэшей.
Ага, и MySQL 64 и 160 битные. Только тут одна проблема — для них тоже существуют Rainbow-таблицы.
>не любыми, а только буквами a-f и цифрами 0-9
Простите великодушно — суть статьи не в том, что бы, разбрасываясь кучей терминов и подробностей, объяснять нормальные вещи. Если быть снобом и заниматься «распальцовокой» (простите, но другого не подобрал), то статья могла получиться нечитаемой. Поэтому здесь и не описывается ни способ генерации Rainbow-таблиц, ни отличия между симметричным и асимметричным шифрованием, ни оценка процессорного времени для того или иного алгоритма.
>скажите, а в каком направлении двигаться для этого хэша xMpCOKC5I4INzFCab3WEmw
Алгоритмов с 88 битным шифрованием, лично я не знаю.
Опять таки — проблемы юриспруденции. Составьте нормальный договор и срыв сроков вам оплатит эта самая типография (непредвиденные расходы по вине исполнителя — нормальный пункт почти в любом договоре). А вот сорви фрилансер сроки — ищи потом ветра в поле.
Я бы назвал статью «7 возможных плюсов, при работе с дизайнером-фрилансером». Как раз таки, при нормально написанном ТЗ и составленном договоре, работать с компанией куда более надёжно. Я не против фриланса, но и по-поводу компаний можно перечислить такие же 7 (или больше) причин заказывать дизайн именно у них.
Кстати, если у злоумышленника есть таки возможность перехватывать Ваши пакеты, то и salt1, md5(salt+password), salt2 он может перехватить. Да, тут встаёт вопрос, может ли он это после обработки дописывать в ответ серверу или, грубо говоря, полностью сэмитировать сессию (в Kerberos ещё помимо проверок паролей идёт шифрование по открытым ключам и выдача всяких посторонних значений для идентификации пользователей и их сессий — не буду подробно расписывать т. к. темы вопроса это не касается :) ).
Но зачем всё усложнять — передавайте пароль по https и никаких лишних ухищрений делать не придётся. Не панацея, конечно, но усложнять веб-системы подобным образом — не самый разумный подход, помоему :)
phone: +7 812 3361217
fax-no: +7 812 3361217
e-mail: art-work@mail.ru
Я бы этому «упырю» всё таки написал письмо, что логотип Вашей компании следует убрать с сайта — только порочит репутацию. Безотносительно к чьему-либо сарказму.
Раздел «Компания»:
«В разделе «о компании» принято использовать умные слова. Например, «реализация бизнес-функций». Или «построение вертикально интегрированной компании». Или, например, «множество разнообразных кейсов». Полезно использовать сочетание «креативный подход».
Мы знаем много умных слов, но предпочитаем что-нибудь попроще.»
Аналогичный раздел на artlebedev:
«У нас аллергия на словосочетания «креативное решение» и «оптимизация бизнес-процессов».»
Не надо мне рассказывать, что «уникальных форм в природе не существует»(с).
Что «Мы можем»:
— Продвигать сайт — оптимизация сайта, контекстная и медийная реклама.
— Поддерживать сайт — размещать тексты и фотографии, обновлять и дописывать программную часть.
Список, наверное, должен выглядеть единообразно, а не «оптимизация сайта» (существительное) — «размещать тексты» (глагол). Это не есть работа с текстом, а набросанный «на скорую руку» черновик.
www.promekbank.ru/ — вы там что-то недоверстали? А почему он уже в портфолио?
Если «покопаться», то расхождений между тем, что пишется и что делается, можно найти ещё больше…
И, кстати, добиться уникальности, копируя чужое позиционирование и не обеспечивая аналогичного качества — это, как минимум, глупо. А Вы здесь, вроде, претендуете на звание умного человека.
А по теме выступления приведу пример: на СПИК-2008 Ромуальд Здебский (Microsoft) успел описать почти весь функционал Expression Studio за то же время, что и Вы объясняли, почему же всё таки поисковики сосут.
PS
Захочется поаппелировать к опыту и возрасту — лучше в личку, я Вам хоть резюме пришлю.
Как я говорил в статье, для этой соли ещё нужно сгенерировать свою Rainbow-таблицу — а это дело неблагодарное :)
Я откровенно сомневаюсь, что человек которому «было не лень посидеть в гуглодоксе пару недель и набросать монументальный труд написанный сухим академическим языком»(с) не занимался первым в ущерб второму.
>«с приевшимися примерами с грушами, которые наследуют абстрактый класс фрукт и агрегируют в себе десятки других объектов класса косточка.» — это велосипед, не так ли? Так зачем на него было убивать пару недель?
А учиться можно (и нужно) на реальных проектах, и не убивать «по два-три часа в день, которые я нашел благодаря тому, что стал уделять меньше времени всему, что меня окружало — друзьям, любимым, музыке.», а по 8 часов и при работе с реальными проектами. А после работы — друзья, любимые и музыка.
Не убивайте своё время на штудирование литературы от именитых авторов — там больше 80% информации вам не нужно. Увидел недавно книжку по AJAXу на аж 500 с чем-то страниц. Вопрос: Как можно написать столько текста про XMLHttpRequest?
Работодателю нахрен не упала ходячая библиотека, от которой пышет снобизмом и чрезмерной крутизной. Ему нужен человек, который может хорошо и в срок сделать проект. И для этого горы книжек не нужны, а нужны элементарные знания фреймворков и их различий (+ знание недостатков того или иного фреймворка и грамотный выбор оного под конкретную задачу).
Используйте фреймворки (также рекомендую смотреть на релизы и бакгфиксы) и справочники по языкам — научитесь куда быстрее. Здравый смысл и логику тоже никто не отменял, но книжек по ним, к сожалению, нет.
Во-первых, на вход алгоритма md5 всегда поступают блоки по 512 бит т. е. поток всегда не битовый, а блочный.
Во-вторых, это свойство (hash(pass1+salt) == hash(pass2+salt) если hash(pass1) == hash(pass2)) относиться не к удлинению сообщения, а к коллизиям алгоритма md5 хэширования, а точнее — к способу их отыскания (т. е. по найденной одной коллизии мы можем найти ещё их неограниченное число) (Глава «Коллизия при частичном хэшировании сообщения»)
В-третьих (и по теме «удлинения сообщения»), как Вы заметили, удлинение сообщения действительно является большим недостатком функций хэширования. Но посмотрим с другой стороны, что же практически необходимо сделать, что бы воспользоваться этим недостатком. Суть проблемы удлинения сообщения заключается как раз в «потоковости» алгоритма т. е. что на n-ом шаге алгоритма хэширования получается хэш (n-1) предыдущих блоков сообщения. Что это означает в теории: мы имеем hash(pass), далее, мы можем получить hash(pass+salt), не пробегая весь алгоритм хэширования, а запустив его с момента, когда алгоритм уже «предвычислил» до hash(pass) и осталось лишь «довычислить» salt. Вот и всё, что даёт этот «недостаток». К тому же соль мы дописываем в начало сообщения, а не в конец. (если бы она дописывалась в конец, то да — зная соль можно перехватить исходный, «незасоленный», пароль и попытаться отыскать его (или коллизию) в Rainbow-таблицах).
Теперь вернёмся с небес на землю и от теории перейдём к практике. Авторы сами указывают на то, что для реализации данного недостатка необходима система аутентификации, при которой злоумышленник может дописывать в исходное сообщение свой текст. Но для того, что бы это реализовать в веб-проектах, необходимо сломать веб-сервер и перехватывать сообщения на уровне исполнения функции md5 в PHP. Но если уж дело дошло до взлома сервера и получения к нему неограниченного доступа (ну или хотя бы перехвата сервисных сообщений интерпретатора PHP), то тут вряд ли помогут какие-либо ухищрения в шифровании информации и дальнейшие изыскания становятся бессмысленными ;)
Стоп. Получив такой «пароль» он будет сравнивать хэш отпароля с солью (он же для проверки пароля пропустит его через тот же алгоритм «засолки») и результат получиться совсем не такой.
А вообще, даже зная соль, для неё необходима генерация своих rainbow-таблиц. Сейчас такие таблицы существуют для «чистого» md5 и паролей до 8-ми символов. Создайте соль хотя бы из 7-ми символов и найти конструкцию соль+пароль в современных Rainbow-таблицах будет невозможно. Даже если использовать Hybrid Rainbow таблицы то добавлением соли, состоящей из большого числа случайных символов, можно также свести на нет вероятность его отыскания.
Именно это и имелось в виду. Это классический алгоритм использования соли.
Вот это очень интересно… И зачем они тогда в куки их md5-хэш пишут?
>есть sha1 и еще куча других хэшей.
Ага, и MySQL 64 и 160 битные. Только тут одна проблема — для них тоже существуют Rainbow-таблицы.
>не любыми, а только буквами a-f и цифрами 0-9
Простите великодушно — суть статьи не в том, что бы, разбрасываясь кучей терминов и подробностей, объяснять нормальные вещи. Если быть снобом и заниматься «распальцовокой» (простите, но другого не подобрал), то статья могла получиться нечитаемой. Поэтому здесь и не описывается ни способ генерации Rainbow-таблиц, ни отличия между симметричным и асимметричным шифрованием, ни оценка процессорного времени для того или иного алгоритма.
>скажите, а в каком направлении двигаться для этого хэша xMpCOKC5I4INzFCab3WEmw
Алгоритмов с 88 битным шифрованием, лично я не знаю.