В чем недостатки такого способа авторизации?

Question

[✭ ☭]

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

Серверная php-функция принимает любые запросы:
header("Access-Control-Allow-Origin: *");

Клиент в XMLHttpRequest-запросе отправляет ключ в виде строки
запрос.send(["логин", "пароль"])

Логин и пароль это просто строки типа "ВАВВРАПРАПТАПТ"

Сервер ищет совпадение в БД и отвечает соответственно - если есть такой пользователь то отдает нужные данные или выполняет действия, и ничего не делает если нет.

Главный вопрос - насколько легко будет подобрать логин и пароль .
И что надо добавить чтобы не было недостатков и была достаточная надежность?
Если добавить ограничение по времени для повторного обращения с одного ip после неудачного - надежность такого способа будет сравнима с надежностью базовой аутентификации?

Comments

[✭ ☭]

MaxKorz, Ключ это просто строка типа "ВАВВРАПРАПТАПТ" - аналог логина-пароля

Этот ключ создает-вводит сам пользователь

Answer 1

[Павел Корнилов]

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

Comments

[✭ ☭]

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

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

[Павел Корнилов]

имя фамилия, тогда нужно ограничивать количество попыток с отдельного IP.
Я так сам организовал безопасность - N попыток неудачных - блок IP, если часто идут неудачные попытки с разных IP - подключаем фингерпринт. Если удачный вход - счётчик для конкретного IP обнуляется. Схематично - так.

[sim3x]

Зачем шифровать на стороне клиента если клмент может подменить все?
Как перехватить https?

[Павел Корнилов]

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

[Павел Корнилов]

sim3x, https - практически никак. А где о нём речь в вопросе?
Солить данные перед передачей - это не я придумал. Ну, это, конечно, актуально для http.

[sim3x]

KorniloFF, хттпс - уже давно дефолт

Что даст соление перед отправкой с клиента, если соль и вторая часть доступна клиенту?

[✭ ☭]

Nikolay Petyukh, а как настраивается предельное число запросов от одного клиента?

KorniloFF, да, конечно же хранить буду в захешированном виде.

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

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

[Павел Корнилов]

sim3x, при грамотном подходе можно значительно увеличить трудоёмкость взлома.
Впрочем, я лишь высказал своё мнение, если у вас другое - создавайте альтернативный ответ.

[Павел Корнилов]

имя фамилия, нужно иметь базу. У меня - это обычный json-файл. В нём сохраняются неудачные попытки входа с каждого IP. Удачная попытка - обнуляет.
При каждом входе проверяется эта база, если количество попыток превышено - 403.

[xmoonlight]

Nikolay Petyukh, а лучше базу и ключ к ней сделать одного размера и типа. Только одни данные будут статическими, а другие - динамическими. Можно и чередовать в едином файле. ;)

[xmoonlight]

Nikolay Petyukh, допустим. Но понял - не до конца... Поясните?

[xmoonlight]

Nikolay Petyukh,

прошлый

- это какой именно (из всех комментариев на ресурсе) и чей он?
(Просто, чтобы внести ясность и единое понимание...)

[sim3x]

KorniloFF, нет, нельзя

[Павел Корнилов]

xmoonlight, да, как вариант.

[xmoonlight]

Nikolay Petyukh, Мда... Боюсь, что промахнулись с выводами - Вы... (но не суть, правда же?...)

[Павел Корнилов]

sim3x, не понял.

[sim3x]

KorniloFF,

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

нет, нельзя

[✭ ☭]

KorniloFF, поясни пожста как шифровать ключ на клиенте и дешифровать на сервере?

И я придумал способ попроще чем тот что предложил ты с блокировкой ip.
Клиент пересылает не один ключ а два - логин и пароль.
На сервере для каждого логина есть свой txt-файл в котором записывается последняя дата входа.
При попытке входа проверяется дата - и так ограничивается частота входов.

[Павел Корнилов]

sim3x, понял =)
В принципе, вы правы, все данные на клиенте доступны анализу. А любое шифрование на клиенте можно также дешифровать. Но всё же - это повышение трудоёмкости.

имя фамилия, например, используя побитовые операции. Но это даст мало эффекта в плане защиты.
Вообще, тема пока очень сырая.
1. Шифровать на клиенте - можно перехватить уже зашифрованный ключ и отправить на сервер. При этом будет всё равно, как он выглядел до шифрования.
2. Блокировка количества попыток - при ДДОС даже с заблокированных IP сервер ляжет, поскольку ему всё равно придётся обрабатывать запросы, чтобы выдать 403.
3. Что там еще? Короче, панацеи нет. Лучшая защита - какой-нибудь секретный трюк, например, с кукисами, который редко используется и не обсуждается на форумах =)

Answer 2

[xmoonlight]

Главный вопрос - насколько легко будет подобрать ключ.

1. При перехвате - А ВОТ ОН!.
2. При переборе - достаточно долго и зависит от политики обработки пользовательских запросов сервером, но если есть вариант проще (п.1), этот не будут даже использовать.

В любом случае, предложенное - это ужасный вариант!

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

Comments

[✭ ☭]

Перехват это не мой уровень безопасности.
Мне надо попроще, и сравнимой надежности с базовой аутентификацией - при которой тоже можно перехватить логин и пароль.

Здесь был предложен вариант - Rate Limit https://httpstatuses.com/429
Если так ограничить переборщика - нормальный способ? в сравнении с базовой аутентификацией.

[xmoonlight]

имя фамилия, Про кол-во попыток для ограничения от перебора (это безопасность политики сервера) - нормальный.
Но ключ у Вас - МНОГОРАЗОВЫЙ :( и не привязанный ни к клиенту, ни к запросу. А должен быть - одноразовый!
Сейчас так у Вас: один раз перехватили и под одним акком зайдёт весь интернет!

[✭ ☭]

xmoonlight, на тостере тоже многоразовый, или на почте...

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

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

[xmoonlight]

имя фамилия, Готов ответить на вопросы из статьи.

Answer 3

[Adamos]

Прочитал описание.
А если другой пользователь скажет в качестве ключа ту же самую фразу "ВАВВРАПРАПТАПТ" - вы ему что ответите?
Тут такая уже есть, можешь входить в чужой кошелек?

Comments

[✭ ☭]

Ну а например на Тостере разве не так?
или в почте обычной.

[Adamos]

имя фамилия,

Ключ это просто строка типа "ВАВВРАПРАПТАПТ" - аналог логина-пароля

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

[✭ ☭]

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

Но говоря о тостере или почте я имел ввиду что логин всем известен.

[Adamos]

имя фамилия, может, вам подумать еще и перестать изобретать велосипеды? Знаний и опыта для того, чтобы сделать что-то оригинальное и при этом путное, вам явно не хватает.

[✭ ☭]

Adamos, это тебе не хватает ума и фантазии, спасибо, неудачник ))