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

[jbert]

Why not use the good old one time pad.

You can embed a big chunk of random data in your script (this is your decryption key) and then simply XOR your data file with that.

The file format (after XOR) can be a simple text/ini format, but won't be readable to anyone without the key.

You'll want to make sure the XOR data is longer than the possible length of your file, and generated randomly (man 4 random on your Linux box - you want /dev/random, not /dev/urandom).

It's a simple approach, but provided you use real random data, longer than your file, it's effectively unbreakable crypto.

Stick your random data (hex encoded) in the __DATA__ section of a module, and you're fine.

[tilly]

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.

[ikegami]

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.

[jbert]

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.