Дополнения к комментарию по поводу сайта компании 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 (или больше) причин заказывать дизайн именно у них.
н-да, с демократией на хабре явные проблемы… А если необходимо разжевывать, что изобретение велосипеда — вещь неблагодарная, то уж простите великодушно… Ставить Хром потому, что это «модно» или потому, что он на сотые доли секунды быстрее обрабатывает HTTP и JS — это, простите, сродни паранойе. Лучше бы web-сервер свой выпустили, пошустрее nginx или Apache. А с точки зрения расширений — Firefox пока вне конкуренции. Это всё моё личное мнение, поэтому минусовать не обязательно — каков вопрос, таков и ответ.
Дока, слегка раскрывающая суть нейронных сетей в применении к морфологическому анализу (забыл поставить (с) при вставке текста — там он очень кратко и чётко написано, а своими словами я бы тут долго размусоливал :))
Если совсем интересно — на вики про сеть Кохонена неплохо написано.
Это так называемые «стоп-слова», которые отбрасываются при частотном анализе. Основываясь на результаты частотного анализа, строится нейронная сеть Кохонена, которая, собственно, и проводит кластеризацию ресурсов. Это научное определение, а по-сути, для рамок российской морфологии, достаточно составить просто массив предлогов, а не строить нейронные сети, рассчитаные на неуправляемое обучение.
Возможно они не не верят, а просто не знают как устраивается полнотекстовый поиск во многих БД… Именно отбрасыванием предлогов, союзов, кавычек и прочих рудиментов.
Раздел «Компания»:
«В разделе «о компании» принято использовать умные слова. Например, «реализация бизнес-функций». Или «построение вертикально интегрированной компании». Или, например, «множество разнообразных кейсов». Полезно использовать сочетание «креативный подход».
Мы знаем много умных слов, но предпочитаем что-нибудь попроще.»
Аналогичный раздел на 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 битным шифрованием, лично я не знаю.
Если совсем интересно — на вики про сеть Кохонена неплохо написано.