Надежный пароль

[StanislavL]

Задумало мну ...
Вот все мы типо знаем шо це такэ "надежный пароль". И юзерам, у которых пароль = имя любимой кошки, не раз мозги вправляли.
А вот довелось мне некоторое время назад поработать на лавочку, где секьюрити пальцЫ круто гнут, и с политиками безопасности фсе типо круче некуда. В пароле обязательно должны быть большие буквы, цифры, спецсимволы... То-исть, "правильные" пароли типа Kr5$63m!
Все хорошо, все правильно ? Секундочку, не торопимся - у меня там таких паролей было 3 штуки. Ну, ладно, 3 - не 33, как-нибудь моск напряжем...
Но вот последняя сцена: в один прекрасный день (а точнее ровно через месяц) с улыбкой идиота наблюдаю надпись "пароль устарел, назначь новый" Назначаю новый пароль, достаю блокнотик и ЗАПИСЫВАЮ его Ага - я, который забыл сколько раз юзеров за это сношал.

А чо делать-то, мля ?!!

Мне, чтобы пересчитать пароли, которые я держу в голове, надо минут 10-15. (Не, не потому что их сотни, всего-то несколько десятков, просто чтоб не забыть ничего) Но я их помню только потому, что они во-первых "запоминаемые", во-вторых - меняются раз в год-два-три, не чаще. Конечно, это "неправильно" с т.з. ахренительной безопасности, но зато помню. А требования неизвестного мне админа сразу вызывают у меня вспухание мозга, и намеренное нарушение одной из основных заповедей становится единственным выходом. Тот админ безусловно прав - при условии, что те три пароля - единственные, что других паролей у меня в принципе нет. То что они - исчезающе малая часть в моем "списке" - вот это его локальной политикой безопасности не предусмотрено!

А нынче время такое - любой ламер кроме пароля на компе имеет пароль на e-mail, пароль на вконтакт, ....

Вопрос на размышление: а не пора ли "азы" безопасности малость пересмотреть ? Ровно настолько, чтоб можно было пароли не записывать.

[watashiwa_daredeska]

Вопрос на размышление: а не пора ли "азы" безопасности малость пересмотреть ? Ровно настолько, чтоб можно было пароли не записывать.

Эти «азы» мэтры безопасности уже давно пересмотрели. Сейчас считается достаточным иметь один master-password к хранилке паролей и все остальные пароли держать там.

[drBatty]

эх...

[enemysystems]

Это капец. И ужас. Забей уже и заюзай один пароль. Один попроще и покороче, чтобы вводить быстро, другой на такие аккаунты, которые требуют большего.

[drBatty]

А чо делать-то, мля ?!!

MKPASSWD(1) MKPASSWD(1)

NAME
mkpasswd - generate new password, optionally apply it to a user

SYNOPSIS
mkpasswd [ args ] [ user ]

INTRODUCTION
mkpasswd generates passwords and can apply them automatically to users. mkpasswd is based on the code
from Chapter 23 of the O'Reilly book "Exploring Expect".

пароли я записываю в текстовый файл, который зашифрован моим личным ключом. (man gpg).

[SLEDopit]

Меня куда больше при таких требованиях радовало требование "чтобы пароль не совпадал с N предыдущими и отличалось от него минимум на N символов". В каком-то банке эта цифра была 33. Как, ну как я могу помнить что у меня тогда был за пароль?

[drBatty]

Меня куда больше при таких требованиях радовало требование "чтобы пароль не совпадал с N предыдущими и отличалось от него минимум на N символов". В каком-то банке эта цифра была 33. Как, ну как я могу помнить что у меня тогда был за пароль?

это при требовании "НЕ записывать пароль нигде, кроме мосга"?
ну... Вдоль.

[SLEDopit]

это при требовании "НЕ записывать пароль нигде, кроме мосга"?

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

[Ленивая Бестолочь]

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

ну блин, не мучаться же самим. :-)

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

меня ещё, как админа искренне радуют всякие умные сотрудники, которые звонят типа "я три часа не могу пароль придумать, мне говорят, что он не достаточно сложный!!!11 работа стоит ваще, вы виноваты во всём, я буду жаловаться."
при этом у нас требования, что пароль должен быть ровно восемь символов, не быть одним из предыдущих, содержать только латинские буквы (и можно цифры) и не быть словарным словом или популярным паролем (а так же содержать оные).
поэтому я говорю - вы требования читали? ну вот, я вам обещаю, что пароль kdfu23hp 100% подойдёт. и ведь подходит.
такие дела.

[kyzic]

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

[sash-kan]

ahappy (admin happy) спешит на помощь·
запоминаете что-нибудь более удобоваримое, скармливаете ahappy, он выдаёт такие кракозябры, что любой админ (и даже отдел безопасности) кипятком описаются·
пример:
$ ahappy -i
enter phrase (empty line to quit): (вводим, например, "12345")
<>/lFz
enter phrase (empty line to quit): (вводим, например, "оченьтупаяфраза")
*-LfbgZo\$+}2PX/v&zF7u0!:pRUZBwn"q#eL
enter phrase (empty line to quit): (нажимаем enter, не вводя ничего — выход)
$

если запустить без (единственного пока) параметра, фраза будет запрошена один раз, пароль будет помещён в x-clipboard (при доступности программы xclip)·

почему написал такую приблуду? потому что не нашёл средства, хэширующего строку с нужными _мне_ параметрами (в частности, чтобы хэш строился из указанного набора символов (такого-то «алфавита»))·

с точки зрения логики работы:
введённая строка рассматривается как набор байт, который преобразуется в большое-большое число (для строки "12345" — "((((49)*256+50)*256+51)*256+52)*256+53")·
это число переводится в систему счисления с основанием, равным длине заданного «алфавита»·
после этого из «алфавита» берутся соответствующие «цифры» (которые могут быть произвольными символами)·
дефолтный алфавит состоит из символов, начиная с 0x21 (!) по 0x7e (~), но легко переопределяется, хоть в самом скрипте, хоть в ресурсном файле ~/.ahappyrc (не обязательно, чтобы символы были уникальными, и чем больше раз символ повторён в алфавите, тем выше вероятность, что он войдёт в хэш)·
предупреждение: при изменении алфавита хэши для одной и той же фразы будут разными!

[watashiwa_daredeska]

введённая строка рассматривается как набор байт, который преобразуется в большое-большое число (для строки "12345" — "((((49)*256+50)*256+51)*256+52)*256+53")·

Фиговенько. Уж лучше md5/sha какой-нибудь брать в качестве числа.

Код: Выделить всё

LANG=C

В общем случае этого недостаточно. Надо LC_ALL=C.

[InterChaynik]

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

[watashiwa_daredeska]

сложность пароля как такового, значения не имеет

http://en.wikipedia.org/wiki/Advanced_persistent_threat

[InterChaynik]

сложность пароля как такового, значения не имеет

http://en.wikipedia.org/wiki/Advanced_persistent_threat

И где там про "сложность пароля"?

[sash-kan]

введённая строка рассматривается как набор байт, который преобразуется в большое-большое число (для строки "12345" — "((((49)*256+50)*256+51)*256+52)*256+53")·

Фиговенько. Уж лучше md5/sha какой-нибудь брать в качестве числа.

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

Код: Выделить всё

LANG=C

В общем случае этого недостаточно. Надо LC_ALL=C.

мне ж только для того, чтобы sed не интерпретировал utf как utf·
в gnu, мне кажется, этого вполне достаточно·
хотя добавить ещё одну строчку — конечно, не проблема·

p.s. спасибо, что посмотрел на код и высказал замечания·

[sash-kan]

сложность пароля как такового, значения не имеет

http://en.wikipedia.org/wiki/Advanced_persistent_threat

И где там про "сложность пароля"?

действительно, что-то связь не ясна·

[watashiwa_daredeska]

мне ж только для того, чтобы sed не интерпретировал utf как utf·

Ну, это контролируется не именно самим LANG, а каким-то из LC_*, типа LC_TYPES или еще чем. LANG — лишь «шорткат». И LC_* имеют приоритет над LANG (у меня, например, LANG=ru_RU.UTF-8, но некоторые LC_*=en_US.UTF-8), а LC_ALL имеет приоритет над ними всеми.

хотя добавить ещё одну строчку — конечно, не проблема·

А ее не надо добавлять, надо просто заменить LANG=C на LC_ALL=C, тогда sed будет интерпретировать всё правильно независимо от значения LANG и прочих LC_*.

[watashiwa_daredeska]

И где там про "сложность пароля"?

Про сложность пароля там нет, однако пароли играют важную роль в защите от threats. При наличии APT можно быть на ~100% уверенным, что защиту пробьют, однако это совсем не означает, что надо опускать руки и вообще не заниматься защитой. Ну, примерно как на войне — ПВО противника пробивается достаточно массированным авианалетом с вероятностью 100%, при необходимости, но ведь это не означает, что ПВО не нужно.

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

[hardworm]

Благодаря менеджеру паролей (использую keepassx) проблем с паролями нет. Пароли генерируются сложные. Хранятся в шифрованном виде. Синхронизируются между компьютерами и смартфоном через dropbox. Помнить надо только 1 сложный пароль.

[Bluetooth]

Благодаря менеджеру паролей (использую keepassx) проблем с паролями нет. Пароли генерируются сложные. Хранятся в шифрованном виде. Синхронизируются между компьютерами и смартфоном через dropbox. Помнить надо только 1 сложный пароль.

И таскать с собой устроство, на котором можно открыть менеджер паролей.


Скажите, господа, есть ли какой-нибудь менеджер паролей, позволяющий в случае крайней необходимости получить доступ к паролям с мобильного телефона?

[hardworm]

И таскать с собой устроство, на котором можно открыть менеджер паролей.


Скажите, господа, есть ли какой-нибудь менеджер паролей, позволяющий в случае крайней необходимости получить доступ к паролям с мобильного телефона?

абсолютно внезапно keepass. Он есть для j2me, win, linux, mac, android, ios и т.д.
Вся проблема в синхронизации.

[sash-kan]

мне ж только для того, чтобы sed не интерпретировал utf как utf·

Ну, это контролируется не именно самим LANG, а каким-то из LC_*, типа LC_TYPES или еще чем. LANG — лишь «шорткат». И LC_* имеют приоритет над LANG (у меня, например, LANG=ru_RU.UTF-8, но некоторые LC_*=en_US.UTF-8), а LC_ALL имеет приоритет над ними всеми.

хотя добавить ещё одну строчку — конечно, не проблема·

А ее не надо добавлять, надо просто заменить LANG=C на LC_ALL=C, тогда sed будет интерпретировать всё правильно независимо от значения LANG и прочих LC_*.

вижу нечто обратное:

Код: Выделить всё

$ locale
LANG=en_US.utf8
LC_CTYPE="en_US.utf8"
LC_NUMERIC="en_US.utf8"
LC_TIME="en_US.utf8"
LC_COLLATE="en_US.utf8"
LC_MONETARY="en_US.utf8"
LC_MESSAGES="en_US.utf8"
LC_PAPER="en_US.utf8"
LC_NAME="en_US.utf8"
LC_ADDRESS="en_US.utf8"
LC_TELEPHONE="en_US.utf8"
LC_MEASUREMENT="en_US.utf8"
LC_IDENTIFICATION="en_US.utf8"
LC_ALL=
$ LC_ALL=C
$ locale
LANG=en_US.utf8
LC_CTYPE="en_US.utf8"
LC_NUMERIC="en_US.utf8"
LC_TIME="en_US.utf8"
LC_COLLATE="en_US.utf8"
LC_MONETARY="en_US.utf8"
LC_MESSAGES="en_US.utf8"
LC_PAPER="en_US.utf8"
LC_NAME="en_US.utf8"
LC_ADDRESS="en_US.utf8"
LC_TELEPHONE="en_US.utf8"
LC_MEASUREMENT="en_US.utf8"
LC_IDENTIFICATION="en_US.utf8"
LC_ALL=
$ LANG=C
$ locale
LANG=C
LC_CTYPE="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_COLLATE="C"
LC_MONETARY="C"
LC_MESSAGES="C"
LC_PAPER="C"
LC_NAME="C"
LC_ADDRESS="C"
LC_TELEPHONE="C"
LC_MEASUREMENT="C"
LC_IDENTIFICATION="C"
LC_ALL=
$

у меня неправильно настроенный дистрибутив?

[diesel]

url="https://market.android.com/details?id=com.android.keepass"]android[url], ios и т.д.
Вся проблема в синхронизации.

если он шифрует базы, то можно и через dropbox ..

[Bluetooth]

абсолютно внезапно keepass. Он есть для j2me, win, linux, mac, android, ios и т.д.
Вся проблема в синхронизации.

Ну, файлик синхронизировать дело нехитрое, вопрос в том, как мобильные приложения умеют работать - с базой, находящейся в файле на мобиле, али в дропбоксе, какой-нибудь webdav, ftp, http, samba, etc

если он шифрует базы, то можно и через dropbox ..

Это если приложения поддерживают.

[/dev/random]

у меня неправильно настроенный дистрибутив?

Не знаю, но у меня ведёт себя правильно, т.е. у LANG низший приоритет, а у LC_ALL - высший:

Код: Выделить всё

$ locale
LANG=ru_RU.UTF-8
LC_CTYPE="ru_RU.UTF-8"
LC_NUMERIC="ru_RU.UTF-8"
LC_TIME="ru_RU.UTF-8"
LC_COLLATE="ru_RU.UTF-8"
LC_MONETARY="ru_RU.UTF-8"
LC_MESSAGES="ru_RU.UTF-8"
LC_PAPER="ru_RU.UTF-8"
LC_NAME="ru_RU.UTF-8"
LC_ADDRESS="ru_RU.UTF-8"
LC_TELEPHONE="ru_RU.UTF-8"
LC_MEASUREMENT="ru_RU.UTF-8"
LC_IDENTIFICATION="ru_RU.UTF-8"
LC_ALL=ru_RU.UTF-8

$ LANG=C

$ locale
LANG=C
LC_CTYPE="ru_RU.UTF-8"
LC_NUMERIC="ru_RU.UTF-8"
LC_TIME="ru_RU.UTF-8"
LC_COLLATE="ru_RU.UTF-8"
LC_MONETARY="ru_RU.UTF-8"
LC_MESSAGES="ru_RU.UTF-8"
LC_PAPER="ru_RU.UTF-8"
LC_NAME="ru_RU.UTF-8"
LC_ADDRESS="ru_RU.UTF-8"
LC_TELEPHONE="ru_RU.UTF-8"
LC_MEASUREMENT="ru_RU.UTF-8"
LC_IDENTIFICATION="ru_RU.UTF-8"
LC_ALL=ru_RU.UTF-8

$ LC_ALL=C

$ locale
LANG=C
LC_CTYPE="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_COLLATE="C"
LC_MONETARY="C"
LC_MESSAGES="C"
LC_PAPER="C"
LC_NAME="C"
LC_ADDRESS="C"
LC_TELEPHONE="C"
LC_MEASUREMENT="C"
LC_IDENTIFICATION="C"
LC_ALL=C

И доказательство того, что именно этот вариант - правильный:

LANG Provide a default value for the internationalization variables that are unset or null. (See the Base Definitions volume of IEEE Std 1003.1-2001, Section 8.2, Internationalization Variables for the precedence of internationalization variables used to determine the values of locale categories.)

LC_ALL If set to a non-empty string value, override the values of all the other internationalization variables.

[diesel]

если он шифрует базы, то можно и через dropbox ..

Это если приложения поддерживают.

по идее должны, если есть приложения под Android/iOS и разработчики не совсем шизонутые

[sash-kan]

watashiwa_darede...
/dev/random
на нескольких машинах (включая православную генту):

Код: Выделить всё

$ cat /tmp/test.lang
#!/bin/bash
LANG=C
echo -n 'абв' | sed 's/./1/g' | wc -c
$ cat /tmp/test.lcall
#!/bin/bash
LC_ALL=C
echo -n 'абв' | sed 's/./1/g' | wc -c
$ bash /tmp/test.lang
6
$ bash /tmp/test.lcall
3
$

мне нужно поведение, которое как раз и обеспечивается наличием в скрипте "LANG=C"·

[/dev/random]

watashiwa_darede...
/dev/random
на нескольких машинах (включая православную генту):

Код: Выделить всё

$ cat /tmp/test.lang
#!/bin/bash
LANG=C
echo -n 'абв' | sed 's/./1/g' | wc -c
$ cat /tmp/test.lcall
#!/bin/bash
LC_ALL=C
echo -n 'абв' | sed 's/./1/g' | wc -c
$ bash /tmp/test.lang
6
$ bash /tmp/test.lcall
3
$

мне нужно поведение, которое как раз и обеспечивается наличием в скрипте "LANG=C"·

Код: Выделить всё

$ echo -n 'абв' | sed 's/./1/g' | wc -c
3

$ LANG=C

$ echo -n 'абв' | sed 's/./1/g' | wc -c
3

$ LC_ALL=C

$ echo -n 'абв' | sed 's/./1/g' | wc -c
6

[drBatty]

мне ж только для того, чтобы sed не интерпретировал utf как utf·

в info написано, что нужно менять

Код: Выделить всё

export LC_COLLATE=ru_RU.UTF-8
export LC_CTYPE=ru_RU.UTF-8

причём первая нужна(ЕМНИП) только для выражений типа [а-я]
а вот вторая как раз и определяет кодировку. Это верно для всей glibc.

LC_ALL=C, тогда sed будет интерпретировать всё правильно независимо от значения LANG и прочих LC_*.

LC_ALL=C заменит и LC_CTYPE

если он шифрует базы, то можно и через dropbox ..

шифрует конечно!