Comments 42
Хэш лучше посчитать сразу на клиенте. А еще можно хранить на сервере сам файл и присылать на клиент каждый раз новую соль, чтобы клиент мог посчитать на себе хэш(соль+файл) (или аналог HMAC), а сервер потом сравнить. Но это надо секьюрно хранить файл, да
Правильные идеи, да! Если буду внедрять где-то в продакшене, то скорее всего примерно так и сделаю, кстати. Но пока что это скорее на уровне идеи — в конце концов, сейчас и так есть OpenID и вход через социальные сети.
Вы изобрели coockie
Не понимаю почему минусуют этот комментарий, ведь сточки зрения техники и безопасности этот метод аутентификации отличается от привычной cookie-based аутенцификации только тем, что вместо куки теперь мы имеем файл
Ну ведь это и есть cookie-based аутентификация.
Даже более того, если использовать такой способ как замену пароля, то он менее секурен чем куки+пароль, потому что любой троянец, да что там троянец, жена\любовница\брат\сестра сможет увести такой файл и получить полный доступ к пользовательскому аккаунту, включая смену настроек. Если же использовать такой метод в связке с паролем, то тогда отпадает весь смысл в такой авторизации, потому что если пользователь знает пароль, зачем его спрашивать какой-то файл? Точнее даже так — если пользователь имеет какой-то файл с уникальным идентификатором — зачем его разлогинивать и спрашивать идентификатор, когда можно этот уникальный идентификатор сохранить в куки?
Если прям так уж действительно хочется сделать аутентификацию без пароля, то почему бы не следовать стандартам — для жуткого энтерпрайза использовать клиентские SSL сертификаты, а для обычных пользователей сделать все через mozilla persona
В каждом авторизационном файле хранится некоторая сгенерированная случайным образом строка символов, для которой в базе данных на сервере есть хэш, привязанный к определённому идентификатору пользователя.
Ну ведь это и есть cookie-based аутентификация.
Даже более того, если использовать такой способ как замену пароля, то он менее секурен чем куки+пароль, потому что любой троянец, да что там троянец, жена\любовница\брат\сестра сможет увести такой файл и получить полный доступ к пользовательскому аккаунту, включая смену настроек. Если же использовать такой метод в связке с паролем, то тогда отпадает весь смысл в такой авторизации, потому что если пользователь знает пароль, зачем его спрашивать какой-то файл? Точнее даже так — если пользователь имеет какой-то файл с уникальным идентификатором — зачем его разлогинивать и спрашивать идентификатор, когда можно этот уникальный идентификатор сохранить в куки?
Если прям так уж действительно хочется сделать аутентификацию без пароля, то почему бы не следовать стандартам — для жуткого энтерпрайза использовать клиентские SSL сертификаты, а для обычных пользователей сделать все через mozilla persona
Мне не понятно зачем придумывать недо-клиентские сертификаты.
Куки и сертификаты привязаны к браузеру а файл можно таскать на флешке. Но в любом случае данная аутентификация не безопасна.
Извиняюсь, хотел написать ответ для комментария от cyberface
Извиняюсь, хотел написать ответ для комментария от cyberface
Кроме того, у куки есть возможность его перезаписать (обновить) с сервера в процессе рефреша контента. Этим можно уйти от возможности использования краденых куки.
В варианте с файлом это уже сложнее.
В варианте с файлом это уже сложнее.
Ваша идея схожна с той мыслью, которая крутилась у меня в голове уже давно: объединить логин и пароль. Т.е. человек вводит особую фразу, которая шифруется на стороне клиента и хэш пересылается на сервер, где ищется в базе. Если есть — этот человек залогинивается.
Но недостатки есть. Возможно, это будет легче взломать (чтобы получить доступ к сайту достаточно угадать любой хэш из всех, а не только один, соответствующий одному логину). Но если сделать хэш длинным…
Но недостатки есть. Возможно, это будет легче взломать (чтобы получить доступ к сайту достаточно угадать любой хэш из всех, а не только один, соответствующий одному логину). Но если сделать хэш длинным…
Смотрите, на некоторых сайтах бывает так, что имени пользователя нет, а есть только пароль.
И, если пароль генерируется автоматически, то всё в порядке, а вот если он выбирается пользователем, то может очень легко получиться ситуация, что некий пользователь захочет поставить себе определённый пароль, но такой пароль уже будет у другого пользователя. И ведь как-то даже и неловко делать, чтобы выводилось сообщение о том, что пользователь с таким паролем в системе уже есть. Но и поставить тот же пароль у второго пользователя тоже не получится.
И, если пароль генерируется автоматически, то всё в порядке, а вот если он выбирается пользователем, то может очень легко получиться ситуация, что некий пользователь захочет поставить себе определённый пароль, но такой пароль уже будет у другого пользователя. И ведь как-то даже и неловко делать, чтобы выводилось сообщение о том, что пользователь с таким паролем в системе уже есть. Но и поставить тот же пароль у второго пользователя тоже не получится.
А при регистрации в случае совпадения хэша выдавать:
«Извините этот пароль уже используется»
Класс!
«Извините этот пароль уже используется»
Класс!
Эту схему не обязательно внедрять по принципу «вместо». Можно же ее использовать как второй фактор, слабый, но второй. Кроме того можно его использовать в качестве «предбанника» — заходит так пользователь, видит какую-то некритичную информацию (статус заказа, например), а если надо подробнее или поменять-удалить, то будьте добры логин-пароль предоставить.
Смысл? Проще тогда сделать двойной пароль. Один на чтение, другой на запись. Примеры такой реализации, думаю, все видели.
Да и схема такой аутентификации — обыкновенный костыль для «неосиляторов» авторизации по сертификатам SSL/TLS
Да и схема такой аутентификации — обыкновенный костыль для «неосиляторов» авторизации по сертификатам SSL/TLS
Суть двухфакторной аутентификации не в том, чтобы получить более длинный пароль, а в том, чтобы использовать различные факторы вместе — например, «то, что юзер знает» (пароль) и «то, чем юзер обладает» (ключевой файл).
Суть двухфакторной аутентификации мне вполне понятна, непонятна лишь суть костыля, описанного в статье.
Суть в использовании фактора «то, что пользователь имеет» вместо «то, что пользователь знает». Конечно, выглядит велосипеднее, чем client certificate auth, но с другой стороны проще в управлении на сервере и использовании пользователями.
В плане же устойчивости в MITM ничем не хуже использования пароля.
В плане же устойчивости в MITM ничем не хуже использования пароля.
Вы почти изобрели «Certificate based authentication».
Только оно не требует дополнительных действий от пользователя при логине.
Используется, например, в WebMoney.
Только оно не требует дополнительных действий от пользователя при логине.
Используется, например, в WebMoney.
Надо к этой идее добавлять стеганографию!
Пользователь регистрируется, закачивает на сервер картинку, а после — скачивает себе на компьютер эту же картинку, но с зашитым ключом.
Пользователь регистрируется, закачивает на сервер картинку, а после — скачивает себе на компьютер эту же картинку, но с зашитым ключом.
> Пользователь регистрируется, закачивает на сервер картинку, а после — скачивает себе на компьютер эту же картинку, но с зашитым ключом.
И в чем смысл такой «защиты», если банальным сравнением обоих файлов злоумышленник не только заметит факт передачи (т.е. задача стеганограии не выполняется), но и получит сам ключ?!
Security theater такой security theater.
И в чем смысл такой «защиты», если банальным сравнением обоих файлов злоумышленник не только заметит факт передачи (т.е. задача стеганограии не выполняется), но и получит сам ключ?!
Security theater такой security theater.
Если удалить оригинальный файл, то, чтобы доказать наличие авторизационного файла у пользователя придется перебрать все картинки.
Если же использовать этот файл не для непосредственного доступа, а для повышения привилегий (sudo, грубо говоря) или двухфаторной аутентификации, то даже перебором его будет не найти.
Если же использовать этот файл не для непосредственного доступа, а для повышения привилегий (sudo, грубо говоря) или двухфаторной аутентификации, то даже перебором его будет не найти.
> Если удалить оригинальный файл, то, чтобы доказать наличие авторизационного файла у пользователя придется перебрать все картинки.
Удалить откуда? Клиентское устройство все равно должно обладать ключем в каком-то виде, иначе оно не сможет использовать фактор «то, чем пользователь обладает», а сервер вообще аутентифицирует клиента и априори должен мочь сопоставить пользователя с его ключем в любое время. Если же мы считаем, что передаваемые данные не могут попасть к злоумышленнику, тогда от кого скрываем в них ключ с помощью стеганографии? Я не понимаю, от каких угроз вы предлагаете защищаться с ее помощью.
> Если же использовать этот файл не для непосредственного доступа, а для повышения привилегий (sudo, грубо
говоря) или двухфаторной аутентификации, то даже перебором его будет не найти.
Так для двухфакторной аутентификации или для «повышения привилегий»? И как использование картинок в качестве транспорта для ключа усложняет его подбор?
Удалить откуда? Клиентское устройство все равно должно обладать ключем в каком-то виде, иначе оно не сможет использовать фактор «то, чем пользователь обладает», а сервер вообще аутентифицирует клиента и априори должен мочь сопоставить пользователя с его ключем в любое время. Если же мы считаем, что передаваемые данные не могут попасть к злоумышленнику, тогда от кого скрываем в них ключ с помощью стеганографии? Я не понимаю, от каких угроз вы предлагаете защищаться с ее помощью.
> Если же использовать этот файл не для непосредственного доступа, а для повышения привилегий (sudo, грубо
говоря) или двухфаторной аутентификации, то даже перебором его будет не найти.
Так для двухфакторной аутентификации или для «повышения привилегий»? И как использование картинок в качестве транспорта для ключа усложняет его подбор?
Идея — скрыть сам факт наличия у пользователя файла-ключа. Т.е. угрозы — троян, потеря смартфона, воровство ноутбука.
Маленький файлик известного формата любой троян скинет владельцу, пересылать же все картинки — несколько накладно.
И уже второе размышление, что файлик нельзя использовать в качестве первого барьера — иначе можно все-таки перебрать все картинки и найти необходимую. Если же первый барьер — логин/пароль, а файлик используется как второй фактор, или система повышения привилегий, то задача доказательства того, что среди имеющихся файлов есть ключ — становится невозможной.
И вне зависимости от стеганографии, мне, кажется, начинает нравиться идея использования «второго фактора» для потенциально опасных действий — смена пароля, email, удаления информации, выгрузка архива… Можно не бояться заходить на ресурс через открытый Wi-Fi, интернет-кафе, не бояться потерять телефон или того, что украдут ноутбук. Так, держать на отдельной флэшке необходимые ключи, а флэшку — дома под замком.
Маленький файлик известного формата любой троян скинет владельцу, пересылать же все картинки — несколько накладно.
И уже второе размышление, что файлик нельзя использовать в качестве первого барьера — иначе можно все-таки перебрать все картинки и найти необходимую. Если же первый барьер — логин/пароль, а файлик используется как второй фактор, или система повышения привилегий, то задача доказательства того, что среди имеющихся файлов есть ключ — становится невозможной.
И вне зависимости от стеганографии, мне, кажется, начинает нравиться идея использования «второго фактора» для потенциально опасных действий — смена пароля, email, удаления информации, выгрузка архива… Можно не бояться заходить на ресурс через открытый Wi-Fi, интернет-кафе, не бояться потерять телефон или того, что украдут ноутбук. Так, держать на отдельной флэшке необходимые ключи, а флэшку — дома под замком.
> скрыть сам факт наличия
Скрыть от кого? От трояна на клиентском хосте? Он и так сможет до ключа добраться без необходимости разбирать картинки, пересылаемые по сети. От человека посередине? Он просто сравнить посланную и принятую вами картинку. От скомпрометированного удаленного сервера? Да вы же аутентифицируетесь на нем!
> Можно не бояться заходить на ресурс через открытый Wi-Fi, интернет-кафе
Как вам поможет второй фактор в виде ключевого файла, если он передается вместе с паролем, избежать успешной MITM-атаки? Аутенификация по сертификатам или OTP-генератор еще бы как-то решили проблему, но голый ключевой файл — нет.
> не бояться потерять телефон или того, что украдут ноутбук. Так, держать на отдельной флэшке необходимые ключи, а флэшку — дома под замком.
Если флешка дома под замком, то так вы собираетесь использовать ключи с нее?
Задача сокрытия у пользователя ключа решается очень просто — не аутентифицироваться по фактору «то, что есть у пользователя», а использовать лишь пароль, хранимый только в голове.
Скрыть от кого? От трояна на клиентском хосте? Он и так сможет до ключа добраться без необходимости разбирать картинки, пересылаемые по сети. От человека посередине? Он просто сравнить посланную и принятую вами картинку. От скомпрометированного удаленного сервера? Да вы же аутентифицируетесь на нем!
> Можно не бояться заходить на ресурс через открытый Wi-Fi, интернет-кафе
Как вам поможет второй фактор в виде ключевого файла, если он передается вместе с паролем, избежать успешной MITM-атаки? Аутенификация по сертификатам или OTP-генератор еще бы как-то решили проблему, но голый ключевой файл — нет.
> не бояться потерять телефон или того, что украдут ноутбук. Так, держать на отдельной флэшке необходимые ключи, а флэшку — дома под замком.
Если флешка дома под замком, то так вы собираетесь использовать ключи с нее?
Задача сокрытия у пользователя ключа решается очень просто — не аутентифицироваться по фактору «то, что есть у пользователя», а использовать лишь пароль, хранимый только в голове.
Если подумать, кстати, ключ большого размера (например фотография) — это весьма неплохо. С той точки зрения, что передача большого количества ключей (всех имеющихся фотографий) потребует значительно больше времени. Соответственно, брутфорс довольно неплохо замедляется по той причине, что такой объём данных не передать на сервер быстро.
Вообще ввиду статичности передаваемого файла, уязвимо по части MITM, ну и replay, конечно.
А вообще вариант интересный.
Может как вариант в непраздничные дни перетаскивать свое свежее фото?
А вообще вариант интересный.
Может как вариант в непраздничные дни перетаскивать свое свежее фото?
UFO just landed and posted this here
Охренеть, а почему-бы в этом файле не хранить
логин:пароль? Нафига какая-то отдельная таблица в БД, какие-то дополнитьельные хеши, скрытые поля?
Первая мысль. Но если хранить пароль в файле, то он может подойти к почте или другим сервисам.
Затем, что пароль НЕЛЬЗЯ хранить нигде, кроме головы, иначе он начинает выступать одновременно в качестве факторов «известное пользователю» и «обладаемое пользователем». Содержимосе ключевого файла должно быть случайным и незапоминаемым.
Посмотрите, как сделана работа с ключевыми файлами в truecrypt и LUKS.
Посмотрите, как сделана работа с ключевыми файлами в truecrypt и LUKS.
Содержимосе ключевого файла должно быть случайным и незапоминаемым.
Ну ок, пусть
base64(login:password) или, если совсем паранойя, то зашифрованное сервером (обратимо, с помощью секретного ключа) значение rsa.encrypt(login:md5(password), SecretKey).Но заводить под это отдельную таблицу в БД? Ну нахрен… Бессмысленно.
>Случайным
>base64(login:password)
>login:md5(password)
Да вы издеваетесь что ли?
>зашифрованное с помощью секретного ключа rsa
Секретным ключем можно только расшифровывать и подписывать информацию.
>Но заводить под это отдельную таблицу в БД?
Колонку
Вообще, зачем придумывать велосипедные сложности (ухудшающие безопасность) в простой концепции аутентификации по фактору «то, чем обладает пользователь»? И в многофакторной аутентификации факторы не должны зависеть друг от друга.
>base64(login:password)
>login:md5(password)
Да вы издеваетесь что ли?
>зашифрованное с помощью секретного ключа rsa
Секретным ключем можно только расшифровывать и подписывать информацию.
>Но заводить под это отдельную таблицу в БД?
Колонку
Вообще, зачем придумывать велосипедные сложности (ухудшающие безопасность) в простой концепции аутентификации по фактору «то, чем обладает пользователь»? И в многофакторной аутентификации факторы не должны зависеть друг от друга.
>СлучайнымВ чём идея то? Если в том, чтобы пользователь не пытался запомнить содержимое файла, то base64 вполне достаточно, т.к. превращает «человекозапоминаемый» текст в условно-беспорядочную последовательность букв
>base64(login:password)
>login:md5(password)
Да вы издеваетесь что ли?
echo -n "123456" | base64
MTIzNDU2
Секретным ключем можно только расшифровывать и подписывать информацию.
Вот так новость… www.openssl.org/docs/crypto/rsa.html
int RSA_public_encrypt(int flen, unsigned char *from,
unsigned char *to, RSA *rsa, int padding);
int RSA_private_decrypt(int flen, unsigned char *from,
unsigned char *to, RSA *rsa, int padding);
int RSA_private_encrypt(int flen, unsigned char *from, # <=======
unsigned char *to, RSA *rsa,int padding); # <=======
int RSA_public_decrypt(int flen, unsigned char *from,
unsigned char *to, RSA *rsa,int padding);
Хотя конечно ассиметричное шифрование в данном случае это оверкилл, можно обойтись и симметричным (DES / RC4).
Колонку
Так то может и колонки хватит, но в топике предлагают именно что таблицу (один ко многим)
github.com/aruseni/fileauth/blob/master/fileauth/models.py
Вообще, зачем придумывать велосипедные сложности (ухудшающие безопасность) в простой концепции аутентификации по фактору «то, чем обладает пользователь»?Пожалуй во фразе [по фактору «то, чем обладает пользователь»] смысл есть. Но объясните мне, как это снижает безопасность то и чем повышает сложность?
В топике, опять же, речь идёт в первую очередь не о безопасности а об удобстве.
> В чём идея то? Если в том, чтобы пользователь не пытался запомнить
Нет, идея в том, чтобы никто не мог запомнить, включая того, кто смотрит на экран через плечо. чтобы аутентифицироваться можно было лишь ОБЛАДАЯ ключевым файлом. Очевидно, что хэш или base64 от пароля для этого не годится.
> Вот так новость
«Шифрование» секретным ключем называется электронной подписью и в принципе не может помочь скрыть информацию от посторонних, потому что «зашифрованная» информация расшифровывается открытым ключем. ОТКРЫТЫМ.
> Но объясните мне, как это снижает безопасность то и чем повышает сложность?
Так, что вы пытаетесь использовать в качестве фактора «то, чем обладает пользователь» производную от пароля, тем самым смешивая этот фактор с фактором «то, что пользователь знает», что защищенность, как минимум, не увеличивает.
> В топике, опять же, речь идёт в первую очередь не о безопасности а об удобстве.
Нафиг такие «средства защиты», которые обеспечивают удобство вместо безопасности. Пароль «123» себе поставьте, очень удобно будет, обещаю вам.
Нет, идея в том, чтобы никто не мог запомнить, включая того, кто смотрит на экран через плечо. чтобы аутентифицироваться можно было лишь ОБЛАДАЯ ключевым файлом. Очевидно, что хэш или base64 от пароля для этого не годится.
> Вот так новость
«Шифрование» секретным ключем называется электронной подписью и в принципе не может помочь скрыть информацию от посторонних, потому что «зашифрованная» информация расшифровывается открытым ключем. ОТКРЫТЫМ.
> Но объясните мне, как это снижает безопасность то и чем повышает сложность?
Так, что вы пытаетесь использовать в качестве фактора «то, чем обладает пользователь» производную от пароля, тем самым смешивая этот фактор с фактором «то, что пользователь знает», что защищенность, как минимум, не увеличивает.
> В топике, опять же, речь идёт в первую очередь не о безопасности а об удобстве.
Нафиг такие «средства защиты», которые обеспечивают удобство вместо безопасности. Пароль «123» себе поставьте, очень удобно будет, обещаю вам.
Давайте попробуем разобраться.
- Пароль у пользователя может быть только один, авторизационных файлов — вагон и маленькая тележка. Не то, чтобы нельзя было реализовать вход по нескольким разным паролям, но это как раз было бы действительно плохо для безопасности: чем больше паролей, тем больше риск брутфорса (здесь мы предполагаем, что пытаться подобрать одну из 62^128 возможных комбинаций для ключа бессмысленно).
- Каждый из авторизационных файлов в любой момент можно деактивировать. Причём если, например, мог быть скомпрометирован только тот ключ, который на компьютере на даче, то и деактивировать имеет смысл только этот конкретный ключ (оставив при этом тот ключ, который используется дома, например). Теоретически, можно также добавить срок истечения.
- Кстати, можно также добавить страницу, где бы отображалось, по каким именно ключам осуществлялся доступ на сайт, и какие на данный момент есть открытые сессии. Это может помочь пользователям легко обнаружить, какие из их ключей были скомпрометированы, если они не знают наверняка.
- Если мы храним ключ, то утащивший ключ получит только доступ. При этом пароль пользователя не будет раскрыт. Собственно говоря, в некоторых случаях не будет раскрыт даже логин — часть сайтов нигде его не показывают после входа (так часто бывает, если отображаемое имя отличается от того, которое используется для авторизации). Если же мы храним в файле логин/пароль — то злоумышленник помимо доступа может получить ещё и их, что значительно хуже (например потому, что такие же логин и пароль пользователь может использовать где-то ещё).
- Благодаря тому, что ключи привязаны к конкретным пользователям только на сервере, и ключ сам по себе не хранит никакую информацию о пользователе, ключи достаточно анонимны. Если предусмотреть возможность не только деактивации, но и удаления ключа, то после того, как ключ будет удалён, определить, чей это был ключ, вообще невозможно (даже имея доступ к базе данных на сервере).
ответил мимо
Sign up to leave a comment.
Вход на сайт с помощью авторизационного файла