Online PIN

[TSprinter]

Товарищи подскажите насчет валидации пина на хосте эмитента.
Вот бывший сотрудник OpenWay утверждает что валидацию PVV можно отключить. Это как так?
Я всегда считал что PVV это единственный вариант проверки пина на хосте назависимо от вида карты (чип не чип). Никто же не хранит пин да и не входит он в авторизационный запрос... Наверное. :-)

Вот что нашел по документации МС (CIS):
DE 52 (Personal ID Number [PIN] Data) contains a number assigned to a
cardholder intended to uniquely identify that cardholder at the point of
interaction. The use of the PIN is subject to bilateral agreement. The data
element may contain the PIN itself or a derivative. This data element transmits
PIN information from acquirers to issuers (or to the network) for PIN verification
or validation.

Т.е. в 0100 сообщении приходит все таки шифрованый пин??? и эмитент сам формирует PVV для проверки (если хранится только PVV)
Всегда считал что только PVV приходит на хост. Или напутал что то?

[nick_st]

TSprinter,
В запросе идет зашифрованный ПИН-блок... PVV берется либо с дорожки из запроса, либо из БД эмитента...

[TSprinter]

PVV берется либо с дорожки из запроса, либо из БД эмитента...

Это понятно.
Ну так валидируется же PVV? PVV хранится в БД при смене пина...
Хранить и валидировать пин вместо PVV особого смысла нет... (т.е. отключить проверку PVV как пишет человек)
Или я что упускаю?

[nick_st]

TSprinter
В некоторых хостах хранился зашифрованный на LMK ПИН-блок, а не PVV. Соответственно можно было проверять по нему.
Часто это использовали для перевыпуска карты с тем же ПИНом.

В связи с требованиями PCI DSS (PA DSS) от этого ушли... но старые версии могут так работать... также обычно правила PCI DSS распространяют на
чужие карты, а для своих на хранение этих данных часто закрывают глаза...

[TSprinter]

Вобщем я понял пин блок и PVV это разные вещи но и там и там это шифрование пина + номер карты.

Вот цитата CIS насчет пин блока:

The acquirer receives the encrypted PIN, which the acquirer then decrypts
using the terminal PEK stored in a TRSM. The acquirer then creates the
ANSI PIN block and encrypts it using the DES algorithm as follows:
First Block—PIN Data: The first digit of this block contains the control
character 0, followed by a number representing the PIN length (maximum
12), and then the PIN itself. The acquirer then fills the remaining digits
of the block on the right with hexadecimal F’s to complete the 16-digit
account number.
Second Block—PAN Data: The first four digits of the second block contain
0000, followed by the 12 right-most digits of the PAN, excluding the check
digit. The acquirer then pads zeros to the left to complete the 16-digit
data element.
In formatting an ANSI block, the acquirer performs an XOR function on the
two 16-digit blocks.
After creating the PIN block, the acquirer sends it through the DES algorithm
along with the 16-digit PEK that the acquirer and the Authorization Platform
share, producing the translated PIN block as follows. The acquirer may
encrypt the PIN

А вот из HSM RG7000 Programmers Manual issue 3

9.6 Generate a Visa PIN Verification Value
Message Header
Command Code = DG
PVK Pair
PIN under LMK
12 Digit account/card number (last difits excluding check digit)
PVKI
...

Т.е. для формирования PVV на HSM нужно подать часть номера карты и шифрованый пин...

А вот список методов проверки пина которые поддерживает HSM

10 PIN Verification
HSM supports 4 methods of PIN verification:
1) IBM 3624
2) Diebold Proprietary Algorithm
3) Visa PVV
4) PIN comparision

Я почему то всегда думал что экваер посылает треки (или аналоги для чипа) и PVV. Т.е. похожий алгоритм (номер карты + пин)...

Вобщем спасибо. Вроде разобрался...

В некоторых хостах хранился зашифрованный на LMK ПИН-блок

Не в хостах а в бэке :-) который печатает пины.
Я видел такой вариант недавно но там и PVV так же хранился до кучи. И проверялся именно он...
Да и хранился там не пин блок а пин под LMK - смысла хранить пин блок для перепечати пина нет как я понимаю.