I'm using data from another server (not my server) and I need to login to this server. So I need to know password for every user account. I need to send this password to the server through HTTP request (no problem). But the server expect unsecure password.
So if the password is '123456' I have to send POST request with data:
"username=user&password=123456"
I can not use md5 function because after it I am not able to get back the password so my question is how can I encode this password? Is exists some common PHP function for this? For example:
$securePassword = php_encode("123456", "mykey")
php_decode($securePassword, "mykey")
Because I just do not want to store to my database "123456"
Use mcrypt_encrypt() and mcrypt_decrypt() for more info SO POST
The point of a hash is that you can't un-encrypt it. To check if someone entered a correct password, hash what they typed in and compare it to the hash of their password in the database. If it matches, the password is right; otherwise, it's wrong. Also, as long as you use SSL and a decent hash algorithm, you should be secure.
If you have PHP >5.5, you can use the function password_hash. If you have a lower version that is bigger than PHP 5.3.7, you should use password compat.
What you are looking for is not how to secure the password but how to secure the transport of the password. You do this using Transport Layer Security, aka TLS aka SSL.
That said, transmitting a password in this fashion isn't really advised and a better mechanism should probably be devised. If you encrypt or hash the password and transmit the cipher text this offers no protection at all because an attacker would simply send cipher text just as you would.
You need to encrypt the data in transit. Get SSL setup on your site.
Have a look at below 2 functions
http://www.php.net/manual/en/function.mcrypt-encrypt.php and http://www.php.net/manual/en/function.mcrypt-decrypt.php.
There is a reason passwords are hashed instead of encrypted. You cannot decrypt a hash. Generally the convention is to do the following:
Create Password
Send the new password to the server
Hash the password
Store the hash in the database
Check Password
Send the password to the server
Hash the password
Check if the hash matches the hash stored in the database
For this you should use something like SHA256:
// check password
$hash = hash('sha256', $password);
$db_hash = db_get_password($username, ...);
if ($hash == $db_hash) {
// correct password
}
Related
Implementing a service that posts a user's ID and an MDG-hashed password to my server for verification.
We store hashes passwords that are generated using the password_hash() function in PHP >5.5.
Is there any way to verify the MD5 hash and our hash point to the same password?
Normally, a password would be submitted to us via a login form and we would verify with password_verify() but without the password in plain text I'm at a bit of a loss.
Normally, a password would be submitted to us via a login form and we
would verify with password_verify() but without the password in plain
text I'm at a bit of a loss.
As long as you use secure transport (SSL), this won't be an issue. That's the standard way that this is done. Otherwise you'll need to implement the hashing mechanism used by password_hash() in your client. Doing this wouldn't make your security scheme any better. It's still susceptible to replay attacks.
Also, you should stay away from MD5 because it's broken.
You can't decrypt it. But if you can change the mechanism for generating the password, you can refer to this post
I need an old password (not hashed) for sending to user but doesn't see a good idea? I read the documentation and there is only a method where I can get a hashed password. What can I do for getting real password?
Password should never be recovered clean after they are hashed and most of the time it's not even possible. I definitely suggest you to provide a reset password link instead of providing the old one.
Hashed password with MD5, SHA1, SHA2, Blowfish and others are one way encrypted this means that you shouldn't be able to decrypt them therefore making them secure (the first ones aren't that secure actually, but that's off topic here).
You can't get the original password; that is the point of using a hash.
If the user needs a new password, then generate a one-time, short-lived, random string and email it to them as part of a URL. When they follow the link, prompt them for a new password.
See the OWASP Forgot Password Cheat Sheet for more advice on how to do this as securely as possible.
You can't recover old password (unhashed) because its not stored in database. Only its hash is stored. Hashed can't be decrypted (that is why its called hash) ORM uses this model to solve alot of security issues.
Sending raw Password is real BAD idea. If you still want to do it:
If you are generating a password yourself during registration (Then mail it to user and then save it)
If user are setting their password. You will have it as POST variable. While saving it to database, mail it too.
If user is using forgot password to recover their password. Then reset the password first (generate a new one and save it to database) and send it to user.
You can't. A hashed password in Kohana is most likely a password encrypted with one-way encryption. I mean you can't decrypt it and get it in clear text. You should not store your applications password in clear text to protect the user.
http://en.wikipedia.org/wiki/Cryptographic_hash_function
What you may do is to generate a new temporary password for the user and send it to the users email, but I think reset password link is the best solution.
Is there a way to use a hashed password with imap_open() function? I have to hide somehow that password even from myself. But cannot find a way to do that. The actual PHP script works on the Linux server. A few people have sudo rights there. So, they may see that password anyway.
Thanks in advance
Such a feature would defeat the very purpose of password hashing:
The standard password scheme is for the resource that requires authentication to store a hash of your password, and that you submit to it your plain password. If the hash of your password matches the stored hash, the authentication succeeds. The purpose of this is that the resource never needs to know your password, nor can anyone who breaks in discover which password you used.
Now you're asking that the user be allowed to hash her own password and submit the hash, and that the resource then just compare the submitted hash with the stored hash. But this would effectively turn the hash itself into a plain password which is stored verbatim! Anyone who gets access to the stored hashes would now have immediate access to the resource, thus utterly derailing the very purpose of only storing a hash of the password!
I don't really know even what questions to ask here. My problem statement is simple: I need to store a password on the DB with a salt, validate an entered password against the stored password, and authenticate the password using a random challenge word whenever a user tries to log on. I am using php/javascript.
In trying to figure this out, the problem I am having is that if I pass up a challenge word in an html form, then hash the entered password with that word, I can authenticate the password on the server, but I can not separate the password from the challenge word so I can validate it against the salted password on the DB. If I send the password to the server in the clear or hash it without a challenge word, I can validate it but now I can not reliably authenticate it.
I think I need a 2 way algorithm of some sort so I can encrypt it with a key, and then authenticate the key while validating the password. How do I do it? or if it can't be done then what should I be doing?
Encrypting a password with client-side scripting is generally a bad idea. The proper way to do this is to use SSL.
Also, never store password in cleartext. If you must use a method like the one you describe above, hash the password twice: once for storing it in the database, another time for the two-way authentication.
To store a password, generate a random salt. Store HASH(password+salt) and salt. (Either the server or the client can do this computation.)
To perform an authentication, the server looks up the salt and HASH(password+salt). It then generates a random challenge and sends the salt and the challenge to the client.
On the client, prompt the user for the password. Compute: HASH( HASH(password+salt) + challenge). Send it to the server.
On the server, you already have HASH(password+salt) and you have challenge. So you can also compute: HASH( HASH(password+salt) + challenge). Compare this to what the client sent you. If they match, the password is correct.
Note that this is vulnerable to a MITM attack, so it should be used over a connection that is itself protected from a MITM, such as an SSL connection.
I need to send the following up to my server to be stored via POST:
&username=xxxx&password=zzzzz
Should I encrypt this before sending? Or just send it via HTTPS (SSL) to my PHP page?
On the PHP page should I then do the encryption to save it to the MySQL server?
Need a little help here as to what is the best iPhone app -> PHP -> MySQL way to do this.
Sending it over HTTPS should be fine for communicating between the iPhone app and PHP. You should hash the password, using a good password hashing algorithm, as soon as possible.
If you're not familiar with good password hashing practices, you might find this useful:
How do you use bcrypt for hashing passwords in PHP?
You can encrypt password using md5() or make your own encryption/decryption function.
Here is the example
From client end
$password = md5('password');
To check with database
//security check
$user = mysql_real_escape_string($_POST['username']);
mysql_query("SELECT user_name, email FROM users WHERE username='".$user."' AND MD5(password)='".$password."'");
HTTPS/SSL should be enough if you simply want to protect your data during transmission. Obviously you may also need to store encrypted values in your MySQL db. In this case you should also encrypt your credentials before doing your sql query.
HTTPS should be sufficient to protect the data en-route, as others have said. On the server side, you should not store the password in any reversible form (unless for some reason you need the plaintext, such as to pass it to a third party). I would recommend using a salted cryptographic hash.
Essentially, what you do is this: when the user sets a password, you generate a new random string (the salt) and then store the password as the result of hash(salt + password). This hash should be a strong cryptographic function (nowadays I would recommend SHA-256 or similar). In this way, the user's plaintext password cannot be retrieved, even if your server is compromised.
When the user submits their password, you can simply compute hash(salt + password) again and check that the result matches what is stored in the database.