Клиентоориентированный подход: версия Яндекса

    Приключилось всё это с коллегой.

    Жил поживал на Яндексе аккаунт с паролем длинной 23 символа. Жил давно и посещался довольно редко. Сегодня понадобилось в него попасть, а не тут то было. Не долго думая делается попытка зарегистрировать другой аккаунт с таким же паролем, однако — «Длинна пароля не может превышать 20-ти символов».

    Секундное раздумие и делается попытка войти на старый аккаунт с паролем минус последних 3 символа. It works!

    P.S. Теперь мне как минимум известно что Яндекс хранит пароли в открытом виде.
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 15

      –1
      Ну зачем гнать на яндекс? Вполне вероятно что раньше он просто отрезал первые 20 символов от пароля и от них брал хеш — Вам все равно без разницы :)
        +8
        Как без разницы, если у меня фактически изменился пароль. Без предупреждения.
          0
          Вы не разобрались. Хеш от x и от x[:20] не могут совпасть для х.length > 20
            0
            это я к тому, что по вашей версии сейчас они перестали обрезать пароли перед хешированием, но предупредили об этом сообщением. есть логика?
              0
              я о том, что они и раньше резали пароль до 20 символов, но только сейчас стали об этом предупреждать
                +1
                В таком случае проблем с доступом к аккаунту не возникло бы…
          –2
          Теперь мне как минимум известно что Яндекс хранит пароли в открытом виде.
          вывод неверный. В первом комменте вам уже рассказали, какой вывод — верный.
            +5
            Ну я бы к примеру не додумался бы до такого ибо смысла ноль. С чего вы решили что разработчики Яндекса сделали именно так?
              +4
              вообще обе версии странны…
              1) хранят хеш и обрезали при предыдущем входе — тогда какого фига, не сказать об этом пользователю, пара строк в код…
              2) хранят пароль и обрезали в базе — тогда какого фига, неужели нельзя было об этом заранее пользователям сказать (тем у кого больше 20 символов пароль)?

              причем, как бы обидно не было, вторая версия выглядит правдоподобнее…
            –1

              +1
              Чума. Ради чего, спрашивается, трогать ранее заданную аутентификационную информацию?
                +1
                [irony] место в базе экономят, поэтому alter table users modify password char(20) [/irony]

                знали бы вы сколько я радости испытал, когда узнал что mount.cifs интерактивно принимает и отдает серверу до 64символов, а неинтерактивно (опцией или cred-файлом) обрезает до 16 символов.
                  0
                  Не ожидал от Яндекса такой неразумной политики безопасности. Или они решили сэкономить на спичках или открытые пароли нужны им для каких-то неэтичных планов.
                    +2
                    Ещё возможен такой вариант. Изначально считался хеш солёного пароля, как полагается. Когда решили перейти на новую систему хранения (например, с более длинной солью, но почему-то с этим ограничением на 20 символов), старая система оставалась работать. Что происходит при логине? Сначала смотрят в базу новой системы, есть ли там хеш пароля или там стоит флажок, что новый хеш ещё неизвестен. Если в новой базе хеш есть, то по ней и происходит проверка. Если там нет хеша, то происходит обращение к старой базе, происходит проверка пароля по ней. Если пароль верный, то от него считается хеш для новой системы и заносится в новую базу.
                      0
                      Когда-то давно тоже самое было с паролями для аськи. У меня был длинный пароль, который однажды не подошёл. Оказалось, что в старую форму для пароля влезало только 8 символов, остальные кнопки нажимались, но не печатались. А новая форма принимала большее количество символов.

                      Only users with full accounts can post comments. Log in, please.