Идея авторизации. Ключевые файлы.

Аага, умножайте "вырост" смело на 1024, ближе к правде будет, там такие "титры", как в титанике
С этой адобовской подписью всегда сложно было, придется подтягивать imagemagic..

-----
Шта? Репозиторий?

Не знал. Может тогда не картинку делать, а просто бинарник какой-нить генерировать?

-----
Пессимисты пользуются die(), оптимисты - exit()

Вариант:
1. Берем имя юзера и его пароль. Создаем ключ-файл (на самом деле - php-функция декодирования имени юзера)
2. Закручиваем ее в base64_encode или аналогичное, но используем возможность ключа для декодирования.
3. Ключ модифицируем (например, делаем его MD5 + сумму всех цифр в md5 этого шифра) и разбрасываем по коду (например, вставляем кусками по 2 символа каждые 4 символа кода). И отправляем юзверю.
4. При отправке юзверем кода нам - сначала вырезаем из него md5 и сумму и проверяем - если совпали - значит код не изменен.
5. Если не изменен - используем его для декодирования пункта 1, получая имя юзера и пароль.
6. Сверяем полученное имя юзера + пароль с базой и ура...

Только вопрос - нахрена нам этот гемор? Все равно "натыкать пароль" проще, чем ткнуть Обзор и найти файл-пароль.

К тому же есть уроды-хостеры, у которых коряво передаются бинарники.

-----
Истина прежде всего в том, что...

Можно. Но все подобные схемы придуманы и реализованы до нас.

-----
Есть в мире две бесконечные вещи - это Вселенная и человеческая глупость. Но насчет первой .. я не уверен.

Вот и я о том же.

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

-----
Истина прежде всего в том, что...

Тогда либо пользователь с сотого раза будет "попадать", либо ф-я будет неустойчива к брутфорсу.

-----
Пессимисты пользуются die(), оптимисты - exit()

Ну разве что заархивировать картинку перед передачей юзеру?
Зипом. С паролем.
Пароль к этому архиву генерировать рандомно хранить как пару к Логину юзера и хешу картинки.

Приняли - распаковали, сравнили хэш.

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

Тогда у юзера - ключ-пароль, который он не может изменить.

(Отредактировано автором: 03 Февраля, 2013 - 08:14:25)

-----
Истина прежде всего в том, что...

Тогда лучше контейнер Truecrypt! C AES-Serpent-Twofish и 30-значным паролем и ключами, которые на сервере (штук двадцать!). И заголовка там нет по умолчанию) Хорошая идея! Прям для сверхсекретных данных каких-то

(Отредактировано автором: 03 Февраля, 2013 - 08:19:23)

-----
Пессимисты пользуются die(), оптимисты - exit()

Сейчас придёте к ключам асимметричного шифрования и к какому-нибудь HASP

-----
PostgreSQL DBA

Действительно вопрос медленно ползет к этому.

Но, как всегда, надо, чтобы "цель оправдывала средства".

А мы имеем:
1. Нам лень натыкать пароль ИЛИ надо сделать так, чтобы пароль нельзя (принципиально) увидеть или сохранить кейлоггером.
2. Размер "пароля" должен быть небольшим (например: в пределах 512 байт - стандартный размер сектора на флешке).

на и отсюда вытекает:
а) надо обеспчить, чтобы даже скопировав этот файл себе, злоумышленник не мог тупо его добавить сам при запросе Логин-Пароль.

Какие еще могут быть ограничения/причины этой порнографии и как обеспечить пункт А?

(Отредактировано автором: 03 Февраля, 2013 - 08:54:26)

-----
Истина прежде всего в том, что...

Зашифровать в картинке секретную фразу, и вместе с загрузкой картинки требовать ввод данной фразы.

p.s. Какими-то извращениями занимаемся =)

Проще уж тогда паролем обойтись. Все равно что-то в голове держать, что потом вводить надо)

-----
Пессимисты пользуются die(), оптимисты - exit()