Вход в админ панель по спец ключу

#php #безопасность

Когда-то делал такую авторизацию в админке. Суть заключается в следующем:

Создаем файл типа file.key.
Генерируем спец ключ с помощью crypt('string') и сохраняем в файл.
Этот же ключ записываем в БД.

Вход в админ панель происходит следующим образом:

Жмем Обзор находим на компе файлик, и жмем отправить.
Считываем файлик и сверяем с тем, что записан в БД. Все совпадает, милости просим.
+ (считываем расширение файла, т.к. его можно придумать вообще каким угодно)

Удобно если:

Система не будет передаваться или продаваться.
Системой пользуется ограниченное количество людей (допустим, в офисе).

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

Ответы

Ответ 1

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


Ответ 2

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


Ответ 3

Все тот же самый shared secret, вид сбоку. Если допустима нестандартность подхода
и хочется нормального решения — используйте HTTPS и клиентские сертификаты.
Видимые плюсы:

Некоторая нестандартность решения. Защищает от кейлоггеров и типичных снифферов,
ловящих POST-запросы.
Эффективный размер ключа выше, чем у типичного пароля. Повышает качество, защищая
от слабых паролей. Хотя защищаться от брутфорса в любом случае нужно не так.

Видимые минусы:

Ключ выдается, а не задается, что несколько повышает возможность его утечки (т.к.
знают пользователь и администратор, а не один пользователь).
Если браузеры хранят пароли хоть как-то их защищая (например, мастер-паролем), то
файл хранится без всякой защиты или даже обфускации. Тащи с диска и пользуйся.
Функция crypt(3) в типичных вариантах (использующая DES, MD5 или варианты SHA) не
рекомендуется для хранения хэшей. Рекомендуют bcrypt.


Ответ 4

Интересная идея, делающая невозможным брутфорс со стороны фронт-энда админки. При
условии, конечно, что в файле бинарные данные, а не текст.


Ответ 5

Такой способ гораздо безопасней, чем тот же логин / пароль. За условием, что всё
сделано верно.


Ответ 6

Например, можно сделать, чтобы админ входил только через обычного пользователя. Т.е.
сначала залогинился обычным пользователем, потом - админка. И никак иначе.
И это все логируется. Будет видно по крайней мере, кто брутфорсит :) И защита тогда
проще строится.
Но еще и SSL конечно.


Ответ 7

И одним ключём все входят.
если я правильно понял вашу затею