Доброго времени суток, уважаемые Хабражители!
Многие из Вас, кто занимается разработкой веб-сайтов, рано или поздно задумывались над безопасностью данных, которые передает пользователь на сервере, в частности над безопасностью передачи пароля.
Совсем недавно, при выполнении дипломного проекта (кстати на тему «Онлайн система управления обучением»), и я задумался над этим. Мне в голову пришла одна идея по улучшению защищенности пароля при авторизации. Идея не доскональная и продумана не до конца, поэтому я хочу поделиться ею со знающими людьми.
Теория
Основная цель — защитить пароль от перехвата «на пути» к серверу. На сервере в базе данных будет храниться логин, MD5-хэш пароля и некая строка, которую сервер отдаст пользователю в куках для последующей аутентификации. Эта простейшая модель лишь для примера.
Суть моей идеи в том чтобы с веб-страницы на сервер вместо пароля передавался некий хеш пароля. Вы скажете что злоумышленник может перехватить хэш и по нему авторизоваться. А вот и нет. Хэш, который будет передаваться будет своего рода динамическим, т.е. будет разным в разное время.
Как это будет работать?
Я предлагаю на сервер передавать пароль в таком виде:
После заполнения логин формы на странице, пользователь нажимает кнопку «Войти», после чего Javascript берет из пароля MD5-хеш, добавляет к этой строки текущее UNIX-время и из полученной строки снова берёт MD5. Это значение подставляется в поле вместо пароля. Также в логин форму придется вставить поле типа hidden в которое будет вставляться UNIX-время. После выполнения скрипта данные отправляются на сервер.
На стороне сервера из базы данных достается строка по указанному логину и проверяется равняется ли MD5 от строки (UNIX-время + [хэш пароля из базы]) строке которую передал браузер сервера. Если да то авторизация прошла успешно и в куках пользователю передается некая рандомная строка для последующей аутентификации, она же записивается и в базу.
Подводные камни
В этой так сказать технологии есть некоторые недостатки.
1. Основной из них сопряжена со временем. Он на стороне пользователя и на стороне сервера должен быть примерно одинаковым (не знаю насколько это примерно, предлагаю брать ± 60 секунд). Вместе с тем это будет одним из дополнительных элементов защиты: перехватив данные один раз, злоумышленник не сможет авторизоваться позже, так как на сервере будет проверяться время когда пришел запрос.
2. А что будет, если злоумышленник, получив данные, сразу попытается авторизоваться? Ему это удастся, потому что те самые ± 60 секунд могли и не пройти. Для решения циие проблемы предлагаю в форме ввести еще одно поле типа hidden в котором сервер будет помещать ключ (сформированный рандонмо). Этот ключ можно зашифровать вместе с временем и паролем, передать обратно на сервер и там он также будет проверяться.
3. Третий также связан с временем. Вы спросите, а что делать если вдруг у пользователя на компьютере установленное время, которое кардинально отличается от времени на сервере? «А не знаю» — скажу Вам я. Хотя есть одна идейка на будущее: перед отправкой данных на сервер, веб-страница может быть на сервер AJAX-запрос чтобы узнать время, а потом уже отправлять данные. Кстати в этом же запросе может и приходить тот самый рандомный ключ.
А нельзя было сделать просто вариант с ключом?
Нет, нельзя. Это моя идея. Начальная ее концепция была с применением проверки времени, когда сгенерирован запрос. Мысль об открытом ключе пришла в мою голову гораздо позже.
Результаты
Одним махом мы получаем несколько уровней защиты: пароль не передается в открытом виде, происходит проверка по времени, применяется открытый ключ.
Имеем все и не имеем ничего. У меня было мало времени тогда, поэтому не удалось воплотить все это в жизнь. Есть только готовая к размышлению идея.
Уважаемые Хабравчане, скажите стоит ли развивать эту идею? У меня сейчас есть некоторые наработки на этот счет. Если Вам понравится моя идея, в следующей статье опубликую результаты моей работы. Если кто имеет какие-то предложения на этот счет, прошу написать. Заранее спасибо за критику.
Многие из Вас, кто занимается разработкой веб-сайтов, рано или поздно задумывались над безопасностью данных, которые передает пользователь на сервере, в частности над безопасностью передачи пароля.
Совсем недавно, при выполнении дипломного проекта (кстати на тему «Онлайн система управления обучением»), и я задумался над этим. Мне в голову пришла одна идея по улучшению защищенности пароля при авторизации. Идея не доскональная и продумана не до конца, поэтому я хочу поделиться ею со знающими людьми.
Теория
Основная цель — защитить пароль от перехвата «на пути» к серверу. На сервере в базе данных будет храниться логин, MD5-хэш пароля и некая строка, которую сервер отдаст пользователю в куках для последующей аутентификации. Эта простейшая модель лишь для примера.
Суть моей идеи в том чтобы с веб-страницы на сервер вместо пароля передавался некий хеш пароля. Вы скажете что злоумышленник может перехватить хэш и по нему авторизоваться. А вот и нет. Хэш, который будет передаваться будет своего рода динамическим, т.е. будет разным в разное время.
Как это будет работать?
Я предлагаю на сервер передавать пароль в таком виде:
MD5(MD5(Пароль)+UNIX-timestamp)После заполнения логин формы на странице, пользователь нажимает кнопку «Войти», после чего Javascript берет из пароля MD5-хеш, добавляет к этой строки текущее UNIX-время и из полученной строки снова берёт MD5. Это значение подставляется в поле вместо пароля. Также в логин форму придется вставить поле типа hidden в которое будет вставляться UNIX-время. После выполнения скрипта данные отправляются на сервер.
На стороне сервера из базы данных достается строка по указанному логину и проверяется равняется ли MD5 от строки (UNIX-время + [хэш пароля из базы]) строке которую передал браузер сервера. Если да то авторизация прошла успешно и в куках пользователю передается некая рандомная строка для последующей аутентификации, она же записивается и в базу.
Подводные камни
В этой так сказать технологии есть некоторые недостатки.
1. Основной из них сопряжена со временем. Он на стороне пользователя и на стороне сервера должен быть примерно одинаковым (не знаю насколько это примерно, предлагаю брать ± 60 секунд). Вместе с тем это будет одним из дополнительных элементов защиты: перехватив данные один раз, злоумышленник не сможет авторизоваться позже, так как на сервере будет проверяться время когда пришел запрос.
2. А что будет, если злоумышленник, получив данные, сразу попытается авторизоваться? Ему это удастся, потому что те самые ± 60 секунд могли и не пройти. Для решения циие проблемы предлагаю в форме ввести еще одно поле типа hidden в котором сервер будет помещать ключ (сформированный рандонмо). Этот ключ можно зашифровать вместе с временем и паролем, передать обратно на сервер и там он также будет проверяться.
3. Третий также связан с временем. Вы спросите, а что делать если вдруг у пользователя на компьютере установленное время, которое кардинально отличается от времени на сервере? «А не знаю» — скажу Вам я. Хотя есть одна идейка на будущее: перед отправкой данных на сервер, веб-страница может быть на сервер AJAX-запрос чтобы узнать время, а потом уже отправлять данные. Кстати в этом же запросе может и приходить тот самый рандомный ключ.
А нельзя было сделать просто вариант с ключом?
Нет, нельзя. Это моя идея. Начальная ее концепция была с применением проверки времени, когда сгенерирован запрос. Мысль об открытом ключе пришла в мою голову гораздо позже.
Результаты
Одним махом мы получаем несколько уровней защиты: пароль не передается в открытом виде, происходит проверка по времени, применяется открытый ключ.
Имеем все и не имеем ничего. У меня было мало времени тогда, поэтому не удалось воплотить все это в жизнь. Есть только готовая к размышлению идея.
Уважаемые Хабравчане, скажите стоит ли развивать эту идею? У меня сейчас есть некоторые наработки на этот счет. Если Вам понравится моя идея, в следующей статье опубликую результаты моей работы. Если кто имеет какие-то предложения на этот счет, прошу написать. Заранее спасибо за критику.
