Retinal and fingerprint scanner logins


When will this function be added? The data is all encrypted and never leaves your local machine? What better data to calculate a hash with?


Ideas like these have been floated on this forum a bunch of times and the answer hasn’t changed: in order for the network to verify your data it must hold a copy of it and be able to read it without your permission.
Why would anyone want to give this data to the network?


@janitor Can’t the network simply store the hash of the biometric data instead of the fingerprint data itself? I recently wrote an app aimed at the SAFE network that stores my data in a database. The data is encrypted via a password and a salt, which together produces a hash. The hash is also stored in the database, and must be matched in order to retrieve the data. So you couldn’t replace the password with the fingerprint/retinal scan data?

Forgive me if I missed a crucial point here.


You may be right, but are you now talking about a two step process where you first have to enter a password that unlocks the DB and then there’s another prompt to check you fingerprint?
In that case can I access any of my Safe data without this second check?
I didn’t know it is possible to have a two-step authentication on SAFE.


Sorry I don’t know much about biometrics but how is entering a fingerprint scan different than entering a password as far as self authentication is concerned. Couldn’t the preverbial puzzle box be created with either one? The network doesn’t store your password or pin, it stores a hash of your login credentials which you have to be able to decrypt (if I’m understanding the concept of self authentication correclty here). So could not you create a similar function using biometric data? Wherein the network does not store your biometric data at all but rather an encrypted hash which you then have to decrypt in order to gain access to your account. Therefore, in that sense, how is a password different than a fingerprint if neither are stored on the network in order to create the puzzle the network needs you to solve in order to log in?


@janitor No, just meant storing the hash of a biometric ‘fingerprint’, as @Blindsite2k suggests.

I assume here that a fingerprint uses points, as do facial recognition systems. If the person’s fingerprint or face is unique, then feeding those points into an algorithm should be able to produce a unique hash number that can only match the person’s biometrics.


You may be right, I am also trying to understand if this works differently to what I thought.
If the “either one” approach that I asked about and Blindsite said may be possible, then I see how it could work. I wasn’t aware that this step accepts pluggable auth modules . But would that mean it’s again a single step, just biometric instead of keyboard based?

A. Anastopulous warned against biometric identification and I think he’s onto something: if you happen to have this compromised, then the attacker can use that info to hack any system where you use the same method (as opposed to the traditional approach where you can use different passwords on different sites). In case of biometric stuff you can’t always decide to not use the right index finger or change your fingerprint (without surgery).


Yeah I think that this is a valid concern; I think there is potentially a weakness in biometrics, as whatever physical kit you use to calculate the data may itself become compromised, then the data, if raw, may be hijacked when communicated between the kit and the machine itself, in the same way as a wireless keyboard can be snooped upon. And then there’s the ‘cut-off-the-finger’ trick.

Personally, I use 45-character plus passphrases for everything I need to keep secure.


If your biometrics can bed used to generate a consistent hash, then this would be easy to implement, but you would need to modify the launcher service code to incorporate it. You simply use the hash as a replacement for the password. I don’t think it is necessarily easy to use biometrics to generate this hash-password though, which leaves you with the original problem highlighted by @janitor

This would not necessarily be a problem. At least, to compromise a SAFEnetwork account. Because having the biometric hash from done other service is not enough to get you in. It does make it easier though - by brute forcing the keyword and pin - assuming you know for certain that this hash is being used, unmodified as the password for a SAFE account.

That makes me realise that reverse brute force attacks are possible on SAFEnetwork.