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).
@janitor
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.