How is fingerprint data stored

[Steve-vfp9user]

Hi
There are a few threads on this forum relating to fingerprint recognition however my question is how is that data stored?
For example, when you scan a barcode you store a series of numbers.
Is a fingerprint the same or an image or something else?

Thank you

Steve

 

[Olaf Doschke]

Not at all in VFP databases. Hoiw should we know. It's a thing/problem of those devices, not of VFP.

http://www.explainthatstuff.com/fingerprintscanners.html

Bye, Olaf.

 

[Steve-vfp9user]

Well it was a valid question Olaf and as a user of VFP9 I am hoping to develop an app with FP recognition. If you can't store data in tables as you would a barcode etc then so be it. Appreciate your negative post.

Thank you

Steve

 

[JRB-Bldr]

Olaf's post wasn't a "negative" post.
He was merely stating that VFP (like Most Databases) do not store Fingerprints (as such) unless you wanted to store the image itself.
And that would best be stored as an image file outside of the data table - storing the image file location reference in the VFP data table.

From the link that Olaf referenced:

So how can a computer compare prints? During enrollment or verification, each print is analyzed for very specific features called minutiae, where the lines in your fingerprint terminate or split in two. The computer measures the distances and angles between these features—a bit like drawing lines between them—and then uses an algorithm (mathematical process) to turn this information into a unique numeric code.​

So if you can get your VFP application to make those measurements and other calculations, or utilize an API/OCX to do it for you, then you too could store that "numeric code" representing the unique Fingerprint in your VFP data table.

Side Note re:

when you scan a barcode you store a series of numbers

A Barcode is merely a graphic representation of Numbers/Letters/etc.
So when a Barcode reader/Scanner 'reads' a barcode, it automatically decodes the barcode 'value' and sends it to the recipient (usually an application) which can then be readily stored.
You cannot readily compare Barcode reader/Scanner data storage to Fingerprint data storage unless you have a Fingerprint 'reader' which can make the aforementioned measurements and calculations itself and then send the resultant "numeric code" to the recipient application for storage.​

Good Luck,
JRB-Bldr

 

[Olaf Doschke]

It's data of the device, you don't store anything in your data. Those devices are handling the Windows Login/Authentication as alternative to Password or PIN. It's not your business to care about how that's done. That's all there is to it.
To know who's logged in Windows call ID(), that's resulting in Domain # Username, or use GETENV("USERNAME") and if you need the domain GETENV("USERDOMAIN") to get these infos separately.

An own login can be useful on devices running on a general account for all users or if users don't use the Windows sessions and login/logout on the OS level. We implemented an own user database at times of NT, when there was no multiple user sessions in Windows.

Other cases for an own login are a web application, where user authentication from home networks or multiple domains don't cross over to your webserver.

If you really want to use fingerprint or smart card readers or any such devices for your own application only, not on the OS level, I bet you can also do that, but the communication to the device and its answes will not be as protected as the Windows login screen. Remember or notice for the first time: Windows Login screen is a protected mode of windows in Session 0 without any normal process getting at eg keyboard buffer during the password entry. Only hardware keyloggers can intercept user input there. But when a Windows user session already runs such devices are not more secure, as all only depends on the device telling you the user it detects and when that communication can be rerouted and intercepted and changed, if the user identification can simply be overridden, the device will give you no better security. To be more concrete: It's no problem to create a DLL with similar name as the devices own driver DLL (for example) and offer the same interface (same methods), but instead of addressing the device simply answer function calls with the desired answers (yes, authentication succeeds).

Bye, Olaf.

 

[Mike Lewis]

I've no experience of this myself, but I would think that most off-the-shelf fingerprint scanners come with their own software to handle the enrollment and verification processes. It would be the responsibility of that software to store the scanned print, either in its own storage or in that of the computer to which it is attached.

Perhaps rather than asking how the image is stored, we should be asking which devices have an API that can be easily accessed from VFP.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

>we should be asking which devices have an API that can be easily accessed from VFP
You indirectyl address something I would also think: The APIs will differ, what devices store where and how they integrate. The concept will be similar, as the explainthatstuff srticle outlines, but the implementations will not adhere to any industry standard. If there would be a simple value to store, comparable to a hash in password login, that's quite OK, but once you have the responsibiliy to store such data as secret, DBFs and VP is a weak client side partner for this, and if the devices manage the fingerprint data needed to identify the user in their own data storage syst4em or binary files and only return the identified username, for example, the driver interface becomes the weak point.

About any alarm system or hardware resulting in a success signal or information will be manipulated at that level, if you wanmt to circumvent it. I would only really trust a system hooking in as alternative Windows authentication and then your own application can rely on what the system reports as logged in user.

Bye, Olaf.

 

[atlopes]

From 7 onward, Windows has a framework to access biometric devices and functions:

https://msdn.microsoft.com/en-us/library/dd401509(VS.85).aspx.

The devices that it controls must adhere to the Windows Biometric Driver Interface specification (if I understood the documentation right, a kind of TWAIN for biometric devices).

There is a client application API that is provided as a .lib, so I assume that a FLL layer will be needed to use it.

 

[Steve-vfp9user]

Apologies for the late reply. I have looked at the posts and taken them in accordingly.

I understand that VFP wouldn't store the data and that it is the job of the scanner and other third party software to do that. I suppose my next question would have to be, "Has anyone developed a VFP9 (or other version) app that uses fingerprint recognition?"

Thank you

Steve

 

[Mike Lewis]

Or, maybe the next question should be, "Does anyone know of any ready-made fingerprint recognition software that I can call from my VFP app?"

I have no experience in this area, but a quick Google search throws up a few possibilities. A couple of examples:

http://www.neurotechnology.com/free-fingerprint-verification-sdk.html

http://www.griaulebiometrics.com/en-us/fingerprint_sdk/features

I don't know anything about either of the above. I just offer them as examples of what might be available.

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Steve-vfp9user]

Thank you for the links Mike. A useful start for my research.

Thank you

Steve

 

[dbMark]

Just saying... every new method for identification or validation can have a weakness so we ought to ponder what a weakness might be. In the case of fingerprints, yes they're more or less unique to the person but... if the system is someday hacked and the FP data compromised or stolen then it's no longer unique - on any system going forward I would surmise. However and wherever the data is stored I'd think it would be best practices to store it encrypted as well just as you would a SSN or other sensitive personally identifiable information.

 

[Olaf Doschke]

I agree with dbMark. Simply compare the riscs of revealing a password and needing to replace it with the fingerprint data in whatever form: If a password is cracked, you can change it in the end. If fingerprint data is hacked, you can't ask users to grow new fingers, they have 9 spare fingerprints to use and then the number of fingers is exhausted. So leaked fingerprint data is a far worse loss than leaked passwords.

That's why I said it's a thing/problem of those devices and accompanying software, not of VFP, to maintain its data. As soon as you start using a vendor unspecific software working on the raw scans a device may provide as output to its own software, you may do better than that software, or worse.

Bye, Olaf.