1

Whenever I check integrity of a file using md5sum, I get a string of alphanumeric characters to compare and verify if it was downloaded correctly.

Couldn't the concatenation of several of those strings be used as password? This would allow to 'store' the password in the clear, as long as I remember exactly which files produce said md5 strings.

I know it's as impractical as it gets, but I'm curious about possible security hazards and advantages, if any.


Advantages I can think of:

  1. Capability to recover your password, even if your hard drives and back ups get nuked.
  2. Being unable to input your password directly if interrogated. Although you could always point to the files, so not really any safeguard here.

Disadvantages I can see without barely any knowledge of information security:

  1. Extremely impractical when compared with a password manager.
  2. If the files are chosen poorly, or are prone to edit, the password could be lost or difficult to find. e.g. One of the files is a wallpaper from a popular show and it sprawls many edits by its fans.

  3. The password is accessible by anyone with internet connection. The only thing protecting it is the fact that it could be any combination of files with a creation date older than the password itself.


As stated, I know next to nothing about IS. Please, correct any misconception or mistake in this question.

  • 1
    Both your "advantages" could be achieved (and better) with proper use of a password manager and backups. Add to that the fact that your scheme can, at best, gives your the same or lower level of security than password managers and backup, I wonder what is the value of even attempting to see if it could be secure. – Stephane Aug 31 '15 at 10:03
  • And you forgot one important loophole: if even one bit of even one file you use to generate your checksum is flipped, your whole password-protected file is lost. – Stephane Aug 31 '15 at 10:03
  • 1
    I'm well aware that this system is dismal compared to password managers. I wonder what is the value of even attempting to see if it could be secure. Doesn't curiosity count as a valid motivation in this part of Stack Exchange? – Calculus Knight Aug 31 '15 at 12:45
  • The answer is inside your question: "what value...": answer: none. – Stephane Aug 31 '15 at 13:30
  • 1
    It sounds like you are basically describing a key file (though generally it's not good practice to use files that might change but instead generate a file filled with random bits). – Paul Sep 1 '15 at 4:58
1

Advantages over a password manager: Little to none.

Security problems:

  • Your password generation technique would be logged in command history.
  • Any file access mechanisms would record access to these files every time you log in.
  • Your password would be visible on screen every time you needed to use it.
  • If any files change without your knowledge, your password is lost.
  • 1
    I…what? Password managers have all of these problems, too. Password generation techniques should always be assumed public (else you're getting into security through obscurity); the password database's atime will be updated fairly frequently; if you ever choose to display a password, it will be visible to; if the database is corrupted, passwords stored in it may be lost. – Blacklight Shining Dec 22 '15 at 20:52
1

If we assume that the content of the input files is random, we can view your proposal as using MD5 as a PRNG algorithm and using the input files as the seed to the PRNG function. So your question becomes:

Is it secure to use a PRNG algorithm, whose seeds are stored on my disk, as a password generator?

The answer to that is clearly no because all of the data to recreate the password is online and unencrypted. While the passwords might appear random to individual identity providers, anyone with access to your system would have access to all of your passwords.

While you feel that the strategy you use for mapping files on the disk to passwords , it really provides no security, only obscurity. So there's no benefit there.

One possible improvement to your scheme would be to encrypt the input files and have some clever application that briefly decrypts them whenever you need a password. That may help some but you will still be left with many of the problems discussed in SilverlightFox's answer.

If the content of these files isn't truly random it becomes very hard to predict the quality of passwords that will be generated. Perhaps a clever and determined attacker will learn enough to predict your passwords or dramatically reduce the search space for some of your passwords. It is just too hard to know. In general, writing your own crypto is difficult and error prone. Note that even the encryption strategy discussed above doesn't increase the randomness/predictability of your input files.

As a final thought, there might be unknown interactions between the algorithm you use to generate passwords and the MD5 hash values. Perhaps MD5s generated from these files are less random than one would like. Without an extensive and public investigation of your proposal, there is no way of knowing (even then a flaw may be found later, but that's the best strategy we have at the moment).

  • Nice answer! What if nothing was stored on disk? I first thought about this question as using a set of wallpapers to generate a password, but since it could be anything... It could be some official files that are likely to remain unchanged and available to the public. Though I admit this condition complicates the problem further. – Calculus Knight Aug 31 '15 at 15:57
  • 1
    If we view this as a random number generator and seed, you're basically asking if passwords from a random number generator whose see is publicly stored is secure. It certainly doesn't seem secure to me. And the whole idea seems open to side-channel attacks. For example, there is a risk that a (network) observer may be able to determine what files are input to what sites based on your network activity. – Neil Smithline Aug 31 '15 at 16:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.