I have seen banks using grid card authentication after primary password based login. However, I am unable to find sufficient detail as to how it is being used. Is the challenge truly random or pseudo random or is it deterministic? Other implementation details also seem to be blurry.

Any clarity would be appreciated

Ref: ICICI grid authentication (http://ishanbhalla.com/good-design-axis-bank-debit-card-based-authentication/)

LastPass Grid Authentication vs Google Authenticator which one is more secure?

  • Are you asking about how the numbers are a) generated and assigned / b) stored in the bank's database / c) the order in which the bank asks for them? – Jedi Apr 7 '17 at 19:37
  • I'm curious as to how the number's ie the grid coordinate are generated by the algorithm as a challenge. – duckvader Apr 8 '17 at 20:36
  • From the pictures, this looks like Entrust IdentityGuard. Since I work at Entrust and have worked on this product, I will refrain from giving an answer out of conflict of interest. – Mike Ounsworth Aug 16 '17 at 12:09

Grid authentication isn't standardised in the same way that TOTP/HOTP is: you can find grids which contain anything from 9 spaces ("keypad" style) to 260+ spaces (Lastpass style), and which require anything from a single character to a whole string formed from some kind of pattern. As a result, it's impossible to give a general answer to the question.

However, the security of these systems doesn't come from the specific position of requested characters, but from the fact that the requested characters should be known only to the grid holder. From an attacker point of view, there is no difference between a system which asks for characters found in spaces A1, B1 and C1 and one which randomly selects from the whole grid, unless they only have part of the grid, or some way of verifying specific characters (whether individually, or as a set).

In all following, the attacker is assumed to know the account details other than the grid contents - remember that grids are usually a second factor, so the attacker first needs to get the password

To give an example, if you have a 5x5 grid containing 25 digits, which were generated randomly and independently (e.g. the presence of a specific digit in one space doesn't have any impact on the contents of other spaces), the chances of guessing the value of any single space is 1 in 10. If you prompt for a single value, request the same value if it's incorrect, and allow 10 guesses before locking an account out, an attacker will always be able to get into the system, unless they're daft enough to try the same digit multiple times. If you prompt for 2 values (again, asking for the same pair if either or both is incorrect, and giving no indication of which is incorrect), the attacker has a 1 in 100 chance of getting the right pair. They might get in given 10 attempts, and have a pretty good chance of getting in given 50 attempts (50%, clearly!).

This is the same no matter how you select the values to ask for, as long as you always pick distinct values - if you use a method where you can ask for "A1" and "A1", the security drops to whatever the security of asking for a single value is in those cases.

If the grid isn't random, though, you can end up with problems. For example, if you generated it by permuting the digits 0-9 into columns labelled A-J and then provide 5 rows, labelled 1-5, you'll have 50 values. If you ask for A1 and B2, you've got a 1 in 100 chance of getting them both right. If you ask for A1 and J1, though, you've reduced the search space. If A1 is 0, J1 isn't - there are only 9 possibilities. The attacker has a 1 in 90 chance of getting the right pair in this configuration. In this case, you'd actually be slightly better off with a less random selection for the requested grid positions...

If an attacker has partial knowledge, however, you clearly want to make it difficult for them to use that knowledge. A system which always requests A1 and B2 doesn't help an attacker with no knowledge much, but falls to an attacker who knows only the contents of A1 and B2, even if the grid is perfectly generated. Therefore, you ideally want to make the values requested for distinct login attempts different (e.g. when someone logs in successfully, the next login attempt should ask for different values). It doesn't matter much how they are different, if the grid is truly random: moving from A1, B2 to A2, B3 would stop an attacker who only knows A1 and B2, after all. However, you then need to think about whether you are providing information which might allow them to log in at some point in the future. For a 5x5 grid, the incremental approach, wrapping at line ends, will mean that the 1st and 26th logins will require the same values to be provided. If you just put all the possible grid positions in an array and randomly shuffled them, you've not got that problem, and you've avoided the same grid position coming up twice.

It would be preferable for any given combination of values to never be requested again. However, this puts an upper bound on the life of the grid - you can only have as many requests as there are combinations of grid coordinates. For one value, that's the number of values in the grid. For 2 values, that's the square of the number of values in the grid. For n values, it's (number of values in grid)^n. You can increase this even more if you care about order, as well as specific values. In order to prevent repetition, you'll need to monitor which combinations have been used already, in some way, and, ideally, avoid any link between requested combinations. If you want to protect against an attacker who has been monitoring data, it's bad if they can intercept A1,B2 and C1,D2, then they get B1,C1 as the next request, predictably. That combination might come up naturally (that's random for you), but that's always a potential flaw here - in theory, you could get two TOTP values in a row which are the same, but it's unlikely. Specific grid authentication methods take steps to avoid repetitions, but again, it's not a single method - it depends on the other properties of the grid system being used.

TLDR: there isn't a single method, but it doesn't really matter, since the selection process for the position shouldn't make as much difference to the security as the contents of the grid itself.

  • 1
    Since I work on this product, I will refrain from giving my own answer, but one thing I think you overlooked is replay attacks; that's the value of never repeating a challenge (cells requested and the order in which they're requested). – Mike Ounsworth Aug 16 '17 at 12:11
  • 2
    I'd say that was a specific case of partial knowledge - sooner or later, you will get repetition, given enough requests (although that could be 1000s of requests or more), unless you retire any grid which has been used a certain amount. I've also seen some grid systems where order does matter, and others where the request is normalised to go left-to-right, so I've avoided that as a criteria in the general sense. I'll add a note about attempting to avoid repetition though. – Matthew Aug 16 '17 at 12:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.