Смотрим дальше. Я живу в России, сайт находится в Обрии - базу этих ID-шников Россия и Обрия совместно ведут? Или как договорятся? Что если не договорятся? Ты не поняла. Нет никакой общей базы. Просто сайт в Обрии полагается на контору, выдавшую тебе сертификат* - скажем, на МВД России - что любой другой сертификат с таким же ID будет выдан только тебе, и никому другому. Или, если боится, что в МВД России любому выдадут любой ID за бутылку водки - то не доверяет, и тогда все сертификаты, подписанные МВД России, отвергает на корню. Поэтому к никакой базе обращаться не надо.
(* Такие конторы называются CA - Certificate Authorities)
Можно вообще построить процесс так: ты регистрируешь ник на сайте, используя свой сертификат. Сайт пишет себе в табличку соответствие: ник - ID - CA. Далее, ты приходишь и логинишься на сайте с каким-то сертификатом - предположим, уже с другим, старый ты потеряла. Сайт проверяет, что сертификат не подделан и что у тебя есть секретный ключ к нему, берёт ID, лезет в табличку, находит ник и пишет тебе: "здравствуй, дорогая R2R! С 8 марта тебя!" То, что залогинилась ты не с тем сертификатом, с каким регистрировала ник - не важно, потому что ID всё тот же, а подделать его нельзя.
Потом, допустим, ты хочешь себе на том же сайте ещё один ник, а сайт такого не позволяет. Тогда при регистрации он запросит сертификат, увидит, что такой ID у него в табличке уже есть, и новый ник не создаст. То, что ты с тех пор успела уже три смарт-карты потерять, не важно, потому что ID не меняется.
Так что уникальный ID-шник, видимо, всё же нужен. Да, я тоже пришёл к такому выводу.
Если никто туда не влезет без моего ведома, а для доступа нужен будет ордер на обыск - почему бы и не вести часть переписки под своим уникальным ID-шником. Уточнение - ты о шифровании почты, или про аутентификацию на почтовом сайте? В принципе, если государство законы играет по правилам и законы уважает - то да, конечно. Проблемы могут возникнуть, когда государство по правилам не играет и нос суёт, куда не положено.
Если отношение "MegaRuleZZZ == Маша Пяткина" останется достоянием сервера, где Маша играет, и будет использоваться им исключительно у себя внутре, чтобы Маша не завела себе лишний аккаунт и не кинула других игроков при каких-то сделках - то всё ОК. Да, конечно. Полиси нормального сайта должна учитывать, что соответствие "ник - сертификат" никуда не публикуется, кроме как с согласия юзера. Хотя и у публикации есть резон - позволить другим юзерам посылать ему шифрованную почту, к примеру. Но только если юзер того хочет.
Ага. Про ID-шники понятно. То есть, в принципе, их может быть у человека и несколько (от разных контор, или от одной, если она разные выдаёт), а сайт уже по сертификату решает, как он с грамотами от данной конкретной СА обращается. И ID-шник в общем случае уникален в пределах одной СА. (а то, скажем, можно странам и компаниям поделить пространство номеров и сделать так, чтобы он быд уникален вообще для всех)
Уточнение - ты о шифровании почты, или про аутентификацию на почтовом сайте? Хотелось бы и то, и другое. Для несекретных вещей - можно без шифрования, но с сохранением обычной тайны переписки. А если про какую-то коммерческую тайну переписываться или, скажем, ДСПшными данными с подразделением в другом городе обмениваться (секретные-то всё равно курьер повезёт) - там бы и шифрование неплохо.
Проблемы могут возникнуть, когда государство по правилам не играет и нос суёт, куда не положено. Угу. Причём ситуацию, когда государство имеет право нос совать куда угодно, а шифроваться от него запрещено, я не рассматриваю - это вопрос политический, а не алгоритмический. :) А вот если по закону государство в пользовательскую инфу лезть не должно, но сертификат генерирует само и ключ знает (само оно ключ порождает или от пользователя получает - не суть) - тут, как я понимаю, схема не допускает дальнейшей доработки напильником?
Полиси нормального сайта должна учитывать, что соответствие "ник - сертификат" никуда не публикуется, кроме как с согласия юзера. В принципе, даже массовый выброс такой информации только помешает сохранению анонимности, но никак не поможет троллям и спамерам, а также похитителям identity.
То есть, в принципе, их может быть у человека и несколько (от разных контор, или от одной, если она разные выдаёт), а сайт уже по сертификату решает, как он с грамотами от данной конкретной СА обращается. И ID-шник в общем случае уникален в пределах одной СА (а то, скажем, можно странам и компаниям поделить пространство номеров и сделать так, чтобы он был уникален вообще для всех). Да, правильно. Но количество возможных сертификатов не должно быть слишком большим - скажем, по одному от каждой страны в мире. Впрочем, и не будет - если какая-то контора и начнет раздавать сертификаты всем подряд, она просто лишится доверия и их просто не будут принимать.
Тут мне на ещё один момент указали - такая система может стать полем разных политических игр между организациями за счет юзеров. Скажем, сайты одной страны вдруг отказываются принимать сертификаты, выписанные другой и т.д.
Хотелось бы и то, и другое. Для несекретных вещей - можно без шифрования, но с сохранением обычной тайны переписки. А если про какую-то коммерческую тайну переписываться или, скажем, ДСПшными данными с подразделением в другом городе обмениваться (секретные-то всё равно курьер повезёт) - там бы и шифрование неплохо. Это я к тому, что если ты посылаешь письмо, подписанное твоим ключом, или хочешь, чтобы почта к тебе шифровалась твоим сертификатом, то твой адресат должен иметь к этому сертификату доступ (он, как правило, посылается с письмом), а стало быть, будет видеть его подробности - тот же ID, если он прописан, и т.д.
А вот если по закону государство в пользовательскую инфу лезть не должно, но сертификат генерирует само и ключ знает (само оно ключ порождает или от пользователя получает - не суть) - тут, как я понимаю, схема не допускает дальнейшей доработки напильником? Ну тогда остаётся этим сертификатам не доверять, не принимать и не пользоваться - ни их владельцам, ни тем, кто их проверяет. Всегда можно генерировать свои - весь вопрос лишь, кто им будет доверять.
В принципе, даже массовый выброс такой информации только помешает сохранению анонимности, но никак не поможет троллям и спамерам, а также похитителям identity. Именно. You got the point.
такая система может стать полем разных политических игр между организациями за счет юзеров. Скажем, сайты одной страны вдруг отказываются принимать сертификаты, выписанные другой и т.д. Ну, это и сейчас не фокус. Не с сертификатами пока, правда; но бывают места, где ты с почтой из домена .ru не зарегистрируешься. По-моему, тут какой-то баланс постепенно выстроится. Сайтам это отчасти удобно будет - скажем, если сертификат выдал штат, в котором азартные игры запрещены, то можно Пупкина с таким сертификатом не впускать в инет-казино или предупреждать, что он туда идёт на свой страх и риск. Сейчас тоже предупреждают, но там оно будет более адресно.
если ты посылаешь письмо, подписанное твоим ключом, или хочешь, чтобы почта к тебе шифровалась твоим сертификатом, то твой адресат должен иметь к этому сертификату доступ (он, как правило, посылается с письмом), а стало быть, будет видеть его подробности - тот же ID, если он прописан, и т.д. Если не будет жёсткой схемы "1 человек - 1 сертификат", то оно и ничего. Это, конечно, экстенсивный подход, и он идентификацию "размывает".
Ну тогда остаётся этим сертификатам не доверять, не принимать и не пользоваться - ни их владельцам, ни тем, кто их проверяет. Всегда можно генерировать свои - весь вопрос лишь, кто им будет доверять.
Это понятно. :) Я немного о другом. Скажем, когда я своим юзерам пароли раздаю, каждый из них может этот пароль у себя потом поменять. Главное, что он залогинился под конкретным паролем-логином (выданным мной) - значит, имеет право в том числе и на смену пароля. А дальше он меняет пароль, и я этот новый пароль уже не знаю, в общем случае.
И такой ещё вопрос, возможно, дурацкий. :) Можно ли у кард-ридера перехватить/скопировать сигнал и его потом "подставлять" вместо пользовательской карточки? Насколько это осмысленный метод взлома? Насколько от него легко защититься?
А дальше он меняет пароль, и я этот новый пароль уже не знаю, в общем случае.
Наоборот. Если мы говорим о традиционных парольных схемах, то сайтовладелец всегда пароль или его аналог узнать может. Допустим, пароль хранится у тебя в базе открытым текстом. Тогда всё понятно. Допустим, пароль хранится в базе в виде одностороннего хэша, юзер посылает его в открытом виде, сайт его хэширует и сравнивает с тем, что в базе (традиционная схема в Unix). Тогда что тебе мешает перехватить пароль, присланный юзером? Допустим, пароль хранится в виде одностороннего хэша, и присылается в нём же. Тогда этот хэш и будет паролем, который можно перехватить, или прочесть из базы и использовать - и мы возвращаемся к началу. Допустим, мы используем схему challenge-response, когда пересылается не пароль или его хэш, а хэш пароля и какого-то случайного значения. Но для того, чтобы проверить response, сайт должен хранить пароль или его хэш - и мы возвращаемся к началу.
(Единственное "но": если на стадии регистрации или смены пароля сайт получает не сам пароль, а хэш пароля и рандомального значения (challenge), и дальше при аутентификации используется то же значение и тот же хэш, то хотя знание этого хэша вполне достаточно, чтобы подделаться под юзера на этом сайте, оно недостаточно, чтобы подделаться под него на других сайтах с той же схемой, на который юзер использует тот же пароль. Потому что там challenge, а стало быть и хэш, будут иными.)
А вот при использовании сертификатов, этой проблемы нет - потому что инфа, хранимая сайтом (сертификат), не позволяет воссоздать инфу, присылаемую юзером, а она всякий раз иная и производится приватным ключом.
Я тут на эту тему в отдельном посте размышлялки накатал - если интересно, глянь.
Зато вот если твой ключ есть у правительства или у той конторы, что выдала тебе сертификат - тогда увы. Сайтовладелец, на сервере которого ты регистрировалась, себя за тебя не выдаст, а вот та контора - запросто. Поэтому я и говорю: важно проследить, чтобы контора ключи не выдавала, а только сертификаты подписывала своим ключом, и не более того.
И такой ещё вопрос, возможно, дурацкий. :)
Это отличный вопрос. Он покрывает целый класс атак, которые называются replay attacks и основываются на том, что атакующий перехватывает некую инфу (пусть даже и сто раз зашифрованную) и пересылает её от себя. Такие атаки бывают много где, далеко не только в ридерах. Собственно, перехват пароля сниффером и его дальнейшее использование - тоже частный случай replay attack. :-)
Классический способ борьбы с ними - использование случайных значений, называемые challenge или nonce. К примеру: комп, к которому подключён ридер, посылает карточке рандомальный challenge. Ридер передаёт его карточке, карточка шифрует его приватным ключом, который хранится только в ней, и результат посылает обратно. Комп берёт сертификат, убеждается, что он ему доверяет, использует его, чтобы расшифровать ответ и сравнивает посланный challenge с полученным.
Теперь: допустим, я атакующий, и я перехватил и challenge, и ответ. Что мне это даст? В следующий раз комп пошлёт совсем другой challenge, и мой перехваченный ответ окажется бесполезен, а ключа, чтобы создать правильный, у меня нет.
Эта техника используется в туче мест: в GSM, в сетях Windows NT, в SSL, в SSH, в IPsec, в модемных диал-апах (протокол CHAP), и ещё черти где. Кстати, LiveJournal её тоже использует - посмотри javascript страницы с логином, обрати внимание на переменные chal и res. :-)
Кроме того, можно использовать метки времени (timestamps), адреса и прочее. Рекорд принадлежит, афаик, схеме digest authentication для web-серверов: для предотвращения replay attacks они используют random nonce, timestamp, IP адрес юзера, URL, имя юзера и её какую-то хрень.
Можно ли у кард-ридера перехватить/скопировать сигнал и его потом "подставлять" вместо пользовательской карточки?
Перечитывал старые комменты и внезапно осознал, что на этот твой вопрос есть, на самом деле, два ответа - "легко" и " невозможно" - в зависимости от обстоятельств.
Вообще, читаю и поражаюсь, сколько я тут наивной дребедени понаписал...
Ты не поняла. Нет никакой общей базы. Просто сайт в Обрии полагается на контору, выдавшую тебе сертификат* - скажем, на МВД России - что любой другой сертификат с таким же ID будет выдан только тебе, и никому другому. Или, если боится, что в МВД России любому выдадут любой ID за бутылку водки - то не доверяет, и тогда все сертификаты, подписанные МВД России, отвергает на корню. Поэтому к никакой базе обращаться не надо.
(* Такие конторы называются CA - Certificate Authorities)
Можно вообще построить процесс так: ты регистрируешь ник на сайте, используя свой сертификат. Сайт пишет себе в табличку соответствие: ник - ID - CA. Далее, ты приходишь и логинишься на сайте с каким-то сертификатом - предположим, уже с другим, старый ты потеряла. Сайт проверяет, что сертификат не подделан и что у тебя есть секретный ключ к нему, берёт ID, лезет в табличку, находит ник и пишет тебе: "здравствуй, дорогая R2R! С 8 марта тебя!" То, что залогинилась ты не с тем сертификатом, с каким регистрировала ник - не важно, потому что ID всё тот же, а подделать его нельзя.
Потом, допустим, ты хочешь себе на том же сайте ещё один ник, а сайт такого не позволяет. Тогда при регистрации он запросит сертификат, увидит, что такой ID у него в табличке уже есть, и новый ник не создаст. То, что ты с тех пор успела уже три смарт-карты потерять, не важно, потому что ID не меняется.
Так что уникальный ID-шник, видимо, всё же нужен.
Да, я тоже пришёл к такому выводу.
Если никто туда не влезет без моего ведома, а для доступа нужен будет ордер на обыск - почему бы и не вести часть переписки под своим уникальным ID-шником.
Уточнение - ты о шифровании почты, или про аутентификацию на почтовом сайте?
В принципе, если государство законы играет по правилам и законы уважает - то да, конечно. Проблемы могут возникнуть, когда государство по правилам не играет и нос суёт, куда не положено.
Если отношение "MegaRuleZZZ == Маша Пяткина" останется достоянием сервера, где Маша играет, и будет использоваться им исключительно у себя внутре, чтобы Маша не завела себе лишний аккаунт и не кинула других игроков при каких-то сделках - то всё ОК.
Да, конечно. Полиси нормального сайта должна учитывать, что соответствие "ник - сертификат" никуда не публикуется, кроме как с согласия юзера. Хотя и у публикации есть резон - позволить другим юзерам посылать ему шифрованную почту, к примеру. Но только если юзер того хочет.
Reply
То есть, в принципе, их может быть у человека и несколько (от разных контор, или от одной, если она разные выдаёт), а сайт уже по сертификату решает, как он с грамотами от данной конкретной СА обращается. И ID-шник в общем случае уникален в пределах одной СА.
(а то, скажем, можно странам и компаниям поделить пространство номеров и сделать так, чтобы он быд уникален вообще для всех)
Уточнение - ты о шифровании почты, или про аутентификацию на почтовом сайте?
Хотелось бы и то, и другое. Для несекретных вещей - можно без шифрования, но с сохранением обычной тайны переписки. А если про какую-то коммерческую тайну переписываться или, скажем, ДСПшными данными с подразделением в другом городе обмениваться (секретные-то всё равно курьер повезёт) - там бы и шифрование неплохо.
Проблемы могут возникнуть, когда государство по правилам не играет и нос суёт, куда не положено.
Угу.
Причём ситуацию, когда государство имеет право нос совать куда угодно, а шифроваться от него запрещено, я не рассматриваю - это вопрос политический, а не алгоритмический. :)
А вот если по закону государство в пользовательскую инфу лезть не должно, но сертификат генерирует само и ключ знает (само оно ключ порождает или от пользователя получает - не суть) - тут, как я понимаю, схема не допускает дальнейшей доработки напильником?
Полиси нормального сайта должна учитывать, что соответствие "ник - сертификат" никуда не публикуется, кроме как с согласия юзера.
В принципе, даже массовый выброс такой информации только помешает сохранению анонимности, но никак не поможет троллям и спамерам, а также похитителям identity.
Reply
Да, правильно. Но количество возможных сертификатов не должно быть слишком большим - скажем, по одному от каждой страны в мире. Впрочем, и не будет - если какая-то контора и начнет раздавать сертификаты всем подряд, она просто лишится доверия и их просто не будут принимать.
Тут мне на ещё один момент указали - такая система может стать полем разных политических игр между организациями за счет юзеров. Скажем, сайты одной страны вдруг отказываются принимать сертификаты, выписанные другой и т.д.
Хотелось бы и то, и другое. Для несекретных вещей - можно без шифрования, но с сохранением обычной тайны переписки. А если про какую-то коммерческую тайну переписываться или, скажем, ДСПшными данными с подразделением в другом городе обмениваться (секретные-то всё равно курьер повезёт) - там бы и шифрование неплохо.
Это я к тому, что если ты посылаешь письмо, подписанное твоим ключом, или хочешь, чтобы почта к тебе шифровалась твоим сертификатом, то твой адресат должен иметь к этому сертификату доступ (он, как правило, посылается с письмом), а стало быть, будет видеть его подробности - тот же ID, если он прописан, и т.д.
А вот если по закону государство в пользовательскую инфу лезть не должно, но сертификат генерирует само и ключ знает (само оно ключ порождает или от пользователя получает - не суть) - тут, как я понимаю, схема не допускает дальнейшей доработки напильником?
Ну тогда остаётся этим сертификатам не доверять, не принимать и не пользоваться - ни их владельцам, ни тем, кто их проверяет. Всегда можно генерировать свои - весь вопрос лишь, кто им будет доверять.
В принципе, даже массовый выброс такой информации только помешает сохранению анонимности, но никак не поможет троллям и спамерам, а также похитителям identity.
Именно. You got the point.
Reply
Ну, это и сейчас не фокус. Не с сертификатами пока, правда; но бывают места, где ты с почтой из домена .ru не зарегистрируешься.
По-моему, тут какой-то баланс постепенно выстроится. Сайтам это отчасти удобно будет - скажем, если сертификат выдал штат, в котором азартные игры запрещены, то можно Пупкина с таким сертификатом не впускать в инет-казино или предупреждать, что он туда идёт на свой страх и риск. Сейчас тоже предупреждают, но там оно будет более адресно.
если ты посылаешь письмо, подписанное твоим ключом, или хочешь, чтобы почта к тебе шифровалась твоим сертификатом, то твой адресат должен иметь к этому сертификату доступ (он, как правило, посылается с письмом), а стало быть, будет видеть его подробности - тот же ID, если он прописан, и т.д.
Если не будет жёсткой схемы "1 человек - 1 сертификат", то оно и ничего. Это, конечно, экстенсивный подход, и он идентификацию "размывает".
Ну тогда остаётся этим сертификатам не доверять, не принимать и не пользоваться - ни их владельцам, ни тем, кто их проверяет. Всегда можно генерировать свои - весь вопрос лишь, кто им будет доверять.
Это понятно. :) Я немного о другом.
Скажем, когда я своим юзерам пароли раздаю, каждый из них может этот пароль у себя потом поменять. Главное, что он залогинился под конкретным паролем-логином (выданным мной) - значит, имеет право в том числе и на смену пароля. А дальше он меняет пароль, и я этот новый пароль уже не знаю, в общем случае.
И такой ещё вопрос, возможно, дурацкий. :)
Можно ли у кард-ридера перехватить/скопировать сигнал и его потом "подставлять" вместо пользовательской карточки? Насколько это осмысленный метод взлома? Насколько от него легко защититься?
Reply
Наоборот. Если мы говорим о традиционных парольных схемах, то сайтовладелец всегда пароль или его аналог узнать может.
Допустим, пароль хранится у тебя в базе открытым текстом. Тогда всё понятно.
Допустим, пароль хранится в базе в виде одностороннего хэша, юзер посылает его в открытом виде, сайт его хэширует и сравнивает с тем, что в базе (традиционная схема в Unix). Тогда что тебе мешает перехватить пароль, присланный юзером?
Допустим, пароль хранится в виде одностороннего хэша, и присылается в нём же. Тогда этот хэш и будет паролем, который можно перехватить, или прочесть из базы и использовать - и мы возвращаемся к началу.
Допустим, мы используем схему challenge-response, когда пересылается не пароль или его хэш, а хэш пароля и какого-то случайного значения. Но для того, чтобы проверить response, сайт должен хранить пароль или его хэш - и мы возвращаемся к началу.
(Единственное "но": если на стадии регистрации или смены пароля сайт получает не сам пароль, а хэш пароля и рандомального значения (challenge), и дальше при аутентификации используется то же значение и тот же хэш, то хотя знание этого хэша вполне достаточно, чтобы подделаться под юзера на этом сайте, оно недостаточно, чтобы подделаться под него на других сайтах с той же схемой, на который юзер использует тот же пароль. Потому что там challenge, а стало быть и хэш, будут иными.)
А вот при использовании сертификатов, этой проблемы нет - потому что инфа, хранимая сайтом (сертификат), не позволяет воссоздать инфу, присылаемую юзером, а она всякий раз иная и производится приватным ключом.
Я тут на эту тему в отдельном посте размышлялки накатал - если интересно, глянь.
Зато вот если твой ключ есть у правительства или у той конторы, что выдала тебе сертификат - тогда увы. Сайтовладелец, на сервере которого ты регистрировалась, себя за тебя не выдаст, а вот та контора - запросто. Поэтому я и говорю: важно проследить, чтобы контора ключи не выдавала, а только сертификаты подписывала своим ключом, и не более того.
И такой ещё вопрос, возможно, дурацкий. :)
Это отличный вопрос. Он покрывает целый класс атак, которые называются replay attacks и основываются на том, что атакующий перехватывает некую инфу (пусть даже и сто раз зашифрованную) и пересылает её от себя. Такие атаки бывают много где, далеко не только в ридерах. Собственно, перехват пароля сниффером и его дальнейшее использование - тоже частный случай replay attack. :-)
Классический способ борьбы с ними - использование случайных значений, называемые challenge или nonce. К примеру: комп, к которому подключён ридер, посылает карточке рандомальный challenge. Ридер передаёт его карточке, карточка шифрует его приватным ключом, который хранится только в ней, и результат посылает обратно. Комп берёт сертификат, убеждается, что он ему доверяет, использует его, чтобы расшифровать ответ и сравнивает посланный challenge с полученным.
Теперь: допустим, я атакующий, и я перехватил и challenge, и ответ. Что мне это даст? В следующий раз комп пошлёт совсем другой challenge, и мой перехваченный ответ окажется бесполезен, а ключа, чтобы создать правильный, у меня нет.
Эта техника используется в туче мест: в GSM, в сетях Windows NT, в SSL, в SSH, в IPsec, в модемных диал-апах (протокол CHAP), и ещё черти где. Кстати, LiveJournal её тоже использует - посмотри javascript страницы с логином, обрати внимание на переменные chal и res. :-)
Кроме того, можно использовать метки времени (timestamps), адреса и прочее. Рекорд принадлежит, афаик, схеме digest authentication для web-серверов: для предотвращения replay attacks они используют random nonce, timestamp, IP адрес юзера, URL, имя юзера и её какую-то хрень.
Reply
Перечитывал старые комменты и внезапно осознал, что на этот твой вопрос есть, на самом деле, два ответа - "легко" и " невозможно" - в зависимости от обстоятельств.
Вообще, читаю и поражаюсь, сколько я тут наивной дребедени понаписал...
Reply
Leave a comment