This a pretty basic question. Let's say I have this iPhone/iPad app that, at some point, gives the user the option to login. The username/pw are stored on the server's database.
What is the best way to communicate with the server to check if the username/pw are correct. How can I safely send & receive these requests via HTTP (without sending the plain pw)? What encryption/decryption should I use (both in-app and serverside)?
Just use SSL (i.e. https). Whatever you do, don't roll your own crypto!
if you dont want to send the password plain text,
you should use md5 hash (there is built in function in iphone)
encrypt the password with md5 function and send it to the server.
if the server DB has the password in plain text, he can also make md5 hash
and compare it with the one he received from the client.
you can also use this method to encrypt you're username.
Related
For token based authentication for any service, first we have to send username/password in the request. Doesn't this cause security issue? How can we overcome this security issue of passing username/password?
The initial request which contains the username and password is no more or less secure than subsequent requests which would instead be bearing some sort of token. The solution to this problem, really to sending any type of information across the network, is to use two way SSL/HTTPS. With HTTPS, information being sent gets encrypted on the client machine, and then (in theory) only the server would be able to read what is contained. So, sending the plain text username and password might seem insecure, but if using HTTPS, then in fact it is secure.
I am developing an app which uses several API services, the API requires that I provide username and password for API transactions, unfortunately no API token :-( in-order to automate I need to store username passwords somewhere, preferably database, I cannot use hashing because I need to send the username/password to authenticate and process API request, hence I am wondering how to go about it.
If I use Zend\Crypt to encrypt and store the password in database and decrypt whenever required, would this be enough for security? is there something else I must consider?
Looking for pointers.
PS: I am using ZendFramework2 with Doctrine/MySQL for the app.
Usually you would use a token mechanism (like OAuth). If that's not possible, one would use TLS/SSL client authentication.
However, if you rely on plain passwords (on the application-level, I still guess the username/password tupel is transmitted over a secure connection!) and you want to store them encrypted, you have to think of a meaningful mechanism to get an encryption key for your scenario. Just generating an encryption key and storing it on the same machine in plain does not provide more security.
Without more information on your scenario it is hard to make a suitable suggestion.
From a post on another stackoverflow, the following was recommended.
Is there a way to avoid using cleartext, maybe supply an existing admin ssh key instead?
from github3 import login
g = login('abcd', password)
with open('~/.ssh/temp.k.pub', 'r') as fd:
key = g.create_key('abcd', fd)
print("Created {0}".format(key.title))`
So to be clear, when communicating with GitHub's API, your communications are secured over HTTPS. github3.py uses requests which performs certificate verification and properly secures the connection. That said when we authentication using basic authentication, you're sending your credentials in the headers after base 64 encoding (which is not encryption and is not secure if it is somehow intercepted).
So really, you need to consider who you're worried about "seeing" your credentials. If you're worried about your company running a proxy locally that is meant to man-in-the-middle your connection and steal your credentials that's a good use for a limited token. You can create the token via the API or via the web UI. Either way, you would then (instead of using the code you have) do the following:
g = login(token='myspecialtoken')
Then you would do everything else the same way. I haven't checked if you can create ssh keys for the user with a token, but if it won't work you'll get an error about needing to use basic authentication (your username and password).
I still want to stress, though, that using your login credentials should be fine. The difficulty of intercepting that and retrieving your credentials as an arbitrary attacker is high. If you're worried about a different situation, you should definitely look more closely into the threat level.
You can use environment variables
ie
gh_login = os.environ.get('GITHUB_LOGIN')
gh_pass = os.environ.get('GITHUB_PASS')
Then pass these into login
I was going through the protocols that are used in email applications (specifically POP and APOP) and I happened to come across this answer somewhere. It says
Short for Authenticated Post Office Protocol, it is similar to the POP protocol except that APOP enables your password to be encrypted while being transmitted over the network. Using POP mail, when you authenticate your username and password in your e-mail client, your password is sent over the network in plain text. If your e-mail client uses APOP, then the password is encrypted while being transmitted. APOP prevents hackers from seeing your password information with sniffer programs.
My question is :Is that the major difference between APOP and POP? Is the password not encrypted when POP protocol is used? If not, will it not cause security concerns?
APOP is just new a command added to the standard POP3, which does not transfer the password in plain (e.g. with USER and PASS commands) but digest based. Later better authorization was added with the AUTH command, similar to how it is done with SMTP and IMAP. All these ways to not use encrypted passwords, but at most hashed passwords which often required the POP3 server to know the cleartext password to verify the send password.
Better is to use POP3 with TLS, e.g. either starting with a TLS connection (POP3s) or upgrading an existing connection with the STARTTLS command before doing the authentication.
The standard practice is to use HTTPs(ssl) when connecting to an email server. This will secure the POP protocol.
Consider the following interaction:
A user stores their username and password on a web server. For the sake of security, the server records a hash of the password plus some unique salt.
While the user is using a client application, it makes a request to the server submitting their username and a hash of the password plus some other unique salt.
So you have the following information on the server and need to know whether or not the request is authentic:
The server's salt
The server's hashed password
The client's salt
The client's hashed password
Again ... client sends: clientSalt + MD5(clientSalt + password). Server has serverSalt + MD5(serverSalt + password). I don't want to know the password, I just want to know if the hashes were calculated from the same password.
Without knowing the password that was hashed, is there any way to verify that both hashes are of the same password?
My goal is to allow some form of secure authentication in a client-server environment without ever exchanging the actual password over the wire. This is just one idea I've had, but I don't even know if it's possible.
That would require unhashing the password, which is not possible. If the server receives: salt, md5sum, it can't see what went into the md5sum.
A challenge-response protocol would work instead. The server should generate a random value nonce and send it to the client. The client calculates md5(md5(password) | nonce)) and returns it to the server. The server verifies by checking md5(storedpassword | nonce).
No, you can't do this.
Once you add a salt into the mix it becomes practically impossible to compare hashes. (To do so would require "un-hashing" those hashes somehow before comparing the "un-hashed" data.)
Challenge-response authentication is probably the way to go, possibly using Kerberos, depending on your tradeoffs. One of the tradeoffs being the possibility for attackers controlling the clients to use compromised hashes to authenticate themselves.
Don't invent your own cryptographic protocols. Use one that is well-known and well tested. If possible, use an existing (vetted) implementation.
My goal is to allow some form of secure authentication in a client-server environment without ever exchanging the actual password over the wire. This is just one idea I've had, but I don't even know if it's possible.
For this, I advise looking into Kerberos: Official Site and Wikipedia
It's impossible. If you don't store password on the server, user must provide it.
OR
If you store password on the server, user can provide hash calculated using requested salt.
You will not be able to verify the hash with this setup.
If you don't want someone to see the password go over the wire, SSL is the easier way.
If you don't want to use SSL, you could check out SRP.
Additionnally: don't use MD5+Salt to store your password, use key strengthening functions like bcrypt or scrypt.