1

We have an application that allows users to login using fingerprint. The server validating the sent fingerprint. Now, anyone can watch the traffic and resend them. What the best way to prevent this from happening? Should we add captcha when using fingerprint as validating the fingerprint?

Update: We have a system where legitimate users watch the traffic using Network Sniffer like Fiddler to capture their fingerprints and they can use the same HTTP traffic to replay which makes them automatically logged in without using fingerprint. We wanna force users to use a fingerprint every time instead of allowing them to replay.

Improve this question
2
  • You don't describe how the authentication protocol works, which is required. Furthermore; who is the attacker? Someone listening to the traffic, or someone controlling the endpoint?
    – vidarlo
    Nov 7, 2020 at 13:01
  • @vidarlo I update the question to add more details.
    – Imran Qadir Baksh - Baloch
    Nov 7, 2020 at 13:12

3 Answers 3

Reset to default
2

That's not possible without TPM. Once a client digitally stores its biometric data, it can reuse it in the authentication request. A nonce won't help either as the client is not replaying anything. It just reuses its biometric like a saved password.

Let app requests nonce from the web service, use that nonce in biometric authentication. Once TPM validates biometric, the authentication result from TPM along with the nonce will be certified which can be validated by the web service. This is called attestation.

TPMs do not certify biometric data as this data never leaves the secure environment. The implementation to use hardware backed attestation varies across OEMs and OS.

Improve this answer
0

Update: We have a system where legitimate users watch the traffic using Network Sniffer like Fiddler to capture their fingerprints and they can use the same HTTP traffic to replay which makes them automatically logged in without using fingerprint. We wanna force users to use a fingerprint every time instead of allowing them to replay.

You can't - not without elements from trusted computing. And not over HTTP. A basic tenant of web development is that you can't trust what the client sends you. Furthermore; you have no control over how the client chooses to gather what he sends you. It could be a fingerprint reader, a keyboard, or whatever.

A good fingerprint reader will have a deterministic output. Equal fingerprints should produce equal output. Otherwise you can't use it to authenticate users.

There's a few ways to solve this. For instance, you can use a embedded, trusted, computer, that can certify (possibly via PKI) that the fingerprint was captured, and attest it by including a nonce sent from the server. But in this case, you need a custom reader with which you can communicate - and you have to trust the reader. This is basically what U2F does; it trusts a dedicated piece of hardware, and has a protocol to communicate securily with this piece of hardware.

As you describe your solution, you don't have that; you get some number from the device, and if this matches what's stored in the database, you authenticate the user. And it happens over HTTP.

Adding a captcha wouldn't improve security of the solution. It would require solving a captcha, which is trivial. Anyone with access to the valid fingerprint string would be able to authenticate at will, without using the fingerprint reader.

In short: you have a x-y problem. Go back to the drawing board.

Improve this answer
4
  • A good fingerprint reader will have a deterministic output. Equal fingerprints should produce equal output. Are you really sure of that? I had always thought that because fingerprints were not deterministic, the server had to store the real data instead of a hash...
    – Serge Ballesta
    Nov 7, 2020 at 15:44
  • Equal input data should lead to equal output data. Deciding if it's a match is a different topic, and 100% equal readings are probably not possible. But the principle stands; if it can be used for authentication, the output has to be decided by the input, and thus equal in equal cases.
    – vidarlo
    Nov 7, 2020 at 15:46
  • 1
    What I mean is that my finger is always the same finger. But I cannot be sure to present it exactly the same way on the reader, and if I have recently opened oysters additional marks could be present. For that reason I would assume that the output of the fingerprint reader is not always exactly the same.
    – Serge Ballesta
    Nov 7, 2020 at 15:52
  • @SergeBallesta Then you'd essentially have to store all data for all users, and deny if a similar, thus valid, response was presented. I don't think that's a great solution...
    – vidarlo
    Nov 7, 2020 at 20:15
0
  1. Prevent replay

Use nonce (based on timestamp, counter, whatever): force client to send the nonce the server presented to it in the login dialog. Register the nonce on the server and delete it when some request contains it. Each authentication request will have a unique nonce. Then only the first response will be accepted. Any subsequent response with the same nonce will be invalid.

  1. Prevent unauthorized reading

"anyone can watch the traffic" - to prevent it use HTTPS, not HTTP.

Improve this answer
7
  • 1
    What he wants to avoid is that a legitimate client uses the captured value from a finger print reader. Not a third party replay attack. Neither nonce or https will solve the problem.
    – vidarlo
    Nov 7, 2020 at 14:03
  • @vidarlo: You are wrong. Have you read the question? 1) Now, anyone can watch the traffic and resend them. What the best way to prevent this from happening? - My first answer addresses this issue. Your statement is wrong, @vidario. 2) legitimate users watch the traffic - my 2nd answer addresses this. Your statement is wrong and means you don't understand how nonce or counter is used. Server accepts each nonce only once no matter how many times you send it.
    – mentallurg
    Nov 7, 2020 at 20:12
  • No. Read the section starting with Update. He's complaining about legitimate users replaying the password (aka fingerprint data). Replaying that data and providing a valid nonce is trivial. A nonce won't help at all in this situation. Nor will TLS. The user can simply fire up developer console and inspect transmitted data. I suggest to discuss this in Information Security Chat if this is unclear.
    – vidarlo
    Nov 7, 2020 at 20:14
  • @vidarlo: It is not trivial. Server requests the client to send the nonce contained in the login dialog. The no matter how many time the user sends requests to server, on the the 1st one will be accepted (because nonce was not used yet), then the nonce will be deleted and any subsequent request that contains it will be rejected. TLS doesn't matter here at all.
    – mentallurg
    Nov 7, 2020 at 20:18
  • It is trivial. Grab a new nonce, replay old fingerprint data with new nonce. He wants to force users to use the fingerprint reader, and not input the data by some other means. A nonce will not change that - unless the nonce is handed to the reader, and used together with the fingerprint to craft a reply. I'm perfectly aware how nonces works, and they can't protect against a legitimate user wanting to use his own input method over HTTP... Please explain why curl http://example.com/foo?nonce=$(curl http://example.com/bar/ | grep nonce) is not trivial. Note that this is a simplistic example.
    – vidarlo
    Nov 7, 2020 at 20:19

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .