Сообщений в теме: 33

[Ty-154]

Добрый день!
давно размышляю на эту тему. решил задать вопрос.

порядка 90 процентов всевозможных веб-ресурсов гоняют пароль от клиента к серверу в ЧИСТОМ виде.

Почему?
ведь есть варианты:

1. SSL. Некоторые ресурсы, например gmail, "мудрят" используя SSL защиту скрипта аутентификации. Но не у всех есть возможность содержать свой сервер и сертификат. Соответственно не все могут себе позволить SSL.
2. Криптография.
подробно:
- на сервере хранятся хеши паролей.
- при аутентификации для пользователя генерируется "соль"(случайная последовательность), она кладется в базу, браузеру передается "соль" и идентификатор "соли".
- браузер делает следующее: хеш( хеш(пароля) + "соль") и передает на сервер идентификатор "соли", имя пользователя и полученный "суперхеш".
- сервер проверяет все по такой же схеме.

Ни разу такого не встречал... почему? кто сможет объяснить?

PS. сначала казалось, что все упирается в сложность реализации хеширования на javascript. Но готовых примеров - хватает.
PPS. возникает мысль о пользователях с выключенным javascript. Но таких ОЧЕНЬ мало. В конце концов для них можно и в чистом виде передать.

жду мнений.

Сообщение отредактировал Ty-154: 20.05.2009, 11:31:55

[eroha]

а что мешает перехватить суперсоль
и выслать ее вместо вас?

[Ty-154]

Прошу прощения, забыл уточнить...

мы для этого и пишем ее в базу, а не просто передаем туда-сюда...
"соль" действительна ТОЛЬКО ОДИН РАЗ.
дали клиенту - лежит в базе ждет.
при первой попытке использования этой "соли" она удаляется сервером. либо удаляется по таймауту.

новая аутентификация - новая "соль". соответственно новый "суперхеш"

такая "шпаргалка" - не прокатит!

Сообщение отредактировал Ty-154: 20.05.2009, 11:44:43

[T. Anre]

порядка 90 процентов всевозможных веб-ресурсов гоняют пароль от клиента к серверу в ЧИСТОМ виде.

В этом нет ничего плохого. И разработчики этих 90% ресурсов это понимают. Остальные "строят замки на песке", либо используют SSL.

[Ty-154]

В этом нет ничего плохого. И разработчики этих 90% ресурсов это понимают. Остальные "строят замки на песке", либо используют SSL.

а конкретнее о "замках"? предлагаемый мной метод чем то плох?

[eroha]

по мне так лучше использовать http digest + SSL
правда не все браузеры поддерживают digest авторизацию

[Ty-154]

по мне так лучше использовать http digest + SSL
правда не все браузеры поддерживают digest авторизацию

а именно? чем лучше? слишком голословно, ни одного обоснованного ответа...

про SSL я уже говорил, у многих нет возможности его использовать...

[eroha]

зачем еще тут обосновывать digest авторизацию
когда в инете куча материалов по оной
там как раз тот самый механизм который не гоняет пароль в открытом виде как через basic авторизацию (base64)

[Ty-154]

зачем еще тут обосновывать digest авторизацию

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

To eroha Вы писали:

по мне так лучше использовать http digest + SSL

Объясните, если можете быть не голословным, почему лучше?

Я в свою очередь скажу, что чаще, всякие всплывающие окошки нативного типа, являются неприемлемыми. Поэтому и ищу иную методику.

[agapit_PSG]

Вот и напишите свой модуль, а мы будем покупать его за совсем небольшие деньги. Если это сайтец простейший, то для чего мудрить. А если безопасность нужна, тогда я все же буду использовать SSL, где злоумышленник и не перехватит реальных данных и не сможет подменить данные ложными.
З.Ы. Вы запросили возможность авторизации, сервер сформировал соль, отправил вам, от вас идет суперхеш, перехватывается, ваш пакет отбрасывается и вуаля, злоумышленник уже зашел. Если есть возможность перехватывать пакеты, то наверное есть возможность и отбрасывать их. Не так ли?

[eroha]

Объясните, если можете быть не голословным

как время будет опишу
жалко времени сейчас

[Gloomy]

... я просил обосновать почему и чем мой вариант плох. Объясните, если можете быть не голословным

как время будет опишу.жалко времени сейчас

Eroha - а давай я помогу?

Ту-154 - Ваш вариант плох потому что он лохОвский^W экскузьмуа мой френч Наивный! Конечно же наивный

Начнём громить Ваш алгоритм?
Сразу же быка за рога - как вы определяете подлинность сервера? Ага ... "джентльменам верят на слово!"(С) Всё - вас уже съели. Читать на тему "man-in-the-middle".
Собственно оригинальный пароль отковырять всё еще будет сложно, но Вас таки поимели. Ну например изменят пароль на свой.
Если не верится - читать как гордятся браузеро-строители выигранной войной за зелёный [красный] адрес-бар ... да-да войной с не доверенными сертификатами. Теперь если это не Verisign, Thawte и др. "приближенные к императору" и ваш браузер из свежих ... Вы сразу заметите

... а если добавить в Ваш метод схемы аутентификации сервера и\или клиента ... то SSL и получится (ну грубо, там таки похитрее)

PS: Только чур без обид. Я подозреваю через создание своего "дико простого и страшно надёжного" крипто-алгоритма прошли ну если не все то многое. Я к примеру

[Ty-154]

как время будет опишу
жалко времени сейчас

другого ответа в принципе не ожидал... Вы похоже не понимаете, того, о чем разговариваете.
Для справки: RFC 2069 - http://www.getrfc.ru...rfc2069.txt.pdf.
Дело в том, что Digest аутентификация и мой вариант имеют одинаковый принцип. Основная разница в том, что я использую СВОЮ форму, а http Digest нативное браузерное окошко.

Очень прошу остальных, прежде чем что то писать, понимать то о чем рассуждаете.

Вот и напишите свой модуль

Модуль - я уже написал, веду доработку.

З.Ы. Вы запросили возможность авторизации, сервер сформировал соль, отправил вам, от вас идет суперхеш, перехватывается, ваш пакет отбрасывается и вуаля, злоумышленник уже зашел. Если есть возможность перехватывать пакеты, то наверное есть возможность и отбрасывать их. Не так ли?

Так! Но не всегда. Иметь возможность отслеживать не всегда значит иметь возможность подменить. это геморойнее...
защищенность ресурса равна защищенности самого слаблого звена этого ресурса.
В любом случае - спасибо за рассуждения.

у моего метода (как и у http digest) есть один недостаток, в сравнении с аутентификацией паролем в чистом виде.
Состоит он в следующем: мы храним в базе в поле password либо чистый пароль, либо хеш пароля.
Злоумышленнику достаточно увидеть(sql injection, подкуп админа и т.д.) это поле, чтобы пройти аутентификацию.
Тогда как в случае с передачей в чистом виде и хранением хеша пароль хешируется, перед сверкой, что исключает возможность воспользоваться данными полученными из базы.

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

[Ty-154]

Начнём громить Ваш алгоритм?
Сразу же быка за рога - как вы определяете подлинность сервера? Ага ... "джентльменам верят на слово!"(С) Всё - вас уже съели.

Давайте давайте.

теперь я погромлю SSL... Как писалось в моем первом посте, хостинг-арендуемый...
Теперь... как вы определяете подлинность сервера?
хоба! Как ни странно, Вас ТОЖЕ СЪЕЛИ!

PS: Только чур без обид. Я подозреваю через создание своего "дико простого и страшно надёжного" крипто-алгоритма прошли ну если не все то многое. Я к примеру

Я ни коем случае не обижаюсь! Обоснованная критика - приветствуется.

[eroha]

Ни разу такого не встречал... почему? кто сможет объяснить?

сначала вы такого не встречали (думая что изобрели алгоритм авторизации)
я указал на http digest

Вы похоже не понимаете, того, о чем разговариваете

я как раз таки понимаю о чем говорю
вариант с digest лучше тем (хотя ваш вариант толком не осмыслил в силу занятости и не желания забивать голову) что это придумали ее задолго до вас
причем что нативные окошки браузера (раз уж так не нравиться) можно и не использовать а опять поизвращаться с http запросами с любого скриптового языка

Злоумышленнику достаточно увидеть(sql injection, подкуп админа и т.д.)

это уже НЕ недостаток алгоритма авторизации а недостаток ума админа или программера - сами хоть понимаете что пишите?

теперь я погромлю SSL... Как писалось в моем первом посте, хостинг-арендуемый...

что мешает арендовать еще и IP адрес
и прикрутить хотя бы тот же rapidssl сертификат (умные люди так и делают) и спят спокойно - стоит он 30-40 $

[T. Anre]

Начнём громить Ваш алгоритм?
Сразу же быка за рога - как вы определяете подлинность сервера? Ага ... "джентльменам верят на слово!"(С) Всё - вас уже съели.

Давайте давайте.

теперь я погромлю SSL... Как писалось в моем первом посте, хостинг-арендуемый...
Теперь... как вы определяете подлинность сервера?
хоба! Как ни странно, Вас ТОЖЕ СЪЕЛИ!

А может НЕ СЪЕЛИ?

Вопрос на засыпку.
Зачем из тонкого клиента,
контент которого передан с сервера по защищенному каналу,
определять подлинность сервера?

[Ty-154]

цепляемся к словам... я поддержу Вашу инициативу...
я не думал(мне то наверное лучше знать, что я думал), что я ИЗОБРЕЛ алгоритм. Я знал, что такое http digest.
и прочее. Я не какой-нибудь быдло-php-кодер который ничего кроме быдлосайтов на php не смыслит.

я не говорю что мой метод круче использования SSL.
кстати

я как раз таки понимаю о чем говорю

и

(хотя ваш вариант толком не осмыслил в силу занятости и не желания забивать голову)

противоречивые высказывания.
с умным видом делать заключения, даже не разобравшись в вопросе, это ОХРЕНЕННО круто!

причем что нативные окошки браузера (раз уж так не нравиться) можно и не использовать а опять поизвращаться с http запросами с любого скриптового языка

это примерно то, что я вынес на обсуждение, открывая топик.

Злоумышленнику достаточно увидеть(sql injection, подкуп админа и т.д.)

это уже НЕ недостаток алгоритма авторизации а недостаток ума админа или программера - сами хоть понимаете что пишите?

Вы забыли рассмотреть и т.д., под которым может скрываться все что угодно, от уязвимости в ОС до дубины которая заставит админа слить базу.
Имеется в виду вероятность(а она ведь есть!) утечки данных. Я прекрасно понимаю о чем говорю.

теперь я погромлю SSL... Как писалось в моем первом посте, хостинг-арендуемый...

что мешает арендовать еще и IP адрес
и прикрутить хотя бы тот же rapidssl сертификат (умные люди так и делают) и спят спокойно - стоит он 30-40 $

и что мне это даст? если сервер ФИЗИЧЕСКИ находится не у меня и администрируется не мной.

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

Сообщение отредактировал Ty-154: 26.05.2009, 14:59:48

[Ty-154]

А может НЕ СЪЕЛИ?

Вопрос на засыпку.
Зачем из тонкого клиента,
контент которого передан с сервера по защищенному каналу,
определять подлинность сервера?

мегаархисложный ответ на просто убийственный вопрос: затем, что бы кому попало не отдать свои личные данные!

не замечали, что всевозможные сервисы, которые используют сертификаты и SSL не базируются на "общественных" серверах?
как думаете почему?

Сообщение отредактировал Ty-154: 26.05.2009, 15:07:42

[eroha]

ваш и другой методы не могут быть круче SSL )
потому что они реализуют механизм авторизации
а SSL это секьюрный протокол передачи данных

люди кто серьезно завязан с безопасностью могут позволит сертификаты упоминаемых verisign и пр. неужели они будут покупать shared хостинг?

Сообщение отредактировал eroha: 26.05.2009, 15:21:39

[T. Anre]

А может НЕ СЪЕЛИ?

Вопрос на засыпку.
Зачем из тонкого клиента,
контент которого передан с сервера по защищенному каналу,
определять подлинность сервера?

мегаархисложный ответ на просто убийственный вопрос: затем, что бы кому попало не отдать свои личные данные!

Зачем кому-то ваши данные?