Develop Reference

How to store password for future CLI calls

I'm writing a CLI using python that pretty much is wrapping around an API for a website. There is authentication for the API, so I need to ask the user for their username and password. I'm not sure how to store these on the system without having them saved in plaintext somewhere. Is there a best practice for something like this?
As an example, a user might call from the command line:
python some_cli.py
And this will prompt them for their username and password if it isn't already saved. I thought about trying to save them with os.putenv or os.environ, but that won't be saved since this process will die and these won't be saved for future processes. The only thing I can think of is to have a file that this information will be saved in and read from.

Use the credentials the user enters to log into the web API that you are wrapping. The API should return a token or a session, just as if you were using it in the browser. Store this token or session somewhere in your CLI program as a variable or store this in a file. This will need to remain as plaintext. Each CLI instance can use this file to make requests to the API when run. You will need to handle expired sessions/tokens too by asking the user for their credentials to re-authenticate.

Generally, passwords are salted and hashed before they are stored on the system's hard disk. It sounds to me as though you're writing a client-side password storage script. Therefore, I would recommend the SHA-2 or bcrypt hashing algorithms to make your passwords unintelligible before storing them. Do not use MD5 or SHA-1 to hash your passwords, as they have known vulnerabilities.
When the user-supplied password and the real password is compared, they are not compared in plaintext. The user-supplied password is first salted, then hashed. The resulting hash is compared with the hash of the "correct" password that is stored on the disk. Using this method, the plaintext password is never stored on the disk. Additionally, since the probability that two hashes will match is extraordinarily low, it is considered a safer practice than storing plaintext passwords (a much, much safer practice because hashes are extremely difficult to reverse even if the attacker knows the hash).
This thread has a couple of interesting implementations of salting and hashing, including a bcrypt implementation. Salt and hash a password in python
A secure password storage tutorial may help you on your journey.
Keep in mind that cryptography has its weaknesses. Rainbow table attacks, timing attacks, and known plaintext attacks are all things that must be understood when switching to cryptographic password storage. That being said, cryptography is a highly respected field known to offer good security.
I'd recommend you join Stack Exchange's Cryptography Forum

Python: securing sensitive variable contents within a script

I need the user to input their password into my script so that I can then use that password to perform an LDAP operation on their account. It's very simple:
password = getpass.getpass()
ldapconn.simple_bind_s(binddn, password)
Even though the password is never leaving the script and is never displayed in plain text, isn't it still vulnerable to something like a memory dump? What's the best way to secure this password within the script, but still make use of it?
This post is interesting: https://security.stackexchange.com/questions/29019/are-passwords-stored-in-memory-safe
Primarily because the answers confirm my suspicion that passwords stored in RAM are not safe. My question is, how is one supposed to do work that requires that sensitive information be stored in RAM? No one on that post really posts a practical real-world solution, just a lot of a confirmation and details as to why RAM is not safe. Using my short example of an LDAP connection above, what concrete changes could you make to better secure the password variable?

Using my short example of an LDAP connection above, what concrete changes could you make to better secure the password variable?
None. You either:
Need to have the plain text to send to the LDAP API,
In which case you need to have the plain text, which an attacker could get
Or you need encrypted text which you decrypt, which an attacker could get after you decrypt it
Need a password hash to send to the LDAP API
Then the attacker could get the hash and use it. It's effectively a plain password at that point.
The solutions which exist are to have a design which does not involve prompting the user for their password at all, and does not involve sending plain text passwords to other services.
e.g. you have a properly working Kerberos environment with synchronised time, users getting Kerberos tickets at first login, and those tickets being used to authenticate with services without password prompts. Tickets have a limited lifetime and Kerberos replay detection is built in, so that if they are taken from memory they are much less useful than a password.
So the user hits a password prompt once for the entire environment, not once per script they run or service they access, and that password is handled by one centralized, well reviewed, low level OS process.

Google App Engine as Authentication Server for Mobile Application

I am attempting to utilize Google App Engine as an Authentication Server for a mobile application that runs on android natively. User names and passwords will be stored in GAE and my goal is to be able to both store and verify credentials from the mobile application using GAE. Is this possible? I've looked into OAuth and JSON, but I don't think I have the proper setup for that.
Also, if I'm going about this the wrong way, please point me to the proper path.

If you are interested in having a more API-like implementation in your GAE instance, I would definitely look more into OAuth. But if you are only interested in validating credentials for this one mobile application then you need not go that far.
Fortunately you can call your GAE instance over SSL, that means that you can offload all the business of handshaking and encryption. Then I would simply use either http-basic authentication, or simply send user-id and encrypted password as parameters in the request.
On the iPhone there is a KeyChain for password storing, maybe there is an Android counterpart? Anyway, make sure to store passwords encrypted on the device and in the GAE-datastore. Send the encrypted password when validating credentials. You should never know your user's clear text passwords. That would provide a level of obscurity which I think is enough (definitely so when sent over SSL).
Then you can simply return whether the account credentials are verified or not.

If by "storign credentials" you mean storing username and password, then I imagine you are going about this the wrong way. Whether you are talking about OAuth or OpenID, the idea is that you never see or have access to the password (and perhaps not username either) of the delegated authentication mechanism. Instead you receive an authentication or authorization token to do your work (and in the case of OpeniD, some meta information about the person like first / last name and e-mail address).
By the way, have you considered a 3rd party, such as Janrain?

Handling Password Authentication over a Network

I'm writing a game which requires users to log in to their accounts in order to be able to play. What's the best way of transmitting passwords from client to server and storing them?
I'm using Python and Twisted, if that's of any relevance.

The best way is to authenticate via SSL/TLS. The best way of storing passwords is to store them hashed with some complex hash like sha1(sha1(password)+salt) with salt.

If you want plug'n'play solution, use py-bcrypt for storing passwords (http://www.mindrot.org/projects/py-bcrypt/) and SSL/TLS to protect them in transit.

Encrypted Django Model Fields

A client wants to ensure that I cannot read sensitive data from their site, which will still be administered by me. In practice, this means that I'll have database access, but it can't be possible for me to read the contents of certain Model Fields. Is there any way to make the data inaccessible to me, but still decrypted by the server to be browsed by the client?

This is possible with public key encryption. I have done something similar before in PHP but the idea is the same for a Django app:
All data on this website was stored encrypted using a private key held by the system software. The corresponding public key to decrypt the data was held by the client in a text file.
When the client wanted to access their data, they pasted the public key into an authorisation form (holding the key in the session) which unlocked the data.
When done, they deauthorised their session.
This protected the information against authorised access to the web app (so safe against weak username/passwords) and also from leaks at the database level.
This is still not completely secure: if you have root access to the machine you can capture the key as it is uploaded, or inspect the session information. For that the cure could be to run the reading software on the client's machine and access the database through an API.
I realise this is an old question but I thought I'd clarify that it is indeed possible.

No, it's not possible to have data that is both in a form you can't decrypt it, and in a form where you can decrypt it to show it to the client simultaneously. The best you can do is a reversible encryption on the content so at least if your server is compromised their data is safe.

Take a look at Django-fields

You might find Django Encrypted Fields useful.

You and your client could agree on them being obscured. A simple XOR operation or something similar will make the values unreadable in the admin and they can be decoded just in time they are needed in the site.
This way you can safely administer the site without "accidentally" reading something.
Make sure your client understands that it is technically possible for you to get the actual contents but that it would require active effort.

Some other issues to consider are that the web application will then not be able to sort or easily query on the encrypted fields. It would be helpful to know what administrative functions the client wants you to have. Another approach would be to have a separate app / access channel that does not show the critical data but still allows you to perform your admin functions only.