There is a corporate web mail site (PHP + MySQL) for limited numbers of users who are employees of a company working remotely with the corporate web portal. Each user has a login and password.

I'm thinking about replacing usual text passwords with a key file, i.e. user choose any file to be the key at his first logon, it can be a text file or even a picture, the checksum of that file gets stored in the database and at next time such a user needs to loging he uploads his key file instead of typing a password. Would such authentication be more secure than a password typing? I guess it is much harder to figure out a key file than a password.

  • 5
    What problem are you trying to solve? Are you trying to force users to have a more complex password and using a hash of a file as that new password? Why not implement minimum password complexity?
    – schroeder
    Jun 11, 2014 at 19:22
  • 2
    I was thinking of multiple media authentication: password is something that user knows and a key file is something he should possess.
    – user164863
    Jun 11, 2014 at 19:30
  • 1
    Sure, I'll just upload this 800mb video file every time I login...
    – Grant
    Jun 14, 2014 at 13:41

6 Answers 6


The main problem with a key file is that it is a file. As such, it is stored somewhere, on some physical medium. It will be copied with backups. The file will still be there on discard hard disks. Users will copy their files to several devices in order to be able to log from all these devices. To sum up, files leak.

Conversely, a password fits in a brain and needs not be written anywhere; the user naturally moves it around with him; passwords don't leak to backup tapes and old disks. Last but not least, password entry works well on mobile phones, whereas file upload can be more technologically challenging.

So while a secret file can contain a lot more secrecy than a mind-powered password, it also tends to be a lot less "secret" and to imply usability issues. Overall, the "secret file" method does not seem to be more secure, in a generic way, than passwords.

Another way to see it: a "secret file" is equivalent, from a security point of view, to a text file that contains a big fat and random password, that the user reads when he wants to log in (and possibly "types" the password with a copy&paste). Every argument against writing down a password in a text file equally applies to your "secret file" idea.

  • I am by no means a security expert, but wouldn't passwords be backed up as well? I mean, Chrome autocompletes my passwords. If I were to back up my drive, wouldn't my passwords get copied as well?
    – 11684
    Jun 12, 2014 at 17:48
  • @11684 only because you've chosen to store your passwords in Chrome's local storage (and perhaps also on Google's servers, depending on your sync settings). With Chrome you have the option of not storing your passwords, or storing them in encrypted form (e.g. with a password manager). But if a password were replaced by a file upload, you would no longer have that option.
    – David Z
    Jun 12, 2014 at 22:30
  • a password fits in a brain and needs not be written anywhere; the user naturally moves it around with him; passwords don't leak to backup tapes and old disks Right,'cause that holds for all modern pwd managers.
    – TC1
    Jun 13, 2014 at 22:05

If you want multifactor authentication (as evidenced by your comment: "I was thinking of multiple media authentication: password is something that user knows and a key file is something he should possess"), there are several options:

  1. Password + client-side certificate (requires PKI infrastructure, and hard to rotate certificate. Hard to access webmail from another device, but that may be a benefit.)
  2. Password + OTP. You can either issue HOTP devices (YubiKey style), TOTP devices (RSA token style) or use a soft TOTP device (like Google Authenticator). There are several libraries implementing TOTP for PHP, such as http://www.multiotp.net/website/index.php?language=en.

Keyfiles are easy to steal, or you can have users make mistakes like altering their keyfile (imagine if they chose a document that they then edited!), deleting their keyfile, etc. It's not a very user friendly approach, and requires transferring the entire file on each login. Additionally, keyfiles offer no protection against malware or MITM attacks.


Nobody has mentioned the "official" way of doing this, using client certificate files. These are not sent to the server but participate in a cryptographic process. You can even store them on smartcards, at which point they cannot be stolen by malware on the client PC.

The downside is the UI is clunky and it's not easy to set up.

(Useful search term: "PKCS11")

  • In my former job we had crypto cards. There was some tricky setup done by admins, but then it was mostly straightforward for users.
    – Jan Hudec
    Jun 13, 2014 at 6:39

I see at least 2 points against that idea:

  1. passwords/passphrases ideally exist in the user's memory and nowhere else, whereas your "key files" must exist on some storage and therefore they can be stolen.
  2. You are not taking into account that users are not always sitting in front of the same computer - they would have to transport those files - more danger

Another problem with using a file is that a file is technically volatile in that you are not guaranteed that it will stay the same as long as it's used. Files can get corrupted or changed without you noticing it or realizing it. Data loss is also a risk: if you lose access to the location the file is stored (laptop stolen, hard drive crash, powershell/Bash/commandline typo), you can no longer access the system. A password does not have these issues. it does not reside on your file system, so any problems with your file system will not affect it.


Like everyone else stated, the main two problems are: 1. Storing their key on a hard drive medium, always a security risk as someone can steal even after the hard drive has been formatted. 2. Users will be copying the key from one system to another since we know for a fact no one uses one system to login. Which will increase the risk of compromise of the key file. Having one system with a key file is risk enough, imagine 3-4 systems with a copy of the key, now what are the odds of one of them being compromised? the risk is definitely there.

You must log in to answer this question.

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