I'm using django.contrib.auth.hashers.make_password method to store passwords. There is an iOS app that sends username and password to my django site to get authenticated. I want them to send encrypted password not the raw password. But I don't know how django encrypt the password? How someone else in other platform can generate the same encrypted password?
Django has a variety of methods it can use to encrypt passwords. By default is uses PBKDF2.
You can look at your PASSWORD_HASHERS list to see what is set:
PASSWORD_HASHERS = (
'django.contrib.auth.hashers.PBKDF2PasswordHasher',
'django.contrib.auth.hashers.PBKDF2SHA1PasswordHasher',
'django.contrib.auth.hashers.BCryptPasswordHasher',
'django.contrib.auth.hashers.SHA1PasswordHasher',
'django.contrib.auth.hashers.MD5PasswordHasher',
'django.contrib.auth.hashers.CryptPasswordHasher',
)
Here is a SO article on implementing that algorithm in iOS:
PBKDF2 using CommonCrypto on iOS
The challenge will be that the password is salted. If you don't know the salt, you can't hash the password correctly. So you'll need to send the salt securely to the device, so your output hash matches.
version <1.4 is SHA1, >=1.4 is PBKDF2, check the table
select * from auth_user;
to make sure, the password column is algorithm$hash
check document for details.
Related
The ArangoDB docs discuss a couple nonce functions here:
https://docs.arangodb.com/3.1/Manual/Appendix/JavaScriptModules/Crypto.html
I understand the idea that I would create a nonce, send it to the client, hash a password with the nonce and send it to the server. But I don't really understand how these two functions work together to make this all happen.
Can someone elaborate on this documentation and the process? If I hash the nonce and the password together, how do I compare it to the stored password that's already hashed? Just looking for some guidance on the process. Thanks!
Update with more details:
I'm working on auth code. I guess in general I'm trying to understand the two functions in the ArangoDB crypto library and how they work together. The documentation doesn't elaborate very much. I found this workflow on wikipedia:https://en.wikipedia.org/wiki/Cryptographic_nonce But I'm not sure I understand it.
Client login page requests a nonce from server. Server provides. Does the server then store this nonce is the users session for later retrieval?
Client hashes password with nonce from server and a client created nonce as well and sends the username, client nonce, and encrypted password to the server.
How does the server compare the password hashed with the nonce & client nonce, to the already hashed and stored password in the database? Instead of hashing the password with the nonce & cnonce, should it just be encrypted using one of the nonce's as a key?
The ArangoDB crypto library provides two functions createNonce, which is obvious, but then it provides checkAndMarkNonce. How does this fit into the workflow? How can I check the returned nonce unless I store it in a session var? And how can I check the nonce if it's hashed along with the password? Is this wikipedia example just wrong, or am I missing some key components?
There is a common requirement of storing user credentials securely (user id / user password) in the App and use them automatically next time the App starts, but I'm not being able to figure out how to do this without user interaction.
Using JSON Store I need a password to encrypt the information, so if I store user credentials in the JSON Store I will need to ask to the user for the password used to encrypt the information.
A solution I figure out is to store the user id in a JSON Store without encryption and the password in a JSON Store encrypted with the user id as password. May be this solution provide a bit more security than not to encrypt anything but I think is not a complete solution.
As explained in the comments this is a really bad idea.
Is there any solution to store user credentials securely and recover them without user interaction?
You can use the Keychain API on iOS. Android doesn't seem to have an equivalent API.
The most complete solution I figure out is to store the user id in a JSON Store without encryption and the password in a JSON Store encrypted with the user id as password. May be this solution provide a bit more security than not to encrypt anything but I think is not a complete solution.
I would strongly advise against doing that, if you store the encryption key (the user id) in plain text, then the attacker can simply use that to get to the password.
Update (Aug 27, 2014)
You should consider:
Hashing - You could hash values you want to protect. These are one-way functions, so you can't get the password back once you hash it. However, you can verify that the user provided the correct password. For example: First login you store( hash(password) ) then on next logins you compare if hash(password_provided) == stored_password_hash. If it matches, the user provided the same password. You should also use a salt.
You could give the user the ability set a pin using some library like ABPadLockScreen (you could probably find or implement something similar for Android too). You can then use the pin as the PBKDF2 input to generate an encryption key (JSONStore will do this for you when you pass the pin as the password). I would advise in favor of letting users only try a small amount of incorrect pin numbers, especially if the pin is only numeric and short, that way they can't easily guess the pin by trying various combinations. The idea here is that a pin will be easier to remember and type than their password.
FYI - There's a Stack Exchange site similar to StackOverflow but for security questions here.
I have a simple webapp which users login to access to a third party API that also require their personal credential in plain text username and password (no OAuth or anything). What's a proper, safe-ish, and straightforward way to store these third-party passwords so I can decrypt them to plain text when needed and minimise leakage of these passwords?
I'm thinking of just hardcoding GPG keys in to encrypt in webapp for storage and decrypt from another machine behind firewall when needed.
I don't think this is a GPG-specific problem. You could think of a scheme like the following (no need for public key crypto):
Generate a random password to encrypt the plaintext credentials you want to protect
Derive a key to protect this random password from the user's password
Encrypt the password from step 1 with the password from step 2
Now you can access the protected credentials after the user has logged in (since you know the password the user entered). When the user changes his password, you only have to re-encrypt the key from step 1 (in case you use this key in multiple places; so you can't miss one).
For step 2, you should use some (slow) key derivation function like PBKDF2. This makes sure that in case of a security breach, a simple dictionary attack on the encrypted credentials is not possible.
I am making a program like yelp. Some people have some accounts. So I got to send the password to the web.
Should I encrypt the password before sending it?
After that what would be the standard password policy others used?
Should the encrypted password be the one stored on the mySQL serve? In other word, there is absolutely no need for decryption?
Basically it's like What encryption procedure I must use to send encrypted 'email' and 'password' values over the HTTP protocoll? but for objective-c
After the user logged in, my program need to tell the server that the user is authenticated already. Does my program need to keep sending password?
There are more than one architecture you can implement, and you have to choose considering many factors, like performance, how many users, server architecture...
Basically, you must use https and not http, store hashed password (MD5, SHA, ecc.) and always check if hashed password is equal to stored hashed password.
You can implement also a "session" using token (you have to create a kind of API server side and then use it on client side) or pass username and password in each call to web service (web service must verify credentials every time is called).
Another "fast" (it's not so fast anyway) solution is to implement (both server-client) a standard protocol like (it's my favorite) oAuth 2. It's used by twitter and Facebook, you can learn more here: http://oauth.net/2/
You might be looking for Base64 encoding:
http://cocoawithlove.com/2009/06/base64-encoding-options-on-mac-and.html
I am trying to use a DigestAuthenticator to secure some parts of an API I am creating using Restlet. In all of the examples, the DigestAuthenticator expects to wrap a LocalVerifier that will return the local secret in plain text. Obviously, I do not want to store all of my users' passwords in plain text. How can I use HTTP Digest with Restlet while not providing the local secret in plain text?
I have written a LocalVerifier that uses the identifer to query a db and retrieve a sha1'd password, but it doesn't work unless my Verifier returns the password in plain text.
Any ideas?
So basically I hashed all the passwords on the server side in the database, and I hashed the password on the client side before it was hashed by http digest. Seems like a more secure solution to me anyway.