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

I simply cannot express how bad an idea this is.

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

Much more serious is the fact that one time pads only work if you only use them once. 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.

If you are doing this anywhere, be assured that any serious security audit should find the fact that you are doing this, and you will get a lecture about how wrong you are.

Comment on Re^2: Storing credentials in a cross-platform binary file?

Replies are listed 'Best First'.
Re^3: Storing credentials in a cross-platform binary file? by ikegami (Patriarch) on Sep 12, 2008 at 04:57 UTC
I think he meant for the whole file to be encoded as one message, so the pad would only be used once. Once, that is, for every time the file is modified. Does it really make sense to update the key in the script every time the file is modified? And does it make it safer? The hacker now needs to get two files instead of one, but you'd think he'd be able to get both if he can get one.	[reply]
Re^3: Storing credentials in a cross-platform binary file? by jbert (Priest) on Sep 12, 2008 at 08:20 UTC
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.	[reply]


Pathologically Eclectic Rubbish Lister
	PerlMonks