Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Encryption Security

Encryption In OpenSource? 3

Millennium asks: "I'm working with some people on developing an Open-Source ICQ client. We're trying to decide how best to store the user's password in a file, should the user elect to do so. We thought about encrypting it, but I see a potential problems. So my question is this: How do you encrypt a password file in an Open-Source app, when the idea is to enter the password only once?" Millenium brings up some good points, so if you are thinking about building encryption into your apps, you might want to check this one out. Click below for more information...
Millenium's list of potential problems, in his own words:
  • If you use a hardcoded key, everyone can get it because the application is Open-Source and you have to code the key somewhere; that defeats the purpose of encrypting the password.
  • If you have the user create a key and reenter it each time they start the program, you've defeated the purpose of storing the password.
  • If you base it off of some data unique to the machine (the MAC address is an example, or perhaps there's a good use for the PIII serial number after all), then you can't transport the file between two machines easily (though an "Export Userlist..." command would be doable, I suppose).

There is a simple way around this one: timings. Ask the user to type a series of keystrokes and just time the difference between keypresses to create a random sequence - Instant random data source. Now that's just one solution (and possibly not even a good one), so does anyone else out there have other ideas?

This discussion has been archived. No new comments can be posted.

Encryption In OpenSource?

Comments Filter:
  • Posted by FascDot Killed My Previous Use:

    The conditions are impossible. Here's why:

    1) The ICQ server (apparently) wants a cleartext password. That's not security--any sniffer from the local machine outward can figure that out easily.

    2) You want the user to only enter the password once--so how does the local machine verify the user is the same person the second time? There's no way, so my brother (for instance) could connect as me just by choosing me from a list.

    A better idea (assuming this client is going to run under Linux) is to:

    a) Tell the user that ICQ "passwords" are not at all secure by their nature, so your program won't bother encrypting it locally, but that it WILL

    b) store the password in cleartext in a properly permissioned file in the user's home dir, assuming the user wants to store it anywhere (which should be configurable).

    The situation is impossible under Win95 since there is no differentiation made between users (with the exception of the PWL file, but I don't think you want to go there).
  • If you want to store information to send to the ICQ server, and you need the cleartext to authenticate, there's no good way. Anything you do can be undone, so you're not really providing actual security by obfuscating the stored password. This doesn't apply soley to visible/open source applications, either, as programs can be disassembled, or the program can be set to authenticate to a different server which listens to passwords, etc.

    Password security relies on having a secret, and unless there's something the computer doesn't know, there is no secret, and the original password is retrievable. The MAC address isn't a secret.

    If you obfuscate the password, perhaps you're just providing a false sense of security for the user, and you shouldn't do that. At least tell them it's not well protected. Rely on file permissions to keep other users from seeing their password.

    But obfuscation can prevent accidental viewing from people who aren't actually after the password, but might be going through your files (backup administrators or something). Something simple like xoring the password with 0xAA is good.

    If you want security, require the user to enter a password. If the password isn't terribly important (as in this case), don't worry about it.

In every non-trivial program there is at least one bug.

Working...