0

I am in the following setup: given department ids, employee ids and file ids I want to check whether employee xy of department AB is allowed to access file f.

E.g. department id = "012", employee id = "123" and file id "012"

Then the application of Luhn's algorithm to "012123012" or some variation of the algorithm should deny or grant access. I am faced by this problem because the man who set up the algorithm has left.

Is there any well-known application or variation of Luhn's algorithm to this kind of problem?

Richi W
  • 109
  • 2
  • I'm not entirely sure I understand the question, when you say a well-known application or variation of the algorithm, what do you mean? – DarkMantis Sep 30 '13 at 14:26
  • Luhn algorithm for access control? Very strange, do people do this? I can't see how this would work in real life. – makerofthings7 Sep 30 '13 at 14:50
  • @DarkMantis I mean: is there a widespread/text book application of Luhn's algorithm in the context of file security (granting/denying access to users). The original formulation will not work without modification. Maybe there is some extension of the (simple) idea of Luhn. – Richi W Sep 30 '13 at 15:05
  • @makerofthings7 I am a mathematician and not an IT security pro. I know that Luhn's algorithm is used for credit card number verification and I can imagine some minor extensions of it to verify whether a combination of employee id, dep id and probably some extra key is granted access to some file id. Maybe it is unusual but it came to somebody's mind. I would simply like to ask the members of this community whether "Luhn" + "access control" appears somewhere in the literature of in practice - thanks! – Richi W Sep 30 '13 at 15:11
  • @Richard Checksums guard against mistakes (e.g. mistype a digit). They're not a security feature. – CodesInChaos Oct 02 '13 at 09:22

1 Answers1

1

The Luhn algorithm is a very poor choice for this application. You are looking to apply an easily reversible algorithm for a security purpose.

The Luhn algorithm does one thing: check digits. The only purpose it should be applied to is for a small amount of input checking, specifically checking for typos such as missing digits or swapped digits. It also works for barcode validation, such as checking UPCs or Code 3 of 9s to ensure the barcode reader properly read all the stripes. But those are the limits of what it should be entrusted with.

For example, in your case I could iterate from "01212301-0" through "01212301-9" until one of them granted me access. I only have to try ten times at most. I can easily do this by hand. The Luhn algorithm can not protect your system.

For use in a security application, it would likely call for a scheme using a cryptographically secure hash, such as SHA-2. Of course, that kind of change entails a huge change to your system - a Luhn algorithm outputs a value from 0-9, whereas a cryptographic hash produces a digest of 40 hexadecimal digits. But all of that is probably not relevant, because you would be better off having a system designed to perform access control handling that responsibility. A system like Active Directory or LDAP is designed exactly to enable this kind of functionality in a secure fashion, and solves the insecurities of your home-grown solution.

John Deters
  • 33,650
  • 3
  • 57
  • 110
  • Thank you for your answer. Just because at the moment I first have to "hack" the existing solution (which was not documented well enough) - have you ever come across an application of Luhn to my problem? Do you know any references for this? Would you know any for a "hand-made" solution? Thanks! – Richi W Sep 30 '13 at 16:12
  • I've seen Luhn algorithms used as security mechanisms, although not as "access control". Some retailers have used a special code number to indicate the amount of a discount, and that code number is "protected" from change by a Luhn check digit. E.g. a hacker recently attacked Tesco's discount barcode to see if he could make unauthorized changes to it and increase his discount. He saw a 10% discount code was something like 44440105, then figured out that the 010 was the discount percent, and changed it to 44440758 and got a 75% discount. – John Deters Sep 30 '13 at 16:54
  • 1
    @Richard, to better answer your question, no, there is likely no published implementation because it wouldn't be a sound approach. My guess is that your predecessor checks the output of Luhn(dept, emp, fileID), and if it's zero, he grants access. You can see http://stackoverflow.com/questions/18625239/what-code-do-i-need-to-calculate-a-checksum-for-any-barcode-and-to-verify-valid/18725714#18725714 for a general purpose Luhn algorithm. – John Deters Oct 01 '13 at 23:10
  • thanks for your useful comment. A last question: have you ever seen somebody doing interference on the checksum algorithm? I mean: checking if it is Luhn or something like ISBN and inferring the multipliers and the divisor? – Richi W Oct 08 '13 at 08:35
  • 1
    @Richard, yes, in a limited way. Some attackers are very sophisticated, and have printed forged receipts with valid check digits. Evidence suggests that they simply tried known common formats (such as those above) until they found one that worked. I don't think they reverse engineered the weights. But trial and error also work-there are only 10 possible values for the check digit. It's not a security operation, it's a simple input validation mechanism designed to catch typos. – John Deters Oct 08 '13 at 19:26