The LUHN algo says that every other number should be doubled, starting with the ones in an even position based on the first number being in position 1.
123456
According to the LUHN algorithm in the above example the ones in bold would be doubled.
But the security essentials Luhn check uses mvexpand which count positions starting with 0 as the first number.
Which leads to that the variables cceand cco (even and odd I assume) ends up with the numbers switched, according to the SPL in the doc above.
Thank you @kennykentaur for sharing, unfortunately this search is not part of (this) security_content repo, and it is managed specifically by SSE. I will part the message along to that team :+1:
I re-used the SPL from https://docs.splunksecurityessentials.com/content-detail/detect_credit_card_numbers_using_luhn_algorithm/ and discovered a problem.
The LUHN algo says that every other number should be doubled, starting with the ones in an even position based on the first number being in position 1.
123456 According to the LUHN algorithm in the above example the ones in bold would be doubled.
But the security essentials Luhn check uses mvexpand which count positions starting with 0 as the first number. Which leads to that the variables
cce
andcco
(even and odd I assume) ends up with the numbers switched, according to the SPL in the doc above.