ссылки для программистов (англ.)

[avva]

Немного из недавнего и накопившегося:

• Learning to Program: What are the best sites for learning programming?
  
  Неплохой обзор сайтов с подробными уроками программирования (где видеоуроками, где просто) для тех, кто совсем не умеет и хочет научиться.
  
  
  
• Data Compression Explained.
  
  Нечто среднее между очень длинным FAQ'ом и небольшой книгой. Краткое введение в основы сжатия данных и подробный обзор основных подходов и алгоритмов. Написано, по-моему, ясно и аккуратно, но несколько сжато для совсем неопытного в программировании читателя. Не требует знаний об алгоритмах сжатия.
  
  
  
• You Are Dangerously Bad At Cryptography.
  
  Отличная запись о том, почему опасно самому наивно использовать криптографические алгоритмы, с несколькими наглядными примерами.
  
  В дискуссии на HN есть тоже немало интересного. В частности, Томас Птачек напоминает, что его компания Matasano продолжает предлагать широкой публике Crypto Challenges - набор упражнений по прикладному криптоанализу, не требующих предварительных знаний в криптографии. Я сам не пытался пока делать Crypto Challenges, не нашел на это времени, но несколько моих знакомых, которым я доверяю, очень и очень их хвалят. Думаю, что всем, кому хочется больше знать в этой области, стоит попробовать.

Comments

[cat_mucius]

Я не перестаю поражаться повсеместному игнорированию clientAuth в SSL/TLS.

Вы имеете в виду использование клиентских сертификатов? Но в таком случае приведённая там схема с MAC-ом просто не нужна.

[trueblacker.livejournal.com]

именно так.
Но товарищ утверждает, что использование HTTPS ничего не меняет. Меняет и ещё как.

[cat_mucius]

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

А клиентские сертификаты, к сожалению, особенно не в ходу, потому что управление ключами и защита их от утечек - дело геморройное.

[trueblacker.livejournal.com]

>о его пойнт, очевидно, в том, что настолько полагаться на HTTPS не стоит и пароль надо защитить дополнительно

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

>А клиентские сертификаты, к сожалению, особенно не в ходу, потому что управление ключами и защита их от утечек - дело геморройное

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

Гугл что-то в последнее время часто упоминает token-based аутентификацию. Авось что-нибудь сдвинется в этом направлении. Хотя, подозреваю, выльется в очередную профанацию.

[cat mucius (from livejournal.com)]

Хотя, подозреваю, выльется в очередную профанацию.
Ну почему же - я вот Вам сейчас отвечаю, используя именно её. :-)

Хотя у этого подхода свои проблемы: если Google может залогинить меня в LiveJournal, предоставив токен, значит, Google может залогиниться вместо меня в LiveJournal. :-) Пока мы исходим из предположения, что Гуглу это нафиг не надо, то это не беда. А вот если таким identity provider'от служит родное государство, службы которого таки да могут возжелать сунуть нос в чужую переписку, к примеру?

[huzhepidarasa.livejournal.com]

родное государство может всякими способами сунуть свой нос куда не надо, и не будучи identity provider'ом.

[cat_mucius]

Может, конечно - и я даже знаю, как. :-)

Но это дополнительная возможность, причём не требующая что-то подсовывать и перехватывать.

[trueblacker.livejournal.com]

что касается ссылки на ваш блог и тему про защиту пароля, то эта "проблематика" как раз отпадает при использовании clientAuth TLS уже потому, что никакого пароля просто не существует

[meshko.livejournal.com]

Чем защита клиентского сертификата принципиально легче защиты пароля?

[trueblacker.livejournal.com]

классическими преимуществами криптографии с открытым ключом по сравнению с использованием симметричных секретов

[trueblacker.livejournal.com]

хотя, возможно я неправильно понял ваше "легче". Поясните?

[meshko.livejournal.com]

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

[trueblacker.livejournal.com]

1. Вам не нужно хранить сертификаты пользователей, достаточно хранить сертификаты, их удостоверяющие (CA)
2. Никакого секрета, известного двум сторонам в криптографии с открытым ключом нет. Сертификат не является секретом и если злоумышленик его перехватит, это ему ничем не поможет.

Клиентский сертификат кардинально улучшает ситуацию по сравнению с паролем, однако требует, как было верно отмечено выше, "дополнительного геморроя" в управлении ключами.

[meshko.livejournal.com]

1) Вы не поняли, что я хочу сказать. Скажем так: я пользватель, а вы -- сервис с фотографиями. Я должен хранить его сертификат, который вы мне выдали. И вот как мне его хранить непонятно. И я не вижу принципиальной разницы что я буду хранить -- сертификат или пароль.

2) Конечно же клиентский сертификат является серкетом. Ну, вернее private key, который ему соотвествует. "Перехватить" его действительно нельзя, он никуде не ходит, сидит на месте. Но защитить его ничем не проще, чем пароль. Поэтому я не вижу в чем кардинальное улучшение ситуации.

[trueblacker.livejournal.com]

1. В таком случае, я вас снова не понял.
>я пользватель,
...
Я должен хранить его сертификат, который вы мне выдали

кого "его" ? Если вы пользователь, то, да, вам нужно "хранить" свой сертификат. Это проблема?

>И вот как мне его хранить непонятно

у каждого браузера свои способы. Их, вобщем, масса.

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

принципиальная разница как раз в этом "никуда не ходит" и заключается. В таких условиях обеспечить защиту секрета на порядок проще, ведь нет необходимости кому-либо его передавать. А пароль нужно постоянно пересылать снова и снова и гадать - не подсмотрит ли его кто-нибудь по дороге?

[meshko.livejournal.com]

1) Ну да, хранить проблема. И она не меняется от того, что я храню -- пароль или сертификат. В смысле так хранить, чтобы его было сложно уркасть.

2) Пароль тоже не нужно пересылать, можно делать challenge-response.

[trueblacker.livejournal.com]

1) От того, как вы называете хранимый секрет действительно ничего не меняется. А от того, нужно ли его знать кому-то ещё - меняется.

2) Challenge-response в случае пароля действительно избавляет от необходимости явно высылать пароль, однако подразумевает, что он уже заранее известен на сервере. Т.е. известен, потенциально, его админу и ещё куче народу.
Вы понимаете разницу между симметричным и асимметричным секретом?

[huzhepidarasa.livejournal.com]

А нагенерировать из воздуха кучу валидных пользовательских сертификатов админ не может, что ли?

[cat_mucius]

Если вы пользователь, то, да, вам нужно "хранить" свой сертификат. Это проблема?
Вообщем-то да, проблема.

1. Если хранить его програмно, то при наличии доступа к компьютеру его можно украсть. В виде пруфа позволю себе ещё одну ссылку на свой уютненький, если не возражаете.
2. Эта проблема решается криптоконтейнерами, из которых ключ нельзя извлечь. Таких в общем два: смарткарты и TPM. Но с ними свои траблы:
2.1 Смарткарты - это ридеры, драйвера, проблемы совместимости, короче, деньги и нервы.
2.2. TPM - штука хорошая, но с програмным обеспечением для него швах: я это дело активно копал, нахлебался. Вот разве что на Windows 8 возлагаю надежды, у них там virtual smartcards появились, использующие TPM.
3. Допустим, юзеру надо поменять станцию. Смарткарту перенести с компа на комп легко - но если ключ хранится програмно или в TPM, то это процедура.
4. Если мы используем сертификат не только для аутентификации, но и для шифрования (S/MIME, EFS, ...), то недостаточно запихать его в криптоконтейнер - нужно обязательно ещё и бэкап хранить. А то потеряется смарткарта - и аминь.
5. А если он ещё и expired - то это ещё геморрой.

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

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

[trueblacker.livejournal.com]

это все известные проблемы, однако они занимаются проблематикой, до которой обычная password-based аутентификация не доросла в принципе. У вас тут речь уже не о MIM, а о прямых атаках на рабочее место легального пользователя. Да, такие атаки тоже возможны, но:
1. password-based аутентификация не имеет тут никаких преимуществ и так же является уязвимой (и снова БОЛЕЕ уязвимой, чем аутентификация на основе асимметричной криптографии)
2. в PKI этими вопросами по крайней мере занимаются специально обученные люди и могут предложить варианты, из которых можно выбрать, балансируя между уровнем защищенности и сложность использования, тогда как у симметричной аутентификации выбор гораздо быстрее упирается в довольно низкий потолок защищенности, выше которого прыгнуть невозможно

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

[cat_mucius]

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

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

Разве что проблема privacy останется: утекшие сертификаты могут содержать юзерские мейлы, имена, другую инфу, да и вообще могут использоваться для сопоставления юзеров.

[meshko.livejournal.com]

Что я буду делать с сертификатом без private key? Для того, чтобы использовать сертификат для открытия соединения SSL нужен private key.

[cat_mucius]

Сорри, был невнимателен. Думал, Вы про сторону сервера спрашиваете.

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

Хранить его - есть несколько альтернатив, но они все со своими траблами.

[asox.livejournal.com]

Значит мне нужно хранить какой-то секрет как часть моей конфигурации. В этой ситуации клиентский сертификат особо ничем ситуацию не улучшает

Фокус в том, что перехват чаще всего происходить при передаче по внешним каналам данных - т.е. "хранить никуда не передавая" вообще говоря проще, нежели чем "обеспечить сохранность при передаче".

[cat_mucius]

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

Для хранения ключей на серверах есть девайсы под названием HSM - ещё один вариант криптоконтейнера. Правда, если сервер бежит на VM... :-)