Пара небольших мыслей о повышении usability и безопасности платёжных web-форм

    Периодически сталкиваясь с различными платёжными формами на сайтах, предназначенными для ввода карточных данных, я довольно часто недоумеваю, почему же у многих список с выбором даты окончания срока действия карты (Expiration Date) содержит мусор, а поле ввода секретного кода (CVV2/CVC2) не защищено. Безусловно, замеченные проблемы и проблемами-то считаться будут далеко не всеми, но всё же хотелось бы услышать мнение тех, кто считает, что это нормально.

    Проблема с списком выбора года завершения срока действия карты заключается в том, что довольно на многих сайтах данное поле содержит устаревшие значения: 2011, 2012 и теперь уже 2013 год. Очевидно, что платёж по просроченной карте всё равно не пройдёт, а вот вероятность ошибки пользователя при заполнении формы, пожалуй, это повышает, хотя, конечно, не пропорционально. Но смотрится это странно.

    Однако устаревшие значения года всё же встречаются реже, чем проблема с полем CVV2/CVC2.

    В подавляющем большинстве платёжных форм, которые встречались лично мне, данное поле является простым (text), а не защищённым (password). То есть не обеспечивается секретность на уровне скрытия на экране данных, вводимых с клавиатуры. Разумеется, многие банки сейчас уже вводят двухфакторную авторизацию через 3-D Secure, но ещё много где провести платёж можно просто по вводу всех данных без дополнительного подтверждения личности пользователя.

    Если первая проблема в общем-то не очень критична и обуславливается всего лишь отсутствием желания редактировать форму каждый год или реализовывать в ней дополнительные проверки текущей даты, то вот история с практически поголовным отсутствием защиты CVV2/CVC2 от простого подсматривания лично не до сих пор не очень ясна.

    Наверняка здесь присутствуют специалисты, в том числе принимавшие участие и в разработки интерфейсов платёжных web-форм. Интересно было бы узнать, насколько это считается проблемой в их среде и почему. Ведь должно же у этого быть какое-то рациональное объяснение.
    Поделиться публикацией
    Комментарии 15
      –1
      Удалено
        +3
        А что не так с CVV2/CVC2? Вас смущает то, что кто-то за вашей спиной что-то увидит? Он может этот код и на карточке посмотреть. А так в том же IE есть кнопочка предпросмотра, да и из web инспектора и из js значения этих полей достаются так же как и из текстовых… Сомнительная защита.
          –2
          Ну лично я свою карту для on-line платежей в принципе не ношу, просто вводя все данные по памяти, а смущает то, что можно подсмотреть из-за плеча.

          В конце концов, чем это хуже электронной почты или аккаунта на Хабрахабре? Там же звёздочками прикрывают и никто не считает, что это лишнее.
            –1
            Это общепринятая и по сути уже устаревшая практика… Потому и просят повторить пароль, ибо за звездочками вы могли ошибиться.
              0
              Нет особого смысла. Любая операция, которая не была проведена через 3D-secure (одноразовый код в SMS) или в офлайне с помощью пин-кода, оспаривается (если не ошибаюсь, у вас есть 30 дней).
            +1
            Про CVV выше написали.
            Разумеется, многие банки сейчас уже вводят двухфакторную авторизацию через 3-D Secure, но ещё много где провести платёж можно просто по вводу всех данных без дополнительного подтверждения личности пользователя.
            Вас это не должно беспокоить, т.к. если у банка-эмитента есть 3ds, а мерчант / процессинг его не использует, то такая операция легко оспаривается.

            Про год только одно предположение. Если не ошибаюсь, дата действия карты (как и имя держателя карты) на самом деле не проверяется.
            А здесь реализована простая защита «от дурака»: ввел прошедшую дату — запрос в визу/мастер не ушел.
              0
              Про дату действия совершенно точно, знаю, что она проверяется, возможно не всеми банками, но альфа и сбер — точно.
                0
                МПС (международные платежные системы) — это очень хм… сложная тусовка. Как с организационной, так и с технической стороны.
                Когда мы подключались к одному процессингу и разрабатывали фрод-мониторинг, то нам сказали, что на имя держателя карты (точно помню) и на дату выпуска карты (точно не помню) можно не обращать внимание. Т.е. сами МПСы эти данные не проверяют.
                А вот дальше процессинг, видимо, может накрутить дополнительные фичи (в т.ч. и проверка даты карты).
                  0
                  Имя держателя карты в России не проверяется, да. Но я не знаю ни одного банка, который авторизует платеж с левым сроком действия карты.
              +1
              А меня в платежных формах другое убивает — почти всегда требуется вводить номер карты сплошняком, без пробелов. Для меня полнейшая загадка — почему?

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

              Но нет, все тупо требуют ввода номера без пробелов — терпи юзер, тренируй внимание!
                0
                ну в тех платежных сервисах что использовал я, номер карточки автоматически разбивается пробелами. Не во всех, но частенько.
                  0
                  Иногда формы все же содержат раздельные поля для ввода частей номера, и тут тоже все бывает очень печально. Я, например, обычно не ввожу номер руками, а копирую его из хранителя паролей, и далеко не всегда вставка обрабатывается правильно. Часто заполняется только первое поле. Такая ерунда, например в форме у системы CyberPlat. Я им даже жаловался, но они посчитали, что это не их проблема.
                    0
                    А всего делов-то — оставить поле одно, но позволить вводить номер с пробелами. Для удобства можно всегда разбивать на части джаваскриптом, даже если вводится номер целиком — и просто, и наглядно, и совсем не затратно
                      0
                      А с одним полем случается еще напасть с ограничением длины. Это, впрочем, проблема не только платежных форм, встречается часто. Я имею ввиду случай, когда требуется ввести длинное число, например, номер счета, а поле ограничено по длине строго определенным количеством цифр, и при попытке ввода с пробелами номер не влезает.
                  0
                  cvv код не является паролем и по факту его может подсмотреть любой, кто имеет физический доступ к вашему монитору с расстояния пару метров(в т.ч и стырить карточку), а вероятность ошибиться в наборе cvv — уменьшает.
                  Вообще код этот код изначально задумывался как «закрытая часть ключа», мол номер карточки это общедоступная информация, а вот без cvv оплатить с неё чего либо невозможно, но частенько такая защита не прокатывает, потому и внедряют двухфакторную авторизацию.
                  А автору я советую завести виртуальный счёт или простую карточку только_для_оплаты_в_интернете, а с остальных карточек вообще заблокировать оплату в интернете. При необходимости — переводить необходимую сумму на эту карту, тогда хотя бы будешь знать какой суммой рискуешь.

                  Про года — быдлокодерам всегда было и будет проще поправить через N времени на свежую информацию чем написать небольшую функцию, которая считает текущий год + M от текущей даты на сервере(new Date не канает т.к зависит от времени пользователя, а она может быть любая) и отображает эти данные пользователям. В своей практике я встречал труЪ-кодеров которые сами писали считалку даты, иногда проскакивали такие лулзы как 30 февраля.

                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                  Самое читаемое