What are Security Considerations of Using File Upload/Comparison as Simplified Second Factor?

Question

I am evaluating the idea of simplified second factor authentication by requiring a file to be uploaded, such as an image along with username/password. The file is stored on a user's device.

My reasoning is that this is faster/simpler than getting a code via SMS and entering it. Specifically, the user does not need to leave the login page to use another app such as an RSA generator or push notification, etc. The user would have previously submitted and stored a file that is not available elsewhere on the Internet, but is located on their device.

I am using HTTPS, but I do understand that a man-in-the-middle attack could cause the uploaded file to be compromised along with the username/password, so in that sense it is less secure than a code that was sent via SMS that expires in a few minutes and can only be used one time. And maybe that is the critical flaw.

I did find this post, but it wasn't very useful/specific (or current). A special file as the second factor in 2FA

I have spent several hours researching the subject of using an uploaded file as a second factor for authentication and found very little, so from this I assume there is something wrong or inferior about the idea. It is much more convenient for the user for frequent use, but what are the negatives?

Answer 1

Copyright James Daniel Marrs Ritchey. This material was created for submission at 'What are Security Considerations of Using File Upload/Comparison as Simplified Second Factor?', but can also be alternatively obtained from 'https://snippetly.blogspot.com/2020/05/pros-and-cons-of-using-file-for-2fa.html' under the terms of any of the following licenses: Ritchey Permissive License v8 (https://jamesdanielmarrsritchey.blogspot.com/2020/01/ritchey-permissive-license-v8.html), The MIT License (https://opensource.org/licenses/MIT).

All security measures are a balancing act between various client-side, and server-side attack vectors. By increasing the security against one vector you decrease security somewhere else. Whether it's a good or bad configuration depends on your service and clients, because that's what decides where you need to prioritize your protection.

Positive:

The file is essentially acting as a secondary password, but assuming it's a decent sized file, created using a secure method (eg: a 10 second video of my dog), it would be significantly more secure than a normal secondary password (eg: 12-18 printable characters) against login attacks, or stolen password database attacks. So this increases some server-side security. Since the user isn't typing it in, it won't be catchable by keyloggers running on the device, or persons/surveillance watching the user login, which increases some client-side security.

Negative:

1. This file must be present on the device, and it can't be protected with file encryption since it's being directly uploaded. The same situation applies to SMS codes. A normal secondary password however, can be stored in a password manager.

2. To avoid loss of the file users may decide to backup it up (eg: external drive, cloud, etc). This results in additional attack vectors which you are counting on the user to have the know-how to protect.

3. The user may be enticed to name it something obvious to more easily remember which file to use (eg: "2FA.jpeg"), but this will also make it easier for hackers/malicious software to find it.

4. Uploading files will use more of the user's internet bandwidth. This could deter cellular, and satellite users from using your service.

5. Matching the uploaded file with the record on your server will use more of your storage, internet bandwidth, cpu usage, and memory usage which may affect your cost of operation.

6. You will likely wish to impose maximum size restrictions, but non-technical users may not know how to best make a file under that limit (eg: You impose a limit of 3MB, but their camera produces images which are 10MB).

7. When the file is uploaded it will be temporarily stored on your server without file encryption, unless you hash it client side, but hashing it client-side would affect the performance of the user's device.

8. Unlike an SMS code which comes through a different route of communication than the username and password, all communication of login credentials will be coming through one line of communication.

9. Unlike SMS codes which are usually one-time use, this file will be used every time, which means once an attacker has it they have it.

10. Depending on the data provided to the user from your service, this file may cause a noticeable change in data transmission (eg: spike, or drop) between the client and the server making it possible to track when a user is logging in vs using the service.

Answer 2

This is not 2FA. 2FA requires two different elements from something you have, something you know, something you are. You're starting with a password (something you know) and adding a second something you know.

Things you know are characterised by being secret, but copiable. Someone else can have knowledge of your password, and you will still know it; their having knowledge of it doesn't deprive you of yours, so your knowing it doesn't prove that someone else doesn't.

Things you have are characterised by being unique physical artefacts. They're easier to steal than things you know, but they're unique; if you've got the artefact, you know nobody else has it, and if you don't have it, you know someone else does.

The reason an SMS delivered by a phone network is a legitimate second-factor to a password (or other something you know) is that it's a proxy for determining contemporaneous possession of something you have, to wit, the handset. Leaving aside all the issues with unauthorised SIM swaps, IMEI cloning, etc., at any given instant one and only one handset can be associated with a pre-declared phone number, to the SMS-delivering network. If a remote system sends a nonce via SMS, and you can tell the remote system that nonce within a short window of time, it is reasonable grounds for the remote system being confident that you currently possess the registered handset in question, and are thus likely to be the authorised user.

If you lose your phone, it is expected that you will notice, and that you will notify the administrators of the remote system(s) in question, so they can deregister that handset as an authentication device for your account¹. This property will not be true of the file-based scheme you propose, because others can have copies of the file without you losing yours.

Any time someone adds a second factor to an existing username/password system and tries to persuade you it's 2FA, ask yourself whether you'd know if someone else had a copy of this second factor, never mind how they got it. If you wouldn't, it's not a second factor; it's just another password, in disguise.

---

¹Or that you will in some other way render the artefact useless for this purpose, such as notifying your mobile phone company that you've lost your phone, and having the right to bind a new IMEI to that number associated with a new GSM SIM in replacement of the old one. The security flaws in that process are fertile ground for people looking to, eg, gain control of other people's bank accounts.