Приветствую всех.

Хочу изложить идею еще одного механизма авторизации, и предложить всем заинтересующимся "взломать" ее.

Данный механизм предназначен исключительно для административного раздела сайта, и подразумевается, что интерфейс административного раздела полностью находится на локальном компьютере. Работает следующим образом:

При входе в админ. раздел, либо автоматически, либо по запросу администратора, без формы, передаются логин и пароль. Передаеются они вшитыми в изображение, которое программно рисуется на локальной машине. Сервер считывает логин/пароль, дает доступ, с условием, что все последующие запросы будут сопровождаться "картинной подписью", тоже программно рисуемое изображение, но содержащее некую подпись, о которой клиент осведомлен. При каждом запросе на авторизацию изображения логина/пароля и подписи изменяются. Весть механизм (как прочем и весь обмен интерфейса с сервером) построен исключительно на AJAX.  

Ниже (в прикреплении) представлены два "компьютерных Малевича", которые и содержат в себе одни и те же логин и пароль. И логин и пароль записаны в открытом виде.

Кто заинтересован, попробуйте прочесть их. Возможно ли это сделать, если да, то каковы затраты на труд и время. В общем хочется понять, насколько это надежно будет.




Присоединённый файл ( Кол-во скачиваний: 12 )
 image.rar 2,76 Kb

Гыыы ... а зачем выдумывать механизм сессии в виде подписи и впихивать его в изображение.
А с изображением вшитым в него паролем, гмм ... а зачем его расшифровывать если можно использовать просто изображение, один фиг оно расшифровуется на стороне сервера. То есть вместо механизма передачи пароля самим браузером выдумываем велосипед шифрования с рисунком,  перехватив можно использовать напрямую точно так же как и обычный пароль. То есть пароль упакованный в красивую ерунду не даёт ни чего впринципе и остаётся таким же паролем для сервера как обычный. 


Это жестоко, менять каждый раз логин и пароль.

Если на ряду с сессией использовать постоянно генерацию подписи! вот другое дело, то есть для каждого запроса (страницы) генерируется подпись, которая сохраняется в сессии,  и встраивается в страницу. Только вот генерировать рисунки с каждым запросом ....   
Вместо подписи генерировать символьный код и встраивать в его в страницу.
Впринципе может и есть смысл шифровать символьную подпись в рисунке, но только подпись. Так как она динамически изменяется при каждом запросе и о истинном коде, и алгоритме распаковки будет знать только сервер, который отдаёт аутентифицированному пользователю запакованный код подписи. Но опять же в виду генерации на каждый запрос это только для админки.
Кстати, если уж важна сильная безопасность, можно вводить рандомный выбор алгоритмов упаковки подписи для страницы и так же вносить его в сессию для следуещей распаковки.


И чего ... 

Это сообщение отредактировал(а) Sentox - 26.2.2012, 00:35

Вы либо невнимательно прочли, либо не поняли сути.

Изобретать всегда полезно, ведь по сути все новое, это забытое старое, но обретенное новые формы.

Кстати, если уж важна сильная безопасность, можно вводить рандомный выбор алгоритмов упаковки подписи для страницы и так же вносить его в сессию для следуещей распаковки.

Да, есть стандартные инструменты - форма. Но перехватив ваш пароль, им можно будет пользоваться, и в сессию можно внедриться.

...гмм ... а зачем его расшифровывать если можно использовать просто изображение, один фиг оно расшифровуется на стороне сервера.

О какои изображении речь? В данном случае изобаражение, содержит логин и пароль, которые вшиваются в изображение по определенному алгоритму, и получить их можно только зная этот алгоритм, это и есть расшифровка.

То есть вместо механизма передачи пароля самим браузером выдумываем велосипед шифрования с рисунком,  перехватив можно использовать напрямую точно так же как и обычный пароль. 
Это жестоко, менять каждый раз логин и пароль.

Если ваш пароль переданный обычной формой перхватят, то да, будут пользоваться пока вы не поймете, что его украли. Я написал вроде бы понятно, и вы процетировали меня, но не вникли, потому повторяю:

С каждым запросом на авторизацию изображение будет совсем уже иным, и если его перехватят, то воспользоваться им не смогут - сервер его не примет, ибо он не сможет прочесть его. Изменяется только изображение - размер, содержание, а логин и пароль не изменяются, с чего вы взяли?

Только вот генерировать рисунки с каждым запросом ....

А вы пробовали генерировать изображения такие как я генерирую? И сколько времени на это уходит? Если вас обескураживает время, то вы его не заметите, если вы о содержании, то рисовать "Девятый вал" Айвазовского в данном случае не требуется.

AJAX потому, что позволяет производить авторизаю автоматически, посему и интересует надежность. 

  

Task, это все уже сделано в ssl протоколе (https). И шифрование данных формы на клиенте и новый ключ на сессию... Если делается подобие ssl - то нужно проверять себя по нему, все ли шаги проделаны ;)

Не очень понятно кто будет генерировать картинку на клиенте. JS на canvas? Флешка? Отдельное приложение, которое нужно сначала поставит?

Поддерживаю, и как об этом поймёт сервер что изменился алгоритм распаковки рисунка? Как синхронизируются клиент с сервером? То есть как произведётся это действие 



Ещё раз, если изображение будет перехвачено в течении сессии то это изображение нет смысла расшифровывать просто можно "скормить" серверу. В свете выше заданной проблемы изображение скорее всего придётся оставлять одним и тем же или генерировать на клиенте и придумывать какую то синхронизацию (оповещение об алгоритме распаковки) для сервера.

. 
А что такого в запросе AJAX отличного от обычного в плане надёжности?


Несколько не понял, причём тут стандартная форма к сессии и алгоритму распаковки изо подписи? Кстати вот здесь управляющим элементом безопасностью является сервер что более правильно.

Это сообщение отредактировал(а) Sentox - 26.2.2012, 12:30

Отвечаю сразу всем )


1. По поводу высказывания, что авторизация происходит автоматически.
Нет, конечно она не потому автоматическая, что автоматику обеспечивает AJAX, я имел ввиду, что нет ни формы, ни запроса на авторизацию - инициатором ее выступает локальная машина, автоматически генерируя изображение и посредством AJAX отправляя его на сервер. Если все ОК, то дается доступ и сообщается, что вход произведен. В традиционном виде авторизации это форма, ввод, отправка формы.

2. По поводу SSL. 
Да в мире много чего уже сделано, но согласитесь, что не всегда все это доступно, в том числе и HTPPS. Так что об этом можно вообще не говорить. Собственно я и не пытаюсь что-то отменять из существующего, а тем  более противопоставлять ему свое.

3. По поводу генерации изображения - кто является "художником" в данном случае.
Еще раз прошу, прочтите внимательно то, что я написал в первом посте. Там сказано, что данный механизм служит исключительно для административного раздела, и что данный раздел (его интерфейс управления) полностью находится на локальной машие. Вот это, что его держать на локалной машине на 100% выгоднее, чем на сервере, я не просто убежден, я в этом давно убедился, ибо свои таковые разделы я помещаю именно на локалную машину, обмениваясь с сервером только "голыми" данными.
Что это дает? Самое ценное, это обширный инструментарий под рукою, интеграция этого инструментария с приложениями, и т.п..
На чем писать такой инструментарий, это уже по желанию, но под Win вполне хватает HTA как основное приложение, плюс JavaScript, VBsvript. А что-то поставить еще из библиотек необходимых - какая сложность?

"Не очень понятно кто будет генерировать картинку на клиенте. JS на canvas? Флешка?"

И это все, которые способны рисовать? Во-первых - на локалной машине вам доступны средства WinAPI, во-вторых - существует масса библиотек сторонних. В моем случае я применил именно стороннюю, свободно распространяемую библиотеку GflAX, именно она выступает в качестве "художника" будучи подключенной в JavaScript как ActiveXObjec. Выбор пал на стороннюю, а не на WinAPI, только потому, что в первом случае писать меньше, и проще. Думаю, что вам не надо объяснять, что подключение ее непосредственно из приложения (HTA) задача очень простая, и при этом совсем не обязательно трогать системную директорию ОС.

4. "Ещё раз, если изображение будет перехвачено в течении сессии то это изображение нет смысла расшифровывать просто можно "скормить" серверу."
Нет, не получится - уже отосланный экземпялр устаревает сразу при получении его сервером, то есть, перхваченное изображение уже не сработает, сервер будет ожидать совсем иного. Условно скажем так:
в прикрепленном архиве два изображения, пусть это будут запросы на аторизацию А и В. Сервер "знает", что в случае авторизации А, он должен получить именно первое изображение, а для следующей авторизации (В) должно прийти только изображение второе, первое уже не действительно. И так далее. Чтобы задействовать перехваченное изображение, вор должен действовать с авторизуемым синхронно, что не выполнимо практически.  Как это происходит в реальности, каков алгоритм всего, я конечно не буду рассказывать, собственно у вас своей фантазии полно, чтобы написать свой алгоритм, если таковой потребуется.
И сессия в данном случае вообще не применяется, она исключена из процесса авторизации полностью, куки тоже не устанавливаются.
Вместо них дальнейшим связующим сервер/клиент служит "графическая подпись".

Все это взаимосвязано. Меня иетересует более всего надежность "шедевра"   , а не рассуждения в плане того, что есть уже..., и стоит ли еще..., чем сделано и как... Я применил этот подход, работает так как и задумывалось. Вопрос самый главный - сможе ли кто-то прочесть то, что вшито в этих картинках? Повторяю, на обеих одно и тоже.

Это сообщение отредактировал(а) Task - 26.2.2012, 16:19

доступ к веб-панели только с 127.0.0.1 и точка   



API или СУБД открываете во внешку?

И всё же я не услышал, как сервер осведомляется о применённом алгоритме упаковки пароля в изображение что бы его считать из рисунка? То есть, если каждый раз рисунок другой, а логин\пароль одни и те же, серверу нужно сообщить как распаковать рисунок и считать содержимое. Если алгоритм распаковки из рисунка на сервере пароля\логина один и тот же какой смысл в постоянной перепаковке в разные рисунки? 

Это сообщение отредактировал(а) Sentox - 26.2.2012, 17:23

API или СУБД открываете во внешку?

Работа с базой происходит точно так же, как и в обычном случае - запрос, выдаем то, что просили. Отличие только в том, что через AJAX передаются только данные, html шаблоны находятся у клиента.

И всё же я не услышал, как сервер осведомляется о применённом алгоритме упаковки пароля в изображение что бы его считать из рисунка?

Я думаю, что вы понимаете, что о том как это делается я распространятся не буду, это ведь естественно. Могу сказать лишь то, что это не является проблемой, подумайте сами, и вы найдете решение, какое-то свое, но найдете. 

Если алгоритм распаковки из рисунка на сервере пароля\логина один и тот же какой смысл в постоянной перепаковке в разные рисунки? 

Если бы рисунок, его параметры и содержимое были бы постоянны, то смысла бы во всем этом не было бы ни какого, это было бы равносильно передачи логин/пароль обычными средствами, формой, то есть довольно легкой для взлома, да и перехватив такое изображение им можно будет пользоваться так же, как если украдут пароль. Я уже говорил об этом ранее.   

Это сообщение отредактировал(а) Task - 26.2.2012, 19:25

Нонсенс

Добавлено через 4 минуты и 1 секунду
По теме.
Автор, вы априори исходите из небезопасного соединения. Т.е. что ваши данные могут перехватываться.

Поэтому если вы не применяете шифрование, то никакие картинки не помогут.

Сохранение секретной информации в изображениях это не изобретение, а давно известный трюк.
Собственно не имеет значения что и как вы храните.
Имеет значение криптостойкость вашего алгоритма шифрования (а именно это вы делаете упаковывая данные в изображение).

Вот я и предлагаю всем прочесть то, что в изображении, потому оно и нешифрованное. Если прочтете, с меня коньяк   , и не буду этим пользоваться, если нет, значит имеет право на существование, а зашифровать еще перед "художеством", это уже другое.

Я никоим образом не претендую на авторство идеи, но и вшивать можно по разному.

У вас целая куча проблем:

•  Мне неинтересно разбирать конкретно ваш алгоритм шифрования (если он есть)
•  Я не пью и коньяк меня не мотивирует. Можем поговорить о 2к у.е., тогда я подумаю над тем чтобы взяться за это (но маловероятно, ибо с самокритикой у меня все хорошо и я понимаю что не специалист по криптостойкости, а значит 2-4 недель будет мне недостаточно)
•  Это не форум специалистов по криптографии. А значит тестирование не имеет практической ценности
•  Безопасность вашей авторизации не имеет ровно никакого значения, если все остальное идет открытым текстом. Т.е. у вас вместо пароля могут перехватить ключ сессии к примеру. Подменить мак и айпи адрес и вместо вас слать серверу чего-нибудь эдакого.

Это сообщение отредактировал(а) Fortop - 26.2.2012, 21:36

Fortop, наконец-то. 

Теперь можно поговорить по существу всех недостатков высера инновации ТС.

1. Весь тред крутится около изображений. Вопрос автору "Зачем?" задавать я думаю бессмысленно. Изображения в данной схеме не несут абсолютно никакой функциональности, то есть автор фактически передает открытую информацию преобразованную (закодированную) неким алгоритмом (набором алгоритмов).

2. Шифрования, насколько я понял нет, и в помине.

3. То есть вся схема строится на секретности алгоритма (набора алгоритмов) что уже не безопасно. Плюс как уже сказали необходимость наличия протокола синхронизации алгоритмов. 

4. Если все же имеется процедура шифрования, тут необходимо говорить о криптостойкости сего алгоритма.

5. Такая схема очевидно уязвима перед атакой "Man in the middle".

6. Стоит отметить, что современная криптография базируется на принципе Керкгоффса, и автору было бы неплохо с ним ознакомиться.

7. Для полноценного анализа как уже сказал Fortop нет ни времени, ни желания, ни ресурсов, ни данных. Вероятно автор хочет таким образом потроллить сообщество, самоутвердившись за счет того, что никто не в силах разгадать схему по двум картинкам. Поэтому совет автору - если он хочет действительно проверить свою схему, пусть будет готов заплатить далеко не 2 тыс. тех самых единиц за работу специалистов в сфере криптографии.

Итог. Вся схема автора строится на принципе Security through obscurity. Очевидные недостатки которой автор, я думаю, в состоянии узнать из авторитетных источников.

P.S. Тут были упомянуты средства WinAPI и прочие 3rd party библиотеки, доступные через COM. То есть на кроссбраузерность и кроссплатформенность придется забить. 

P.S. и почему я всегда замечаю, что к псевдонаучным трудам в области безопасности тянутся исключительно пхпшники.

Добавлено через 12 минут и 34 секунды


Этот трюк, а точнее один из методов сокрытия информации, известной как стеганография, предназначен именно для, внимание, сокрытия факта наличия информации на каком-либо носителе, коим может быть изображение, аудио-дорожка, etc. Здесь же никакого сокрытия факта передачи нет. Так как заранее известно что изображение является просто аналогом ключа.

Это сообщение отредактировал(а) cutwater - 26.2.2012, 22:10

Ну вот и веские доводы, наконец-то. Все ясно.

Нет, я не ради самоутверждения, я далек от себялюбия.