Безопасность локального банка

Всем привет.
Приходится пользоваться картой центр-инвест банка (банк, работающий преимущественно в Ростовской области). Изначально, регистрируясь в онлайн приложении ЦИ, меня заставили придумать 8-значный цифровой пароль для входа в панель управления аккаунтом. Было очень неудобно каждый раз вводить 8 цифр, но что поделаешь...
И вот в чем, собственно, загвоздочка: с месяц - другой тому назад пришло обновление, в котором нужно вводить уже 4х символьный пароль. При этом, первые 4 цифры моего 8-значного пароля подходят!
Это что получается, банк хранит пароли в открытом виде? Я не вижу возможности сравнить контрольную сумму полного пароля, с КС обрезанного пароля на соответствие.
Мб, конечно, я что-то не понимаю в этом мире, но сейчас, как только на мой счет поступают денежные средства, я сразу их обналичиваю.

Информационная безопасность IT

1.4K постов25.5K подписчиков

Добавить пост

Правила сообщества

Обязательно к прочтению для авторов:

1. Если вы добавляете пост, утверждающий об утечке данных или наличии дыр в системе, предоставьте ссылку на источники или технически подкованное расследование. Посты из разряда "Какой-то банк слил данные, потому что мне звонили мошенники" будут выноситься в общую ленту.
2. Все вопросы "Как обезопасить сервер\приложение\устройство" - в лигу "Компьютер это просто".

Обязательно к прочтению для всех:

Добавление ссылки разрешено если она не содержит описание коммерческих (платных) продуктов и/или идентификаторов для отслеживания перехода и для доступа не нужен пароль или оплата в т.ч. интернет-ресурсы, каналы (от 3-х тематических видео), блоги, группы, сообщества, СМИ и т.д.


Запрещены политические holy wars.

По решению модератора или администратора сообщества пользователь будет забанен за:

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

2. Публикацию поста/комментария не соответствующего тематике сообщества, в том числе обсуждение администраторов и модераторов сообщества, для этого есть специальное сообщество.

3. За обвинение в киберпреступной деятельности.

4. За нарушение прочих Правил Пикабу.

Вы смотрите срез комментариев. Показать все
16
Автор поста оценил этот комментарий

Есть три варианта. В порядке убывания вероятности.


1. Пароль от приложения хранится в базе Банка в открытом виде. Ну тут понятно.  


2. Правильность (уже) ПИН-кода от приложения расситывалась алгоритмом, делящим вводимой значение на две четырёхзначные сущности. Это нормально и безопасно.


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

раскрыть ветку (40)
5
Автор поста оценил этот комментарий
4. Пин хранится приложением на телефоне.
1
Автор поста оценил этот комментарий

На основании какого пароля система назначила новый пин, если они хранились как хеш?

раскрыть ветку (4)
3
Автор поста оценил этот комментарий

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

раскрыть ветку (3)
1
Автор поста оценил этот комментарий

Интересно. Не знал о таком. Спасибо.

Автор поста оценил этот комментарий

Вы знаете, зачем на серверной стороне пароль хранится в хэшированном виде, а не в открытом?

раскрыть ветку (1)
Автор поста оценил этот комментарий

логично жеж что бы не скомпромитировали кулхацкеры либо работники банка

Автор поста оценил этот комментарий
Это нормально и безопасно

ну вообще, получив хеш, сбрутить 2 четырехзначные половинки намного проще чем целое.

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

раскрыть ветку (2)
1
Автор поста оценил этот комментарий

Верно. Поэтому в мобильном ПО используется пин-код, а не пароль.

раскрыть ветку (1)
1
Автор поста оценил этот комментарий

Это неверно. Зависит от алгоритмов, соли и многих других факторов. Как пример: SHA1=(PIN+randomABC09)*SALT превращает наш пин анальную боль для любого брутфорса, если не знать какую рандомную часть подставляют к пину и какая соль. При этом данная формула частично исключает брут соли на основании заведомо известного пина (к примеру, злоумышленник перед этим оформил карту в банке и знает пин от своей карты). Конечно можно завести 50 карточек и начать параллельный брутфорс пытаясь найти соль и рандомно подставленные числа и это действительно сократит тысяч на 20 лет процесс брутфорса, но остальные пару миллионов лет никуда не денутся :)

1
Автор поста оценил этот комментарий

2 пункт -- это НЕ нормально и НЕ безопасно.

Чего бы тогда не рассчитывать алгоритмом, делящим вводимое значение на 8 сущностей по 1 цифре?
раскрыть ветку (30)
5
Автор поста оценил этот комментарий

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

раскрыть ветку (10)
1
Автор поста оценил этот комментарий

по твоей логике в открытом виде пароли хранить так же безопасно.

если ты знаешь результат аутентификации

суть хеширования как раз в том, чтобы зная результат (хеш) нельзя было восстановить пароль.

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

раскрыть ветку (2)
1
Автор поста оценил этот комментарий

Результат аутентификации и хэш это разные вещи)

Первое это успешно/не успешно. Второе - строка.

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

раскрыть ветку (1)
1
Автор поста оценил этот комментарий

так тут речь не о том как сервер отвечает. он то понятно весь пароль целиком проверяет, а не по половинкам говорит, где верная половинка, а где нет.

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

Автор поста оценил этот комментарий

Так тогда и банк не сможет по 2 хэшам восстановить один из них. А тут речь шла про то, что может.

Пароли хранятся на серверной части в хэшированном виде не просто так.

раскрыть ветку (6)
Автор поста оценил этот комментарий

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

Если не ошибаюсь, была такая история с WPA. Восьмизначный пароль сравнивался по 4 символа и была возможность узнать результаты сравнения каждой половины. Т.е. задача упрощались со ста миллионов вариантов до 20 тысяч.

раскрыть ветку (5)
Автор поста оценил этот комментарий
Зачем на серверной стороне пароли хранятся в виде хэша? Почему не в открытом виде? :)

Про WPA вы почти правы. Только WPS.
раскрыть ветку (4)
Автор поста оценил этот комментарий

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

раскрыть ветку (3)
Автор поста оценил этот комментарий
Я утверждаю, что с точки зрения подбора есть большая разница: 1 хэш от всего пароля или 2 хэша от его половин. Вы с этим не согласны?
раскрыть ветку (2)
Автор поста оценил этот комментарий

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

раскрыть ветку (1)
Автор поста оценил этот комментарий
Пароли на серверной стороне надо хранить в хэшированном (и посоленном) виде для защиты от слива базы. Получивший базу не получит пароли в открытом виде.
Весь сыр-бор ради этого.
Так что у взломщика будет хэш. Иначе можно было бы хранить пароли в открытом виде.
А надежды на скрытость алгоритма -- это вообще от лукавого, надеяться на такое нельзя.
Автор поста оценил этот комментарий

Почитай теорию криптографических алгоритмов. Например, про NTLM и как хешируется пароль от учётной записи на твоём компе.

раскрыть ветку (10)
Автор поста оценил этот комментарий

Что конкретно почитать? Как работает NTML я по большей части догадываюсь. А уж как хэшируется пароль от учетки знаю точно:

morr:$gost94hash$wgc7Ct4G$FK/GjEKFTmEGfu6A1kQy9euEIlxUbwkki0pIHnEn5T4:17767:0:99999:7::: :)

раскрыть ветку (5)
Автор поста оценил этот комментарий

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

раскрыть ветку (4)
Автор поста оценил этот комментарий
Пока не понимаю, о чем вы. "Эти два это LM Hash ( функции, основанные на стандарте шифрования данных для первых 14 символов пароля преобразованные в традиционную 8 битную кодировку для языка ПК) и NT Hash ((MD4 of the little endian UTF-16 Unicode password)." -- это? Или о каком разбиении пароля на 2?
В любом случае NTLM -- вообще не то, на что сейчас нужно опираться. Один md4 чего стоит. Уже md5 не используют нигде.
Если вы о чем-то другом, то дайте прямо абзац, прочитаю конкретно.
раскрыть ветку (3)
Автор поста оценил этот комментарий
Все, нашел о чем речь. Но достаточно процитировать начало статьи на вике: "С самого изобретения протоколы NTLMv1 и NTLMv2 подвергались множеству нападений и демонстрировали широкий спектр серьёзных уязвимостей. ". Не нужно опирать на старый и плохой NTML :)
Автор поста оценил этот комментарий

Хешировать пароли учёток Винды md* это сильная идея. Про неиспользование md5 нигде ещё более сильная. Процессинги ecommerce смотрят на твой пост с удивлением.

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

обожаю такие комменты. 0 конкретики и "прочитай там-то", подразумевая "даже объяснять тебе тупому не буду, все равно не поймешь"

а по факту вижу звон и не знаю где он

раскрыть ветку (3)
Автор поста оценил этот комментарий

А что нужно было? Скопипастить спецификацию алгоритма?

раскрыть ветку (2)
Автор поста оценил этот комментарий

ну, раз ты помнишь название, наверно и в двух словах можешь рассказать о чем ты.


по запросу NTLM я нашел две вещи:

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

сам NTLM, но там хеш один, просто он делится на 3 части и этими частями шифруется полученное от сервера случайное число.


таким образом я потратил лишнее время и все равно не получил объяснение.

раскрыть ветку (1)
Автор поста оценил этот комментарий

Ты получил информацию, просто не вполне корректную. LAN manager ещё как используется в древних мейнстримах и станках АСУ ТП на всяких заводах и даже частично в газовой отрасли. В другом бизнесе да, это говно мамонта уже давно выпилено.

Автор поста оценил этот комментарий

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

раскрыть ветку (7)
1
Автор поста оценил этот комментарий

Прямо WPS повеяло.

Полный перебор для хэша 1 пароля из 8 цифр -- 100.000.000 вариантов.

Полный перебор для хэшей 2 паролей из 4 цифр каждый -- 20.000 вариантов.

раскрыть ветку (6)
1
Автор поста оценил этот комментарий

Да, согласен, логично.

С другой стороны в итоге пришли к одному паролю из 4-х цифр - 10000 вариантов.

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

раскрыть ветку (2)
Автор поста оценил этот комментарий

Это другой вопрос, да )

Про 100 миллионов хэшей ваще не вопрос -- ну смотря какие хэши ) Но в целом вы правы, все равно все через задницу, чего уж )

раскрыть ветку (1)
1
Автор поста оценил этот комментарий

вот мы тут гоним на банк, а они может все хорошо хранят.

просто они великодушно перебрутили всем пароли и заменили четырехсимвольными)

Автор поста оценил этот комментарий

почему? реально не понимаю. 8 ячеек же и там и там. И должны совпасть все. Как так меньше то?

раскрыть ветку (2)
Автор поста оценил этот комментарий

Ну так проверка результата для половины кода. Т.е. подобрали 4 символа -- узнали, что подбор успешен. Потом подобрали еще 4.

раскрыть ветку (1)
Автор поста оценил этот комментарий

там проблема в том, что можно было узнать результат на каждые из 4 символов отдельно. Если бы коробка считала внутри обе части и выдавала объединенный ответ (только когда обе половинки совпали), дыры бы не было.

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