Двач.hk не отвечает.
Вы видите копию треда, сохраненную 1 августа 2021 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Вы видите копию треда, сохраненную 1 августа 2021 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
156 Кб, 592x445Прошлый: https://2ch.hk/pr/arch/2021-04-22/res/1658420.html (
М)
Теперь это также авторизации тред.
Пусть есть сайт на сервере, клиент с браузером.
Наиболее простой способ авторизации - проверка пароля,
но передавать пароль в открытом виде - чревато его перехватом.
Обычно, в базах данных, хранят хэш пароля, но и хэш пароля можно перехватить, блядь, и использовать его как пароль.
Авторизация по кукам, чревата угоном сессии, через пиздинг кук из заголовков запроса, оседающих на снифферах.
Как вариант, передач кук только по HTTPS,
для этого есть флаг Secure
Но HTTPS можно замитмать, если подписать левый сертификат ключе корневого.
CSRF-атака, вообще не требует доступа к кукам, а производится через фишинговый сайт.
Здесь, мы поговорим, о самых различных способах авторизации и аутентификации,
желательно анонимной, или полуанонимной, защищённой от перехвата и MITM-атак,
а также попробуем синтезировать наиболее простую и наиболее эффективную схему,
регистрации-авторизации пользователя на сайте, с проверкой подлинности его,
такую, чтобы регистрационных данных клиента, было как можно меньше,
чтобы не вводить кучу данных в кучу полей, на каждом говносайте,
ибо это заёбует - пиздец как.
Всякие там токены-хуёкины, дополнительные ключи, таймштампы-хуямпы, всю хуйню скидывайте здесь кароч, вместе со схемами.
М)Теперь это также авторизации тред.
Пусть есть сайт на сервере, клиент с браузером.
Наиболее простой способ авторизации - проверка пароля,
но передавать пароль в открытом виде - чревато его перехватом.
Обычно, в базах данных, хранят хэш пароля, но и хэш пароля можно перехватить, блядь, и использовать его как пароль.
Авторизация по кукам, чревата угоном сессии, через пиздинг кук из заголовков запроса, оседающих на снифферах.
Как вариант, передач кук только по HTTPS,
для этого есть флаг Secure
>Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure;
Но HTTPS можно замитмать, если подписать левый сертификат ключе корневого.
CSRF-атака, вообще не требует доступа к кукам, а производится через фишинговый сайт.
Здесь, мы поговорим, о самых различных способах авторизации и аутентификации,
желательно анонимной, или полуанонимной, защищённой от перехвата и MITM-атак,
а также попробуем синтезировать наиболее простую и наиболее эффективную схему,
регистрации-авторизации пользователя на сайте, с проверкой подлинности его,
такую, чтобы регистрационных данных клиента, было как можно меньше,
чтобы не вводить кучу данных в кучу полей, на каждом говносайте,
ибо это заёбует - пиздец как.
Всякие там токены-хуёкины, дополнительные ключи, таймштампы-хуямпы, всю хуйню скидывайте здесь кароч, вместе со схемами.
>>035184 (OP)
То есть нельзя.
/thread
> Но HTTPS можно замитмать, если подписать левый сертификат ключе корневого.
То есть нельзя.
/thread
>>035184 (OP)
Самый простой способ - это:
1. еmail/мобильник + пароль + одноразовый код с емейла/мобильника.
Емейл/мобильник и пароль - в базе данных, одноразовый код - генерируется рандомно.
Но для этого, надо слать эти коды на почту или на мобильник,
то есть надо подключить говносайт ко всей этой хуйне.
Как вариант, может быть также:
2. Генерация JavaScript'ом, на клиенте - двух RSA-ключей, публичного и приватного.
Сохранение тройки: user, password, UserPubKey
Ну и отправка одноразового кода в браузер, при входе с логином-паролем,
и возврат подписи приватным ключем клиента,
с последующей проверкой подписи по пабкею.
В таком случае (2.) не нужно смс и почта вообще,
надо просто приватник чтобы был у клиента,
и он может висеть где-то в LocalStorage, будучи зашифрован хэшем пароля, там.
В варианте (1.) и (2.), пароль могут спиздить из базы данных.
Поэтому следует хранить там хэш пароля, а не сам пароль.
Но если приватный ключ потеряется, или если клиент забудет пароль,
то с восстановлением этих данных, могут возникнуть проблемы,
поэтому, как вариант, можно хранить зашифрованный пароль в БД,
и шифровать его специальным публичным RSA-ключем сервера,
и только при необходимости восстановить доступ, расшифровывать эти данные - приватным ключем сервера.
Например, при корректном ответе на секретный вопрос.
Тогда, в таблицу базы данных, добавляется ещё четыре столбца:
ЗашифрованныйПароль, ЗашифрованныйПриватник, Секретный вопрос, и ХэшОтветаНаСекретныйВопрос.
Чтобы не передавать ОтветНаСекретныйВопрос, или же ХэшОтветаНаСекретныйВопрос, при восстановлении доступа,
ведь эти данные могут быть перехвачены,
можно сгенерировать дополнительный ClientID,
и сделать так, и на клиенте:
передать эту залупу - на сервер, и там же это и вычислить, и сверить.
При этом hash(answer),
а при его установке (при регистрации), он может быть зашифрован рса-пакеем сервера, как впрочем и хэш пароля, и Приватник тоже.
Если ОтветНаСекретныйВопрос введён верно, то ЗашифрованныйПриватник, ЗашифрованныйПароль, и Пабкей - можно сменить,
но не передавать их в расшифрованном виде, потому что они могут быть перехвачены.
Самый простой способ - это:
1. еmail/мобильник + пароль + одноразовый код с емейла/мобильника.
Емейл/мобильник и пароль - в базе данных, одноразовый код - генерируется рандомно.
Но для этого, надо слать эти коды на почту или на мобильник,
то есть надо подключить говносайт ко всей этой хуйне.
Как вариант, может быть также:
2. Генерация JavaScript'ом, на клиенте - двух RSA-ключей, публичного и приватного.
Сохранение тройки: user, password, UserPubKey
Ну и отправка одноразового кода в браузер, при входе с логином-паролем,
и возврат подписи приватным ключем клиента,
с последующей проверкой подписи по пабкею.
В таком случае (2.) не нужно смс и почта вообще,
надо просто приватник чтобы был у клиента,
и он может висеть где-то в LocalStorage, будучи зашифрован хэшем пароля, там.
В варианте (1.) и (2.), пароль могут спиздить из базы данных.
Поэтому следует хранить там хэш пароля, а не сам пароль.
Но если приватный ключ потеряется, или если клиент забудет пароль,
то с восстановлением этих данных, могут возникнуть проблемы,
поэтому, как вариант, можно хранить зашифрованный пароль в БД,
и шифровать его специальным публичным RSA-ключем сервера,
и только при необходимости восстановить доступ, расшифровывать эти данные - приватным ключем сервера.
Например, при корректном ответе на секретный вопрос.
Тогда, в таблицу базы данных, добавляется ещё четыре столбца:
ЗашифрованныйПароль, ЗашифрованныйПриватник, Секретный вопрос, и ХэшОтветаНаСекретныйВопрос.
Чтобы не передавать ОтветНаСекретныйВопрос, или же ХэшОтветаНаСекретныйВопрос, при восстановлении доступа,
ведь эти данные могут быть перехвачены,
можно сгенерировать дополнительный ClientID,
и сделать так, и на клиенте:
>SaltedAnswer = hash(hash(answer) + ClientID)
передать эту залупу - на сервер, и там же это и вычислить, и сверить.
При этом hash(answer),
а при его установке (при регистрации), он может быть зашифрован рса-пакеем сервера, как впрочем и хэш пароля, и Приватник тоже.
Если ОтветНаСекретныйВопрос введён верно, то ЗашифрованныйПриватник, ЗашифрованныйПароль, и Пабкей - можно сменить,
но не передавать их в расшифрованном виде, потому что они могут быть перехвачены.
>>035184 (OP)
Самый простой способ - это:
1. еmail/мобильник + пароль + одноразовый код с емейла/мобильника.
Емейл/мобильник и пароль - в базе данных, одноразовый код - генерируется рандомно.
Но для этого, надо слать эти коды на почту или на мобильник,
то есть надо подключить говносайт ко всей этой хуйне.
Как вариант, может быть также:
2. Генерация JavaScript'ом, на клиенте - двух RSA-ключей, публичного и приватного.
Сохранение тройки: user, password, UserPubKey
Ну и отправка одноразового кода в браузер, при входе с логином-паролем,
и возврат подписи приватным ключем клиента,
с последующей проверкой подписи по пабкею.
В таком случае (2.) не нужно смс и почта вообще,
надо просто приватник чтобы был у клиента,
и он может висеть где-то в LocalStorage, будучи зашифрован хэшем пароля, там.
В варианте (1.) и (2.), пароль могут спиздить из базы данных.
Поэтому следует хранить там хэш пароля, а не сам пароль.
Но если приватный ключ потеряется, или если клиент забудет пароль,
то с восстановлением этих данных, могут возникнуть проблемы,
поэтому, как вариант, можно хранить зашифрованный пароль в БД,
и шифровать его специальным публичным RSA-ключем сервера,
и только при необходимости восстановить доступ, расшифровывать эти данные - приватным ключем сервера.
Например, при корректном ответе на секретный вопрос.
Тогда, в таблицу базы данных, добавляется ещё четыре столбца:
ЗашифрованныйПароль, ЗашифрованныйПриватник, Секретный вопрос, и ХэшОтветаНаСекретныйВопрос.
Чтобы не передавать ОтветНаСекретныйВопрос, или же ХэшОтветаНаСекретныйВопрос, при восстановлении доступа,
ведь эти данные могут быть перехвачены,
можно сгенерировать дополнительный ClientID,
и сделать так, и на клиенте:
передать эту залупу - на сервер, и там же это и вычислить, и сверить.
При этом hash(answer),
а при его установке (при регистрации), он может быть зашифрован рса-пакеем сервера, как впрочем и хэш пароля, и Приватник тоже.
Если ОтветНаСекретныйВопрос введён верно, то ЗашифрованныйПриватник, ЗашифрованныйПароль, и Пабкей - можно сменить,
но не передавать их в расшифрованном виде, потому что они могут быть перехвачены.
Самый простой способ - это:
1. еmail/мобильник + пароль + одноразовый код с емейла/мобильника.
Емейл/мобильник и пароль - в базе данных, одноразовый код - генерируется рандомно.
Но для этого, надо слать эти коды на почту или на мобильник,
то есть надо подключить говносайт ко всей этой хуйне.
Как вариант, может быть также:
2. Генерация JavaScript'ом, на клиенте - двух RSA-ключей, публичного и приватного.
Сохранение тройки: user, password, UserPubKey
Ну и отправка одноразового кода в браузер, при входе с логином-паролем,
и возврат подписи приватным ключем клиента,
с последующей проверкой подписи по пабкею.
В таком случае (2.) не нужно смс и почта вообще,
надо просто приватник чтобы был у клиента,
и он может висеть где-то в LocalStorage, будучи зашифрован хэшем пароля, там.
В варианте (1.) и (2.), пароль могут спиздить из базы данных.
Поэтому следует хранить там хэш пароля, а не сам пароль.
Но если приватный ключ потеряется, или если клиент забудет пароль,
то с восстановлением этих данных, могут возникнуть проблемы,
поэтому, как вариант, можно хранить зашифрованный пароль в БД,
и шифровать его специальным публичным RSA-ключем сервера,
и только при необходимости восстановить доступ, расшифровывать эти данные - приватным ключем сервера.
Например, при корректном ответе на секретный вопрос.
Тогда, в таблицу базы данных, добавляется ещё четыре столбца:
ЗашифрованныйПароль, ЗашифрованныйПриватник, Секретный вопрос, и ХэшОтветаНаСекретныйВопрос.
Чтобы не передавать ОтветНаСекретныйВопрос, или же ХэшОтветаНаСекретныйВопрос, при восстановлении доступа,
ведь эти данные могут быть перехвачены,
можно сгенерировать дополнительный ClientID,
и сделать так, и на клиенте:
>SaltedAnswer = hash(hash(answer) + ClientID)
передать эту залупу - на сервер, и там же это и вычислить, и сверить.
При этом hash(answer),
а при его установке (при регистрации), он может быть зашифрован рса-пакеем сервера, как впрочем и хэш пароля, и Приватник тоже.
Если ОтветНаСекретныйВопрос введён верно, то ЗашифрованныйПриватник, ЗашифрованныйПароль, и Пабкей - можно сменить,
но не передавать их в расшифрованном виде, потому что они могут быть перехвачены.
>>035193
Сайт не может его "присунуть". Он уже был в браузере, это тупо Let's Encrypt. Браузер просто говорит, что с ним что-то не так, но он был у тебя с самого начала.
Сайт не может его "присунуть". Он уже был в браузере, это тупо Let's Encrypt. Браузер просто говорит, что с ним что-то не так, но он был у тебя с самого начала.
>>035265
В этот момент браузер ругнётся на сертификат от неизвестного CA или подпись. Даже до проверки origin не доберётся. Пользователь может, конечно, нажать на "Подтвердить" в предупреждении браузера, но это примерно как рассуждать, что пользователь может установить сертификат CA сам (хотя и правда может, если качает софт откуда попало).
> Certificateattacker
В этот момент браузер ругнётся на сертификат от неизвестного CA или подпись. Даже до проверки origin не доберётся. Пользователь может, конечно, нажать на "Подтвердить" в предупреждении браузера, но это примерно как рассуждать, что пользователь может установить сертификат CA сам (хотя и правда может, если качает софт откуда попало).
>>035184 (OP)
От CSRF может защитить токен доступа с рандомной солью от сервера.
При CSRF куки не пиздят, просто через фишинговый сайт юзеру подсовывается форма какая-то, и он сам вводит данные или делает что-то от своего имени, со своей кукой.
Если владелец такого говносайта не знает КукуЮзера, то он не сможет вычислить токен, даже зная соль от сервера, перехватив её на сниффере, скажем, но это маловероятно уже, хотя...
Чтобы с базы не спиздили пароль, можно хранить там хэш пароля.
При авторизации, получив СольОтСервера - не передавать ХэшПароля - вообще, а передавать нечто вроде:
то же самое вычислять на сервере, доставая ХэшПароля из базы.
Но если, на этапе самой регистрации, передавать хэш-пароля в открытом виде, то его может спиздить и сниффер и митмщик,
и в случае отсутствия защиты входа, они могут залезть с этим ХэшемПароля - в акк.
А вот логин по кукам есть на множестве говносайтов,
и куки действительно могут тупо перехватить, и логиниться по ним.
Поэтому, можно пхать в куки
тогда, сниффер, спиздивший куки,
при попытке зайти - будет выкинут из акка, и пойдёт нахуй на перелогин.
Но в случае, если клиент заходит с куками, через митмщика,
тогда митмщик будет прозрачно проксировать запросы клиента, пхая туда, в заголовки - уже свой айпишник и юзерагент.
При этом, перехватив куки-хуюки, митмщик может логиниться с ними даже не зная ХэшПароля, скажем.
Чтобы этой хуйни не было, можно юзать одноразовый код на емейл/телефон,
а также уведомления туда, о попытках несанкционированного доступа, то есть входа с другими юзерагентом/айпишником, и возможностью - обнулить куки там, путём банального перелогина, при подозрительной активности.
Ну или подпись СолиОтСервера, приватным рса-ключем клиента, с проверкой подписи по пабкею, что хранится в базе, вместе с данными клиента.
рса-ключи можно было бы генерировать жаваскриптом, а хранить в локалстораже, зашифровав их паролем,
однако в случае утери доступа к приватнику, восстановить бы его,
для этого, можно было бы отправить его вместе с данными на сервер, и засунуть в базу, но не просто засунуть приватник, в открытом виде, а зашифровать его, внезапно, специальным, отдельным, публичным рса-ключем сервера.
При восстановлении доступа, ответив на секретный вопрос, хэш ответа от которого хранится тоже в базе,
можно было бы инициализировать расшифровку специальным приватным ключем, или же, что ещё лучше, чтобы не хранить его на сервере - отправить заявку на восстановление доступа, в течении надцати часов.
Можно было бы просто перегенерировать пару, после ответа на секретный вопрос, хэш ответа от которого - хранится в базе,
тогда хранить зашифрованный приватник не имеет смысла,
но всё замкнётся на секретный вопрос, как на пароль, и его могут спиздить или выпытать, методом социальной инженерии,
или напоить, или снотворного дать в какой-нить больничке, а потом психику обработать, или мозги просканировать, и вот так
- спиздить данные прямо из нервов, из мозгов, где нейросети срабатывают.
От CSRF может защитить токен доступа с рандомной солью от сервера.
>токен = хэш(КукаЮзера+соль_от_сервера)
При CSRF куки не пиздят, просто через фишинговый сайт юзеру подсовывается форма какая-то, и он сам вводит данные или делает что-то от своего имени, со своей кукой.
Если владелец такого говносайта не знает КукуЮзера, то он не сможет вычислить токен, даже зная соль от сервера, перехватив её на сниффере, скажем, но это маловероятно уже, хотя...
Чтобы с базы не спиздили пароль, можно хранить там хэш пароля.
При авторизации, получив СольОтСервера - не передавать ХэшПароля - вообще, а передавать нечто вроде:
>хэш(ХэшПароля+СольОтСервера)
то же самое вычислять на сервере, доставая ХэшПароля из базы.
Но если, на этапе самой регистрации, передавать хэш-пароля в открытом виде, то его может спиздить и сниффер и митмщик,
и в случае отсутствия защиты входа, они могут залезть с этим ХэшемПароля - в акк.
А вот логин по кукам есть на множестве говносайтов,
и куки действительно могут тупо перехватить, и логиниться по ним.
Поэтому, можно пхать в куки
>хэш(UserAgent+clientIP+(инфа клиента, хэш пароля скажем))
тогда, сниффер, спиздивший куки,
при попытке зайти - будет выкинут из акка, и пойдёт нахуй на перелогин.
Но в случае, если клиент заходит с куками, через митмщика,
тогда митмщик будет прозрачно проксировать запросы клиента, пхая туда, в заголовки - уже свой айпишник и юзерагент.
При этом, перехватив куки-хуюки, митмщик может логиниться с ними даже не зная ХэшПароля, скажем.
Чтобы этой хуйни не было, можно юзать одноразовый код на емейл/телефон,
а также уведомления туда, о попытках несанкционированного доступа, то есть входа с другими юзерагентом/айпишником, и возможностью - обнулить куки там, путём банального перелогина, при подозрительной активности.
Ну или подпись СолиОтСервера, приватным рса-ключем клиента, с проверкой подписи по пабкею, что хранится в базе, вместе с данными клиента.
рса-ключи можно было бы генерировать жаваскриптом, а хранить в локалстораже, зашифровав их паролем,
однако в случае утери доступа к приватнику, восстановить бы его,
для этого, можно было бы отправить его вместе с данными на сервер, и засунуть в базу, но не просто засунуть приватник, в открытом виде, а зашифровать его, внезапно, специальным, отдельным, публичным рса-ключем сервера.
При восстановлении доступа, ответив на секретный вопрос, хэш ответа от которого хранится тоже в базе,
можно было бы инициализировать расшифровку специальным приватным ключем, или же, что ещё лучше, чтобы не хранить его на сервере - отправить заявку на восстановление доступа, в течении надцати часов.
Можно было бы просто перегенерировать пару, после ответа на секретный вопрос, хэш ответа от которого - хранится в базе,
тогда хранить зашифрованный приватник не имеет смысла,
но всё замкнётся на секретный вопрос, как на пароль, и его могут спиздить или выпытать, методом социальной инженерии,
или напоить, или снотворного дать в какой-нить больничке, а потом психику обработать, или мозги просканировать, и вот так
- спиздить данные прямо из нервов, из мозгов, где нейросети срабатывают.
>>035184 (OP)
От CSRF может защитить токен доступа с рандомной солью от сервера.
При CSRF куки не пиздят, просто через фишинговый сайт юзеру подсовывается форма какая-то, и он сам вводит данные или делает что-то от своего имени, со своей кукой.
Если владелец такого говносайта не знает КукуЮзера, то он не сможет вычислить токен, даже зная соль от сервера, перехватив её на сниффере, скажем, но это маловероятно уже, хотя...
Чтобы с базы не спиздили пароль, можно хранить там хэш пароля.
При авторизации, получив СольОтСервера - не передавать ХэшПароля - вообще, а передавать нечто вроде:
то же самое вычислять на сервере, доставая ХэшПароля из базы.
Но если, на этапе самой регистрации, передавать хэш-пароля в открытом виде, то его может спиздить и сниффер и митмщик,
и в случае отсутствия защиты входа, они могут залезть с этим ХэшемПароля - в акк.
А вот логин по кукам есть на множестве говносайтов,
и куки действительно могут тупо перехватить, и логиниться по ним.
Поэтому, можно пхать в куки
тогда, сниффер, спиздивший куки,
при попытке зайти - будет выкинут из акка, и пойдёт нахуй на перелогин.
Но в случае, если клиент заходит с куками, через митмщика,
тогда митмщик будет прозрачно проксировать запросы клиента, пхая туда, в заголовки - уже свой айпишник и юзерагент.
При этом, перехватив куки-хуюки, митмщик может логиниться с ними даже не зная ХэшПароля, скажем.
Чтобы этой хуйни не было, можно юзать одноразовый код на емейл/телефон,
а также уведомления туда, о попытках несанкционированного доступа, то есть входа с другими юзерагентом/айпишником, и возможностью - обнулить куки там, путём банального перелогина, при подозрительной активности.
Ну или подпись СолиОтСервера, приватным рса-ключем клиента, с проверкой подписи по пабкею, что хранится в базе, вместе с данными клиента.
рса-ключи можно было бы генерировать жаваскриптом, а хранить в локалстораже, зашифровав их паролем,
однако в случае утери доступа к приватнику, восстановить бы его,
для этого, можно было бы отправить его вместе с данными на сервер, и засунуть в базу, но не просто засунуть приватник, в открытом виде, а зашифровать его, внезапно, специальным, отдельным, публичным рса-ключем сервера.
При восстановлении доступа, ответив на секретный вопрос, хэш ответа от которого хранится тоже в базе,
можно было бы инициализировать расшифровку специальным приватным ключем, или же, что ещё лучше, чтобы не хранить его на сервере - отправить заявку на восстановление доступа, в течении надцати часов.
Можно было бы просто перегенерировать пару, после ответа на секретный вопрос, хэш ответа от которого - хранится в базе,
тогда хранить зашифрованный приватник не имеет смысла,
но всё замкнётся на секретный вопрос, как на пароль, и его могут спиздить или выпытать, методом социальной инженерии,
или напоить, или снотворного дать в какой-нить больничке, а потом психику обработать, или мозги просканировать, и вот так
- спиздить данные прямо из нервов, из мозгов, где нейросети срабатывают.
От CSRF может защитить токен доступа с рандомной солью от сервера.
>токен = хэш(КукаЮзера+соль_от_сервера)
При CSRF куки не пиздят, просто через фишинговый сайт юзеру подсовывается форма какая-то, и он сам вводит данные или делает что-то от своего имени, со своей кукой.
Если владелец такого говносайта не знает КукуЮзера, то он не сможет вычислить токен, даже зная соль от сервера, перехватив её на сниффере, скажем, но это маловероятно уже, хотя...
Чтобы с базы не спиздили пароль, можно хранить там хэш пароля.
При авторизации, получив СольОтСервера - не передавать ХэшПароля - вообще, а передавать нечто вроде:
>хэш(ХэшПароля+СольОтСервера)
то же самое вычислять на сервере, доставая ХэшПароля из базы.
Но если, на этапе самой регистрации, передавать хэш-пароля в открытом виде, то его может спиздить и сниффер и митмщик,
и в случае отсутствия защиты входа, они могут залезть с этим ХэшемПароля - в акк.
А вот логин по кукам есть на множестве говносайтов,
и куки действительно могут тупо перехватить, и логиниться по ним.
Поэтому, можно пхать в куки
>хэш(UserAgent+clientIP+(инфа клиента, хэш пароля скажем))
тогда, сниффер, спиздивший куки,
при попытке зайти - будет выкинут из акка, и пойдёт нахуй на перелогин.
Но в случае, если клиент заходит с куками, через митмщика,
тогда митмщик будет прозрачно проксировать запросы клиента, пхая туда, в заголовки - уже свой айпишник и юзерагент.
При этом, перехватив куки-хуюки, митмщик может логиниться с ними даже не зная ХэшПароля, скажем.
Чтобы этой хуйни не было, можно юзать одноразовый код на емейл/телефон,
а также уведомления туда, о попытках несанкционированного доступа, то есть входа с другими юзерагентом/айпишником, и возможностью - обнулить куки там, путём банального перелогина, при подозрительной активности.
Ну или подпись СолиОтСервера, приватным рса-ключем клиента, с проверкой подписи по пабкею, что хранится в базе, вместе с данными клиента.
рса-ключи можно было бы генерировать жаваскриптом, а хранить в локалстораже, зашифровав их паролем,
однако в случае утери доступа к приватнику, восстановить бы его,
для этого, можно было бы отправить его вместе с данными на сервер, и засунуть в базу, но не просто засунуть приватник, в открытом виде, а зашифровать его, внезапно, специальным, отдельным, публичным рса-ключем сервера.
При восстановлении доступа, ответив на секретный вопрос, хэш ответа от которого хранится тоже в базе,
можно было бы инициализировать расшифровку специальным приватным ключем, или же, что ещё лучше, чтобы не хранить его на сервере - отправить заявку на восстановление доступа, в течении надцати часов.
Можно было бы просто перегенерировать пару, после ответа на секретный вопрос, хэш ответа от которого - хранится в базе,
тогда хранить зашифрованный приватник не имеет смысла,
но всё замкнётся на секретный вопрос, как на пароль, и его могут спиздить или выпытать, методом социальной инженерии,
или напоить, или снотворного дать в какой-нить больничке, а потом психику обработать, или мозги просканировать, и вот так
- спиздить данные прямо из нервов, из мозгов, где нейросети срабатывают.
>>035365
Алсо, здесь: https://2ch.hk/pr/res/2027019.html#2034080 (М)
анон говорил о неких тайм-кодах.
Не ебу что это такое и как юзать,
но я вижу это, примерно так:
Ну и собственно, на сервере, интервал заданный, скажем час активна кука.
Если в течении часа юзер заходит с этой же кукой - она пашет.
Если через два часа, то - перелогин.
Нахрена это надо? А например, чтобы куки не были статичными, и пожизненными,
и чтобы они менялись, и чтобы перехват их, быстро делал их неактуальными, в течении некоего времени.
Алсо, здесь: https://2ch.hk/pr/res/2027019.html#2034080 (
М)анон говорил о неких тайм-кодах.
Не ебу что это такое и как юзать,
но я вижу это, примерно так:
>ХуйняВКуках = Таймштамп+ хэш(ЮзерАгент+ЮзерАйпи+ХэшПароля+Таймштамп)
Ну и собственно, на сервере, интервал заданный, скажем час активна кука.
Если в течении часа юзер заходит с этой же кукой - она пашет.
Если через два часа, то - перелогин.
Нахрена это надо? А например, чтобы куки не были статичными, и пожизненными,
и чтобы они менялись, и чтобы перехват их, быстро делал их неактуальными, в течении некоего времени.
>>035365
>>035369
А есть способ попроще защитить куки от перехват mitm-атакером?
Чтобы без телефонов и емейлов всяких, и подписей?
Вот зарегистрировался, я, на сайте каком-то, и нажал кнопку - "запомнить меня".
Что-то там - прописалось в куки.
При обновлении страницы, я в аккаунте снова, потому что кука есть.
Но если митмщик будет проксировать запросы, он может перехватить куки, юзерагент и IP, будет его же, а значит он, зная куки, может зайти в акк.
Тогда, если каждый раз слать код на мыло или на тел,
или если шифровать рса-ключами, JavaScript'ом,
то придётся производить все эти операции при каждом обновлении страницы, штоле?
Можно как-то попроще послать нахуй митмщика?
Ну, кроме HTTPS, разумеется.
>>035369
А есть способ попроще защитить куки от перехват mitm-атакером?
Чтобы без телефонов и емейлов всяких, и подписей?
Вот зарегистрировался, я, на сайте каком-то, и нажал кнопку - "запомнить меня".
Что-то там - прописалось в куки.
При обновлении страницы, я в аккаунте снова, потому что кука есть.
Но если митмщик будет проксировать запросы, он может перехватить куки, юзерагент и IP, будет его же, а значит он, зная куки, может зайти в акк.
Тогда, если каждый раз слать код на мыло или на тел,
или если шифровать рса-ключами, JavaScript'ом,
то придётся производить все эти операции при каждом обновлении страницы, штоле?
Можно как-то попроще послать нахуй митмщика?
Ну, кроме HTTPS, разумеется.
>>035184 (OP)
>>035365
Из базы могут спиздить хэш пароля, и перехватив СольОтСервера - вычислить
и зайти из любого места, даже не зная пароля, блядь.
Поэтому, можно сделать так: https://habr.com/ru/post/120380/
1. Сервер хранит ХэшПароляВбд в базе.
2. Клиент хочет зайти и шлёт логин.
3. Сервер шлёт
4. Клиент вводит Пароль, получает ХэшПароля, и вычисляет
и шлёт на сервер
6. Сервер зная rnd получает
Затем считает
и сравнивает ХэшПароля с ХэшПароляВбд.
Здесь, взлом базы, и доступ к ХэшПароляВбд может дать разве что неактуальное и одноразовое число rnd
и зайти из любого места уже не получится.
Однако, зная ХэшПароляВбд, и перехватив КриптоХэш на сниффере,
можно вычислить rnd,
а перехватив КриптоПароль в ответе клиента,
и зная rnd - можно получить голый пароль, и спиздить пароль, блядь.
Шоб такой хуйни не было, надо, походу, квантовой криптографией всё это дело, сверхуй, обмазать.
>>035365
>Чтобы с базы не спиздили пароль, можно хранить там хэш пароля.
>При авторизации, получив СольОтСервера - не передавать ХэшПароля - вообще, а передавать нечто вроде:
>>хэш(ХэшПароля+СольОтСервера)
>то же самое вычислять на сервере, доставая ХэшПароля из базы.
Из базы могут спиздить хэш пароля, и перехватив СольОтСервера - вычислить
>хэш(ХэшПароля+СольОтСервера)
и зайти из любого места, даже не зная пароля, блядь.
Поэтому, можно сделать так: https://habr.com/ru/post/120380/
1. Сервер хранит ХэшПароляВбд в базе.
2. Клиент хочет зайти и шлёт логин.
3. Сервер шлёт
>КриптоХэш = ХэшПароляВбд XOR rnd, где rnd - случайное значение.
4. Клиент вводит Пароль, получает ХэшПароля, и вычисляет
>rnd = КриптоХэш XOR ХэшПароля,
и шлёт на сервер
>КриптоПароль = rnd XOR Пароль.
6. Сервер зная rnd получает
>Пароль = КриптоПароль XOR rnd
Затем считает
>ХэшПароля = хэш(Пароль)
и сравнивает ХэшПароля с ХэшПароляВбд.
Здесь, взлом базы, и доступ к ХэшПароляВбд может дать разве что неактуальное и одноразовое число rnd
и зайти из любого места уже не получится.
Однако, зная ХэшПароляВбд, и перехватив КриптоХэш на сниффере,
можно вычислить rnd,
а перехватив КриптоПароль в ответе клиента,
и зная rnd - можно получить голый пароль, и спиздить пароль, блядь.
Шоб такой хуйни не было, надо, походу, квантовой криптографией всё это дело, сверхуй, обмазать.
>>035184 (OP)
>>035365
Из базы могут спиздить хэш пароля, и перехватив СольОтСервера - вычислить
и зайти из любого места, даже не зная пароля, блядь.
Поэтому, можно сделать так: https://habr.com/ru/post/120380/
1. Сервер хранит ХэшПароляВбд в базе.
2. Клиент хочет зайти и шлёт логин.
3. Сервер шлёт
4. Клиент вводит Пароль, получает ХэшПароля, и вычисляет
и шлёт на сервер
6. Сервер зная rnd получает
Затем считает
и сравнивает ХэшПароля с ХэшПароляВбд.
Здесь, взлом базы, и доступ к ХэшПароляВбд может дать разве что неактуальное и одноразовое число rnd
и зайти из любого места уже не получится.
Однако, зная ХэшПароляВбд, и перехватив КриптоХэш на сниффере,
можно вычислить rnd,
а перехватив КриптоПароль в ответе клиента,
и зная rnd - можно получить голый пароль, и спиздить пароль, блядь.
Шоб такой хуйни не было, надо, походу, квантовой криптографией всё это дело, сверхуй, обмазать.
>>035365
>Чтобы с базы не спиздили пароль, можно хранить там хэш пароля.
>При авторизации, получив СольОтСервера - не передавать ХэшПароля - вообще, а передавать нечто вроде:
>>хэш(ХэшПароля+СольОтСервера)
>то же самое вычислять на сервере, доставая ХэшПароля из базы.
Из базы могут спиздить хэш пароля, и перехватив СольОтСервера - вычислить
>хэш(ХэшПароля+СольОтСервера)
и зайти из любого места, даже не зная пароля, блядь.
Поэтому, можно сделать так: https://habr.com/ru/post/120380/
1. Сервер хранит ХэшПароляВбд в базе.
2. Клиент хочет зайти и шлёт логин.
3. Сервер шлёт
>КриптоХэш = ХэшПароляВбд XOR rnd, где rnd - случайное значение.
4. Клиент вводит Пароль, получает ХэшПароля, и вычисляет
>rnd = КриптоХэш XOR ХэшПароля,
и шлёт на сервер
>КриптоПароль = rnd XOR Пароль.
6. Сервер зная rnd получает
>Пароль = КриптоПароль XOR rnd
Затем считает
>ХэшПароля = хэш(Пароль)
и сравнивает ХэшПароля с ХэшПароляВбд.
Здесь, взлом базы, и доступ к ХэшПароляВбд может дать разве что неактуальное и одноразовое число rnd
и зайти из любого места уже не получится.
Однако, зная ХэшПароляВбд, и перехватив КриптоХэш на сниффере,
можно вычислить rnd,
а перехватив КриптоПароль в ответе клиента,
и зная rnd - можно получить голый пароль, и спиздить пароль, блядь.
Шоб такой хуйни не было, надо, походу, квантовой криптографией всё это дело, сверхуй, обмазать.
>>039412
Тогда, надо слать нечто вроде
а декриптить пабкеем клиента, который генерируется при регистрации и передаётся на сервер, и хранится в базе.
Привкей можно сунуть в локалстораж, и зашифровать паролем.
А сменить его можно было бы перегенерацией, при корректном ответе на секретный вопрос.
>зная ХэшПароляВбд, и перехватив КриптоХэш на сниффере, можно вычислить rnd,
>а перехватив КриптоПароль в ответе клиента, и зная rnd - можно получить голый пароль,
>и спиздить пароль, блядь.
Тогда, надо слать нечто вроде
>encryptedPassword = rsaencrypt(password, privkey) XOR rnd
а декриптить пабкеем клиента, который генерируется при регистрации и передаётся на сервер, и хранится в базе.
Привкей можно сунуть в локалстораж, и зашифровать паролем.
А сменить его можно было бы перегенерацией, при корректном ответе на секретный вопрос.
>>039412
Если по этой схеме, отправлять много раз,
то можно, походу, вычислить биты HashPassword_db - используя частотный анализ, то есть даже не лазя в БД и не взламывая сервер.
А после этого, зная биты ХэшПароляВбд, и перехватив очередной КриптоХэш, можно вычислить и rnd, причём так же,
как делает клиент:
Ну а после перехвата, на сниффере, значения
зная rnd можно вычислить и
>>039422
Тогда уж, вместо
можно слать значение:
Но всё-равно если сервак ломанут и базу тоже, и ХэшПароляВбд достанут, то достанут и ClientPubKey, и расшифруют это
'без проблем, спиздив, втупую - пароль клиента.
Если по этой схеме, отправлять много раз,
>КриптоХэш = ХэшПароляВбд XOR rnd, где rnd - случайное значение.
то можно, походу, вычислить биты HashPassword_db - используя частотный анализ, то есть даже не лазя в БД и не взламывая сервер.
А после этого, зная биты ХэшПароляВбд, и перехватив очередной КриптоХэш, можно вычислить и rnd, причём так же,
как делает клиент:
>rnd = КриптоХэш XOR ХэшПароля,
Ну а после перехвата, на сниффере, значения
>КриптоПароль = rnd XOR Пароль.
зная rnd можно вычислить и
>Пароль = КриптоПароль XOR rnd
>>039422
>Тогда, надо слать нечто вроде
>encryptedPassword = rsaencrypt(password, privkey) XOR rnd
Тогда уж, вместо
>КриптоХэш = ХэшПароляВбд XOR rnd, где rnd - случайное значение.
можно слать значение:
>КриптоХэш = rsaencrypt(ХэшПароляВбд XOR rnd, ClientPubKey) - случайное значение.
Но всё-равно если сервак ломанут и базу тоже, и ХэшПароляВбд достанут, то достанут и ClientPubKey, и расшифруют это
>encryptedPassword = rsaencrypt(password, privkey) XOR rnd
'без проблем, спиздив, втупую - пароль клиента.
>>040499
Если не ксорить втупую, а юзать какой-нибудь AES (Rijndael), то ему уже насрать на частотный анализ.
Хотя какой может быть частотный анализ, если rnd - непредсказуемо, а ХэшПароляВбд - неизвестно, на сниффере? Частотный анализ работает, если ХэшПароляВбд - это предсказуемый текст, скажем.
Вот, скажем, ХэшПароляВбд - это сообщение,
и ты знаешь, что в сообщении ХэшПароляВбд содержится слово "Привет".
Ты расшифровываешь букву П, затем р, и дальше полагаешь, что следующие три буквы - будут "вет".
Дальше ксоришь и получаешь первые 5 символов ключа rnd.
Ну а если ХэшПароляВбд состоит только из символов английского алфавита - отфильтровываешь остальные значения, получая вероятные значения ключа rnd.
Если на том же ключе происходит шифрование ответного предсказуемого сообщения,
или если оно и вовсе известно,
то ключ может быть вскрыт, таким образом,
и дальше, вся хуйня на этом ключе зашифрованная - может быть вскрыта.
Но rnd - это одноразовый ключ, его вскрытие не имеет смысла.
>Если по этой схеме, отправлять много раз,
>>КриптоХэш = ХэшПароляВбд XOR rnd, где rnd - случайное значение.
>то можно, походу, вычислить биты ХэшПароляВбд - используя частотный анализ,
>то есть даже не лазя в БД и не взламывая сервер.
Если не ксорить втупую, а юзать какой-нибудь AES (Rijndael), то ему уже насрать на частотный анализ.
Хотя какой может быть частотный анализ, если rnd - непредсказуемо, а ХэшПароляВбд - неизвестно, на сниффере? Частотный анализ работает, если ХэшПароляВбд - это предсказуемый текст, скажем.
Вот, скажем, ХэшПароляВбд - это сообщение,
и ты знаешь, что в сообщении ХэшПароляВбд содержится слово "Привет".
Ты расшифровываешь букву П, затем р, и дальше полагаешь, что следующие три буквы - будут "вет".
Дальше ксоришь и получаешь первые 5 символов ключа rnd.
Ну а если ХэшПароляВбд состоит только из символов английского алфавита - отфильтровываешь остальные значения, получая вероятные значения ключа rnd.
Если на том же ключе происходит шифрование ответного предсказуемого сообщения,
или если оно и вовсе известно,
то ключ может быть вскрыт, таким образом,
и дальше, вся хуйня на этом ключе зашифрованная - может быть вскрыта.
Но rnd - это одноразовый ключ, его вскрытие не имеет смысла.
Храню access token в localstorage и посылаю его в заголовке Authorization. Ваши оправдания?
Bump
>>040636
Токен можно в случае чего отозвать без блокировки аккаунта, а с паролем так не выйдет.
Токен можно в случае чего отозвать без блокировки аккаунта, а с паролем так не выйдет.
>>035184 (OP)
Если "A" будет прешаренным, и "a" статичным и секретным, на сервере,
то митмщик не сможет подменить "A", и не сможет получить "K", так как надо "a".
Посему, эту схему >>039412
вместо рса, можно обмазать диффи-хелманом с прешаренным ключем.
Тогда соснёт и митмщик, и снифер, разве что кулхацкер сможет спиздить пароль.
Посмотрим чо ещё здесь аноны скажут: двач/крипт/res/46773.хтмл
>Пикрелейтед. Митм DH.
Если "A" будет прешаренным, и "a" статичным и секретным, на сервере,
то митмщик не сможет подменить "A", и не сможет получить "K", так как надо "a".
Посему, эту схему >>039412
вместо рса, можно обмазать диффи-хелманом с прешаренным ключем.
Тогда соснёт и митмщик, и снифер, разве что кулхацкер сможет спиздить пароль.
Посмотрим чо ещё здесь аноны скажут: двач/крипт/res/46773.хтмл
>>040630
Посланный токен прямым текстом оседает на снифферах.
Похуй где хранишь, главное что ты его отправляешь каждый раз.
>>040636
И каждый раз отправляется либо пароль, либо хэш пароля, который можно тупо перехватить и зайти даже не зная пароля??
>>040647
Можно просто сменить его или перегенерировать.
Или сделать временный токен, наподобие:
Который будет длинее, чем пожизненный токен:
И по длине токенов определить какой из них временный, какой постоянный.
Лучше уж временные, чтобы они ещё и менялись, если перелогин происходит откуда-то с другого места.
>Храню access token в localstorage и посылаю его в заголовке Authorization. Ваши оправдания?
Посланный токен прямым текстом оседает на снифферах.
Похуй где хранишь, главное что ты его отправляешь каждый раз.
>>040636
>Заставляю пользоателя вводить логин и пароль на КАЖДЫЙ запрос. Ваши оправдания?
И каждый раз отправляется либо пароль, либо хэш пароля, который можно тупо перехватить и зайти даже не зная пароля??
>>040647
>Токен можно в случае чего отозвать без блокировки аккаунта, а с паролем так не выйдет.
Можно просто сменить его или перегенерировать.
Или сделать временный токен, наподобие:
>токен = timestamp+хэш(ХэшПароляИВсякихДанных+timestamp)
Который будет длинее, чем пожизненный токен:
>токен = хэш(ХэшПароляИВсякихДанных)
И по длине токенов определить какой из них временный, какой постоянный.
Лучше уж временные, чтобы они ещё и менялись, если перелогин происходит откуда-то с другого места.
>>035325
Ну я же хочу зайти, а браузер не пускает. Конечно я жмакну грёбанную кнопочку, лишь бы зайти поскорее на сайт.
Ну я же хочу зайти, а браузер не пускает. Конечно я жмакну грёбанную кнопочку, лишь бы зайти поскорее на сайт.
>>040953
А ещё ты продиктуешь одноразовый код тем, кто представится службой безопасности банка, ведь ты беспокоишься о своих средствах
И вирусов с митмщиками никаких не надо, пользователи сами себя угробят, стоит лишь их попросить об этом.
А ещё ты продиктуешь одноразовый код тем, кто представится службой безопасности банка, ведь ты беспокоишься о своих средствах
И вирусов с митмщиками никаких не надо, пользователи сами себя угробят, стоит лишь их попросить об этом.
>>041126
Кстати да вот, пару раз в банке, при телефонном разговоре с поддержкой банка, у меня спрашивали ответ на секретный вопрос, мол чтобы проверить личность. И пришлось назвать, а разве не нужно, если это сотрудник службы поддержки банка?
Кстати да вот, пару раз в банке, при телефонном разговоре с поддержкой банка, у меня спрашивали ответ на секретный вопрос, мол чтобы проверить личность. И пришлось назвать, а разве не нужно, если это сотрудник службы поддержки банка?
>>035184 (OP)
Можно было бы сделать так:
1. Сервер тупо шлёт КлиентРандом каждому кто хочет зарегистрироваться или войти.
2. Клиент вводит логин, и пароль, по паролю - извлекает из локалстоража зашифрованый паролем приватник биткоина,
либо генерирует приватник биткоина,
затем получает с него адрес, сохраняет его в локалстораж и шифрует паролем,
затем - подписывает приватником КлиентРандом,
и отправляет юзернейм и подпись - на сервер.
4. Сервер по юзернейму, извлекает адрес биткоина, и если его нет - добавляет в базу вместе с юзернеймом, затем проверяет подпись, извлекает адрес из подписи, и если подпись ок, и адрес тот - временный токен доступа в куки.
Перехват КлиентРандом - нихуя не даст.
Перехват подписи - нихуя не даст.
Перехват кук может дать временный доступ в акк, либо не дать его вообще (при входе с другого юзерагента и ипа - может выбивать из акка).
Алсо, митмщик может тупо подменить адрес и подпись в процессе ретрансляции подписанного сообщения, то есть в процессе регистрации,
но можно это просечь по адресу в базе, и перерегистрироваться под другим логином, тогда.
Можно было бы сделать так:
1. Сервер тупо шлёт КлиентРандом каждому кто хочет зарегистрироваться или войти.
2. Клиент вводит логин, и пароль, по паролю - извлекает из локалстоража зашифрованый паролем приватник биткоина,
либо генерирует приватник биткоина,
затем получает с него адрес, сохраняет его в локалстораж и шифрует паролем,
затем - подписывает приватником КлиентРандом,
и отправляет юзернейм и подпись - на сервер.
4. Сервер по юзернейму, извлекает адрес биткоина, и если его нет - добавляет в базу вместе с юзернеймом, затем проверяет подпись, извлекает адрес из подписи, и если подпись ок, и адрес тот - временный токен доступа в куки.
Перехват КлиентРандом - нихуя не даст.
Перехват подписи - нихуя не даст.
Перехват кук может дать временный доступ в акк, либо не дать его вообще (при входе с другого юзерагента и ипа - может выбивать из акка).
Алсо, митмщик может тупо подменить адрес и подпись в процессе ретрансляции подписанного сообщения, то есть в процессе регистрации,
но можно это просечь по адресу в базе, и перерегистрироваться под другим логином, тогда.
>>041472
Порыл, нашёл это:
https://habr.com/ru/post/123372/
Можно использовать ECC и ECDSA. Алсо, существует алгоритм Диффи-Хелмана на эллиптических кривых - ECDH.
Порыл, нашёл это:
https://habr.com/ru/post/123372/
>Регистрация.
>Клиент выбирает login и password;
>На их основе формируется PrivateKey = SHA256(login+password);
>На основе PrivateKey формируется PublicKey;
>Login и PublicKey отправляются на сервер и сохраняются в БД.
>Аутентификация.
>Клиент вводит логин и пароль;
>На их основе формируется PrivateKey = SHA256(login+password);
>Клиент получает от сервера случайное число(RNDserver) и генерирует свое случайное число(RNDclient);
>С помощью PrivateKey клиент формирует ЭЦП Sign(SHA256(RNDserver+RNDclient))
>и отправляет на сервер Login, RNDclient и ЭЦП;
>Сервер проверяет корректность ЭЦП с помощью PublicKey клиента, хранящегося в БД.
Можно использовать ECC и ECDSA. Алсо, существует алгоритм Диффи-Хелмана на эллиптических кривых - ECDH.
>>041794
Не совсем понял что ты хотел сказать, но митмщик может подменить данные, и номер, и сервер на конкретном домене - подсунув свой сервер, и изменив айпи на свой, на замитманом днс-сервере.
>>041573
Почему бы мне на промежуточной проксе не реализовать точно такой же алгоритм и не прикинуться сервером для клиента и клиентом для сервера?
Тогда, подпись данных от сервера, рса-приватником, а пабкей - прешаренный.
В этом случае, митмщик не сунет свои данные, если пабкей будет у клиента заранее (вшит в код скрипта, скажем, выкачанного по другому каналу связи, или через торрент, хэш которого повешан в паблике или вшит в блокчейн).
>Нужно, ведь ты делаешь проверку origin, глядя на номер.
Не совсем понял что ты хотел сказать, но митмщик может подменить данные, и номер, и сервер на конкретном домене - подсунув свой сервер, и изменив айпи на свой, на замитманом днс-сервере.
>>041573
>Ну и как любой из этих алгоритмов предотвращает MITM?
Почему бы мне на промежуточной проксе не реализовать точно такой же алгоритм и не прикинуться сервером для клиента и клиентом для сервера?
Тогда, подпись данных от сервера, рса-приватником, а пабкей - прешаренный.
В этом случае, митмщик не сунет свои данные, если пабкей будет у клиента заранее (вшит в код скрипта, скажем, выкачанного по другому каналу связи, или через торрент, хэш которого повешан в паблике или вшит в блокчейн).
30 Кб, 400x240>>035184 (OP)
А что если так. На пикрил - обмен ключами (ключ К) по алгоритму Диффи-Хелмана.
1. a(секретно); - генерируется на сервере единожды.
2. A, g, p - прешаренные значения сервера для Diffie-Hellman Key-Exchange, публикуются в открытом доступе.
3. b(секретно); - генерируется на клиенте, каждый раз при каждой попытке авторизации.
4. K = A^b mod p = g^ab mod p; - общий ключ шифрования, на клиенте вычисляется.
5. B = g^b mod p; - вычисляется на клиенте.
6. B -> отправляется клиентом на сервер.
7. K = B^a mod p = g^ab mod p; - общий ключ шифрования - вычисляется на сервере.
8. СерверРандом - генерируется на сервере.
9. КриптоХэш = ХэшПароляИзБД XOR (СерверРандом XOR K); - вычисляется на сервере и отправляется клиенту.
10. ХэшПароля = Хэш(пароль); Клиент вводит пароль - получает из него хэш, на клиентской строне.
11. СерверРандом = КриптоХэш XOR (ХэшПароля XOR K); - зная хэш и общий ключ, клиент - получает СерверРандом.
12. КриптоПароль = Пароль XOR K; - клиент шифрует пароль и отправляет криптопароль на сервер.
13. ТокенДоступа = timestamp+hash(СерверРандом+timestamp) - генерация и на клиенте, и на сервере - токена доступа, который действителен час, скажем, он лезет в куки.
14. Пароль = КриптоПароль XOR K; - пароль восстанавливается на сервере для сравнения, по общему ключу шифрования К. После этого, токен доступа активен.
СерверРандом или токен достпа, может быть записан в базу данных, на время актуальности токена доступа.
Ключ K - уничтожается, он одноразовый.
А что если так. На пикрил - обмен ключами (ключ К) по алгоритму Диффи-Хелмана.
1. a(секретно); - генерируется на сервере единожды.
2. A, g, p - прешаренные значения сервера для Diffie-Hellman Key-Exchange, публикуются в открытом доступе.
3. b(секретно); - генерируется на клиенте, каждый раз при каждой попытке авторизации.
4. K = A^b mod p = g^ab mod p; - общий ключ шифрования, на клиенте вычисляется.
5. B = g^b mod p; - вычисляется на клиенте.
6. B -> отправляется клиентом на сервер.
7. K = B^a mod p = g^ab mod p; - общий ключ шифрования - вычисляется на сервере.
8. СерверРандом - генерируется на сервере.
9. КриптоХэш = ХэшПароляИзБД XOR (СерверРандом XOR K); - вычисляется на сервере и отправляется клиенту.
10. ХэшПароля = Хэш(пароль); Клиент вводит пароль - получает из него хэш, на клиентской строне.
11. СерверРандом = КриптоХэш XOR (ХэшПароля XOR K); - зная хэш и общий ключ, клиент - получает СерверРандом.
12. КриптоПароль = Пароль XOR K; - клиент шифрует пароль и отправляет криптопароль на сервер.
13. ТокенДоступа = timestamp+hash(СерверРандом+timestamp) - генерация и на клиенте, и на сервере - токена доступа, который действителен час, скажем, он лезет в куки.
14. Пароль = КриптоПароль XOR K; - пароль восстанавливается на сервере для сравнения, по общему ключу шифрования К. После этого, токен доступа активен.
СерверРандом или токен достпа, может быть записан в базу данных, на время актуальности токена доступа.
Ключ K - уничтожается, он одноразовый.
>>042081
Митмщик может тупо ретранслировать подписанное сообщение, и извлечь значение из подписанного сообщения, а ключ клиента подменить.
Чтобы этой хуйни не было, подписанное сообщение можно шифровать по ключу K , как здесь: >>042086
>Тогда, подпись данных от сервера, рса-приватником, а пабкей - прешаренный.
>В этом случае, митмщик не сунет свои данные, если пабкей будет у клиента заранее
Митмщик может тупо ретранслировать подписанное сообщение, и извлечь значение из подписанного сообщения, а ключ клиента подменить.
Чтобы этой хуйни не было, подписанное сообщение можно шифровать по ключу K , как здесь: >>042086
>>042086
Такая схема вроде бы защищена и от сниффера, и от митмщика, и от хакера, спиздившего базу данных (пароль-то он не знает, там только хэши).
Но она не защитит от хакера, который взломал серв, и знает "a", а значит и "K", а значит и пароль,
ведь значение
а ХэшПароляИзБД он будет знать.
Достаточно лишь хакер, взломаушему сервер,
перехватить данные между взломанным сервером и клиентом, и вуаля, он будет знать пароль пользователя, причём пароль в открытом виде, безо всяких хэшей-хуешей.
Впрочем, ясен хуй, что хакер, взломавший серв, может писать в базу данных что угодно,
и может даже повесить хуй на главную говносайта,
и написать маты в базу данных, где юзеры.
Стоит задуматься и над подобной угрозой,
особенно если сайт с базой данных хостится хуй знает где,
на арендованном сервере, каком-либо,
в каких-либо ебенях мухосранских.
>>035184 (OP)
А что если вместо проверки пароля или хэша пароля, путём их пересылки, и хранения хэшей в БД,
применить нечто вроде
Cудя по статье про пещеру:
https://ru.wikipedia.org/wiki/Доказательство_с_нулевым_разглашением#Пещера_нулевого_разглашения
пароль и вовсе не передаётся, а значит его нельзя перехватить,
и его не сможет перехватить даже вышеописанных хакер.
Хз, правда, как это вкодить, может кто знает?
Такая схема вроде бы защищена и от сниффера, и от митмщика, и от хакера, спиздившего базу данных (пароль-то он не знает, там только хэши).
Но она не защитит от хакера, который взломал серв, и знает "a", а значит и "K", а значит и пароль,
ведь значение
>(СерверРандом XOR K) = КриптоХэш XOR ХэшПароляИзБД
а ХэшПароляИзБД он будет знать.
Достаточно лишь хакер, взломаушему сервер,
перехватить данные между взломанным сервером и клиентом, и вуаля, он будет знать пароль пользователя, причём пароль в открытом виде, безо всяких хэшей-хуешей.
Впрочем, ясен хуй, что хакер, взломавший серв, может писать в базу данных что угодно,
и может даже повесить хуй на главную говносайта,
и написать маты в базу данных, где юзеры.
Стоит задуматься и над подобной угрозой,
особенно если сайт с базой данных хостится хуй знает где,
на арендованном сервере, каком-либо,
в каких-либо ебенях мухосранских.
>>035184 (OP)
А что если вместо проверки пароля или хэша пароля, путём их пересылки, и хранения хэшей в БД,
применить нечто вроде
>доказательства с нулевым разглашением?
Cудя по статье про пещеру:
https://ru.wikipedia.org/wiki/Доказательство_с_нулевым_разглашением#Пещера_нулевого_разглашения
пароль и вовсе не передаётся, а значит его нельзя перехватить,
и его не сможет перехватить даже вышеописанных хакер.
Хз, правда, как это вкодить, может кто знает?
>>042086
Такая схема вроде бы защищена и от сниффера, и от митмщика, и от хакера, спиздившего базу данных (пароль-то он не знает, там только хэши).
Но она не защитит от хакера, который взломал серв, и знает "a", а значит и "K", а значит и пароль,
ведь значение
а ХэшПароляИзБД он будет знать.
Достаточно лишь хакер, взломаушему сервер,
перехватить данные между взломанным сервером и клиентом, и вуаля, он будет знать пароль пользователя, причём пароль в открытом виде, безо всяких хэшей-хуешей.
Впрочем, ясен хуй, что хакер, взломавший серв, может писать в базу данных что угодно,
и может даже повесить хуй на главную говносайта,
и написать маты в базу данных, где юзеры.
Стоит задуматься и над подобной угрозой,
особенно если сайт с базой данных хостится хуй знает где,
на арендованном сервере, каком-либо,
в каких-либо ебенях мухосранских.
>>035184 (OP)
А что если вместо проверки пароля или хэша пароля, путём их пересылки, и хранения хэшей в БД,
применить нечто вроде
Cудя по статье про пещеру:
https://ru.wikipedia.org/wiki/Доказательство_с_нулевым_разглашением#Пещера_нулевого_разглашения
пароль и вовсе не передаётся, а значит его нельзя перехватить,
и его не сможет перехватить даже вышеописанных хакер.
Хз, правда, как это вкодить, может кто знает?
Такая схема вроде бы защищена и от сниффера, и от митмщика, и от хакера, спиздившего базу данных (пароль-то он не знает, там только хэши).
Но она не защитит от хакера, который взломал серв, и знает "a", а значит и "K", а значит и пароль,
ведь значение
>(СерверРандом XOR K) = КриптоХэш XOR ХэшПароляИзБД
а ХэшПароляИзБД он будет знать.
Достаточно лишь хакер, взломаушему сервер,
перехватить данные между взломанным сервером и клиентом, и вуаля, он будет знать пароль пользователя, причём пароль в открытом виде, безо всяких хэшей-хуешей.
Впрочем, ясен хуй, что хакер, взломавший серв, может писать в базу данных что угодно,
и может даже повесить хуй на главную говносайта,
и написать маты в базу данных, где юзеры.
Стоит задуматься и над подобной угрозой,
особенно если сайт с базой данных хостится хуй знает где,
на арендованном сервере, каком-либо,
в каких-либо ебенях мухосранских.
>>035184 (OP)
А что если вместо проверки пароля или хэша пароля, путём их пересылки, и хранения хэшей в БД,
применить нечто вроде
>доказательства с нулевым разглашением?
Cудя по статье про пещеру:
https://ru.wikipedia.org/wiki/Доказательство_с_нулевым_разглашением#Пещера_нулевого_разглашения
пароль и вовсе не передаётся, а значит его нельзя перехватить,
и его не сможет перехватить даже вышеописанных хакер.
Хз, правда, как это вкодить, может кто знает?
>>043448
применить нечто вроде
Вот здесь, что-то нашёл: https://sites.google.com/site/anisimovkhv/learning/kripto/lecture/tema11
но там пиздец как многабукафф...
>А что если вместо проверки пароля или хэша пароля, путём их пересылки, и хранения хэшей в БД,
применить нечто вроде
>доказательства с нулевым разглашением?
>Хз, правда, как это вкодить, может кто знает?
Вот здесь, что-то нашёл: https://sites.google.com/site/anisimovkhv/learning/kripto/lecture/tema11
но там пиздец как многабукафф...
>>043488
Походу, стоит реализовать либо это:
https://ru.wikipedia.org/wiki/Протокол_Фейга_—_Фиата_—_Шамира
Но тут s - не произвольное значение, а вычисляется особым образом.
наверное, лучше сделать нечто наподобие этого: https://ru.wikipedia.org/wiki/SRP
>Вот здесь, что-то нашёл: https://sites.google.com/site/anisimovkhv/learning/kripto/lecture/tema11
>III. Упрощенная схема аутентификации Фейге-Фиата-Шамира.
Походу, стоит реализовать либо это:
https://ru.wikipedia.org/wiki/Протокол_Фейга_—_Фиата_—_Шамира
Но тут s - не произвольное значение, а вычисляется особым образом.
наверное, лучше сделать нечто наподобие этого: https://ru.wikipedia.org/wiki/SRP
>>043710
Вот тут без этих выебонов, вроде.
https://ru.wikipedia.org/wiki/Протокол_Фиата_—_Шамира#Описание_протоколa
УМВР.
Но много раундов - много запросов, хотя можно в три запроса организовать, и JSON-ом гнать,
но как сказано там, в той статье:
Поэтому, проще использовать подписи.
Шлёшь рандом, и просишь подписать приватником.
Или шлёшь рандом, зашифрованный пабом, и просишь расшифровать приватником.
Один раунд, и приватник не передаётся, только рандом.
>Вот здесь, что-то нашёл: https://sites.google.com/site/anisimovkhv/learning/kripto/lecture/tema11
>III. Упрощенная схема аутентификации Фейге-Фиата-Шамира.
>2. Выбирает число v, являющееся квадратичным вычетом по модулю n и имеется обратное значение v-1 по модулю n.
>3Определяет закрытый ключ s - наименьшее значение, удовлетворяющее выражению s2 mod n = v-1.
>Но тут s - не произвольное значение, а вычисляется особым образом.
Вот тут без этих выебонов, вроде.
https://ru.wikipedia.org/wiki/Протокол_Фиата_—_Шамира#Описание_протоколa
УМВР.
Но много раундов - много запросов, хотя можно в три запроса организовать, и JSON-ом гнать,
но как сказано там, в той статье:
>Следует отметить, что приведенные выше протокол на базе RSA и схема Шнорра,
>по своей сути, тоже можно отнести к протоколам доказательства с нулевым разглашением.
>Ведь аутентифицируемая сторона доказывает знание секрета (закрытого ключа), не разглашая его.
>При этом процедура аутентификации носит детерминированный характер и выполняется всего за один раунд.
Поэтому, проще использовать подписи.
Шлёшь рандом, и просишь подписать приватником.
Или шлёшь рандом, зашифрованный пабом, и просишь расшифровать приватником.
Один раунд, и приватник не передаётся, только рандом.
>>035184 (OP)
А когда аутентификация без авторизации это хорошо? А авторизация без аутентицикации?
А когда аутентификация без авторизации это хорошо? А авторизация без аутентицикации?
>>045284
Шиза какая-то. Можно, наверное, представить какую-нибудь страницу проверки логина и пароля, которая просто отвечает ок/не ок, и не делает входа в систему.
В некоторых особо защищённых сетях или таких, которые защищать не нужно вообще бывает достаточно идентификации, то есть тупо назвать логин или имя компьютера. Но там авторизация косвенная всё равно есть.
> А когда аутентификация без авторизации это хорошо?
Шиза какая-то. Можно, наверное, представить какую-нибудь страницу проверки логина и пароля, которая просто отвечает ок/не ок, и не делает входа в систему.
> А авторизация без аутентицикации?
В некоторых особо защищённых сетях или таких, которые защищать не нужно вообще бывает достаточно идентификации, то есть тупо назвать логин или имя компьютера. Но там авторизация косвенная всё равно есть.
>>035184 (OP)
Может что-то вроде OAuth?
>>045284
Этот: >>045364
правильно сказал
Например, когда нужно подпись цифровую проверить,
чтобы просто ответить, тот ли чел пиздит хуйню или не тот.
В результате проверки, ты просто получаешь ответ - да/нет,
без всяких авторизаций и прочей хуйни.
Ну, например, когда надо статистику какую-то из акка в браузере прогрузить, или на бирже криптовалютной поторговать.
Нахуй вводить каждый раз пароль?
Просто заходишь, кука в браузере есть, стата вся на виду, поставил ордер, себе, и пошёл.
А вот когда надо вывести бабло с криптобиржи, надо уже подтверждение какое-то, потому что куку могут спиздить на сниффере.
А если спиздят, и натыкают хуйни, можно написать в саппорт,
и сказать мол чё за хуйня, там какой-то хуй влез с другого ип, отмените ордера, выведите бабки мои, и компенсируйте взлом, и всё такое. Вот пруф, я аутентифицирован дохуя, кароч.
А вообще, для начала, разберись во всех этих терминах, ебучих: https://wiki.diphost.ru/Authentication
Может что-то вроде OAuth?
>>045284
>А когда аутентификация без авторизации это хорошо?
Этот: >>045364
правильно сказал
Например, когда нужно подпись цифровую проверить,
чтобы просто ответить, тот ли чел пиздит хуйню или не тот.
В результате проверки, ты просто получаешь ответ - да/нет,
без всяких авторизаций и прочей хуйни.
>А авторизация без аутентицикации?
Ну, например, когда надо статистику какую-то из акка в браузере прогрузить, или на бирже криптовалютной поторговать.
Нахуй вводить каждый раз пароль?
Просто заходишь, кука в браузере есть, стата вся на виду, поставил ордер, себе, и пошёл.
А вот когда надо вывести бабло с криптобиржи, надо уже подтверждение какое-то, потому что куку могут спиздить на сниффере.
А если спиздят, и натыкают хуйни, можно написать в саппорт,
и сказать мол чё за хуйня, там какой-то хуй влез с другого ип, отмените ордера, выведите бабки мои, и компенсируйте взлом, и всё такое. Вот пруф, я аутентифицирован дохуя, кароч.
А вообще, для начала, разберись во всех этих терминах, ебучих: https://wiki.diphost.ru/Authentication
3 Кб, 261x271>>035184 (OP)
> Обычно, в базах данных, хранят хэш пароля, но и хэш пароля можно перехватить, блядь, и использовать его как пароль.
77 Кб, 1034x532>>035184 (OP)
Отвечу здесь, этому анону, из криптача: https://2ch.hk/crypt/res/32539.html#46785 (М)
Не устойчив к MITM.
Можно как-то защитить?
Ну, там через диффи-хелмана, или через подпись рса какую-нибудь?
Хотя и они MITM-аются, вот блядь... Хз, короче.
Как знать что это ключ клиента, а не MITM-щика?
Митмщик может её расшифровать, если паб митмщика в базе сервера.
Если хранить приватник на железе клиента,
то могут просто по факту доставки пакета, сделать trace route, и прийти и спиздить приватник, выколупав его из железа,
или используя хардварные закладки, спиздить прив.
А вот если в башке у клиента какой-то пароль будет, который будет знать только он, то хэш от этой хуйни, можно юзать как пруф того, что это чел.
Поэтому, как вариант, уже вижу следующее:
пароль -> хэш пароля -> приватник ECDSA -> пабкей(точка на эллиптической кривой) -> в базу пабкей или хэш пабкея.
Ну а дальше подпись. Ввёл пароль, получил хэш, получил приватник с него - и приватником сгенерил подпись.
Годно. Сходу вижу XSS-атаку, и флаг HttpOnly для кук, чтобы их не спиздили JavaScript'ом!!
Есть ещё флаг Secure, чтобы по HTTPS их отправлять, а не по Http. Тогда их будет сложнее перехватить, и придётся делать MITM-атаку на HTTPS.
Поначалу, это напрягало, по причине того, что если хранить пароль в базе или хэш пароля,
то пароль либо хэш надо каждый раз передавать, а канал-то открытый,
и перехват пароля, либо же перехват хэша пароля - может дать доступ снифферу,
без знания пароля даже.
Но если использовать ECDSA-подпись для аутентификации, то пароль из котогого генерируется ключ приватный,
он будет в секрете, и не будет передаваться по открытому каналу, только подпись цифровая.
Однако, ещё на этапе регистрации, MITM-атакер может подменить ключ.
Отвечу здесь, этому анону, из криптача: https://2ch.hk/crypt/res/32539.html#46785 (
М)>>46771
>>46782
>>46785
>TOTP
Не устойчив к MITM.
Можно как-то защитить?
Ну, там через диффи-хелмана, или через подпись рса какую-нибудь?
Хотя и они MITM-аются, вот блядь... Хз, короче.
>при реге просить публичный ключ.
Как знать что это ключ клиента, а не MITM-щика?
>при аутентификации просить расшифровать фразу, которую ты подписал имеющимся публичным ключем пользователя.
Митмщик может её расшифровать, если паб митмщика в базе сервера.
>ничего указывающего на персону пользователя хранить нельзя, т.к. любую инфу с клиента могут перехватить.
Если хранить приватник на железе клиента,
то могут просто по факту доставки пакета, сделать trace route, и прийти и спиздить приватник, выколупав его из железа,
или используя хардварные закладки, спиздить прив.
А вот если в башке у клиента какой-то пароль будет, который будет знать только он, то хэш от этой хуйни, можно юзать как пруф того, что это чел.
Поэтому, как вариант, уже вижу следующее:
пароль -> хэш пароля -> приватник ECDSA -> пабкей(точка на эллиптической кривой) -> в базу пабкей или хэш пабкея.
Ну а дальше подпись. Ввёл пароль, получил хэш, получил приватник с него - и приватником сгенерил подпись.
>на jwt посмотри для общего развития.
Годно. Сходу вижу XSS-атаку, и флаг HttpOnly для кук, чтобы их не спиздили JavaScript'ом!!
Есть ещё флаг Secure, чтобы по HTTPS их отправлять, а не по Http. Тогда их будет сложнее перехватить, и придётся делать MITM-атаку на HTTPS.
>каждый раз. настройки, статистику и прочую инфу без персонализации - храни где угодно, хоть в сессии,
>хоть явно в куках.
>надо обновить данные - проходим аутентификацию повторно.
Поначалу, это напрягало, по причине того, что если хранить пароль в базе или хэш пароля,
то пароль либо хэш надо каждый раз передавать, а канал-то открытый,
и перехват пароля, либо же перехват хэша пароля - может дать доступ снифферу,
без знания пароля даже.
Но если использовать ECDSA-подпись для аутентификации, то пароль из котогого генерируется ключ приватный,
он будет в секрете, и не будет передаваться по открытому каналу, только подпись цифровая.
Однако, ещё на этапе регистрации, MITM-атакер может подменить ключ.
77 Кб, 1034x532>>035184 (OP)
Отвечу здесь, этому анону, из криптача: https://2ch.hk/crypt/res/32539.html#46785 (М)
Не устойчив к MITM.
Можно как-то защитить?
Ну, там через диффи-хелмана, или через подпись рса какую-нибудь?
Хотя и они MITM-аются, вот блядь... Хз, короче.
Как знать что это ключ клиента, а не MITM-щика?
Митмщик может её расшифровать, если паб митмщика в базе сервера.
Если хранить приватник на железе клиента,
то могут просто по факту доставки пакета, сделать trace route, и прийти и спиздить приватник, выколупав его из железа,
или используя хардварные закладки, спиздить прив.
А вот если в башке у клиента какой-то пароль будет, который будет знать только он, то хэш от этой хуйни, можно юзать как пруф того, что это чел.
Поэтому, как вариант, уже вижу следующее:
пароль -> хэш пароля -> приватник ECDSA -> пабкей(точка на эллиптической кривой) -> в базу пабкей или хэш пабкея.
Ну а дальше подпись. Ввёл пароль, получил хэш, получил приватник с него - и приватником сгенерил подпись.
Годно. Сходу вижу XSS-атаку, и флаг HttpOnly для кук, чтобы их не спиздили JavaScript'ом!!
Есть ещё флаг Secure, чтобы по HTTPS их отправлять, а не по Http. Тогда их будет сложнее перехватить, и придётся делать MITM-атаку на HTTPS.
Поначалу, это напрягало, по причине того, что если хранить пароль в базе или хэш пароля,
то пароль либо хэш надо каждый раз передавать, а канал-то открытый,
и перехват пароля, либо же перехват хэша пароля - может дать доступ снифферу,
без знания пароля даже.
Но если использовать ECDSA-подпись для аутентификации, то пароль из котогого генерируется ключ приватный,
он будет в секрете, и не будет передаваться по открытому каналу, только подпись цифровая.
Однако, ещё на этапе регистрации, MITM-атакер может подменить ключ.
Отвечу здесь, этому анону, из криптача: https://2ch.hk/crypt/res/32539.html#46785 (
М)>>46771
>>46782
>>46785
>TOTP
Не устойчив к MITM.
Можно как-то защитить?
Ну, там через диффи-хелмана, или через подпись рса какую-нибудь?
Хотя и они MITM-аются, вот блядь... Хз, короче.
>при реге просить публичный ключ.
Как знать что это ключ клиента, а не MITM-щика?
>при аутентификации просить расшифровать фразу, которую ты подписал имеющимся публичным ключем пользователя.
Митмщик может её расшифровать, если паб митмщика в базе сервера.
>ничего указывающего на персону пользователя хранить нельзя, т.к. любую инфу с клиента могут перехватить.
Если хранить приватник на железе клиента,
то могут просто по факту доставки пакета, сделать trace route, и прийти и спиздить приватник, выколупав его из железа,
или используя хардварные закладки, спиздить прив.
А вот если в башке у клиента какой-то пароль будет, который будет знать только он, то хэш от этой хуйни, можно юзать как пруф того, что это чел.
Поэтому, как вариант, уже вижу следующее:
пароль -> хэш пароля -> приватник ECDSA -> пабкей(точка на эллиптической кривой) -> в базу пабкей или хэш пабкея.
Ну а дальше подпись. Ввёл пароль, получил хэш, получил приватник с него - и приватником сгенерил подпись.
>на jwt посмотри для общего развития.
Годно. Сходу вижу XSS-атаку, и флаг HttpOnly для кук, чтобы их не спиздили JavaScript'ом!!
Есть ещё флаг Secure, чтобы по HTTPS их отправлять, а не по Http. Тогда их будет сложнее перехватить, и придётся делать MITM-атаку на HTTPS.
>каждый раз. настройки, статистику и прочую инфу без персонализации - храни где угодно, хоть в сессии,
>хоть явно в куках.
>надо обновить данные - проходим аутентификацию повторно.
Поначалу, это напрягало, по причине того, что если хранить пароль в базе или хэш пароля,
то пароль либо хэш надо каждый раз передавать, а канал-то открытый,
и перехват пароля, либо же перехват хэша пароля - может дать доступ снифферу,
без знания пароля даже.
Но если использовать ECDSA-подпись для аутентификации, то пароль из котогого генерируется ключ приватный,
он будет в секрете, и не будет передаваться по открытому каналу, только подпись цифровая.
Однако, ещё на этапе регистрации, MITM-атакер может подменить ключ.
>>043448
Многораундовый алгоритм Фейге-Фиата-Шамира, во-первых, вероятностный, во-вторых, требует множества запросов и ответов от сервера.
Лучший способ реализации доказательства с нулевым разглашением - аутентификация по цифровой подписи.
При этом, секретный ключ не передаётся, передаётся просто подпись.
А сервер шлёт рандом для подписи.
Но, рандом может перехватить митмщик, и на этапе регистрации, подменивший ключ, и базе будет ключ митмщика, поэтому митмщик может подписывать своим приватным ключем.
Чтобы этой хуйни не было, рандом можно слать шифруя ключем K >>043710 после обмена этим ключем через Диффи-Хелмана, с прешаренными A, g, p сервера, и секретным a, на сервере, (просто чтобы митмщик их не подменил). Вот тогда-то, он и соснёт.
Многораундовый алгоритм Фейге-Фиата-Шамира, во-первых, вероятностный, во-вторых, требует множества запросов и ответов от сервера.
Лучший способ реализации доказательства с нулевым разглашением - аутентификация по цифровой подписи.
При этом, секретный ключ не передаётся, передаётся просто подпись.
А сервер шлёт рандом для подписи.
Но, рандом может перехватить митмщик, и на этапе регистрации, подменивший ключ, и базе будет ключ митмщика, поэтому митмщик может подписывать своим приватным ключем.
Чтобы этой хуйни не было, рандом можно слать шифруя ключем K >>043710 после обмена этим ключем через Диффи-Хелмана, с прешаренными A, g, p сервера, и секретным a, на сервере, (просто чтобы митмщик их не подменил). Вот тогда-то, он и соснёт.
>>045479
таки да, в схемах что я видел пароль фронт передает плейн текст пароль, а вот хешируются с сверяется с бдшным он уже на бекенде.
таки да, в схемах что я видел пароль фронт передает плейн текст пароль, а вот хешируются с сверяется с бдшным он уже на бекенде.
>>045619
А можно как-то по паролю сгенерировать RSA-приватник, чтобы не ебаццо со впиливанием ECDSA, EdDSA, и прочих Montgomery Elliptic Curve?
А можно как-то по паролю сгенерировать RSA-приватник, чтобы не ебаццо со впиливанием ECDSA, EdDSA, и прочих Montgomery Elliptic Curve?
>>047056
На этапе генерации e:
https://ru.wikipedia.org/wiki/RSA#Алгоритм_создания_открытого_и_секретного_ключей
можно выбрать такое e, которое рядом со значением хэша пароля,
а d взять мультипликативно-обратным.
При этом, в качестве паба, выдать наименьшее значение,
чтобы брутфорс другого - занимал дохуя времени.
На этапе генерации e:
https://ru.wikipedia.org/wiki/RSA#Алгоритм_создания_открытого_и_секретного_ключей
можно выбрать такое e, которое рядом со значением хэша пароля,
а d взять мультипликативно-обратным.
При этом, в качестве паба, выдать наименьшее значение,
чтобы брутфорс другого - занимал дохуя времени.
>>047230
А p, q, n как по паролю генерить? Имеет ли это смысл, или можно будет взять и сбрутить ключи - атакой по словарю, скажем?
А p, q, n как по паролю генерить? Имеет ли это смысл, или можно будет взять и сбрутить ключи - атакой по словарю, скажем?
>>035184 (OP)
Может лучше сделать так:
a - секрет на сервере;
Прешаренные (A, g, p) - висят в паблике.
Клиент генерирует b,
Клиент считает Kc = A^b mod p = g^ab mod p = g^ab mod p;
Клиент считает B = g^b mod p -> на сервер.
Сервер считает Ks = B^a mod p = g^ba mod p = g^ab mod p;
Добавляет Ks в хэш-таблицу, по ключу B;
B - прописывается в куки.
Дальше уже, симметричная криптография между клиентом и сервером, шифрованные данные передатся по HTTP в виде бинарных запросов от клиента и ответов от сервера.
Шифруются и расшифровываются прямо в браузере, JavaScript'ом, на клиентской стороне, ну и на серверной тож. Похуй каким шифром.
Сниффер - сосёт, митмщик сосёт, а вот хацкер, который получит доступ к "a", походу не соснёт, но он тогда сможет поломать всё нахуй.
Может лучше сделать так:
a - секрет на сервере;
Прешаренные (A, g, p) - висят в паблике.
Клиент генерирует b,
Клиент считает Kc = A^b mod p = g^ab mod p = g^ab mod p;
Клиент считает B = g^b mod p -> на сервер.
Сервер считает Ks = B^a mod p = g^ba mod p = g^ab mod p;
Добавляет Ks в хэш-таблицу, по ключу B;
B - прописывается в куки.
Дальше уже, симметричная криптография между клиентом и сервером, шифрованные данные передатся по HTTP в виде бинарных запросов от клиента и ответов от сервера.
Шифруются и расшифровываются прямо в браузере, JavaScript'ом, на клиентской стороне, ну и на серверной тож. Похуй каким шифром.
Сниффер - сосёт, митмщик сосёт, а вот хацкер, который получит доступ к "a", походу не соснёт, но он тогда сможет поломать всё нахуй.
>>048492
Чёт вспомнилась старая добрая схема DH+AES.
Только надо наебаться со впиливанием и на бекенде и на фронтенде - это раз.
Во вторых, что если жаваскрипт отключен в браузере?
Чёт вспомнилась старая добрая схема DH+AES.
Только надо наебаться со впиливанием и на бекенде и на фронтенде - это раз.
Во вторых, что если жаваскрипт отключен в браузере?
>>035184 (OP)
В тред врывается специалист по кукам.
Я долго выжидал, и таки-пришёл задеанонить вас по кукам.
А ну быстраблять покажите мне свои куки, и я скажу по ним, кто вы есть.
В тред врывается специалист по кукам.
Я долго выжидал, и таки-пришёл задеанонить вас по кукам.
А ну быстраблять покажите мне свои куки, и я скажу по ним, кто вы есть.
>>048492
Заебенил это вот тут вот: https://github.com/username1565/nanoboard/commit/b37d98bde5b675d53d21ab60082c0e820ea5e6cf
Заебенил это вот тут вот: https://github.com/username1565/nanoboard/commit/b37d98bde5b675d53d21ab60082c0e820ea5e6cf
Двач.hk не отвечает.
Вы видите копию треда, сохраненную 1 августа 2021 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Вы видите копию треда, сохраненную 1 августа 2021 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.