[SOLVED] Encrypting (or protecting) a Python password

apolyonn · 2014-03-14 14:14:35

I have a script which accesses my Facebook and lets me know when I have notifications, etc. However, within the script, my password is currently in plain-text; I see this as a security flaw for obvious reasons. After Google searching, I couldn't really find a solid answer on encryption methods for passwords in a situation like this, and, to be honest, I know very little about cryptography.

I was hoping to get some ideas, solutions, or confirmation of existing solutions, for keeping my password safe and accessible to my script; it would be nice to hear from someone with working knowledge on the subject, but any and all help would be appreciated.

http://stackoverflow.com/questions/1020 … pt-decrypt
http://stackoverflow.com/questions/1867 … encryption

Last edited by apolyonn (2014-03-16 16:29:16)

Trent · 2014-03-14 14:39:18

You should put the password in a config file and have your script read it. That way you can share or back up the script without the risk of accidentally divulging your password.

But when it comes to protecting the password, remember -- if someone can read or run your script, and can access the file containing your password, they can log in to Facebook as you in one way or another even if it's encrypted. There's no safety in encrypting it for storage unless you're going to prompt the user for a decryption key on every run, which would kind of defeat the purpose of storing the password to begin with. I refer you to the fetchmail design notes (scroll down to "Password encryption..."): the only thing client-side encryption buys you is extraneous complexity.

x33a · 2014-03-14 14:40:20

One way is to keep the password in a separate file, and then use a script such as the following one:

https://unix.stackexchange.com/a/48355

Stebalien · 2014-03-14 15:08:10

You can use a keyring. Both KDE and GNOME provide XDG Secret Service (http://standards.freedesktop.org/secret … index.html) implementations. In python I generally use the keyring package: https://pypi.python.org/pypi/keyring#using-keyring

This is slightly better than storing it in a file because passwords in the keyring will be encrypted with your login password.

apolyonn · 2014-03-14 15:19:35

Trent wrote:

You should put the password in a config file and have your script read it...the only thing client-side encryption buys you is extraneous complexity.

Thank you for the tip; I wasn't aware of these limitations of encryption. However, if this is true, then I have a few more questions. For instance, when phone applications (ie, Facebook App) store your credentials, are they storing it with secure protection methods; if not, why are they used without question -- and without being exploited en masse? Also, I've heard a lot of good things about GPG, as x33a suggested; but, if this type of encryption is useless, then I must ask what the difference is between "client-side encryption" and encryption in general, and if either will really protect information.

Stebalien wrote:

You can use a keyring...In python I generally use the keyring package

Thanks for this tip as well; I will look into this. I'll also need to make sure that SL4A can run this so I can use it on my phone.

Last edited by apolyonn (2014-03-14 15:33:19)

Trent · 2014-03-14 16:30:08

If you can use your phone to log on to Facebook without entering your password, then so can anybody else -- your phone becomes a proxy for your password. If your phone has some kind of lock on it to prevent unauthorized access, then your Facebook account is only as secure as the locking mechanism.

You might store your Facebook password, encrypted, in some public database, and use a locally stored decryption key to read it. Then, in order to learn your password, an attacker would have to access both the database and your local decryption key. But once the attacker has your key, the database encryption is transparent, so you now have to protect the key with the same safeguards you would have protected your password -- your Facebook account is no more secure than it was. If, then, your encrypted password file and the script that reads it are stored on the same device with the same measures of physical security, the password file might as well be plaintext, because anybody who can view it can also decrypt it by reading or running the script. Password encryption only makes sense when you are storing the password less securely than the decryption key.

Edit -- the other responses don't avoid this problem. A keyring requires that you unlock it before use, usually with your login password. GPG decryption requires that you unlock your private key by entering your passphrase. I'm only pointing out that you can't remove the need for user intervention, even if it's just once when the script starts up.

Last edited by Trent (2014-03-14 16:37:13)

apolyonn · 2014-03-14 17:23:19

Trent wrote:

If you can use your phone to log on to Facebook without entering your password, then so can anybody else -- your phone becomes a proxy for your password...Password encryption only makes sense when you are storing the password less securely than the decryption key...I'm only pointing out that you can't remove the need for user intervention, even if it's just once when the script starts up.

That's fair, and I really appreciate your insights. Since user intervention seems crucial to security, I wouldn't be opposed to encrypting my password file with, say, a 7- or 8-character letters/numbers/symbols combination -- my actual password is 17 assorted characters (it would be really annoying for continuous input). If the most I have to worry about is the people around me taking and hacking that encrypted file, I think I'll be okay given their level of computer knowledge; I'd rather use some level of protection than plain text. Are there any flaws with this idea that haven't yet been mentioned?

Trent · 2014-03-14 17:55:09

There's something just wrong about using a less secure password to encrypt a more secure password, but sure, that would probably keep your kid sister or the average laptop thief out of your Facebook. I'd instead change my Facebook password to something easier to type, because the proposed solution is in no measurable way more secure, besides being more likely to fail. But you should make that call based on your own requirements.

apolyonn · 2014-03-14 18:56:37

Trent wrote:

that would probably keep your kid sister or the average laptop thief out of your Facebook.

That's more-or-less the plan. This code merely tells me if I have notifications; in and of itself, it would not allow access to any other feature. If I compile it, that will keep the script from being edited, as far as I know, in such a way that it could not be manipulated to extract meaningful information (if that is incorrect, I'd be happy to know how); if the password file is encrypted, that will keep it from being visible; and, it seems very unlikely that anyone I know will intercept the I/O stream to extract my password (I imagine that if someone who did got into my files, I would have much bigger problems). Basically, I just want a "bike lock" for the event that someone happens to be snooping around on my computer or phone. The lesser-password-for-password thing could prove counter-intuitive, but it should satisfy what I'm trying to accomplish.

Last edited by apolyonn (2014-03-14 18:57:16)

Trent · 2014-03-14 23:58:31

Then you're probably fine.

Your post #5 has a few extra questions in it I want to clarify, since I kind of ignored them earlier:

apolyonn wrote:

For instance, when phone applications (ie, Facebook App) store your credentials, are they storing it with secure protection methods; if not, why are they used without question -- and without being exploited en masse? Also, I've heard a lot of good things about GPG, as x33a suggested; but, if this type of encryption is useless, then I must ask what the difference is between "client-side encryption" and encryption in general, and if either will really protect information.

I have no idea how Facebook App (or any other app) stores passwords. But, even if an app stores passwords in plain text, an attacker still has to gain read access to your individual phone in order to actually *read* them. Plain text passwords are as secure as the device they're stored on; encrypted passwords are as secure as the device the decryption key is stored on. When an encrypted password is stored alongside its own decryption key, it might as well be stored in plain text. I hope this kind of addresses the question of why plain text passwords aren't susceptible to mass exploitation (or, at least, why they're no more susceptible than encrypted passwords).

But encryption in storage (I said "client-side" earlier) is different from the issue of in transit encryption, which is what prevents an attacker from snooping on passwords being sent through unsafe channels (such as open Wi-Fi networks, or any network not owned by someone you absolutely trust). Facebook probably uses HTTPS for this purpose, and that's what encrypts your credentials whenever they're actually being sent across the Internet. What makes it safe is that only Facebook has the private key that can decrypt your HTTPS messages.

GPG used correctly is similar to HTTPS: strong encryption, beyond kid-sister level. (At least until D-Wave or somebody makes a quantum computer capable of factoring large numbers quickly.) But encryption alone doesn't make your data safe; you must also keep secret the decryption keys.

apolyonn · 2014-03-16 16:28:21

Trent wrote:

When an encrypted password is stored alongside its own decryption key, it might as well be stored in plain text....But encryption in storage (I said "client-side" earlier) is different from the issue of in transit encryption, which is what prevents an attacker from snooping on passwords being sent through unsafe channels (such as open Wi-Fi networks, or any network not owned by someone you absolutely trust). Facebook probably uses HTTPS for this purpose, and that's what encrypts your credentials whenever they're actually being sent across the Internet. What makes it safe is that only Facebook has the private key that can decrypt your HTTPS messages.

Alright, this makes a lot more sense. In-transit encryption is still a fuzzy area of knowledge for me, so thanks for making the distinction.

At least until D-Wave or somebody makes a quantum computer capable of factoring large numbers quickly.

http://i.imgur.com/KHY8vfj.jpg

Thanks to everyone who contributed. I learned quite a bit from this discussion.
Solved.

Arch Linux

#1 2014-03-14 14:14:35

[SOLVED] Encrypting (or protecting) a Python password

#2 2014-03-14 14:39:18

Re: [SOLVED] Encrypting (or protecting) a Python password

#3 2014-03-14 14:40:20

Re: [SOLVED] Encrypting (or protecting) a Python password

#4 2014-03-14 15:08:10

Re: [SOLVED] Encrypting (or protecting) a Python password

#5 2014-03-14 15:19:35

Re: [SOLVED] Encrypting (or protecting) a Python password

#6 2014-03-14 16:30:08

Re: [SOLVED] Encrypting (or protecting) a Python password

#7 2014-03-14 17:23:19

Re: [SOLVED] Encrypting (or protecting) a Python password

#8 2014-03-14 17:55:09

Re: [SOLVED] Encrypting (or protecting) a Python password

#9 2014-03-14 18:56:37

Re: [SOLVED] Encrypting (or protecting) a Python password

#10 2014-03-14 23:58:31

Re: [SOLVED] Encrypting (or protecting) a Python password

#11 2014-03-16 16:28:21

Re: [SOLVED] Encrypting (or protecting) a Python password

Board footer