Комментарии 79
Странно что не рассказали о самом лучшем и надежном методе генерирования паролей — использование нескольких случайных слов:

Примеры:
bytes-mail-chimp-hat
pizza-sloth-car-banana

Главное только, чтобы слова не были явно связаны между собой

Плюсы:
— Легко запомнить («шимпанзе в шляпе» легче запоминается, чем «H4v$#.!4a!3»)
— Не требует «заглавных букв, цифр, символов»
— Вводится быстрее, и шанс ошибиться меньше, чем при вводе пароля из случайных символов, где нужно постоянно нажимать shift, и есть шанс ошибиться в регистре
— Очень высокий уровень энтропии
— В отличии от паролей из «случайных букв, цифр, и символов», не вызывает желание забить на все и использовать простой пароль вроде: qwerty123

Странно что не рассказали о самом лучшем и надежном методе генерирования паролей — использование нескольких случайных слов:

Идем, скажем, на список случайных слов от EFF. В длинном списке их 7776 штуки или 12.9248… бит на слово. Чтобы набрать 128 бит энтропии нужно 10 слов. А десять случайных слов запомнить — тоже проблема.


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

а если использовать слова с грамматическими ошибками?
что-нибудь меняется при использовании пароля "шемпанзе в шляпи"?

Это становится заметно труднее запомнить. Ту часть которая "а какую именно ошибку тут сделать надо?".

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

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

Есть такой опыт. :) Пароль нужно запомнить с неверным произношением "на иностранный манѣръ". Вышеуказанный пример будет звучать как "шЕмпанзе в шляпИ" (ударения показаны заглавными буквами).
p.s. По ходу написания комментария родилась мысль, что никто не запрещает указать ошибки в верхнем регистре в самом пароле.

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

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

Теперь берем три случайных прилагательных из 512 самых частых (т.е. 9*3=27 бит) и получаем "шимпанзе в древней густой счастливой шляпе".


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

В русском языке используется склонение и спряжение, что несколько увеличивает энтропию. А недостаток грамотности (что легко заметить в первом предложении) добавляет еще несколько бит.
А как же классика: «40000 обезьян в рот засунули банан?»
Делал лабораторные по взлому, пароли а-ля «admin-123» при наличии SAM взламывались в пару минут, а вот в боевых условиях, когда потребовалось узнать забытый пароль родственницы, состоящий только из русских букв и нескольких цифр, программа трудилась часов 12. Безрезультатно.
ИМХО, безопасный пароль — это веселое словосочетание и пара цифр. + замена раз в 2 месяца.
Сразу вспоминается писатель Лукьяненко со своей знаменитой фразой-паролем в одной из книг: «Сорок тысяч обезьян в жопу сунули банан...»)
P.S. кстати не известно «сорок тысяч» или «40 000»)))
Всё известно ;)
Это фраза, первая буква строчная, все остальные прописные. Пробелы значимы. В конце должна стоять точка. Набирай… и повторяй по буквам.
Интересно, сколько админов боролись с искушением поставить этот пароль на свой сервер?
повтореный шесть qwerty123 уже не выглядит таким уж безобидным для брутфорса
По учебе в лабораторной работе несколько минут взлом занял.

это если заранее знать, что длина пароля 54 символа. Не верю что "6 раз кверти123" так легко крякнется.

За сколько времени взломаете мой архив с повторяющимся паролем?
Почему-то все забывают про проверки на HaveIBeenPwned и zxcvbn от DropBox.
Есть даже готовое решение с красивой графикой, которое оценивает пароль по самым современным метрикам
image
По тому, что созданный на этих ресурсах словарь, будет намного эффективней простого перебора.
Крайне странная мысль. Насколько намного, вы считали?
Не позволяя пользователю выбрать пароль из подмножества слабых, мы заставляем его задать пароль из гораздо большего множества возможных вариантов. Где тут логика?
Если бы вероятность попадания пароля в HaveIBeenPwned и zxcvbn была большая, то проблем у пользователей было бы гораздо больше

Я полагаю, оппонент намекает, что люди добровольно сливают свои пароли этим сервисам. Я, например, не поленился выкачать базу havebeenpowned, т.к. ссу отправлять им свой пароль, и даже хэш от него (они ведь простой sha1, а не scrypt/argon просят)

Чего именно вы опасаетесь? Вот мой реальный пароль от одного из аккаунтов на одном из сайтов (нет, не хабра) — 58CNTCzzL9Ls5hWZ — что вы с ним сделаете, не зная логина и собственно сайта? И это с учётом того что оставляя его здесь я рискую гораздо больше чем на каком-то сервисе который про меня знает только мой динамический IP, ОС и браузер.


А если отправить им SHA1, то на его реверс уйдут в лучшем годы работы всех устройств планеты (в нём 87 бит энтропии) — никто в здравом уме не будет этого делать не зная деталей, как минимум ценности аккаунта. Если бы это был пароль от кошелька биткоина на котором миллион биткоинов — думаю, в этом случае было бы проще меня найти и допросить альтернативными способами.

1) Раз вы засветили реальный пароль (вы правда это сделали?), то в нём сейчас ровно 0 бит энтропии. Его просто добавят в базу паролей, и в следующий раз во время переборя его попробуют ко всем логинам. Вполне возможно, что и к вашему логину.

2) Конечно, если у вас действительно настолько рандомный пароль (и такая хорошая память), то можно безбоязненно посылать SHA1. Те несколько паролей, что я помню и применяю в зависимости от вшивости сайта, имеют меньшую энтропию, и подобрать их по SHA труда не составит. Самый старый (и самый простой) из моих паролей давно утёк.

Да, у меня действительно настолько рандомный пароль — я пользуюсь генератором, каждый сайт получает свой пароль и почти рандомный логин/email (только домен неизменен), так что успехов тем кто его будет пробовать.


На действительно важные сайты (банки, paypal etc) у меня к тому же 2FA, а с запоминанием всего этого проблем нет благодаря KeePass.

Вы что, не в курсе как работает их API? k-means? Реально думаете, что туда отправляется пароль в чистом виде?
Если у них база SHA, значит туда можно отправлять SHA. Ок. Но если пароль не такой сложный, как у Tangeman, то подобрать его offline проще паренной репы.

Просто ждём, пока накидают 10 миллионов ненайденных в базе SHA, и запускаем переборщик. Даже если ему придётся работать месяц, и он отыщет десятую часть, всё равно это будет 1 миллион новых паролей. Чем не профит?
Ок, проверил, что посылает HaveIBeenPwned. Выглядит действительно более-менее безопасно: посылается 20битный хэш в виде части пути. В ответ уже приезжают SHA, из которых нужный проверяется на клиенте. Я был не прав.
Важно было не SHA/не SHA, а сколько бит. 20бит явно не достаточно для идентификации пароля.
Раньше был у меня некий алгоритм формирования паролей на различных сайтах, но со временем понял, что по некоторым причинам это не всегда подходит.

В итоге перешел полностью на keepassxc. Файл синхронизирую через ядиск, защиен паролем + файл ключ на устройствах (win, linux, andr).
И для всех генерирую пароли вида: i_óälÝgíldjâ-¸+¼np@:º.

Один большой минус — на некоторых сайтах стоит дурацкая регулярка с запретом ASCII и\или спецсимволов.

P.S. Жду когда добавят в автогенератор эмодзи)
Не знаете, можно ли делать что-то на подобии скрытых томов в keepassx? Когда под разными ключами открываются разные базы?
К сожалению, нет. Но при большом желании можно было бы хранить базу в скрытом томе Veracrypt.
KeePass сам вводит пароли без copy/paste. Хотя умеет и с copy/paste, но предупреждает, что буфер обмена небезопасен.
Не во всех случаях. Если не ошибаюсь (в терминологии разбирался давно при Outpost-е ещё, сейчас на z-oleg посмотрел, вроде правильно), при автовводе (Auto-Type) действительно KeePass подключается к очереди потока и пишет прямо туда. Если используется двойное усложнение набора (Two-Channel Auto-Type Obfuscation), то пароль делится на две части, одна из которых вводится так же, а другая именно через буфер обмена. При этом есть некоторая несовместимость с «Безопасными платежами» Касперского: к очереди потока Касперский подключиться не даст. Тогда и работает copy/paste (Ctrl-B, Ctrl-C и Ctrl-V — немного не стандартно, в соответствии с инструкцией). По умолчанию буфер обмена очищается через 12 секунд, вроде. Что касается kepass2android, то там в составе приложения входит своя клавиатура, которая вводит информацию не через copy/paste, а напрямую, хотя и через буфер обмена возможность ввода остаётся, но не рекомендуется.
Вот-вот. По это же причине, даже пользуясь вышеупомянутым Keepass, генерирую пароли без спецсимволов, ориентируясь, как и автор статьи на необходимую длину пароля. Единственное чтобы я добавил, не на всех символах дабл-клик запинается, подчеркивание вполне себе подходит (на самом деле не только оно) и с ним вполне можно задавать усложненные пароли.
На старых андроидах FullKeyboard или ХакерКейбоард.
На новых есть глюки, если верить 4pda.

Я про всевозможные железки, требующие ввод пароля какой-либо учётки при первоначальной инициализации, будь то Playstation, iphone или разнообразные сервера. не везде разработчики предусматривают безпарольную аутентификацию на такой случай.

Айфон — это просто.
А вот железка, где две аппаратных кнопки… — ввести что-то длинней 3-5 символов, уже подвиг, а бывает серийник символов на 50. И он не навсегда.

А как вы введёте в новый айфон при активации строку, которую человек выше приводил в качестве примера? i_óälÝgíldjâ-¸+¼np@:º
Ладно, в любом случае всё сводится к тому, что увеличивая алфавит парольной строки мы увеличиваем основание, а увеличивая её длину — степень сложности подбора. Другими словами эффективнее добавить лишнюю букву, чем заменять в строке "а" на "а с апокрифом" или 4 на 1/4.

Уж очень высок риск компроментации сразу всего и вся, если этим проектом завладеют недоброжелатели. Разве что скомпилить из сырцов самому, и никогда не обновлять.
Для паролей стал использовать KeePass, везде либо стандартные 30 символа автогенератора (буквы, цифры, символы, например 7?iVEqD&hplw=;QX4$@jQ«ezUO`j0,) либо иногда приходится тюнить под сайт (бывает максимальная длина в 8 паролей, собрал шаблоны генератора для таких сайтов).
Ставить разные стойкие пароли даже для десятка популярных сайтов уже проблема, если их запоминать, а завязывать всё на условный гугл и входить через него — тоже так себе затея.
У Эпла довольно удобно сделано, сафари при заполнении формы для пароля во время регистрации предлагает сгенерировать уникальный пароль и сразу вносит в keychain из-за чего становится доступным на всех устройствах. Уже забыл когда последний раз придумывал пароль.
Подтверждаю. Очень удобно, пароли генерит сложные, запоминать не надо, Сафари их сама подставляет. Хранит в защищенном месте. Можно синхронизировать с другими устройствами. Одна из удобнейших функций на маке. И вообще — Сафари отличный браузер.
Хром и огнелис тоже умеют это делать, притом тоже достаточно давно. Другое дело, что этим сервисам я не доверяю, вместо них использую GNU pass с шифрованием и синхронизацией через свой гит-репозиторий, который хостится на собственном сервере.

Mozilla Firefox тоже так умеет. Удобно для одноразовых сайтов которые нужны, но требуют регистрации на совершение действия. Одноразовая почта + какой-то рандомно сгенерированный пароль который мне даже не интересен и voila

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

С точки зрения хранения пароля, нет: по скорости примерно равны, а уязвимости SHA1 на такой короткий ввод весьма ограниченного паттерна не распространяются.

а реально ли встречается 5,6,7 бит энтропии на символ? разве все не будет кратно 8 битам? пароль то пользователь все равно вводит символами, а символ в простом представлении это 8 битное число. хотя есть кодировки и 7 битные, но кто будет заморачиваться? так что даже если взять только одни цифры, то злоумышленнику все равно придется перебирать все 256 вариантов(если рассматривать стандартную ACII таблицу) на символ.
разве все не будет кратно 8 битам?

Удачи Вам ввести в пароле символ 0x07 (Backspace) или 0x0D (возврат каретки). Да и вообще пусть не большую, но значительную часть возможных битовых сочетаний.

Иногда такая возможность все же есть. Например ввод пароля для зашифрованного тома luks при загрузке linux.

Не хватает хорошего парольного алфавита, чтобы не было 1 и I, O и 0, u и v, i и j, nn и m, vv и w, и так далее.
Берёте случайный текст или лучше файл и в base56 его.
Все символы подходящие, энтропия в норме, если забыли/потеряли пароль — можно попробовать вспомнить сид
Действительно base58 — любопытнейшая штука. Всё что могло быть изобретено, уже изобретено ). Спасибо.
Во многих генераторах есть опция исключения похожих символов.
KeePassXC, опция «не использовать визуально схожие символы» – примерно это и делает.
Для того чтобы получить 256 бит энтропии в пароле из букв и чисел нужно 43 символа.
P.S. кажется во Вселенском компьютере индексация начинается с 0 :)
Преимущество хранения хэшей вместо самих паролей заключается в том, что паролей в БД нет. И это правильно, потому что вам нужно только доказать, что вы знаете свой пароль, но сам он не имеет значения.

В плане аутентификации по паролю есть два подхода: PAP и CHAP. Так вот вы их смешали: при PAP пользовательский пароль передаётся как есть, а в БД хранится хэш для сверки. А вот при CHAP как раз пользователь передаёт лишь признак знания пароля, но на стороне сервиса он должен хранится в обратимом виде.

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

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

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

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

«Хранители паролей» это складывание яиц в одну корзину, к тому же часто не свою…

Все «мнемотехники» это сразу нестойко, притом сильно нестойко.

Биометрию сложно сменить в случае утечки.

Я бы копал в сторону центров выдачи ЭЦП с возможностью отозвать + пропускать через биометрию. Какой нибудь IRIS-сканер с пин-кодом и смарт-картой содержащей ЭЦП. То есть мы имеем три составляющие, одна жестко привязывает к человеку, другая обеспечивает возможность сменить пароль в случае утечки, третья (пин-код) служит признаком добровольности и обеспечивает отзыв ЭЦП в случае серии подбора или ввода тревожного кода.
Компрометацию центров выдачи ЭЦП вы кажется не учли. Более того, за последнюю пятилетку ситуаций связанных именно с этим было предостаточно, начиная от выдачи левых сертификатов мошенникам в России для всяких кадастров и реестров, заканчивая недавней историей с SSL.
Причём риск в данном случае ещё выше, т.к. с такой структурой сразу понятно к кому идти и утечка базового сертификата гораздо страшнее, чем взлом любого сайта или менеджера паролей, которые, если нормальные, не видят данные своих клиентов, т.к. они зашифрованы.
Я уже не говорю что в такой структуре можно выпустить «дубликат» кредов через «дружественный» центр.
Ок, если центр ЭЦП скомпрометирован, это во первых станет довольно быстро известно, во вторых остается фактор биометрии и пинкода (защита для ранее получивших там ЭЦП людей). Собственно скомпрометировав ЭЦП можно нагенерить спамеров с фейковой биометрией. Но их сразу будет видно и все подозрительные ЭЦП отзовут.
Впервую очередь надо забыть порочную практику использовать логин как имя, и детеоменированный логин в виде мыла или номера телефона.
у тинькова у меня логин и пароль случайные строки по 25 символов.
раньше это мог ок.ру, но там теперь и номер телефона работает.
я конечно всего-навсего юзер и не обладаю всей полнотой знания в данном вопросе, во всех статьях которые я читал почему-то нигде не предлагали ввести сложный короткий пароль несколько раз v31T# согласитесь 5-6 значных сложный пароль запомнить гораздо легче чем 25-36 значный.

Потому, что такой пароль по стойкости будет почти равен короткому паролю плюс одна цифра(кол-во повторений).
Как только подобная практика генерации паролей окажется в топ 1000 популярных паролей, её внесут во все утилиты по подбору.

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

Для усиления криптостойкости еще можно добавить что-нибудь в хвост или в середину или в начало.
В своё время очень понравилась идея проекта qwertycards.com, хотя имеет существенный минус – наличие этой карточки (в кошельке или в фотоголерее с паролем), т.е. когда смотришь на неё, то кто-то другой также может смотреть её, и что страшнее – сфоткать
Вот тут, как раз и защищает вас та часть, которую придумываете сами.

пример карточки и инструкция к использованию
image
image

Моя демка для генерации собственной карточки sansys.github.io/cryptocard

Все преимущество — что электроники нет. В современных условиях лучше купить самый дешевый (можно даже БУ) китайский смарт, поставить на него CryptoPass, вбить мастер-пароль и генерировать пароли для сайтов в нем.


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

Встает вопрос удобства ввода пароля (набивать 64-128 символов? есть ли драйвер для смартфона чтобы прикинуться клавиатурой?) и криптостойкости сгенерированных сторонним приложением паролей (кто гарантирует вам генерацию уникальных паролей, а не выборку из 100000 паролей которые выглядят вполне случайно).

Далее, как бакапить такие пароли? А то китайский смарт умер, дальше что?

Как обеспечить невозможность восстановления пароля путем социнженерии, взлома почты и смены симкарты?

есть ли драйвер для смартфона чтобы прикинуться клавиатурой
Я тоже искал. Сам по себе Linux эмулировать HID умеет. Но в том же андроиде это умение с самых ранних версий выключено. Правда, когда Android Pie был на стадии слухов — были статьи, что HID эмуляция таки будет. Но ее, похоже, так и не включили.


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


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


Далее, как бакапить такие пароли? А то китайский смарт умер, дальше что?


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


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


PBKDF2 вроде бы это и гарантирует.


Как обеспечить невозможность восстановления пароля путем социнженерии, взлома почты и смены симкарты


Никак. Это за пределами обсуждения. Если сервис позволяет по почте и телефону пароль сбросить и восстановить — то этот риск от способа хранения и генерации пароля не зависит.

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

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

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

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


Возможно я не понял вашу схему, что происходит при вводе мастер-пароля?

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


Если мы бакапим только его, то где хранятся сами пароли?

Нигде. Они каждый раз генерируются из мастер пароля и прямо тут же введенного имени учетной записи. (Собственно, все это написано в описании CryptoPass, которым я предлагал заменить qwertycards, которые делают похожее, но ручным алгоритмом):


password = base64(pbkdf2(secret, username@url))

PBKDF2 это стандарт, метод генерации паролей. Как проверить его корректную реализацию?

Ссылка CryptoPass была на f-droid. Что означает что исходники доступны. Возможно, что PBKDF2 прямо в этих исходниках нет, но тогда реализация системная и ищется в исходниках андроида или используемой библиотеки.

Кто-нибудь знает, какую хэш-функцию использует контроллер домена на Windows Server 2012 R2?
В большой компании сисадмины очень часто сталкиваются с тем, что пользователи забывают свои пароли (привыкли люди, что браузеры и почтовые клиенты запоминают пароли за них); и приходится каждый раз сбрасывать пароли пользователей и заводить их заново (и заставлять пользователя записать в свой блокнот). А еще хуже, когда пользователи держат свои пароли на виду. В своей госбюджетной организации мы боролись с пользователями, наклеивающими стикеры с паролями на мониторы, и все равно не могли это побороть окончательно: обязательно у кого-то где-то проявится (хотя и стало значительно реже). Кто-то иконки со святыми клеит на монитор, а кто-то — стикеры с паролями и также молится на эти листочки — типа как бы не ошибиться при вводе пароля. Хотя бы листочки клали под клавиатуру, а не вешали на самом видном месте! Представьте себе, например, кабинет бухгалтера, каждый день — куча посетителей (своих сотрудников и извне), а на мониторе бухгалтерши висит стикер со всеми паролями (АД, вход в БД, Интернет, почта, банк-онлайн и т.д.) И не мудрено, что периодически какие-нибудь недохакеры (все пароли-то известны) получают нелегальный доступ к БД и пр. авторизованным сервисам, и отследить такие заходы не так просто. Не так давно зашел к одному начальнику отдела, настраивал ему компьютер, а когда он вышел, взял со стола открыто лежащий листок с паролями сотрудников его отдела и тут же отксерил на его МФУ. Потом разбирался с ними и их начальством; ведь так и любой их др. посетитель мог поступить, т.к. посетителей к нему всегда было довольно много.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.