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
Related
Please follow thread below in comments for further clarity if anyone else has the same question
I'm not very knowledgeable in web security setup. Is it reasonable to store a hashed username and password in a php file inside a variable?
For instance I have a login form, on submit it hashes the username and password into a cookie. Than matches the hashed cookie to the hashed variables on the sever to allow access.
These are also one way hashes.
The problem is not in storing the hash in PHP itself; although a database is generally recommended.
The problem is using the hash as a plain-text password/secret; this is no different than any plain-text password. If someone was able to view the PHP source code they would have the hash and thus 'password'. Remember, password hashes are not secrets even though they should generally be treated confidentially1.
Instead, accept the username/password as plain-text - although, do use SSL to encrypt the password over the connection - and verify this against the hash2. At no point is a hash from the user trusted - as it cannot be proved that it was generated from an actual secret.
Once the submitted username/password has been validated on the server against the stored hash then a session nonce is established; it is this unguessable per-session secret that is then used to re-validate/authorize the user each subsequent request3. This is 'automatically handled' in PHP when creating a new session.
See the "Do's and Don'ts" and "Don't write your own password checker" answers, which are especially pertinent.
1 In real-world applications there should be a high priority given to confidentiality and preventing unauthorized disclosure. This is because most user choose stupidly short or common passwords (at least when given the chance) that can be brute-forced quickly. This can be mitigated by encouraging secure passphrase usage and secondary validators.
2 The newer password_verify / password_hash (or an equivalent library / backport) functions should be used as these correctly handles basic details including
Applying a correctly generated salt which prevents rainbow table attacks, and
Using an appropriate (ie. bcrypt) hash function which mitigates brute-force attacks on strong passwords/passphrases.
(If planning on using SHA - don't! - for hashing passwords, stop and read the links..)
3 Unlike using a hash-as-a-password this is only susceptible to session-hijacking, even if the hash in the PHP source code were leaked: it is also unique per-session. The attacker needs access to the client's cookies (via local access or Cross-site scripting (XSS); XSS can be mitigated with HTTP-Only cookies) or a method of intercepting the HTTP request (which can be mitigated with HTTPS); then, within that session, an attacker could impersonate the authenticated client.
As a long aside: if there was a need to store data in cookie (or otherwise sent back with a server request) and to ensure that it came from the server to begin with, one solution would be to use an HMAC as an authentication code. But this does not apply here.
User name/password authentication has a well tested solution that should not be modified.
When you store a password, use PHP's password_hash function.
password_hash("rasmuslerdorf", PASSWORD_DEFAULT)
is a typical use case. This creates what people loosely refer to as a hash. It's not really a hash as it uses bcrypt, a key derivation function, but everyone refers to them as hashes. Store the password alongside the username. You can do this in a database or a flat file. You should do your best to keep this secure to prevent offline attack, but this hash is relatively secure against all but a very determined and well equipped attacker.
When the use logs in, pass their username and their clear text password to the server. The server should obtain the user's stored password hash using the username as the key. Then the server validates the password using PHP's password_verify.
All you've done here is substitute one password for another password. It is vulnerable to replay attacks. And that you are storing the effective password in a cookie opens up a world of exploits.
There are lots of good tutorials on PHP authentication on the internet, and a few bad ones. You should:
Use PHP sessions (with a session cookie)
Use https (and HSTS)
Send the submitted values serverside in a post for validation
On the server lookup the hashed password and random salt stored against the username
Hash the submitted password with the stored salt
If it matches the stored hash you have a successful authentication; regenerate the session id and continue.
Otherwise track and limit the number of failed attempts to prevent brute forcing.
provide an explicit logout function which removes the data in $_SESSION
Not enough but it's good as start.
Cookies still a security problem as it can be used in attacks since the hash is stable result whatever it was MD5 or whatever.
In Wordpress they use a good strategy which is "Salt Keys" this makes application secure and hard to get cracked
here's what I'm up against.
I have an app for iPhone that I am building that communicates with password protected pages on my site. The app can get through the password protection fine and can get the response from the page just fine. The problem is that when I try to login to the site from my app it gets rejected. I believe this is because I am hashing the password with Bcrypt in the app before sending it to the site and then checking it with password_verify(), which of course takes the plain text of the password and then the hashed version, but I am giving it two hashed versions of the same thing which it is not accepting.
My question is this: is it possible to compare the two encrypted passwords using password_verify or some other function, or not? And if not, is it secure enough to (dare I say it) send the password in plain text from the app?
Thanks to everyone in advance!
is it possible to compare the two encrypted passwords using password_verify or some other function, or not?
No. password_verify requires the plaintext password and the previously hashed form of the password with the embedded salt as its inputs and there's no way around that. The algorithm is such that you need the salt again to produce the same hash, so your only other option would be to transfer the hash/salt to the client to reproduce the algorithm there. But that's pointless, since you want to do the password confirmation at the server, not on the untrustworthy client.
And if not, is it secure enough to (dare I say it) send the password in plain text from the app?
Sure, as long as the communication channel is secure, meaning you have an SSL connection.
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'd like to implement a forgot password function for my website. I hash the passwords using sha1. How would I recover this for the user?
What's the best method for implementing this?
Short answer, you can't.
You want to implement a password reset function, not a password retrieval function. The whole point of hashing passwords is that you don't get to store the user's password, and you can't recover it if it is lost.
This should give you a rough idea of how to allow users to reset forgotten passwords:
The best method is to not attempt to recover the original password. If a user loses their password then generate a new, random one and use an out-of-band method for sending it to them (e.g. email). Remember that the whole point of hashing the password is to prevent recovery.
I know, I know, email is insecure. But if you require users to immediately change the generated password then the risk is mitigated.
By the way, I cannot recommend enough that you also salt the password and iterate the hash to prevent brute-force attacks in the event that an attacker obtains the hashed value.
NO
There is no known effective way of reverting a sha1 hash to it's original text (since it's a one way function by design). If you would like to be able to show users their password at a later time, you will have to store it in a method that would be reversible (IE encryption, plaintext). This still is probably a bad idea, try to find a better way of doing it.