интересно, можно ли создать такой пароль, который знает пользователь, а на сервере он не хранится? вообще никак -- ни хэш, ничего.
клиент именно знает этот пароль, в уме, а не владеет чем-то физическим, заменяющим пароль, например, каким-то физическим ключом или отпечатками пальцев.
Здравствуйте, sin_cos, Вы писали:
_>интересно, можно ли создать такой пароль, который знает пользователь, а на сервере он не хранится? вообще никак -- ни хэш, ничего.
Никто не запрещает, создавай. А для чего он будет использоваться? Очевидно, использовать его может только клиент.
Здравствуйте, sin_cos, Вы писали:
_>интересно, можно ли создать такой пароль, который знает пользователь, а на сервере он не хранится? вообще никак -- ни хэш, ничего. _>клиент именно знает этот пароль, в уме, а не владеет чем-то физическим, заменяющим пароль, например, каким-то физическим ключом или отпечатками пальцев.
Да. Например, одноразовый шифроблокнот можно рассматривать как такой пароль.
Здравствуйте, pestis, Вы писали:
P>Здравствуйте, sin_cos, Вы писали:
_>>интересно, можно ли создать такой пароль, который знает пользователь, а на сервере он не хранится? вообще никак -- ни хэш, ничего. _>>клиент именно знает этот пароль, в уме, а не владеет чем-то физическим, заменяющим пароль, например, каким-то физическим ключом или отпечатками пальцев.
P>Да. Например, одноразовый шифроблокнот можно рассматривать как такой пароль.
я не говорил про одноразовый.
ну допустим. как будешь логинить клиента, если на сервере этот пароль не хранится?
Здравствуйте, sin_cos, Вы писали:
_>интересно, можно ли создать такой пароль, который знает пользователь, а на сервере он не хранится? вообще никак -- ни хэш, ничего. _>клиент именно знает этот пароль, в уме, а не владеет чем-то физическим, заменяющим пароль, например, каким-то физическим ключом или отпечатками пальцев.
Если понимать вопрос напрямую — то нельзя.
Как бы ни выглядели данные, которые предъявляет клиент для аутентикации, серверу надо проверять именно эти данные. Как бы эти данные ни назывались, именно они по сути и будут паролем. И серверу надо их хранить.
Если же поставить вопрос "но всё-таки как?", то на это давно отвечено через PKI. Публичный ключ клиента на сервере — и приватный у самого клиента.
Здравствуйте, pestis, Вы писали:
_>>интересно, можно ли создать такой пароль, который знает пользователь, а на сервере он не хранится? вообще никак -- ни хэш, ничего. _>>клиент именно знает этот пароль, в уме, а не владеет чем-то физическим, заменяющим пароль, например, каким-то физическим ключом или отпечатками пальцев.
P>Да. Например, одноразовый шифроблокнот можно рассматривать как такой пароль.
И как сервер проверит его, не обладая копией такого же блокнота?
Здравствуйте, sin_cos, Вы писали:
_>ну допустим. как будешь логинить клиента, если на сервере этот пароль не хранится?
Смотри: пользователь регистрируется со своим шифроблокнотом, сервер отдает ему некий токен, пользователь зашифровывает этот токен своим блокнотом и отдает серверу. Когда пользователь логинится сервер дает ему зашифрованные данные и если пользователь сумел их расшифровать, значит точно он.
Здравствуйте, sin_cos, Вы писали:
_>интересно, можно ли создать такой пароль, который знает пользователь, а на сервере он не хранится? вообще никак -- ни хэш, ничего. _>клиент именно знает этот пароль, в уме, а не владеет чем-то физическим, заменяющим пароль, например, каким-то физическим ключом или отпечатками пальцев.
Есть такая группа протоколов как "доказательство с нулевым разглашением". По сути сервер должен убедиться что клиент знает этот некий секрет. Тогда ничего именно про клиента хранить не надо.
Здравствуйте, pestis, Вы писали:
P>Здравствуйте, sin_cos, Вы писали:
_>>ну допустим. как будешь логинить клиента, если на сервере этот пароль не хранится?
P>Смотри: пользователь регистрируется со своим шифроблокнотом, сервер отдает ему некий токен, пользователь зашифровывает этот токен своим блокнотом и отдает серверу. Когда пользователь логинится сервер дает ему зашифрованные данные и если пользователь сумел их расшифровать, значит точно он.
тогда на сервере все равно будет храниться этот токен или шифроблокнот. какая разница?
Здравствуйте, pestis, Вы писали:
_>>ну допустим. как будешь логинить клиента, если на сервере этот пароль не хранится?
P>Смотри: пользователь регистрируется со своим шифроблокнотом, сервер отдает ему некий токен, пользователь зашифровывает этот токен своим блокнотом и отдает серверу. Когда пользователь логинится сервер дает ему зашифрованные данные и если пользователь сумел их расшифровать, значит точно он.
А клиент сказал, что смог расшифровать, хотя не смог. А сервер поверил, потому что метода проверки у него нет.
Здравствуйте, pestis, Вы писали:
N>>И как сервер проверит его, не обладая копией такого же блокнота?
P>Никак. Расшифрует пользовательские данные и отдаст что получилось, не проверяя валидность.
Здравствуйте, netch80, Вы писали:
N>Если же поставить вопрос "но всё-таки как?", то на это давно отвечено через PKI. Публичный ключ клиента на сервере — и приватный у самого клиента.
А еше лучше — у клиента сертификат, подписанный сервером. Тогда серверу даже и не надо хранить у себя публичный ключ клиента.
Здравствуйте, Pzz, Вы писали:
N>>Если же поставить вопрос "но всё-таки как?", то на это давно отвечено через PKI. Публичный ключ клиента на сервере — и приватный у самого клиента.
Pzz>А еше лучше — у клиента сертификат, подписанный сервером. Тогда серверу даже и не надо хранить у себя публичный ключ клиента.
Сертификат должен передаваться серверу в открытую и не меняется при этом. Скопировав его, другой может представиться тем же клиентом. Значит, этот "сертификат" это всего лишь другое имя для обычного пароля.
В отличие от этого, шифрование или подпись приватным ключом (для неповторяемости — случайного слова, присланного сервером) не открывает приватный ключ, но показывает его наличие.
В PKI сертификаты используются для ссылки на более высокого одобрятеля, но собственно ключ клиента должен быть подтверждён знанием приватного ключа.
Здравствуйте, sin_cos, Вы писали:
_>интересно, можно ли создать такой пароль, который знает пользователь, а на сервере он не хранится? вообще никак -- ни хэш, ничего. _>клиент именно знает этот пароль, в уме, а не владеет чем-то физическим, заменяющим пароль, например, каким-то физическим ключом или отпечатками пальцев.
Ну если предположить, что пользователь способен в уме выполнять криптографические операции — классический случай криптографии с открытым и закрытым ключом. Сервер знает открытый ключ клиента (или знает открытый ключ того, кем подписан открытый ключ клиента) и просит клиента подписать некоторое случайное значение. Клиент своим закрытым ключом (который он знает в уме) подписывает это значение, далее сервер проверяет подпись и убеждается, что клиент действительно владеет этим ключом.
На практике в уме проводить такие вычисления сложно и вряд ли кто-то сможет это сделать. Поэтому используются криптографические устройства: пользователь помнит только пин-код от этого устройства, а сам ключ и операции выполняются в устройстве. Принципиальной разницы тут нет. Если устройство своруют, пин-код всё равно останется у пользователя в уме.
Здравствуйте, netch80, Вы писали:
Pzz>>А еше лучше — у клиента сертификат, подписанный сервером. Тогда серверу даже и не надо хранить у себя публичный ключ клиента.
N>Сертификат должен передаваться серверу в открытую и не меняется при этом. Скопировав его, другой может представиться тем же клиентом. Значит, этот "сертификат" это всего лишь другое имя для обычного пароля.
Нет. Сертификат содержит открытый ключ, некоторое количество дополнительной информации, и он кем-то подписан. К сертификату прилагается еще закрытый ключ, известный только владельцу сертификата.
Проверка сертификата заключается, кроме проверки валидности подписи и этой дополнительной информации, еще и в том, что владельцу сертификата предлагается чего-нибудь (например, большое случайное число) подписать своим закрытым ключем, и эта подпись проверяется с помощью открытого ключа, содержащегося в сертификате.
Таким образом, просто слямзить сертификат недостаточно, чтобы прикинуться его владельцем.
Мое рацпредложение по сравнению с твоим заключается в том, что серверу не обязательно хранить у себя публичные ключи клиентов, которым разрешен доступ. Достаточно подписать эти ключи приватным ключем сервера, и пусть клиенты при каждом запросе их предъявляют вместе с подписью. Это может быть (а может и не быть) эффективнее с точки зрения использования вычислительных ресурсов, чем хранить авторизованные ключи в базе данных сервера. И очень упрощает серверную сторону, если предполагается, что она может работать сразу на большом количестве компутеров в "облаке".
Здравствуйте, sin_cos, Вы писали:
_>интересно, можно ли создать такой пароль, который знает пользователь, а на сервере он не хранится? вообще никак -- ни хэш, ничего. _>клиент именно знает этот пароль, в уме, а не владеет чем-то физическим, заменяющим пароль, например, каким-то физическим ключом или отпечатками пальцев.
Ну если на сервере вообще ничего не хранить, то и валидировать любые предоставленные пользователем доказательства, что это именно он, будет затруднительно. Без третьей стороны, по крайней мере. Если с третьей стороной, то можно взять любой OpenId или что-нибудь из новомодных блокчейн-решений для аутентификации типа http://emercoin.com/content/EMCSSL.pdf. Если же ослабить изначальное требование до "что-нибудь хранить можно, но не результат преобразования непосредственно пароля", то можно генерировать на основе пароля ключ, шифровать им случайную соль и хранить на сервере только её, как в зашифрованном, так и в открытом виде. Для аутентификации, сервер сообщает клиенту соль в открытом виде, клиент на основе введённого пароля генерирует ключ, шифрует им соль и отправляет результат на сервер, где происходит сопоставление зашифрованной клиентом соли с солью, зашифрованной на этапе регистрации пользователя. Ну и конечно возможна чуть более сложная схема на основе ассиметричного шифрования
Здравствуйте, Pzz, Вы писали:
Pzz>>>А еше лучше — у клиента сертификат, подписанный сервером. Тогда серверу даже и не надо хранить у себя публичный ключ клиента. N>>Сертификат должен передаваться серверу в открытую и не меняется при этом. Скопировав его, другой может представиться тем же клиентом. Значит, этот "сертификат" это всего лишь другое имя для обычного пароля. Pzz>Нет. Сертификат содержит открытый ключ, некоторое количество дополнительной информации, и он кем-то подписан. К сертификату прилагается еще закрытый ключ, известный только владельцу сертификата.
Тогда так и надо говорить, что сертификат плюс приватный ключ.
Pzz>Мое рацпредложение по сравнению с твоим заключается в том, что серверу не обязательно хранить у себя публичные ключи клиентов, которым разрешен доступ. Достаточно подписать эти ключи приватным ключем сервера, и пусть клиенты при каждом запросе их предъявляют вместе с подписью. Это может быть (а может и не быть) эффективнее с точки зрения использования вычислительных ресурсов, чем хранить авторизованные ключи в базе данных сервера. И очень упрощает серверную сторону, если предполагается, что она может работать сразу на большом количестве компутеров в "облаке".
В этом методе принципиально отсутствует возможность закрытия доступа через отзыв (revocation). Если же ты добавляеш CRL, то уже есть копируемые всем данные.
Здравствуйте, netch80, Вы писали:
N>Тогда так и надо говорить, что сертификат плюс приватный ключ.
А что, сертификаты кто-то использует по-другому?
N>В этом методе принципиально отсутствует возможность закрытия доступа через отзыв (revocation). Если же ты добавляеш CRL, то уже есть копируемые всем данные.
Можно хранить на сервере fingerprint'ы отозванных сертификатов. Это заведомо в сто раз дешевле, чем хранить неотозванные сертификаты целиком. И модель распределенного хранения, которая eventually consistent, почти наверняка подходит, потому что если от отзыва сертификата до того, как этот отзыв сработает, пройдет немного времени, это, скорее всего, не является проблемой.
