Под «там» я имел ввиду в самой странице (ну и как следствие в базе), просто изначально статья попала в обрезанном виде (не полностью), и мы строили предположение на что автор намекал
Я сообщал. «Благодарим за письмо. Мы обязательно передадим Ваши пожелания разработчикам.» Это не автоматический ответ. Апрель 2008-го. Никаких подвижек.
Мне кажется, что доверять таким образом одному сервису- нецелесообразно, по описанным в статье причинам. Проще настроить на каждом почтовом ящике, который необходимо мониторить, форвардинг писем на необходимый адрес. Таким образом, пароли от ящиков остаются известными только вам.
Интересно а как можно организовать сбор почты с других ящиков?
ТОЛЬКО зная пароль от них.
А что бы не перехватили пароль при настройке через WEB — пользуйтесь https
Вы плохо читали статью. Его вообще на клиента вытягивать не надо. А так он приходит на клиентскую машину для того, чтобы вместо него нарисовались звёздочки. Защита от дурака. Да ещё и просто http.
Да, я это понял :)
В интерфейсе он и так не показывается, вместо уже присланного пароля показываются звёздочки, с помощью параметра type=«password». Но в интерфейсе он таки не виден…
Если человек его вводил, то он должен его знать. Для напоминания есть сервисы «забытый пароль». Здесь же существует опасность, что пароль смогут узнать люди, которые его не вводили =)
Вы не правы
Допустим у меня есть ящик на яндексе и я собираю почту с ящика на mail.ru (а может и нескольких)
Злоумышленник проник в мой ящик яндекса и зайдя в настройки импорта получает совершенно свободно пароли от ВСЕХ моих mail ящиков.
Как должно быть: мой ящик на яндексе взломан, но пароли от импорта можно только сменить а не увидеть. Максимум что сможет сделать злоумышленник это попытаться подобрать пароль от этих ящиков (вдруг он совпадает с яндексом) или попробовать использовать функцию восстановления пароля на самом mail.ru, но это уже дополнительная проблема — ведь надо ответить на секретный вопрос и т.д.
Ну пароль и так можно в бинокль подсмотреть в момент ввода.
А натренированные люди наверно и просто подслушав шелест кнопок, уж проги то на это точно способны.
Ну а прочий TEMPEST и не такое позволяет :)
«Яндекс-Почта» SSL не любит. Во-первых, если не меняешь адрес руками на https://, вход идет по нешифрованному каналу. Во-вторых, вебовая почта по SSL глючит в «Сафари». В-третьих, нет шифрования для POP3, SMTP.
Особенно опасно пользоваться ящиками на яндексе всем у кого спутниковый интернет. Известные мне спутниковые провайдеры PlanetSky, SkyDSL и прочие вещают трафик который легко ловиться. Всем кому знаком термин «спутниковая рыбалка» прекрасно об этом знают.
Если вам зажать палец дверью или воспользоваться паяльником — то вы пароль скажете и так.
Конструктивно же — новый интерфейс (с которого вы тут просите переключиться), такой проблемы не имеет. Старым интерфейсом пользуется пренебрежимо малое количество пользователей.
Я не считаю это заметной и опасной уязвимостью (простите, но в большинстве случаев ваши пароли от POP3 и так ходят по интернету в открытом виде), но тем не менее в ближайшее время мы в старом интерфейсе эту недоработку устраним.
О полном переходе на https думаем — тут проблема не в том чтобы букву s добавить, а в том, чтобы более комплексно к проблемам безопасности пользователя на почте подойти и ради этого требуется заметное количество архитектурных изменений и доработок.
Спасибо.
Можно было бы страницу с настройками защить https. И это лазейка для злоумышленников, которые могут снифить трафик на «последней миле» (именно здесь самый высокий риск) или украсть пароль к мастер-ящику.
Ну и офтоп, старый интерфейс винрарный — самый экономичный по трафику и самый эргономичный. Кроме того, он гораздо реже глючит по сравнению с новым, сделанным чуть более чем полностью из AJAX
абсолютно согласен с вами.
2003 интерфейс наиболее удобный.
в службе поддержки мне сказали, что «В настоящее время поддержка классического интерфейса остановлена, т.к. выпущен новый и более современный интерфейс «Нео», созданный в том числе с учетом опыта разработки интерфейса «Классический» и пожеланий его пользователей.»
Мое пожелание закопать интерфейс «Нео» и добавить gzip сжатие классическому интерфейсу.
И вообще верните ссылку на Яндекс.Ленту ко мне в почту. «Подписки» никуда не годятся!
У Я.Ленты была оригинальная эргономика — минимум ширины терялся на навигацию, очень удобно для работы (и развлечения) с сплошным потоком — читаешь скроллирушь подряд, а иконки-идентификаторы слева переключали контекст, используя только периферическое зрение.
Т.е. параллельно, для редко используемых фидов, или каналов, где шло много мусора (нужно просматривать только заголовки) я использовал гуглридер, а для удовольствия — Я.Ленту.
Подписки же выглядят ухудшенной копией гуглридера, и я попробовал вербализировать, почему они мне не нравятся: верстка ленты — свободный текст, не зарытый в отдельные блоки, с большим пространством, на котором отдыхает глаз (эргономике это не вредит, ибо по вертикали скроллировать можно быстро и удобно), а в Подписках — очень плотно расставленные блоки, ощущение тесноты, надо вчитываться (плюс еще разбирать что и от кого).
Ну, и чтобы два раза не вставать — просьба. Я понимаю, что Ленту заморозили, такие дела. Но меня ужасно напрягло, что после обьявленной заморозки, умирающую Ленту обвесили жуткими ссылками на ярушку, аки заброшенный сайт, превращаемый врагами рода человеческого (сеошниками), в линк-ферму.
Я взываю к вашей совести, пожалуйста, верните Ленту к прошлому состоянию, или (понимаю, что тяжело), сделайте ссылки отключаемыми специальной настройкой.
Я ответил на него. Мне нравится лента абсолютно полностью в том виде, в каком она была. Со ссылкой из почты и количеством сообщений в том числе.
Подписки абсолютно не предоставляют того функционала, который предоставляла Лента, а именно возможность без напряга просматривать в виде кратких анонсов новостные ленты по RSS.
Чем Подписки отличаются от Ленты, что вам кажется, что они не предоставляют возможность без напряга просматривать в виде кратких анонсов новостные ленты по RSS?
Тем, что вы оформили Подписки аля интерфейс Почты.
Все новые письма выделяются жирным. Это приемлемо когда у меня 5-10 новых писем за раз. Но совершенно не годится для сотен сообщений в день, собраных по RSS. Все заголовки набраны мелким жирным шрифтом, и ведь по ним еще нужно кликать, чтобы получить подробности!
Скажем иначе
Отечественные компании типа mail.ru и yandex не имеют права делать https, так как товарищ майор не получит доступа — СОРМ пока SSl не умеет
зачем сорму встраиваться посреди между пользователем и почтой и расшифровывать почтовый трафик если тот же яндекс и так им все выдаст по первому требованию в лучшем виде?
Логика сотрудников Яндекса всегда меня удивляла, а точнее её отсутствие. Откройте новый сервис parolchik.yandex.ru (навеяно словом fotki) и выкладывайте там логины/пароли всех пользователей, а в анонсе напишете:«Теперь вам нечего бояться, вас никто не будет пытать паяльником или прищемлять пальцы дверью, чтобы узнать пароль, потому что он опубликован на нашем новом сервисе»
Извините, конечно, но лично мне это напомнило недавнюю историю в духе МС:
«Да, проблема есть, да, ею можно воспользоваться, но выпускать критичное обновление мы не будем, т.к. это нарушает наш цикл выпуска обновлений».
Думаю, все помнят, что это вызвало и чем это закончилось. Так же можно вспомнить, что другой поставищик e-mail сервиса после случившегося тут же включил шифрование всего трафика для всех пользователей (при этом, шифрование странички аутентификации у них было включено и до этого инцидента.
о нет, не передергивайте, пожалуйста.
Мы готовим обновление (срочное) обозначенной проблемы и, как я написал выше, https — на подходе, но там все несколько серьезнее, чем просто букву s внедрить. Это вопрос недель, к сожалению.
Боюсь, это сложно объяснить человеку «вне контекста» архитектуры сервиса.
Да, нужно несколько недель и достаточно заметные переделки — понять это, не понимая, как и что тут устроено — почти нереально. Простите.
Если кратко, то сам по себе https добавляет мало безопасности, если процесс логина происходит по https (а у нас именно так). Но, переработав некоторые элементы портальной авторизации и некоторые подходы к хранению и передаче данных, можно получить от внедрения https действительно большой профит.
Вот нам и хочется сделать не быструю отмазку, а реальную пользу.
Хочу защитить саппорт Яндекса. Они ответ на любое письмо об ошибке отвечают через несколько часов, если это небольшая проблема.
А месяц назад со мной произошел случай — в Гуглохроме ни с того ни с сего начала разваливаться верстка ЯндексоПочты (с разных компьютеров), о чем я и написал в саппорт. Через несколько дней пришел ответ — «Ваша проблема устранена?» с кодом ошибки. И проблемы больше не было.
надоели уже эти посты с припиской «у имярек нет кармы».
Нету — значит не заработал. Кончилась — сам виноват!
Пусть постит в персональный блог, или постите в профильный, но без перевода стрелок — подписались постить за другого, так и отгребайте (и плюсы, и минусы) за него.
Кстати, наконец-то понял людей, которые видят преимущество в минусовой карме. Можно не задумываться особо о словам, принцип «кнута и пряника» в виде кармы уже почти не работает.
Единственное неудобство — что каментить можно, только раз в 5 минут, но и тут можно найти преимущства — можно писать более основательные каменты, или же что более полезно, больше времени обратить на работу. :)
Вот я и не пользуюсь нашими сервисами, потому что их представители вместо того, чтобы признать проблему и оперативно ее исправить, начинают размышлять о паяльниках.
Каким образом? Интерфейсом classic пользуется меньше процента пользователей Яндекс.Почты. Для эксплуатации уязвимости нужно одновременно:
* чтобы пользователь пользовался classic-ом
* чтобы у него были настроены сброщики
* чтобы у злоумышленника был доступ к сниффингу траффика пользователя
* чтобы пользователь попал на страницу с CSRF, сконструированную злоумышленником
Мне кажется, это весьма редкое сочетание условий. Тем не менее, проблему мы исправили.
Первый пункт отменяет, но сборщики действительно должны быть.
Я не взломщик, а разработчик, не занимался целенаправленно поиском XSS.
Вот тут, например, почти каждое приложение содержит в себе XSS. Еще ошибки находил на buki.yandex.ru и других местах, их легче использовать, они с GET запросами, но я не сохранил их адресов.
Да, на всех клиентских протоколах поддерживается TLS-авторизация, а пользоваться ей или нет — решает сам клиент, мы тут, к сожалению, за пользователя решить не можем.
Вынужден признать нашу ошибку — в help-е на скриншотах мы не отчекали галочки про то, что по-умолчанию людям рекомендуется ставить опцию «безопасная авторизация» — я уже попросил это поправить, в ближайшее время поменяем, спасибо, что обратили на это внимание.
Ограбление по-дилетантски или о том, как Яндекс хранит пароли