http://qs321.pair.com?node_id=710833


in reply to Re^2: Storing credentials in a cross-platform binary file?
in thread Storing credentials in a cross-platform binary file?

First there is the problem of what you do if someone gets access to your script. But that is minor.

That's a given. He's storing credentials in an external file to be 'decrypted' by the script. The script has to have the info (key+algo) needed to decrypt the credentials file available to it. Anyone who has access to the script has access to the data, whatever scheme is used.

Suppose someone gets access to your data. If they xor an "encrypted" password with the real password, they get your xor data back. All they need to do is take a small dictionary of common passwords, xor it against 100 passwords, and look for some piece of xor text popping up more than once. (Lots of people use very bad passwords.) Once they find that, they now have your xor text and they have everyone's xor text.

Please elaborate. If I'm storing the repeated text in your scenario (10 passwords, all "banana\n") and XORing that with a random chunk of data *longer than the total password data*, you won't see repeated XOR text if you XOR the file with banana, since there is no repeated XOR text. You will have the XOR key but not know it. The XOR key needs to be bigger than the stored data (I stipulated this).

Much more serious is the fact that one time pads only work if you only use them once.

This is a more legitimate concern. If the file is repeatedly acquired by other people, and changes often, and changes in ways which allow multiple guesses of passwords to expose some of the XOR key, then yes, parts of the XOR key can be obtained.

But that requires an environment in which regular password change is mandated, which is the sort of environment which doesn't allow easily guessed passwords. Changing the XOR key with approximately the same frequency as the passwords are changed defeats this.

Edit: yes, using another crypt module is probably a better idea but perhaps harder to achieve given his platform constraints. Homebrew crypto is a bad idea. But we're only really obfuscating here since the script can decrypt at any time, and the script is presumably no better protected than the credentials file.