Придумываем стойкий к взлому пароль. Практические рекомендации. Пароли должны быть идентичными

Придумываем стойкий к взлому пароль. Практические рекомендации

Приветствую!Несмотря на стремительное развитие технологий и появление альтернативных способов распознавания владельца, парольная защита не сдаёт своих позиций и остаётся весьма популярной и по сей день.

Содержание:

Пароль превратился в обыденность и используется для доступа к устройствам и интернет сервисам. И со временем их становится только больше. Сложившаяся ситуация, в конечном итоге, приводит к тому, что пользователи начинают использовать один и тот же пароль на используемых устройствах и сервисах.Данный подход очень опасен и грозит серьёзными последствиями. Несомненно, скомпрометированный пароль от социальной сети не несёт таких последствий, как пароль от платёжной системы. Но если они будут идентичны, то вероятность того, что доступ будет получен и к остальным используемым сервисам очень высок.Чтобы этого не произошло, пароли должны быть сложными (стойкими к перебору) и разными.

Принципы, используемые при создании пароля

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

Логин и пароль не должен быть идентичным
Пароль не должен состоять из личной информации (дата рождения, телефон и т.д.)
Пароль не должен состоять исключительно из слов

На первый взгляд эти рекомендации могут показаться избыточными, но давайте посмотрим, каким образом происходит взлом простых паролей.

К примеру, чтобы подобрать пароль, состоящий из 6 цифр – необходимо перебрать всего 1 миллион комбинаций. Современный компьютер справится с этой задачей за считанные минуты. По этой же причине не стоит полагаться на пароли, состоящие исключительно из слов и их сочетаний. Такие пароли перебираются с использованием словарей популярных слов.

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

Дата рождения 12071996 – 0,003 секунды
Имя с заглавной буквы Maksim и строчной maksim – не больше полусекунды
Сочетание, состоящее из букв и цифр 7s3a8f1m2a – около суток
На перебор следующего сочетания vSA-DFRLLz – 1 год
Сочетание iu2374NDHSA)DD – 204 миллиона лет

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

Правильно генерируем пароль

С теоретической частью мы разобрались, теперь перейдём непосредственно к генерации стойкого и надёжного пароля.При создании сложного и стойкого пароля существенную роль играет человеческий фактор. Трудности возникают на самом начальном этапе – придумывании сложного пароля, а после – его запоминания. Ведь комбинация разрозненных символов едва ли предрасполагает к скорому запоминанию.С проблемой генерации стойкого пароля нам помогут он-лайн сервисы. Их довольно много, из популярных русскоязычных сервисов можно отметить:Passwordist.comOnline-Generators.ruPassGen.ruРаботают представленные сервисы по одному принципу, от вас лишь требуется указать какие символы необходимо использовать и выбрать длину генерируемого пароля.Отдельной особенностью сервиса Passwordist.com можно отметить возможность задать количество создаваемых паролей и генерировать варианты с лучшей читабельностью за счёт исключения похожих символов, к примеру, B и 8.

Хранение паролей

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

Среди популярных решений можно отметить программу KeePass. Данная программа бесплатна и в тоже время весьма функциональна. Помимо прочего в ней присутствует генератор паролей, благодаря которому отпадает необходимость в использовании он-лайн генератора.Для доступа к базе сохранённых паролей необходимо будет установить мастер-пароль. Для его создания можно, к примеру, воспользоваться методикой набора слов в другой раскладке, дабы создать сложный пароль, но при этом самому не забыть его.Локальная база с паролями на вашем компьютере априори будет менее подвержена взлому, нежели общедоступные сервисы в интернет, так что здесь со сложностью перебарщивать не стоит.

Проверка стойкости паролей

Если вы желаете проверить уже имеющиеся или вновь сгенерированные пароли на стойкость к взлому, то для этого существуют несколько он-лайн сервисов:

1) How Secure Is My Password? После того, как вы введёте пароль в соответствую форму на сайте, вы увидите сколько времени понадобится на взлом методом перебора. Срок в несколько миллионов лет можно считать превосходным.

2) Kaspersky Lab: Secure Password Check Данный сервис создан отечественным разработчиком популярного антивирусного решения. Он также демонстрирует примерное время, которое необходимо на взлом пароля методом перебора.

3) 2IP: Стойкость пароля Сервис категорично выносит вердикт для проверяемого пароля – он может быть либо надёжным, либо нет.

Проверяя ваши пароли не стойкость, не забывайте, что отображаемые там результаты стойкости весьма условны. Они рассчитываются исходя из средней производительности домашнего компьютера, и едва ли будут аналогичными для мощного лабораторного суперкомпьютера.Одно успокаивает – людям, имеющим доступ к такому оборудованию, едва ли будет интересен ваш пароль от сервиса электронной почты или мессенджера.

Краткий итог

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

it-actual.ru

Тестируем поля логин/пароль | Normal testing

Тестируем поля логин/пароль

09.09.2009 Автор: Алексей Лупан

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

Повсюду под предложением «Expected: alert» подразумевается, что ответ должен быть отрицательным, но система должна как-то сигнализировать юзеру о причине проблемы.

Регистрация нового пользователя

Зарегистрировать нового пользователя с логином new_user. Expected: можно.
Зарегистрировать нового пользователя с логином new_user_test. Expected: можно.
Зарегистрировать нового пользователя с логином new-user. Expected: можно.
Зарегистрировать нового пользователя с логином new1234user. Expected: можно.
Зарегистрировать нового пользователя с логином new@user. Expected: alert.
Зарегистрировать нового пользователя с логином newuser и паролем newuser (полное совпадение). Expected: alert.

использование только ASCII символов в логине – Expected: alert.
регистрация пользователя с логином, содержащим пробелы или состоящим из одних пробелом – Expected: alert.
регистрация пользователя с паролем, содержащим пробелы или состоящим из одних пробелом – Expected: alert.
регистрация пользователя с логином содержащим XSS или SQL injections. – Expected: alert.
а можно ли зарегистрировать пользователя «admin», и пользователя «аdmin» (где а – из русской расскладки)?
В некоторых случаях разработчики проверяют пользователя в базе с помощью LIKE, и не обрабатывают user input. Поэтому нужно проверить комбинацию %%%/%%% (знак % повторяется 3

testitquickly.com

Требования к логинам и паролям в системе Сбербанк Онлайн

Сегодня мы рассмотрим информацию о регистрации в системе «Сбербанк онлайн», а также о требованиях к логину и паролю, которые указываются пользователями в процессе процедуры создания персонального аккаунта.

Личный кабинет

«Сбербанк онлайн» представляет собой систему веб-банкинга от крупнейшего банковского учреждения страны, которой ежедневно пользуются миллионы пользователей для выполнения рутинных операций, переводов средств между счетами, пополнения счетов и оплаты покупок. Представить себе комфортную жизнь в 21 веке без использования подобного сервиса попросту невозможно. Поэтому, если вы еще не являетесь активным пользователем системы, рекомендуем вам срочно исправить данный недочет.

Регистрация в системе «Сбербанк онлайн»

Процедура создания персонального аккаунта для дальнейшего использования веб-банкинга состоит всего из нескольких простых шагов. Безусловно, их мы опишем ниже. Запоминайте инструкцию:

Откройте главную страницу официального сайта банка. Он находится по ссылке sberbank.ru.
На открывшейся странице присутствует блок, отвечающий за сервис веб-банкинга. Он называется «Сбербанк Онлайн» и находится в верхней правой части страницы. Вам необходимо нажать на кнопку «Регистрация», расположенную в данном блочном элементе.
На следующем этапе от пользователя требуется только ввод номера основной банковской карты Сбербанка. Введите его в соответствующее поле, проверьте правильность ввода, и перейдите к следующему этапу.

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

Вот так, всего в 5 предельно простых и интуитивно понятных шагов, любой клиент Сбербанка России может создать персональный аккаунт в веб-банкинге.

Условия использования логина и пароля в Сбербанк Онлайн

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

Если говорить о логине, то условия его создания выглядят так:

Никнейм может содержать только цифры, а также буквы латинского и русского алфавита в любом регистре;

Требования к длине ника – не менее 8-ми символов;
В авторизационном имени не может идти три одинаковых буквы подряд. Это же условие касается и других знаков, вроде цифр или спецсимволов;

В идентификаторе можно использовать спецсимволы следующего вида:

Знак тире «–»;
Восклицательный знак «!»;
Знак собаки «@»;
«Решетку» — «#»;
Знак доллара США «$»;
Знак процентов «%»;
Птичку «^»;
Знак and «&»;
Значок «звездочка;
Открывающиеся и закрывающиеся скобки;
Нижнее подчеркивание «_»;
Символы «плюс» и «минус»;
Символ точки с запятой;
Запятые и точки;
Кавычки «елочкой».

Что же касается требований к паролям, то они выглядят так:

Длина пароля не должна быть менее 8-ми символов;
В кодовом слове должны присутствовать цифры, строчные и прописные буквы;
Ввод трех одинаковых символов подряд не рекомендуется;
Кодовое слово должно отличаться от логина-идентификатора;
В пароле могут быть использованы спец. символы из списка, указанного выше;
Если речь идет об изменении пароля, а не о регистрации нового пользователя, то его значение не должно быть идентичным прошлым паролям.

Вот и вся информация, которую необходимо знать для успешного прохождения процедуры регистрации в сервисе «Сбербанк Онлайн».

sbguide.ru

Решение вопроса с паролями — раз и навсегда / Хабрахабр

Эта статья выросла из одного обстоятельного комментария. За идеи, описанные там, меня поблагодарили несколько человек в реале — поэтому было решено оформить их в топик.

Итак, как же легко и ненапряжно создавать и использовать уникальные и криптостойкие пароли для каждого сайта, на котором довелось заводить аккаунт? Как сделать так, чтобы через 3 года забвения, обнаружив свой покрытый мхом аккаунт, вы не задумываясь залогинились, введя уникальный для этого сайта 15-символьный пароль, состоящий из не поддающегося анализу набора букв и цифр?

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

Ход конем

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

«Десять тысяч обезьян в **** сунули банан». Лукьяненко С.

За основу будущего пароля берем кусок незабываемого или легкогуглящегося английского текста. В качестве примера я возьму первые три строчки из песни Celine Dion к «Титанику»:

Every night in my dreams I see you, I feel you That is how I know you go on

Берем первые буквы каждого слова, сохраняя регистр. Тут всего 3 строчки. Запомнить, с какого слова начинается каждая — легче, чем напечатать это предложение. Результат:

EnimdIsyifyTihikygo

заменяем i на 1, o на 0 — или любую другую пару букв на цифры, по вашему выбору. Мой выбор обусловлен визуальным сходством между «I» и «1», «o» и «0» — облегчает замену «на лету», делает ввод пароля более механическим, не требующим лишний раз задумываться. Результат:

En1md1sy1fyT1h2kyg0

Время для главного финта ушами, который обеспечит уникальность пароля на каждом интернет-ресурсе. «Привязываем» получившийся пароль к имени сайта. К примеру, добавляем 1-м и последним символом пароля третий и предпоследний символ из адреса сайта, а точнее — из имени домена второго уровня. Например:

для mail.ru пароль iEn1md1sy1fyT1h2kyg0i для google.com пароль oEn1md1sy1fyT1h2kyg0l

Что, у вас уже давно есть аккаунт в фейсбуке? Почему бы не поменять пароль и в нем:cEn1md1sy1fyT1h2kyg0o

Привязка к доменам может быть любой другой — можно считать символы в имени домена, можно считать отдельно гласные и согласные буквы, главное — ввод пароля должен быть слитным от начала и до конца. Нельзя допускать способ, в котором сначала пишется сам пароль, а потом в него добавляются в нужные места символы, привязанные к имени сайта.

Вспомнить все!

Да не нужно ничего вспоминать… Алгоритм ввода пароля:

1) смотрим на адресную строку, отсчитываем 3й символ с начала, жмем кнопочку 2) мысленно напевая песенку, печатаем пароль, делая буквы начала строчек большими и заменяя на лету нули и единицы 3) еще раз смотрим на адрес, находим предпоследнюю букву, дописываем

Подведем итоги

плюсы:

Высокая для web криптостойкость
Потрясающая меметичность — невозможно забыть
Уникальность пароля для каждого веб-ресурса — при утечке пароля от одного, угроза остальным минимальна
Отсутствие необходимости что-либо запоминать*
Визуально при вводе пароля ничем себя не выдаешь — со стороны кажется, что ты просто помнишь все наизусть
Быстро вырабатывается моторная память — весь этот бредовый набор символов вскоре набирается на полном автомате
Если вы случайно вбили пароль в открытом виде при свидетеле, он ничего не поймет и скорее всего не запомнит, а на вас станет посматривать с уважением
Это забавно — напевать про себя My heart will go on при каждом вводе пароля)

минусы:

утечка паролей от двух и более ресурсов в одни руки создает серьезную угрозу всем аккаунтам
Если слишком увлечься, можно вместо чтения текста «про себя» произнести его вслух
При потере пароля от ресурса, придется создать новый — который уже не получится вспомнить, пользуясь системой. В дальнейшем может возникнуть путаница.

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

* необходимость запомнить 2-3 строчки стиха или песни (пусть и на английском), равно как необходимость помнить какая песня вообще взята за основу и то, сколько символов нужно отсчитывать с начала и конца имени домена — дело одной минуты. С первой частью справляются дети в детских садах.

**** Фраза про обезьян — это классический пароль из «Лабиринта отражений». В оригинале писалась в английской раскладке, без пробелов и с чередованием регистра.

upd: В комментах поправили — не десять тысяч, а сорок тысяч обезьян (очевидно, криптостойкость в 4 раза выше), пробелы значимы и в конце еще точка.

habr.com

Файл скрытых паролей

Механизм устаревания паролей ограничивает срок, в течение которого пароль пользователя остается корректным. Этот механизм может быть реализован на общесистемном уровне посредством файла /etc/login.defs либо для отдельных пользователей посредством файла /etc/shadow. Последний называют файлом скрытых паролей. Для каждого пользователя он содержит запись, в которой указаны хешированный пароль и сведения о сроке его действия. По умолчанию этот файл может не существовать. Давайте рассмотрим, как создавать и использовать такой файл.

Файл скрытых паролей по умолчанию создается в ходе инсталляции системы, что существенно повышает ее безопасность, и вот почему. Дело в том, что все хешированные пароли переносятся из файла /etc/passwd в файл /etc/shadow, доступ к которому разрешен только суперпользователю и только для чтения. Кроме того, появляется возможность задать предельный срок действия каждого пароля. Файл /etc/ passwd открыт для чтения, а значит, и для копирования. Если файл скрытых паролей не используется, все хешированные пароли находятся в файле /etc/passwd, и любой пользователь может попытаться «взломать» его с помощью утилиты Crack.

Для того, чтобы создать файл скрытых паролей в Linux (предполагается, что файл не был создан во время инсталляции) не нужны статусы в контакте (см. finestatus.ru), выполните команду pwconv от имени суперпользователя. Она автоматически переместит в файл /etc/shadow все хешированные пароли (а также пароли вида *) и запишет во второе поле каждой записи файла /etc/passwd символ х. Если нужно произвести обратное действие, просто выполните команду pwunconv от имени суперпользователя. Разумеется, информация об устаревании паролей, хранящаяся в файле /etc/shadow, будет потеряна.

Механизм устаревания паролей отдельных пользователей включается только при наличии файла /etc/shadow. С помощью команды chage в этот файл можно добавлять сведения о пользовательских паролях. Фрагмент файла /etc/shadow:

root:otlY/YgV5e.Bk:10640:0:99999:7::: bin:*:10640:0:99999:7::: daemon:*:10640:0:99999:7::: adm:*:10640:0:99999:7::: lp:*:10640:0:99999:7::: sync:*:10640:0:99999:7::: joe:E/ulR7fLAQO6o:10640:0:99999:7::: mary:VBtHXaJk3IPD6:10640:7:30:3:45:: guest1:xdbt9JIxfCUvo:10 64 0:0:99999:7::10640:

Подобно файлу passwd, файл shadow содержит одну строку (запись) для каждого пользователя. Каждая запись состоит из списка полей, разделенных двоеточиями. Всего существует 9 полей. Порядок записей в обоих файлах должен быть идентичным. Поля файла /etc/shadow:

№	Команда для модификации	Описание
1	useradd, usermod и userdel	Регистрационное имя пользователя; должно в точности соответствовать имени пользователя в файле /etc/passwd
2	passwd	Хешированный пароль длиной от 13 до 34 ASCII-символов; допустимые символы — a-z, A-Z, 0-9, ‘.’, $и/
3	passwd или chage -d	Дата последнего изменения пароля (число дней, прошедших с начала эпохи UNIX — с 1 января 1970 года)
4	chage -m	Число дней, которое должно пройти с момента последнего изменения пароля, прежде чем его снова можно будет поменять
5	chage -M	Число дней, которое должно пройти с момента последнего изменения пароля, когда пользователь обязан будет сменить пароль
6	chage -W	Число дней до истечения срока действия пароля, когда выдается предупреждение
7	chage -I	Число дней по истечении срока действия пароля, когда учетная запись блокируется
8	chage -E	Число дней, которое должно пройти с начала эпохи UNIX, чтобы учетная запись устарела. В полночь последнего дня учетная запись будет заблокирована
9	–	Зарезервировано

Команда chage

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

В первом примере пользователю joe запрещается менять пароль в течение 14 дней, а по прошествии 30 дней он обязан поменять пароль:

# chage -m 14 -М 30 joe

Во втором примере срок действия учетной записи guest истекает 4 апреля 2009 года:

# chage -E 04/04/09 guest

А вот как пользователь mary может проверить свои текущие установки:

$ chage -1 mary

Minimum: 7

Maximum: 30

Warning: 3

Inactive: 45

Last Change: Feb 18, 2009

Password Expires: Mar 20, 2009

Password Inactive: May 04, 2009

Account Expires: Never

Файл /etc/login.defs

Файл /etc/shadow — не единственный способ включить механизм устаревания паролей. В Linux есть общесистемный файл /etc/login.defs, который задает параметры устаревания паролей всех пользователей, кроме root. В нем также содержится ряд других записей.

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

В следующей части файла задаются общесистемные параметры устаревания паролей. Параметры PASS_MIN_DAYS, PASS_MAX_DAYS и PASS_WARN_AGE соответствуют четвертому, пятому и шестому полям файла /etc/shadow (см. табл.). Установки файла /etc/shadow имеют более высокий приоритет. Параметры устаревания паролей в файле /etc/login.defs:

PASS_MAX_DAYS 30 PASS_MIN_DAYS 10 PASS_MIN_LEN 5 PASS_WARN_AGE 7

Параметр PASS_MIN_LEN задает минимальную длину пароля для всех пользователей, кроме root. Если используются модули РАМ, их установки имеют более высокий приоритет.

Помните, что записи файла /etc/shadow действительны для конкретных пользователей, поэтому если в файле /etc/login.defs заданы параметры устаревания паролей, а в файле /etc/shadow описан не каждый пользователь, то для «отсутствующих» пользователей будут выбраны стандартные установки. Таким образом, в файле /etc/login.defs можно задать установки по умолчанию, а затем настроить их для конкретных пользователей в файле /etc/shadow.

Оставшаяся часть файла показана ниже. Параметры CHFN_AUTH и CHFN_RESTRICT могут принимать значение yes либо no. Если первый из них равен yes, то всякий раз, когда пользователь выполняет команду chfn или chsh, будет выдаваться запрос на ввод пароля. В противном случае пользователь сможет менять информацию, выдаваемую утилитой finger, и при этом не вводить пароль. Только суперпользователь имеет право менять данные утилиты finger, относящиеся к другим пользователям. Если параметр CHFN_RESTRICT равен yes, пользователь не сможет поменять свое «настоящее» имя с помощью команды chfn —f. Завершающие директивы файла /etc/login.defs:

UID_MIN 500 UID_MAX 60000 GID_MIN 500 GID_MAX 60000 # CHFN_AUTH yes # CHFN_RESTRICT yes # #USERDEL_CMD /usr/sbin/userdel_local # CREATE_HOME yes

Все параметры, за исключением CHFN_AUTH и CHFN_RESTRICT, связаны с командами useradd и userdel. Это утилиты командной строки, предназначенные для управления учетными записями. Параметры UID_MIN, UID_MAX и CREATE_HOME задают стандартное поведение команды useradd, а параметр USERDEL_CMD расширяет функциональные возможности команды userdel.

Если при вызове команды useradd не задать идентификатор пользователя, то при наличии показанных выше установок команда назначит первой созданной учетной записи идентификатор 500, следующей — идентификатор 501 и т.д. вплоть до максимального идентификатора 60000. Параметр CREATE_HOME может принимать значение yes или no. В первом случае команда useradd автоматически создаст начальный каталог пользователя в каталоге /home. Во втором случае начальный каталог будет создан только в том случае, если указан флаг -m. Дополнительные установки команды useradd содержатся в файле /etc/default/useradd. Если возникает неоднозначность, установки файла /etc/login.defs имеют приоритет.

Параметр USERDEL_CMD задает сценарий или программу (должно быть указано полное имя) для выполнения перед удалением учетной записи. По умолчанию ни сценария, ни программы не существует. Команда userdel не удалит учетную запись, если пользователь зарегистрирован в системе и/или в ней выполняются процессы пользователя. С помощью параметра USERDEL_CMD администратор может задать собственную программу, которая проанализирует и, возможно, устранит все факторы, препятствующие удалению учетной записи.

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

В Linux, есть графические утилиты, позволяющие выполнять все действия, связанные с управлением учетными записями. Сюда относится как универсальная утилита linuxconf, так и специальные административные программы (например, User Manager).

Твитнуть

Добавить комментарий

securos.org.ua

Хранение паролей пользователей | Безопасность

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

Я конечно не буду отрицать что статей в интернете на эту тему достаточно, но ни одна на мой взгляд не освещает всех тонкостей казалось бы такого простого процесса. Для понимания этих тонкостей разработчику необходимо наличие умения оценивать систему со стороны взломщика, а для этого необходим хотя бы небольшой опыт в этой сфере (по принципу «кто предупрежден, тот вооружен»). К сожалению, у большинства разработчиков такого опыта нет, и безопасность своих приложений они строят на основе скудной информации найденной в интернете.

В этой статье я попытаюсь рассмотреть минусы хранения открытых паролей в БД. Попытаюсь убедить в необходимости хешировать каждый пароль. Также попытаюсь объяснить зачем нужна «соль» и какой она бывает. Ну и вкратце расскажу про разные алгоритмы хеширования.

Зачем?

Для начала нам необходимо понять зачем вообще нужно правильно хранить пароли. Правильно организованный алгоритм хранения паролей должен:

Снизить риск полного взлома системы
Предотвратить утечку паролей пользователей

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

На практике это выглядит так. Злоумышленник находит на сайте SQL-injection, через которую получает логин-пароли всех пользователей. При правильной системе хранения паролей злоумышленник получает не исходные пароли а только их хеш суммы (см.далее).

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

Хеш сумма

Разработчики пришли к выводу что использовать открытое хранение паролей в своих системах занятие не безопасное и надо придумать что-то другое. И тут на помощь пришли хеш суммы.

Что такое хеш сумма? Допустим у пользователя пароль «123456». Придумаем свою хеш-функцию. Сложим все цифры получим число «21» — это и будет являться результатом нашей хеш функции, хеш-суммой или хешем. Конечно наш алгоритм отвратителен (да и хеш суммой его назвать нельзя, это скорее контрольная сумма), так как один и тот же хеш может соответствовать большому количеству различных паролей. То есть пароли «654321», «555222», «100299» и т.д будут давать такой же хеш, или по-научному будут являться коллизией.

Идеальная хеш функция должна обладать следующими параметрами:

Необратимость — хеш сумма не должна «расшифровываться» подобно обычным алгоритмам шифрования
Отсутствие коллизий — для каждых данных проходящих через хеш-функцию должен получится уникальный хеш

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

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

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

«Соленые» хеши

Вообщем все бы хорошо, но если бы не ленивые или забывчивые пользователи которые стремятся использовать максимально короткие и простые пароли… Почему это плохо? Потому что сбрутить короткие пароли можно в считанные минуты, а простые (часто используемые) пароли брутятся по словарям.

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

Как же нам защитить пользователей и свой ресурс в случае его взлома? На помощь проходит соль. Грубо говоря соль — это набор случайный символов который каждый раз перед прохождением через хеш-функцию добавляется к паролю. При регистрации пользователя генерируется случайная соль, на основе которой и указанного пароля генерируется «соленый» хеш, при этом соль также заносится в БД:Что дает соль в этом случае? Если подумать, то если злоумышленник имеет доступ к хешам пользователей, то если соль каждого хеша мы храним рядом (в той же таблице/БД), то злоумышленник также будет иметь и доступ к соли. То есть сможет найти исходный пароль методом брутофорса, но словари ему уже не подойдут, так как не существует словарей учитывающих все комбинации паролей с солью.

Теперь рассмотрим второй плюс. Допустим вы владеете ресурсом с десяткой тысяч зарегистрированных пользователей. Каждый пароль пользователя имеет уникальную соль. Что это даст? Это даст невозможность одновременного брута хешей всех пользователей, так как для каждой соли нам придется генерировать новый хеш. И если вдруг злоумышленник сбрутить все аккаунты, то ему придется на каждый вариант пароля генерировать столько хешей сколько пользователей у вас имеется. При этом скорость брутофорса упадет пропорционально. Допустим скорость брута — 1 миллион паролей в секунду. В нашем случае (десять тысяч пользователей) скорость брута упадет до 100 паролей в секунду. Согласитесь, брутить всех бессмысленно? Разве что по простейшим и коротким словарям…

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

Дважды «соленый» хеш

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

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

Давайте немного порассуждаем. Отставьте в сторону в свои выпады в стиле «надо предполагать что взломщик имеет полный доступ к всей системе и такая соль бессмысленна». Представьте ситуацию, которую я описывал выше, в вашей системе имеется уязвимость по типу SQL-injection, через которую злоумышленнику удалось получить администраторский хеш и соль из БД. Далее злоумышленнику удалось и сбрутить хеш — и все, ваша система, считайте, взломана.

А ведь наличие дополнительной соли не дало бы злоумышленнику взломать систему, так как ему бы пришлось брутить еще и соль (а это, скорее всего, будет бесполезным занятием). Да, вы опять можете сказать, что «надо предполагать что взломщик имеет полный доступ к всей системе». Но вдумайтесь, зачем тогда злоумышленнику брутить пароль администратора если он уже имеет полный доступ ко всей системе? Да, теоретически вероятны атаки на других пользователей, кроме администраторов, но на моей практике я не слышал ни об одном таком случае.

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

Главная идея этого принципа — раздельное хранение хеша и общей соли, т.е. постараться не допустить попадание соли в руки злоумышленника Если подумать над практической реализацией то, в момент настройки системы, создается общая соль, которая будет хранится в конфиге приложения, и далее эта соль будет также добавляться к паролю. Если схематично то это будет выглядеть вот так:При этом проверка правильности пароля при авторизации будет выглядеть так:

Алгоритмы хеширования

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

Теперь представьте что мы используем алгоритм который позволяет генерировать хеши со скоростью лишь тысяча или сотня хешей в секунду. Такой хеш вкупе с паролем хотя бы в 10-12 знаков будет подбираться значительно дольше чем «разумное время», и смысла такой подбор иметь не будет.

К примеру на моем ноуте:

MD5 — 2 200 000 паролей/сек
SHA — 800 000 паролей/сек
MD5(unix) — 1 200 паролей/сек

Теперь давайте добавим немного математики, и подсчитаем среднее время, которое понадобится нам для перебора простенького пароля из 6 симолов латиницы верхнего и нижнего регистров и цифр. То есть это всего около 100 000 000 000 комбинаций.

Для MD5 ~45 000 секунд или ~12 часов
Для SHA ~125 000 секунд или ~35 часов
Для MD5(unix) ~83 300 000 секунд или ~23 100 часов или ~3 года

Причем для md5 и sha брут еще как-то более-менее имеет смысл, то брутить md5(unix), на мой взгляд, смысла нет абсолютно. Кстати, для справки, в основе md5(unix) лежит тысяча итераций обычного md5.

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

Коллизии

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

И к большому сожалению на данный момент не существует стопроцентного решения этой проблемы для хеш сумм, так как теоретически любой хеш фиксированной длины будет иметь коллизии. Но обычно для снижения вероятности нахождения коллизей используют несколько алгоритмов хеширования. На практике это может выглядеть так: один пароль хешируют сначала по md5, затем тот же пароль хешируют по sha, полученные хеш-суммы объединяют в один хеш, который и используют в дальнейшем.

Но у меня вроде как возникла еще одна идея для решения этой проблемы, но об этом в одной из следующих статей ;)

Итог

Вот основные правила которые вы должны были понять из этой статьи:

Пароль не должен хранится в БД в открытом виде, а должна хранится лишь хеш-сумма
При регистрации пользователя желательно рекомендовать (но не вынуждать!) использовать более сложный пароль
Каждый пользовательский хеш необходимо генерировать с уникальной солью
К пользовательской соли должна быть добавлена общая соль, которая хранится в другом месте (отдельно от пользовательских данных)
Соль должна быть достаточно длинной
Алгоритм вычисления хеш суммы должен быть ресурсоемок (но не вешать ресурс напрочь)

intsystem.org

что такое логин, пароль, подтвердить пароль

•Что такое логин? Логин (login, log in) - это последовательность английских символовов, цифр и символа "_", например vasya, lena, kiska10 или даже такой XkeDx34d. Каждый пользователь имеет свой уникальный логин.

Аксиома: Ни у каких двух пользователей не может быть одинакового логина!

•Что такое пароль? Пароль (фр. parole — слово, англ. password) — это секретная комбинация букв, цифр, знаков, слов, или осмысленное предложение.

Комбинация логин/пароль нужна для идентификации пользователя на нашем сайте.

Запрещается ставить следующие пароли:

◦короче 6 символов

◦вида 123456 или abcdef или qwerty

◦совпадающий с логином или именем

◦совпадающий с датой рождения

◦совпадающий с номером вашего сотового телефона

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

Какие символы допустимы в пароле?

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

Запрещается

◦Сообщать свой пароль другим пользователям и/или администратору.

◦Публиковать свой пароль на интернет сайтах.

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

Мужик в ответ на «Подтвердите пароль» ввёл русскими буквами «Подтверждаю» — и правильно сделал. Забавный случай, но авторы текста «подтвердите пароль» идиоты в значительно большей степени, чем этот мужик.

Как минимум нужно заменить «Повторите пароль» на «Введите пароль ещё раз» .

Но продвинутые-то ребята знают, что возле полей ввода вообще не нужно писать призывов к его заполнению. Точно так же, как на кнопке мы пишем «Отправить» , а не «Нажмите, чтобы отправить» , у поля ввода должно быть написано «Пароль ещё раз» , а не «Введите пароль ещё раз» . Поле ввода своим видом призывает вводить (ага) .

А лучшее когда-либо виденное мной решение проблемы «подтверждения» пароля придумал — ха-ха, сюрприз — я. Оно называется «Пароль два раза» (и два поля рядом).

otvet.mail.ru