LINUX.ORG.RU

Молчаливое Табу - Никогда Не Устаревающие Пароли


0

0

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

>>> Подробности

★★★★★

Проверено: Shaman007 ()

What is that three common used passwords?
- Love, secret and sex. But not in the order necessary. Right?
Yeah, don't forget god, system operators love use god...(c) Hackers 1995

SatanClaus ★★★
()

А на какой тогда ssl ???

faust
()

> Автор статьи не даёт никаких советов для решения проблемы, но она действительно острая, особенно учитывая то, что в последнее время outsourсing стал особенно популярен, а значит такие "пароли" могут знать слишком много "левых" людей

А у этой проблемы вообще есть решение?

alman ★★★
()
Ответ на: комментарий от SatanClaus

Ххы-хы-хы. У нас пароли на вход в домен вида Логин:Логин, а кое-кто до сих пор с третьей попытки входит. Для таких, как мы, зверобухи и ящероменеджеры, пароли - зло.

Ekonomist
()
Ответ на: комментарий от baka-kun

> Пользуйте аппаратные токены или однократные пароли.

Токены для веб? А по подробней можно? Очень интересно, честно.

mutronix ★★★★
()
Ответ на: комментарий от mutronix

> Токены для веб?

да нет, это ответ на: "У нас пароли на вход в домен вида Логин:Логин, а кое-кто до сих пор с третьей попытки входит". ;)

baka-kun ★★★★★
()
Ответ на: комментарий от mutronix

А по теме статьи... Тут рассматривается проблема "хардкодед" паролей между сервером приложений и бекендами (между php и mysql, и т.п.), и что произойдет (гипотетически), если "кто-то" -- предполагаемый malicious former employee -- полезет им воспользоваться.

Что сказать?.. "Отдел IT безопасности на мыло." и "Опенсорс рулит, при условии, что есть мозги." ;)

baka-kun ★★★★★
()
Ответ на: комментарий от baka-kun

У нас в универе я перехватил сниффером пароль SA (system admin) на SQL базу считающую траффик. Было прикольно, но потом ситивики его поменяли.

anonymous
()
Ответ на: комментарий от anonymous

Ну кто же пускает такой трафик по общедоступным каналам?

baka-kun ★★★★★
()
Ответ на: комментарий от anonymous

> нас в универе я перехватил сниффером пароль SA

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

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

anonymous
()
Ответ на: комментарий от anonymous

> и сделали всю сеть свичеванной (один хост - один порт), хрен бы кто
> чего снифером отлавил

не все так просто
легким движением руки (атака типа arp cache poisoning ) свитч превращается в хаб

Tester ★★★
()
Ответ на: комментарий от Tester

Лёгким движением руки при смене arp нормально настроенная циска посылает тебя в далёкое эротическое путешествие. И банит на 2 недели.

anonymousI
()
Ответ на: комментарий от anonymousI

> Лёгким движением руки при смене arp нормально настроенная циска
> посылает тебя в далёкое эротическое путешествие. И банит на 2 недели.

мало таких контор в которых все свитчи, включая оконечные - циски.
и уж тем более мало "нормально настроенных"

имхо нормальный админ должен полагаться не на решение которое "защитит" его от сниффинга а на решение которое делает этот сниффинг бессмысленным

Tester ★★★
()
Ответ на: комментарий от Tester

> имхо нормальный админ должен полагаться не на решение которое "защитит" его от сниффинга а на решение которое делает этот сниффинг бессмысленным

Доставай зачетку, приятель, если бы у всех были хотя бы в половину столь светлые головы, как у тебя, то гейтс был бы нищим а мир был бы прекрасен :)

anonymous
()
Ответ на: комментарий от alman

> А у этой проблемы вообще есть решение?

Как минимум 3:

- шифрование канала связи.
- регулярная смена паролей.
- использование одноразовых паролей.

anonymous
()
Ответ на: комментарий от baka-kun

2 baka-kun

И как это сделать в случае 1С которая ломится в SQL под sa? Есть предложение закидывать такие конторы тряпками, или отправлять полным составом в славный город Бобруйск за иадом.

anonymous
()

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

darth
()
Ответ на: комментарий от anonymous

> И как это сделать в случае 1С которая ломится в SQL под sa?

Или выкинуть 1С ;)

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

baka-kun ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.