GitHub сообщил (https://github.com/blog/2190-github-security-update-reused-p...) о выявлении крупной атаки, пытающейся получить доступ к учётным записям пользователей, используя базу известных логинов, email и паролей (https://www.opennet.ru/opennews/art.shtml?num=41646), полученную на основе происходивших ранее утечек персональных данных пользователей различных online-сервисов (например, eBay (https://www.opennet.ru/opennews/art.shtml?num=39832) и LinkedIn (https://www.opennet.ru/opennews/art.shtml?num=34033)). Разбирая связанную с атакой активность, инженеры GitHub выявили, что ряд попыток оказался успешным и атакующим удалось захватить некоторые из аккаунтов, владельцы которых используют одинаковые пароли на разных сайтах. Пользователям рекомендовано выбрать для GitHub уникальный пароль и воспользоваться двухфакторной аутентификацией (https://www.opennet.ru/opennews/art.shtml?num=37815).URL: https://github.com/blog/2190-github-security-update-reused-p...
Новость: http://www.opennet.ru/opennews/art.shtml?num=44609
Гитхаб вынужден рассказывать хипсторам очевидные вещи. Дожились.
Возможно это лишь косвенный способ ещё раз привлечь внимание к проблеме, озвученной Марком Барнеттом годом ранее.
Какой еще Барнетт, проблема повторного использования паролей уже боян почти. Даже в xkcd было https://xkcd.com/792/
Расскажи это хипсторам из aws, нехипстор. Те то же самое сделали.
Ты небось такое же даунито, как и целевая аудитория советов гитхаба? Один ник, один пароль, один смузи?
Вслух произнеси что написал и подумай над своим поведением, клоун.
Хех, сапожники-то все до единого без сапог. :)))))))А еще поют повсюду о безопасности. :))))))
В том числе и здесь :))))
Просветите как такое может быть, если пароли хешируются с солью, и не один раз?
> Просветите как такое может быть, если пароли хешируются с солью, и не
> один раз?Хешированные пароли _должны_ передаваться на сервер в открытом тексте при логине.
Продолжать или сделаешь вид, что понял?
>> Просветите как такое может быть, если пароли хешируются с солью, и не
>> один раз?
> Хешированные пароли _должны_ передаваться на сервер в открытом тексте при логине.
> Продолжать или сделаешь вид, что понял?Это где же пароль передается открыто? Что за протокол?
ftp, http. Кэп.
http не протокол аутентификации. ftp - древний как мамонт, когда аутентификация была чисто на доверии
> ftp, http. Кэп.pap еще вспомни.
Я могу вспомнить только pop3. Что за протокол pap, мне не ведомо.
При этом ВСЕ 3 протокола актуальны и самые часто используемые.
pop3 - почтовый протокол. POP3 поддерживает различные методы аутентификации для предоставления разных уровней защиты от незаконного доступа к пользовательской почте.
PAP - Password Authentication Protocol. Самый простейший и древний протокол аутентификации.
Многие протоколы прикладного уровня используют механизм PAM для "прикручивания" модуля поддержки безопасности
> PAP - Password Authentication Protocol. Самый простейший и древний протокол аутентификации.Спасибо, буду знать.
Вы можете понять простую вещь, что в вебе для доступа к обычным, не финансовым, сайтам не используется никаких протоколов аутентификации, и зачастую по http они передаются постом, в открытом виде.
https тут не сильно спасает а ставить x509 сертификат для каждого отдельного простого сайта никто не будет.
Это, скорее всего, не нормально, но это де-факто.
Спасибо, кэп ))
> Спасибо, кэп ))Да не за что. :-)
Сам вот задумался, а как сделать-то по нормальному?
Можно использовать JavaScript, чтобы хэш пользователь создавал у себя сам, но во-первых, нативной реализации sha512 в JS нет, а во-вторых, такое поведение вынуждает сервер отсылать каждому пользователю соль, которая должна хранится в секрете, или отказаться о соли вообще, что ещё хуже.
Браузер должен на клиентской стороне заниматься этим, а не клиентский скрипт, который вообще не обязан выполняться пользователем. Но никаких средств для этого, кроме сертификатов, не предусмотрено.
Как вариант: Сервер хранит hash пароля, полученного при регистрации.
В дальнейшем при обращение отдавать запрашивающему куки и соль. Браузер и скрипт у клиента из соли и хэша, введенного пароля создает уникальный хэш и передает его вмести с куки. Сервер по куки идентифицирует запрашивающего и проверяет пароль, проделывая с солью и ххранящимся хэшем тоже самое. Накладно и Задосить здесь можно, поэтому сервер должен тут же выдать клиенту временный билет и клиент через определенный промежуток времени с того же ip предъявив куки и временный билет, при удачной проверки, которую сервер неспеша выполнит, становиться авторизованным. Это так, экспромт только что. )
важно, чтобы куки и временный билет передавались вместе один раз запрос-ответ
> которая должна хранится в секрете,Соль без хэша бесполезна. перехватившей же не знает пароль. А парольный хэш не передается, а или храниться на сервере или формируется из введенного пароля на клиенте
>> Спасибо, кэп ))
> Да не за что. :-)
> Сам вот задумался, а как сделать-то по нормальному?
> Можно использовать JavaScript, чтобы хэш пользователь создавал у себя сам, но во-первых,
> нативной реализации sha512 в JS нет, а во-вторых, такое поведение вынуждает
> сервер отсылать каждому пользователю соль, которая должна хранится в секрете, или
> отказаться о соли вообще, что ещё хуже.
> Браузер должен на клиентской стороне заниматься этим, а не клиентский скрипт, который
> вообще не обязан выполняться пользователем. Но никаких средств для этого, кроме
> сертификатов, не предусмотрено.еще вариант. подумать в сторону взаимного изменения куки.
сервер отдает куки клиенту. клиент на основе пароля и соли меняет куки и отдает его вместе со старым куки через таймаут. Сервер делает тоже самое в пределах таймаута и сравнивает результат
у вас что, совещание капитанов? Или почетный слет велосипедистов?
гуглите digest и cram, все уже придумано до вас
> гуглите digest и cram, все уже придумано до васhttps://ru.wikipedia.org/wiki/CRAM-MD5
Это вообще не относится к вэбу.https://ru.wikipedia.org/wiki/%D0%94%D0%...
Это совсем не то, что ожидалось.
Во-первых, смущает использование md5, да ещё и без соли.
Во-вторых, не понятно, как будет происходить регистрация пользователя, восстановление пароля и предполагается ли это тут вообще?
>>> Просветите как такое может быть, если пароли хешируются с солью, и не
>>> один раз?
>> Хешированные пароли _должны_ передаваться на сервер в открытом тексте при логине.
>> Продолжать или сделаешь вид, что понял?
> Это где же пароль передается открыто? Что за протокол?Я, наверное, опять! непонятно написал? Ай-ай... Я испралюсь:
При хранении паролей в хешированном виде на сервере, с которого их _уводят_ плохие плохиши, хороший малыш при _логине_ на этот сервер/сервис _должен_ передавать серверу свой пароль открытым текстом.
Лучше?
/// И да, для ненаблюдательных: я ничего не писал про "протоколы" -- потому что это всё **независимо от** протокола. То есть при любом п. авторизации, не знаю уж почему оно тебя взбудоражило...
>[оверквотинг удален]
>>> Продолжать или сделаешь вид, что понял?
>> Это где же пароль передается открыто? Что за протокол?
> Я, наверное, опять! непонятно написал? Ай-ай... Я испралюсь:
> При хранении паролей в хешированном виде на сервере, с которого их _уводят_
> плохие плохиши, хороший малыш при _логине_ на этот сервер/сервис _должен_ передавать
> серверу свой пароль открытым текстом.
> Лучше?
> /// И да, для ненаблюдательных: я ничего не писал про "протоколы" --
> потому что это всё **независимо от** протокола. То есть при любом
> п. авторизации, не знаю уж почему оно тебя взбудоражило...Открытый пароль может быть передается при регистрации.
https://var.pp.ua/Materialy/Old-lessons/Security/Less-2/1-Au...
Только не надо упоминать прикладные протоколы, криво прикрученные к процессу авторизации или аутентификации.
> Это где же пароль передается открыто? Что за протокол?Какая разница, как передаётся пароль, если linkedin хранил твой пароль от gmail открытом виде?
ну ты ... chap md5 отменили? как и прочие протоколы без разглашения секрета..
> Хешированные пароли _должны_ передаваться на сервер в открытом тексте при логине.
> Продолжать или сделаешь вид, что понял?А давайте уже кто-нибудь напишет что-нибудь про challenge-response и _не_передачу открытого пароля? -----
Тогда он хранится на сервере не в виде хэша - неизвестно, что хуже...
> Тогда он хранится на сервере не в виде хэша - неизвестно, что
> хуже...Не обязательно. Паролем может быть хеш от реального пароля.
О чём ты вообще? С других сайтов произошла утечка паролей (ну и походу логинов). И эти пароли тупо ввели в аккаунты на гитхабе
Использована утечка из базы паролей. То что добавляется к "соли". Сервер добавляет к соли хэш из базы.
Генерирую длиннющие пароли для каждого нового сайта и храню их в KeepassX. Брат жив, зависимость огромная.
Я - это ты. Одно бесит: некоторые сайты накладывают ограничения на пароли, когда настроенный дефолтный генератор keepassx приходится тюнить в сторону ослабления.
> Я - это ты. Одно бесит: некоторые сайты накладывают ограничения на пароли,
> когда настроенный дефолтный генератор keepassx приходится тюнить в сторону ослабления.А нативный "pwgen -(s|y) 16" чем плох?
Не менее 1 прописной буквы, не менее 1 строчной буквы, не менее 1 цифры, не более 8 символов, символы помимо этих 36 запрещены. Это мой бывший провайдер.
> Не менее 1 прописной буквы, не менее 1 строчной буквы, не менее
> 1 цифры, не более 8 символов, символы помимо этих 36 запрещены.
> Это мой бывший провайдер.То есть не 36, а 62. Районный провайдер из ЮВАО Москвы, давно купленный Акадо.
> Не менее 1 прописной буквы, не менее 1 строчной буквы, не менее
> 1 цифры, не более 8 символов, символы помимо этих 36 запрещены.
> Это мой бывший провайдер.pwgen -s 8
> не более 8 символов
А если вы, таки, ошиблись и имели ввиду не МЕНЕЕ 8 символов, что логично предположить, то, как приводил ранее:
pwgen -s 16
Хранитель паролей изолирован надежно? ))
Для мобильных ОС приложение кажется отсутствует? Тогда в 2016 году уже не надо.
http://keepass.info/download.html выбирайте на вкус
> http://keepass.info/download.html выбирайте на вкусНет, Contributed/Unofficial KeePass Ports, не нужно. Под iOS всё равно нет. Далее не трудитесь, я в состоянии купить себе приличное ПО. Купил 1password для двух платформ - вот это ПО.
>> keepass.info/download.html
> Нет, Contributed/Unofficial KeePass Ports, не нужно.KeePassX с которого ты начал своё "восхождение" -- сразу не keepass.info-"оригинал". Не знал? Не заметил? Не осилил.
//У меня для мобильной ос - https://f-droid.org/wiki/page/KeePassDroid //тебе не подойдёт -- не для тебя написал.
>Под iOS всё равно нет.
>Купил 1password для двух платформ - вот это ПО.Какой Ви жЫрный., фу.
Купил какой-то "Contributed/Unofficial".
Нет, чтоб, как Большой, купить офисьяльно! без-СМС!! не-лоX!1адын порт MS Mono на свою недо"платформу".
> Генерирую длиннющие пароли для каждого нового сайта и храню их в KeepassX.
> Брат жив, зависимость огромная.а как ввести те же самые логины/пароли с iOS? синхронизация какая-нибудь есть? Приложения для мобильных ОС есть?