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

[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

[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]

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

[trueblacker.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]

password-based аутентификация не имеет тут никаких преимуществ и так же является уязвимой
Ну вот разве что сбросить пароль можно быстрее, чем отозвать сертификат - апдейт и распространение CRL берёт время.

О новых технологиях: есть infocards - это такой любопытный гибрид между PKI и claim-based authentication. Все их аспекты я пока не понимаю, но там есть моменты, которые удачно облегчают жизнь по сравнению с традиционным PKI. Микрософт их имплементировала под названием Windows CardSpace, а потом почему-то списала в утиль и дальше поддерживать не будет. Мне жаль, что распространения infocards не получили - идея-то хорошая.

Ещё есть такая новая штука, как U-Prove - Микрософт на неё собирается заменять CardSpace. Там много интересного, разбираюсь потихоньку.

[trueblacker.livejournal.com]

>Ну вот разве что сбросить пароль можно быстрее, чем отозвать сертификат - апдейт и распространение CRL берёт время.

OCSP.

Про новые технологии спасибо за наводку, ознакомлюсь

[cat_mucius]

А знаете, как работает микрософтовский OСSP Responder? Будете смеяться - он читает CRL. :-)

Но в принципе OСSP это решение, конечно. Но оно убивает то преимущество сертификатов, что сторона удостоверителя не должна быть доступна в сети постоянно. Плюс там ещё всякие соображения от privacy.

[trueblacker.livejournal.com]

>А знаете, как работает микрософтовский OСSP Responder? Будете смеяться - он читает CRL. :-)

недостатки реализации не являются недостатками технологии :-)
Впрочем, доступность актуального CRL для OCSP Responder - вполне выполнимое, кмк, требование

[cat_mucius]

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

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

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

[meshko.livejournal.com]

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

[cat_mucius]

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

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

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

[huzhepidarasa.livejournal.com]

Кто разрешает заливать свой сертификат? Его же хранить надо. Если сервис, наоборот, выдает клиентам сертификаты, он их может не хранить, а хранить только CA.

[cat_mucius]

На практике я такого не видел, признаю. Впрочем, я и публичных сервисов, позволяющих аутентификацию по сертификатам видел всего два: Verisign PIP и сайт StarSSL.

А если говорить теоретически, то:
1. Сертификат на каждый сервис - проблема scalability.
2. Чем длиннее цепочка верификации - тем больше возможностей для атаки. Если мы полагаемся на подпись CA - значит, подделка этой подписи разом побивает всю схему - и это не что-то заведомо нереальное.
3. Если CA посторонний - то тот, кто контролирует его, автоматом может имперсонировать юзера.
4. Чисто технически - разве сложно в датабазе к записи юзера добавить блоб в несколько килобайт?

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

[meshko.livejournal.com]

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


Это, кажется, звучит разумно.

[huzhepidarasa.livejournal.com]

CA свой, конечно, не посторонний. Корпоративные сервисы так устроены сплошь и рядом.

[trueblacker.livejournal.com]

а как защитить пользователя от заливки хакером нужного ему (хакеру) сертификата? Не паролем же?

[cat_mucius]

В смысле? Если у сайта есть програмная дырка, которая позволяет подменить в юзерском record-е в базе данных один сертификат другим - то это таки плохо. Что тут можно предложить, кроме как залатать дырку?

И что в этом смысле меняется от того, что сертификат самоподписанный? Если в базе будет лежать не сам сертификат, а его серийник, присвоенный местным CA, а хакер его подменит - что изменится?

Или Вы имеете в виду сценарий, когда хакер подменяет сертификат на стадии регистрации нового юзера? Ну, SSL. :-)

[trueblacker.livejournal.com]

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

[cat_mucius]

Ну как что. Аутентификация и шифрование. :-)

Сценарий раз: регистрируется новый юзер. Вместо поля "введите пароль" сайт предоставляет поле "залейте сертификат". Эта сессия защищена обычным SSL по серверному сертификату. Последующие сессии после регистрации требуют аутентификации по клиентскому.

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

На каком этапе дырка?

[trueblacker.livejournal.com]

на этапе первоначальной заливки сертификата и замены сертификата в случае утери личного ключа. Как сервер определяет, валидный ли пользователь залил сертификат?