-1

Sorry, might be a stupid question: But is there any hash function, which use the biometric fingerprint as salt?

First, the User enters his plaintext password, second he use his fingerprint - some constant biometric characteristics (loops, islands, gaps between papillary strips and so on, so you can be sure IT IS constant) - as salt and all this gets into a hash function. Some kind of double authentication, but with the biometric fingerprint.

idontknowwhoiamgodhelpme
  • 131
  • 3

3 Answers3

4

I'm not sure you'd need a special hash function for this. You'd just use the output of the biometric as the salt.

The bigger problem is how you would normalize the biometric for use in such a strict way. Normally, biometric analysis allows for some small variation. If you just pumped the biometric output directly to salt, then the user would have to get the fingerprint "just right" every time.

schroeder
  • 123,438
  • 55
  • 284
  • 319
  • I also thought about this problem, that the user has to get his finger everytime in the exact right position. – idontknowwhoiamgodhelpme Feb 09 '17 at 07:39
  • Maybe, the person has to 'roll' his thumb over a panel. From left to right, right to left,(maybe also up to down, down to up and so on). So, what we get is not the typical egg-shaped form from a fingerprint, instead we get a more rectangular form of the fingerprint with more areas and even more characteristics. At this point, i could always check for a specific characteristic. For example an island, which is more placed in the middle(my constant),as any other characteristics. From this point, i check a specific, defined area, starting at a specific pixel from the island (i.e. upperleft corner) – idontknowwhoiamgodhelpme Feb 09 '17 at 07:50
  • Nope. You're assuming that the user will always place a finger in the exact same orientation and place on the pad, even to roll it. Use biometrics as a 'gate' with a binary outcome (success/fail) and use the username as a salt. Salts don't have to be secret. – schroeder Feb 09 '17 at 07:59
  • 1
    Also, if a standard mechanism existed that created a salt from a biometric input, it's likely that this would yield the same salt for a given input across multiple implementations, making it less secure as the same salt could be used in multiple places. Also salts should not be persistent, when a user changes a password, the salt should change. – iainpb Feb 09 '17 at 08:56
-1

It exists and has many benefits in term of privacy, diversification and repudiation of fingerprints. look at ISO/IEC 24745 standard and its implementation by GenKey BioHASH

Mike
  • 1
  • 1
-2

It does make sense to combine biometrics and passwords. However, the term "salt" does not apply to this, and using biometrics and passwords together does not make a salt unnecessary.

A salt is a random string that makes the hash function different for each password. It is stored on the server besides the hash, something you would not want for your biometric information. A salt is not particularly secret. In fact, if it were to be exposed it does not reduce the security of the system. The goal is to make the attacker do work on each hash seperately, instead of cracking all hashes as a whole.

To implement your system, you could concatenate the password and the biometric information and hash that. You would still profit from a salt, because this prevents the attacker from precomputing hashes or cracking all hashes simultaneously.

Sjoerd
  • 28,707
  • 12
  • 74
  • 102
  • Assuming the biometric info is consistent with every reading ... – schroeder Feb 09 '17 at 08:24
  • 1
    Sjoerd - this is the big problem with biometrics: they are terrible for use as an authenticator as the output is different every time, or has to be generalised in such a way that attack is relatively straightforward. Use it as a 2nd factor, but never as input to a 1st factor. – Rory Alsop Feb 09 '17 at 08:28
  • My point was that using something else *as a salt* makes no sense. – Sjoerd Feb 09 '17 at 20:16