Comments 66
Довольно неплохой способ передачи пароля. А вы смотрели что используется в стандартной поставке форумного движка IPB? Там что-то подобное
Нет, не видел, посмотрю обязательно теперь.
Посмотрел этот форум, ничего похожего там нет, пароль передается открыто. Похоже что для хранения пароля используется избыточное хеширование, хотя сложно код исследовать, он размазан по множеству файлов.
Я бы не советовал использовать этот форум, если там пишут так:
Я бы не советовал использовать этот форум, если там пишут так:
"m.members_l_username='". $username ."', или так: members_l_username LIKE '{$this->ipsclass->input['name']}%', то за безопасность данных нельзя поручиться, это же вероятная возможность SQL-инъекции, не стал тратить время на анализ защищают ли данные в $username, при таком подходе к коду, всех дыр не закрыть никогда.
если есть возможность перехватить трафф, то можно и сессию перехватить (подставить в запрос ид сессии), вас конечно спасет, то что ваши ключи завязаны на ip, но я не понял зачем такие сложности. Ведь можно просто передавать пароль в зашифрованном виде + в сессии хранить ip адрес, который проверять при старте сессии.
Здесь усложняется еще и тем, что файл могут прочитать нежелательные личности, и надо устранить в том числе и возможность подключения в случае если злоумышленнику известны и хеши пароля.
если траф слушают в корпоративной сети за NAT, то и IP будет одинаковый
ненавижу принудительную проверку по ip — с моим провайдером просто ужас! :(
>>Здесь усложняется еще и тем, что файл могут прочитать нежелательные личности
какой файл?
какой файл?
С исходным текстом, в моем проекте будет один PHP файл, в котором будет храниться хеш пароля пользователя. Надо чтобы было невозможно использовать данные из этого файла для подключения к этому или другому серверу (где будет такой же файл). И еще надо работать по незащищенным каналам связи, где трафик могут свободно читать.
UFO just landed and posted this here
Именно так, но у меня такой вот проект, без JS не может работать. Хотя здесь можно пойти на компромис, и дописать на сервере клиентскую часть, тогда клиенты без JS будут авторизоваться, но при этом их пароль пройдет по сети.
UFO just landed and posted this here
К примеру, если пароль не 40 символов, то значит он скорее всего не был зашифрован на клиенте, и пишем процедуру клиентского хеширования на сервере перед сравнением.
Для большинства случаев это не важно, ну подумаешь, пароль одноклассников увидит сосед по сетке. Но есть скрипты посерьезнее одноклассников. Конечно лучше заходить через https протокол, но не всегда он может быть доступен. У меня проект такой, что будут скрипт ставить в совершенно разные места, где SSL просто не будет настроено, и использовать его будут в разных сетях, допустим в гостиничной.
А смысл моего кода в том, что не зная настоящего пароля, нельзя будет пройти авторизацию. Разве что только методом перебора подберут пароль, или используют кейлогер на компьютере, где вводится пароль.
Для большинства случаев это не важно, ну подумаешь, пароль одноклассников увидит сосед по сетке. Но есть скрипты посерьезнее одноклассников. Конечно лучше заходить через https протокол, но не всегда он может быть доступен. У меня проект такой, что будут скрипт ставить в совершенно разные места, где SSL просто не будет настроено, и использовать его будут в разных сетях, допустим в гостиничной.
А смысл моего кода в том, что не зная настоящего пароля, нельзя будет пройти авторизацию. Разве что только методом перебора подберут пароль, или используют кейлогер на компьютере, где вводится пароль.
если сайт того стоит то стоит :)
Почему не может быть? Если нет JS, то логин-пароль уйдут в явном виде (тут мы теряем секьюрность…), после чего ничто не мешает отловить этот факт на сервере и провести те же самые вычисления (…но не теряем функциональность).
На что только люди не идут, лишь бы не использовать готовые решения :)
Чем SSL-то не угодил?
Чем SSL-то не угодил?
Поясните пожалуйста, каким образом вот это:
Для защиты от перехваченного трафика, с формой авторизации передается хеш, сформированный на основе random данных, IP адреса, и обратного хеша на основе логин-пароль: hash1 = sha1_hmac(password, login); key = sha1(hash1, random_key+remote_addr). Случайно сформированный ключ для хеширования хранится в сессии.
защищает от перехваченного трафика? Ведь идентификатор сессии также пересылается по сети и может быть перехвачен.
Для защиты от перехваченного трафика, с формой авторизации передается хеш, сформированный на основе random данных, IP адреса, и обратного хеша на основе логин-пароль: hash1 = sha1_hmac(password, login); key = sha1(hash1, random_key+remote_addr). Случайно сформированный ключ для хеширования хранится в сессии.
защищает от перехваченного трафика? Ведь идентификатор сессии также пересылается по сети и может быть перехвачен.
Вместо самого пароля передается хеш hash2 = sha1_hmac(login, password), однако на сервере хранится не он, а его хеш с логином: sha1_hmac(hash2, login). Этим отсекаем возможность залогиниться, если кто-то украл захешированные данные с сервера, например, взяли из базы данных, или прочитали php файл, если хеш данные находятся в нем, как в примере ниже.
…
В файле храним два хеша на основе логина и пароля, один обратный sha1_hmac(pass, login), и один прямой двойной sha1_hmac(sha1_hmac(login, pass), login).
Так один хеш на сервере хранится или два? Судя по всему, таки два. С чего Вы тогда взяли, что укравший данные с сервера не сможет залогиниться? В чем проблема сгенерить Ваш $key, используя хеши?
Вообще, нельзя, используя shared secret авторизацию, защититься одновременно от компрометации одной из сторон (кражи с сервера) и возможности внедрения злоумышленника в трафик. Тут нужно ассиметричное шифрование.
Используется два, один на основе пароль+логин, другой двойной, на основе (логин+пароль)+логин. Один используется для защиты от перехвата (чтения) трафика, другой для защиты от воровства хешей. С помощью одного хеша у меня не получилось решить обе задачи. Хеш логин+пароль не известен, поэтому зная (логин+пароль)+логин, нельзя сформировать его.
Получается именно так, только перехватив и трафик (узнаем хеш логин+пароль), и узнав хеши (одновременно оба условия должно быть выполнено), можно подключиться, не зная пароль.
Получается именно так, только перехватив и трафик (узнаем хеш логин+пароль), и узнав хеши (одновременно оба условия должно быть выполнено), можно подключиться, не зная пароль.
По большому счёту, вся ваша защита сводится к этому:
$_SESSION['remote_addr'] === $_SERVER['REMOTE_ADDR']
Если злоумышленник имеет внешний IP такой же, как и жертва и возможность перехвата трафика (а второе, кстати, обычно подразумевает возможность первого), то он легко получает все ваши «секретные» данные.
Если Вы в качестве упражнения хотите написать свою собственную систему шифрования (а не использование HTTPS я могу объяснить только академическим интересом), то лучше реализовать на связке Javascript-PHP что-нибудь уже изобретенное человечеством, например, обмен ключами или что-то более экзотическое, типа алгоритма Диффи-Хэллмана.
$_SESSION['remote_addr'] === $_SERVER['REMOTE_ADDR']
Если злоумышленник имеет внешний IP такой же, как и жертва и возможность перехвата трафика (а второе, кстати, обычно подразумевает возможность первого), то он легко получает все ваши «секретные» данные.
Если Вы в качестве упражнения хотите написать свою собственную систему шифрования (а не использование HTTPS я могу объяснить только академическим интересом), то лучше реализовать на связке Javascript-PHP что-нибудь уже изобретенное человечеством, например, обмен ключами или что-то более экзотическое, типа алгоритма Диффи-Хэллмана.
Не совсем, еще пароль ему не достается. Это самое важное для моего проекта, пускай читают трафик, главное чтобы не могли подключиться сами. Если злоумышленник имеет тот же IP, то после установления соединения он может подключиться. Это минус, пока не знаю как это обойти программным простым способом.
Ага, у меня тоже сразу про SSL / HTTPS возникла.
Неужели есть серьезная объективная причина делать что-то своё?
Ведь атаку Men-in-the-middle никто не отменял, так не легче ли использовать SSL-сертификат уважаемой конторы (типа Verisign), купленный недорого? Ведь на этапе передачи самого первого, нешифрованного ключа такая PKI-схема решает проблему подмены, соответственно рушит всю цепочку подмен, которая вполне вероятна в вашем случае.
Неужели есть серьезная объективная причина делать что-то своё?
Ведь атаку Men-in-the-middle никто не отменял, так не легче ли использовать SSL-сертификат уважаемой конторы (типа Verisign), купленный недорого? Ведь на этапе передачи самого первого, нешифрованного ключа такая PKI-схема решает проблему подмены, соответственно рушит всю цепочку подмен, которая вполне вероятна в вашем случае.
Я так понял, что javascript-овый вариант hex_hmac_sha1(a, b) эквивалентен PHP-шному hash_hmac('sha1', b, a), то есть аргументы a и b переставлены местами. Тогда я могу доказать, что ваша система не защищена в поставленных вами условиях.
Именно так, аргументы в обратном порядке. Докажите мне это, я буду только рад (пока еще этот код не используется в реальном проекте).
Будем оперировать тем порядком аргументов, который идёт в PHP. Обозначим hash_hmac('sha1', a, b) как s(a, b) для краткости. Ещё: L — login, P — password, KR = random_key+remote_addr.
На сервере в файле лежат:
s(P, L)
s(s(L, P), L)
С клиента на сервер передаются:
s(KR, s(P, L))
s(L, P)
Зная первый хеш, можно в любое время вычислить клиентский key, а зная последний хеш (подсмотрев при передаче), можно его без изменений использовать в дальнейшем как клиентский password. Готово.
На сервере в файле лежат:
s(P, L)
s(s(L, P), L)
С клиента на сервер передаются:
s(KR, s(P, L))
s(L, P)
Зная первый хеш, можно в любое время вычислить клиентский key, а зная последний хеш (подсмотрев при передаче), можно его без изменений использовать в дальнейшем как клиентский password. Готово.
Для этого надо и трафик посмотреть во время авторизации, и получить содержимое серверных хешей одновременно. Да, такое допускаю. По отдельности получается что защищено. То есть, получив хеши, не подключишься, прочитав трафик не подключишься.
Еще тут намекают на незащищенность самой сессии, я ее только по IP защищаю, а у злоумышленника может быть такой же IP, надо подумать как тут можно поступить.
Еще тут намекают на незащищенность самой сессии, я ее только по IP защищаю, а у злоумышленника может быть такой же IP, надо подумать как тут можно поступить.
Мне кажется, лучше использовать решения на базе SSL, ну или VPN организовать.
Если это использовать, то все мои ухищрения не нужны совершенно, задача в другом, возможно использование при отсутствии SSL. Нужно обязательно сохранить пароль, и избежать несанкционированного запуска защищенной части скрипта. Представьте что это админка сайта, только пароль хранится в скрипте. Чаще всего админки сайтов передают пароль открыто, а это не правильно. Если нет возможности шифровать канал, так хоть можно шифровать сам пароль. Ну и плюс, я могу предположить, что хеши украдут, надо тоже противодействовать этому.
ну вот смотрите, если я в корпоративной сети за NAT, слушаю трафик, затем осуществляю атаку man-in-the-middle с полученными хэшами и тем же IP — тогда что?
а чаще всего трафик снифают именно в общей сетке.
а чаще всего трафик снифают именно в общей сетке.
От этой атаки не защищено. Таким образом можно все не защищенные сертификатами сайты атаковать.
Вот здесь kitchen.microolap.com/articles/http-auth расписано почти то же самое, только немного подробнее и с хранением хеша пароля в СУБД.
Там решается только одна часть задачи, если злоумышленник сможет достать из базы данных хеш пароля, то он сможет залогиниться на сайте.
К тому же не советую хранить хеш без соли, такой пароль можно будет искать в базах данных хешей. Если посолить хотя бы логином, такого рода поиск уже будет бессмысленным, даже если пароль простой.
К тому же не советую хранить хеш без соли, такой пароль можно будет искать в базах данных хешей. Если посолить хотя бы логином, такого рода поиск уже будет бессмысленным, даже если пароль простой.
OMG! О_О
А javascript PGP вас не спасет?
А javascript PGP вас не спасет?
Решение сырое совершенно:
Цитата
Далее
Цитата
в комплекте отсутствует один из файлов *.js, что делает комплект неработоспособным
Далее
Он нормально зашифровывает сообщения, написанные латиницей. Корёжит лишь русскоязычный текст. При этом для нескольких первых символов явно угадывается побитовое смещение, а дальше уже начинается ахинея. Вероятно, там проблемы с 8-м битом.
Эх, если бы кто-то взялся доработать алгоритм...
Объясните мне однако.
Уже не первый раз, вижу подобную бредятину.
Обычный подход.
Клиент -> POST -> (Допустим злоумышленник здесь (MIM)) -> Сервер (точка авторизации, к примеру поиск sha1($_REQUEST['Password'])) в базе.
Подход с клиентским хешированием.
Клиент -> Хеширование JS -> POST -> (Допустим злоумышленник здесь (MIM)) -> Сервер (точка авторизации, к примеру поиск $_REQUEST['HashedPassword']) в базе.
Что мешает catch — and -replay ваш запрос?
И вы думаете, брутфорс — стойкость sha1 хеша выше обычной алфавитноцифровой комбинации?
Это не безопасность, это саботаж.
Потуги на соль, вообще в расчёт брать не буду — если есть MIM, то ваш рандомный супер ключ уже у Кэрол.
Вы бы еще sha1(sha1(sha1($Password))) написали.
Уже не первый раз, вижу подобную бредятину.
Обычный подход.
Клиент -> POST -> (Допустим злоумышленник здесь (MIM)) -> Сервер (точка авторизации, к примеру поиск sha1($_REQUEST['Password'])) в базе.
Подход с клиентским хешированием.
Клиент -> Хеширование JS -> POST -> (Допустим злоумышленник здесь (MIM)) -> Сервер (точка авторизации, к примеру поиск $_REQUEST['HashedPassword']) в базе.
Что мешает catch — and -replay ваш запрос?
И вы думаете, брутфорс — стойкость sha1 хеша выше обычной алфавитноцифровой комбинации?
Это не безопасность, это саботаж.
Потуги на соль, вообще в расчёт брать не буду — если есть MIM, то ваш рандомный супер ключ уже у Кэрол.
Вы бы еще sha1(sha1(sha1($Password))) написали.
Двойное хеширование не против брутфорса сделано, и не для запутывания алгоритма, а лишь с целью невозможности подключения при потере хеша (когда его смогли достать из базы или файла). Передается одинарный хеш, а хранится двойной, те кто узнали двойной, не могут вычислить одинарный.
Соль здесь тоже применяется не только для того, чтобы усилить пароль, но и для формирования двух хешей, первый для защиты от открытой передачи данных, второй от тех, кто узнает хеши. К тому же, соль нужна по-любому, ведь поиск по базе хешей быстрее перебора.
Соль здесь тоже применяется не только для того, чтобы усилить пароль, но и для формирования двух хешей, первый для защиты от открытой передачи данных, второй от тех, кто узнает хеши. К тому же, соль нужна по-любому, ведь поиск по базе хешей быстрее перебора.
Процитирую себя.
«И вы думаете, брутфорс — стойкость sha1 хеша, выше обычной алфавитноцифровой комбинации?»
Тут не видно неприкрытого сарказма???
Двойным хешированием, вы натянули собственную безопасность. 1 курсе ЗИ в любом порядочном универе.
У второго хеша, пространство открытых текстов равно пространству закрытых первого.
Помимо того, что вы увеличили сложность на… нисколько. 2*O операций. Всё.
"(когда его смогли достать из базы или файла)." — если вы просрали доступ к базе или файлу с паролями, ваши хеши ничем никому не помогут. Пароль — аутентификатор для доступа к информации. Просрали пароль — просрали информацию.
Соль ваша — херня на постном масле, если она передаётся на клиента.
Shared Secret? По untrusted channel? Кэрол в восторге, а Алиса и Боб плачут.
Изучайте матчасть и если уж хочется безопасности — копайте в сторону гетерогенной многофакторной аутентификации.
Напишите в приват, могу скинуть ссылку на систему с примером такой аутентификации.
«И вы думаете, брутфорс — стойкость sha1 хеша, выше обычной алфавитноцифровой комбинации?»
Тут не видно неприкрытого сарказма???
Двойным хешированием, вы натянули собственную безопасность. 1 курсе ЗИ в любом порядочном универе.
У второго хеша, пространство открытых текстов равно пространству закрытых первого.
Помимо того, что вы увеличили сложность на… нисколько. 2*O операций. Всё.
"(когда его смогли достать из базы или файла)." — если вы просрали доступ к базе или файлу с паролями, ваши хеши ничем никому не помогут. Пароль — аутентификатор для доступа к информации. Просрали пароль — просрали информацию.
Соль ваша — херня на постном масле, если она передаётся на клиента.
Shared Secret? По untrusted channel? Кэрол в восторге, а Алиса и Боб плачут.
Изучайте матчасть и если уж хочется безопасности — копайте в сторону гетерогенной многофакторной аутентификации.
Напишите в приват, могу скинуть ссылку на систему с примером такой аутентификации.
Повторяю, двойное хеширование используется совершенно для других целей:
При авторизации передается одинарный хеш:
Другой хеш
У меня такая специфика задачи, что
Ссылка на пример защищенной аутентификации не помешает.
При авторизации передается одинарный хеш:
hash21 = sha1_hmac(login, password). На сервере же хранится хеш hash22 = sha1_hmac(hash21, login). Сможете вычислить hash21, зная только hash22 и login?Другой хеш
hash1 = sha1_hmac(password, login) хранится для других целей, и этот хеш отличается от hash21 и hash22.У меня такая специфика задачи, что
hash1 и hash22 вполне можно потерять, если бы они были недоступны никому, я бы не парился с hash1. Сам пароль не теряется при краже хешей, и злоумышленник остается без hash21, который нужен для авторизации. Докажите мне, что зная login, hash1, hash22 можно вычислить или password, или хотя бы hash21. hash1 используется не для случая кражи хешей, а как ключ для хеширования при передаче данных по небезопасным каналам связи. Одновременная кража хешей и подсмотр трафика позволяет авторизоваться, хотя при этом не выявляет пароль.Ссылка на пример защищенной аутентификации не помешает.
«Сможете вычислить hash21, зная только hash22 и login?»
Даже пытаться не буду. Зачем, если — «Одновременная кража хешей и подсмотр трафика позволяет авторизоваться, хотя при этом не выявляет пароль.»
Хэш от хэша — энтропию в топку, как вы не понимаете.
В вашем случае, как минимум hash22 — слабый.
И кстати — названия переменных — ужасные.
Ссылку скину вечером в личку.
Даже пытаться не буду. Зачем, если — «Одновременная кража хешей и подсмотр трафика позволяет авторизоваться, хотя при этом не выявляет пароль.»
Хэш от хэша — энтропию в топку, как вы не понимаете.
В вашем случае, как минимум hash22 — слабый.
И кстати — названия переменных — ужасные.
Ссылку скину вечером в личку.
Задача состояла из двух частей, каждая по отдельности выполнена, как я считаю (никто не доказал обратного). Энтропии как раз нет, просто не хотите понять почему я так сделал, а не иначе. Здесь нет тупого md5(md5(password)), как Вы подумали. hash22 выполняет свою задачу — не дает войти в систему подсмотревшему hash21 злоумышленнику.
Вы утверждаете что hash22 слабый, хотя при этом не сможете получить hash21. Скажу еще как можно сломать эту систему авторизации — можно поставить кейлогер на компьютер вводящего пароль, из этого правда не надо делать вывод, что хешировать ничего не надо, и что это бесполезное занятие.
А по поводу переменных, я не на конкурсе каллиграфии, в первую очередь интересно было решить задачу. А ее то как раз видеть не хотите, зацепились за то, что увидели поверхностно, причем увидели неправильно. Если сидеть, чистить код, и бояться его показать другим, так за всю жизнь ничего не напишешь.
Жду ссылку, интересно посмотреть на другие решения, а то все мастера учить, а сами ничего похожего не сделали. Я не нашел ни одно похожее решение, на всех сайтах вообще пароль открыто отправляется, и в базе хранится хеш, по которому можно авторизоваться не зная пароль.
Вы утверждаете что hash22 слабый, хотя при этом не сможете получить hash21. Скажу еще как можно сломать эту систему авторизации — можно поставить кейлогер на компьютер вводящего пароль, из этого правда не надо делать вывод, что хешировать ничего не надо, и что это бесполезное занятие.
А по поводу переменных, я не на конкурсе каллиграфии, в первую очередь интересно было решить задачу. А ее то как раз видеть не хотите, зацепились за то, что увидели поверхностно, причем увидели неправильно. Если сидеть, чистить код, и бояться его показать другим, так за всю жизнь ничего не напишешь.
Жду ссылку, интересно посмотреть на другие решения, а то все мастера учить, а сами ничего похожего не сделали. Я не нашел ни одно похожее решение, на всех сайтах вообще пароль открыто отправляется, и в базе хранится хеш, по которому можно авторизоваться не зная пароль.
«А по поводу переменных, я не на конкурсе каллиграфии» — а Хабр должен в телепатии упражняться?
Уважайте читателей ваших СЫРцов.
«как я считаю (никто не доказал обратного)»
Nobody Cares.
«Если сидеть, чистить код, и бояться его показать другим, так за всю жизнь ничего не напишешь.»
То-то я смотрю, ваш год пыщщет гениальностью, при всей своей непричёсанности.
«причем увидели неправильно.»
Научитесь доносить мысль.
«В базе хранится хеш, по которому можно авторизоваться не зная пароль.»
С чего бы этого? Вы где такое видели?
«а то все мастера учить, а сами ничего похожего не сделали»
Еще бы, кому нужно хернёй страдать.
«Вы утверждаете что hash22 слабый, хотя при этом не сможете получить hash21.»
Да на**я мне получать ваш хэш! Точка входа на сервере одна! О, мамма миа!
Показывать я вам передумал, ибо вы полный ноль в простейших понятиях ИБ, жаль, что я сразу не понял.
Тем более, показать я вам хотел просто систему с множественной аутентификацией по ключам, мылам и блокнотам, которая «я-узнал-что-такое-sha1-я-хакер-хэш-эм-олл»-специалиста не устроит.
Одна большая просьба.
Изучите хотя бы Самую Известную Книжку Шнайера, а потом замахивайтесь на пост про «Безопасную авторизацию». Не мутите головы молодому поколению. А пока, спрячьте эту муру.
Уважайте читателей ваших СЫРцов.
«как я считаю (никто не доказал обратного)»
Nobody Cares.
«Если сидеть, чистить код, и бояться его показать другим, так за всю жизнь ничего не напишешь.»
То-то я смотрю, ваш год пыщщет гениальностью, при всей своей непричёсанности.
«причем увидели неправильно.»
Научитесь доносить мысль.
«В базе хранится хеш, по которому можно авторизоваться не зная пароль.»
С чего бы этого? Вы где такое видели?
«а то все мастера учить, а сами ничего похожего не сделали»
Еще бы, кому нужно хернёй страдать.
«Вы утверждаете что hash22 слабый, хотя при этом не сможете получить hash21.»
Да на**я мне получать ваш хэш! Точка входа на сервере одна! О, мамма миа!
Показывать я вам передумал, ибо вы полный ноль в простейших понятиях ИБ, жаль, что я сразу не понял.
Тем более, показать я вам хотел просто систему с множественной аутентификацией по ключам, мылам и блокнотам, которая «я-узнал-что-такое-sha1-я-хакер-хэш-эм-олл»-специалиста не устроит.
Одна большая просьба.
Изучите хотя бы Самую Известную Книжку Шнайера, а потом замахивайтесь на пост про «Безопасную авторизацию». Не мутите головы молодому поколению. А пока, спрячьте эту муру.
В общем понятно, вы один из болтунов, которые сами ничего не понимают, зато других поучают. Мой код вот прямо здесь работает, а вот ваши все потуги лишь в воспаленном воображении. Я строил не одну систему аутентификации, и разбираюсь в этом деле практически. Если не в состоянии понять идею, то так и скажите, а не махайте Самой Известной Книжкой, у вас каша в голове.
> «Я строил не одну систему аутентификации, и разбираюсь в этом деле практически.»
Видно по тому, как вы не можете подсчитать простейшие криптографические параметры своего «творения».
Практически? Соболезную вашим заказчикам.
Маленькое отступление: прогуляйтесь в википедию, и перестаньте путать «аутентификацию» и «авторизацию», выглядеть будете перед школотой круче.
>«Мой код вот прямо здесь работает»
Зачем мучался? Сходи на phpclasses.org, тебе с твоим кодом, даже нос зажимать не придётся.
Там такого добра — на отдельный блог на Хабре хватит.
>«Если не в состоянии понять идею» — о да, мешает профильное образование («каша»), вкусить всю прелесть.
А книжку прочитайте — меньше будет риска, еще раз опозориться на те 30% Хабра, которые не обсуждают телефончики и бугагашечки.
> «Болтун»? Ну, ваше право так считать. Я вот вас считаю говнокодером, с завышенным ЧСВ, который засоряет Хабр своими высерами на уровне первокурсника провинциального вуза.
Но это ничего не меняет.
«Lingua Latina Non Penis Canina». Информационная безопасность — аналогично.
Меня возмущает, что чёрти кто, мешающий HTML с PHP, и засоряющий код глобалами, вылезает с «потугами» и словом «Безопасность» в заголовке. Не дорос еще, до «безопасности».
Из дискуссии удаляюсь. Мне лично всё понятно, Хабр уже не кекс.
PS Если такой молодец, почему выбрали непрофильный блог? Кросспостите в Информационную Безопасность. Там много болтунов с кашей.
Видно по тому, как вы не можете подсчитать простейшие криптографические параметры своего «творения».
Практически? Соболезную вашим заказчикам.
Маленькое отступление: прогуляйтесь в википедию, и перестаньте путать «аутентификацию» и «авторизацию», выглядеть будете перед школотой круче.
>«Мой код вот прямо здесь работает»
Зачем мучался? Сходи на phpclasses.org, тебе с твоим кодом, даже нос зажимать не придётся.
Там такого добра — на отдельный блог на Хабре хватит.
>«Если не в состоянии понять идею» — о да, мешает профильное образование («каша»), вкусить всю прелесть.
А книжку прочитайте — меньше будет риска, еще раз опозориться на те 30% Хабра, которые не обсуждают телефончики и бугагашечки.
> «Болтун»? Ну, ваше право так считать. Я вот вас считаю говнокодером, с завышенным ЧСВ, который засоряет Хабр своими высерами на уровне первокурсника провинциального вуза.
Но это ничего не меняет.
«Lingua Latina Non Penis Canina». Информационная безопасность — аналогично.
Меня возмущает, что чёрти кто, мешающий HTML с PHP, и засоряющий код глобалами, вылезает с «потугами» и словом «Безопасность» в заголовке. Не дорос еще, до «безопасности».
Из дискуссии удаляюсь. Мне лично всё понятно, Хабр уже не кекс.
PS Если такой молодец, почему выбрали непрофильный блог? Кросспостите в Информационную Безопасность. Там много болтунов с кашей.
Да, и то, что вы насрали мне в *****, повысило криптостойкость повторного хеширования в миллион раз. Молодец, возьми пряник с полки.
Вы хам, на улице за оскорбления бы в лицо получили, а не в карму. Такие как вы, способны только в инете оскорблять других, зная что это анонимно, хотя на хабре это поправимо, к счастью.
Зря только распинался столько времени, объясняя простейший алгоритм, который вы понять просто не в состоянии.
Зря только распинался столько времени, объясняя простейший алгоритм, который вы понять просто не в состоянии.
У меня вообще-то данные не скрыты. Валяйте, не надорвитесь только.
Гоповские замашки, тоже охуенно повысят ценность вашей идеи.
«Жду ссылку, интересно посмотреть на другие решения, а то все мастера учить, а сами ничего похожего не сделали. Я не нашел ни одно похожее решение, на всех сайтах вообще пароль открыто отправляется, и в базе хранится хеш, по которому можно авторизоваться не зная пароль.»
Первый пост в ветке, с агрессивным настроем. Подсказать чей, а?
Хам, это если бы я сказал — «Ты тупой хуй.». А я сказал, так или иначе, что ваш код надо спрятать далеко-далеко, а Вам в безопасность грязными руками не лезть. Из-за ИБ — неучей, общая ситуация — безрадостна.
PS Чего — то ваш гениальный топик, голосов смотрю собрал очень много, видимо я чего-то не понял.
Ну раз мы с Вами, осознаем тщетность времязатрат — закроем тему.
Гоповские замашки, тоже охуенно повысят ценность вашей идеи.
«Жду ссылку, интересно посмотреть на другие решения, а то все мастера учить, а сами ничего похожего не сделали. Я не нашел ни одно похожее решение, на всех сайтах вообще пароль открыто отправляется, и в базе хранится хеш, по которому можно авторизоваться не зная пароль.»
Первый пост в ветке, с агрессивным настроем. Подсказать чей, а?
Хам, это если бы я сказал — «Ты тупой хуй.». А я сказал, так или иначе, что ваш код надо спрятать далеко-далеко, а Вам в безопасность грязными руками не лезть. Из-за ИБ — неучей, общая ситуация — безрадостна.
PS Чего — то ваш гениальный топик, голосов смотрю собрал очень много, видимо я чего-то не понял.
Ну раз мы с Вами, осознаем тщетность времязатрат — закроем тему.
Sign up to leave a comment.
Безопасная авторизация с передачей хешированного пароля