I am using Werkzeug for password hashing so that the passwords entered by users will be safe(atleast).
Lets say my application is as follows:
When a user gets logged in I will use check_password_hash and then login the user inside.
After the user is logged in, I want to show them their password.
The problem I am encountering:
How do I convert the hashed password back to string to show the user their password?
My code is as follows:
>>> import werkzeug.security as ws
>>> ws.generate_password_hash('abcdefg')
'pbkdf2:sha1:1000$fYAXLNA6$637528ae2fa195304c328d585e805b164f1c718f'
>>> ws._hash_internal('pbkdf2:sha1:1000', 'fYAXLNA6', 'abcdefg')
('637528ae2fa195304c328d585e805b164f1c718f', 'pbkdf2:sha1:1000')
Now how do I convert this '6375.....' back to 'abcdefg'?
I have access to database and the all the other stuff required. Basically I am the admin!
Note: I cannot use the password which user entered while logging in. I can only use the password from database.
After the user is logged in, I want to show them their password.
The whole purpose and reason of hashing a password is that you can never do this. Not you, not anyone else.
If someone has access or steals the database with the list of passwords, converting the hash back to the original password is really, really expensive. You will need a million years to break and reverse one single password.
We cannot get the original text back while using hashing. Generally all the passwords are stored as hash value, in order to make the passwords private (known only to the user). All the servers implement this. If you want to get the password back then you should use symmetric key cryptography. Where a secret key will be shared between the clients and the server (But it is a very bad practice) It better that you go with hashing.
Related
I would like that every time a user changes the password, it is also changed on firebase. The main problem is that the passwords taken from the wordpress database are hashed, while the auth.update_users command takes the raw password.
Obviously I'm not aware of the password in raw format...
What can I do?
i had try it:
...
users = auth.get_user_by_email('user1#gmail.com')
print('Successfully email fetched user data: {0}'.format(users.uid))
user = auth.update_user(
uid=users.uid,
password='$P$BOCNIc5Nw1e9fwm8HaLBChsd7eE4Hh1'
)
print('Sucessfully updated user: {0}'.format(user.uid))
There's nothing you can reasonably do here with the hash. The whole purpose of storing hashes (and hopefully salts) is to make it unfeasible to brute force revert password hashes to their cleartext password. If you could do that, so could any malicious user that gets access to the database of hashes.
If you want to send the cleartext password to two providers, you'll have to capture it at the source (so when the user enters it in the web app) and then send it to both providers.
So, I'm working on a project where I'm storing passwords in a mongoDB and using Python. Python do has bcrypt build-in module which allows us to hash a plaintext. Now, I can hash a password and store the hashed password in database. Cool. And If I want to know if saved (hashed password saved in database) is same as a given password or not. (i.e. If I hashed a password 'Password' and saved it in database, bcrypt allows us to compare this hashed password and a plain password to check if they are same or not) I can check it with some built in functions.
But, what I really want is, I want to take that hashed password and want to print original plaintext.
(e.g. If I hashed a password (say Plain password is 'Password' and hashed password is 'Hashed_Password' ) and saved it in database along with UserID and email for a specific website, now at some point I want to know what was the UserID and Password. So I can get UserID (since I'm not gonna hash it) but I'll only be able to get hashed password (i.e. 'Hashed_Password) and not the real one (i.e. 'Password') I saved.)
I hope you can Understand my problem and give me a solution. In summary, is there a way to get plaintext (i.e. original text) from hashed text or Should I used any other method to do so (like encryption or something).
The whole purpose of hashing passwords before saving them in a databse is, others should not be able to see(calculate) the oraginal password from database.
Simply you cannot get oraginal value from a hashed value.
From what I know,
We hash passwords so that even if the attacker gets access to the database the attacker will not be able to have the passwords without using a technique like brute force to get the password. I.E. assuming the attacker know how you hash the password a dictionary of passwords can be hashed and compared with the database to see which passwords match.
Now if you want to reverse the hash I am pretty sure that can't be done other than you trying the brute force method explained above. We can't reverse the hash but only guess by giving passwords.
In terms of encryption which is often used as another layer. For example you could use encryption before the hash and then hash the encrypted password. This way even if the attacker inputs the correct password and only hashes that password the attacker will simply not get it right when compaing the hashes.
I'm aware of how encryption works. I'm unable to get my mind around the fact that for generating a key using PBKDF2HMAC, I need the user password for encryption. For example, if a user logs in and creates a note, I want it to be encrypted. The key that is derived shouldn't be stored anywhere. So should I pass the users password every time the user creates a note for it to be encrypted or is there any other way.
Note: By passing the user password, I mean from the frontend to the backend. Also, is it bad practice to store the user password as a django-session variable once it has been passed by the user?
I have managed to salt and hash password using this method:
import hashlib, uuid
salt = uuid.uuid4().hex
hashed_password = hashlib.sha512(password + salt).hexdigest()
How do I reverse this process to recover the actual password?
Update: You are supposed to take a password from the user, apply the same salt and hash method to their password, and then compare it with the originally salted/hashed password to see if they match. That makes perfect sense.
You don't. Hashing is a technique which is only one way. This is the whole point of hashing.
You never store raw passwords in order to protect your user if you got a leak of information in your DB.
If you want to implement some "password recover" procedure, you need to do as everyone do, send a email to the person with a temporary link to reset password on send a new one randomly generated.
Hashing is one way as in you can only encrypt (for example) a string and then compare the user provided hash with the one your app generates.
However, there is simple-crypt and it may be what you're looking for if you want "2 way" hashing.
Good question.
First off: never send users their passwords in plaintext!!
It's considered a bad security practice for a few reasons.
If anyone gets access to a user's email account (gmail, etc), then they have the password and can hijack the user account.
Second, hashing is a one-way form of encryption where you turn the password into gibberish. The big value in hashing is that the same password will always be turned into the same gibberish: every time. This means you can do password matching without ever storing the raw password. The reason you're supposed to hash a password and not do 2-way encryption like AES-256, is that 2-way encryption requires the creation, management, and securing of encryption keys which can be hard. Hashing is just easier and more secure for the vast majority of developers.
Instead of implementing password reset stuff by sending a user their password, you should instead send a user a link to a secure page where they can reset their password with a one-time token that expires after a certain amount of time.
This way, even if an attacker gets a hold of someone's email account (gmail, etc.) -- there's only a limited amount of time they can do damage.
There are a variety of ways to do this stuff yourself, but an easy approach to getting a one-time use token you don't have to store or manage is to offload user management to a microservice like Stormpath where it takes care of all the user management for you: password reset, password storage, user profiles, authentication, encryption, hashing, etc.
If you wanted to implement something like this in a Flask web app, for instance, you'd use the Flask-Stormpath library like so:
from flask import Flask
from flask.ext.stormpath import StormpathManager
app = Flask(__name__)
app.config['STORMPATH_ENABLE_FORGOT_PASSWORD'] = True
stormpath_manager = StormpathManager(app)
app.listen(3000)
NOTE: I work at Stormpath, but these rules apply regardless of what you're using and help make any application more secure.
Is there anything wrong with this procedure?
Enter in username and email in a reset form.
Flask creates a really long random string and stores it into the session under "reset_code". Session will also have a key for "reset_pw_username"
Flask sends an email with a link to the path /password_reset/reset_pw_username/reset_code
That link displays a form where the customer can reset the password if the session reset code matches the session reset_code item. Otherwise it bombs out.
The session will expire the reset code after an hour.
If I can enter a username and email address, then I can get a reset token for any user of your service emailed to me. Maybe you should check that the email address is one that actually belongs to the user whose password is going to be reset.
You must ensure that username and email entered match one of the accounts (or use emails as username in the first place).
From a usability perspective, this won't work if the browser that displays the link contained in the email is not the same as the one initially used.
Apart from that, you should pay special attention to the randomness (not so much the length) of the reset_code. It should be cryptographically random (i.e. os.urandom) so that an attacker cannot simply guess it. random.random and derived methods are not suitable.
As Jean-Paul pointed out, asking for both username and e-mail requires checking whether they both match the same user. Hence it is more common to ask for either username or e-mail, verifying they are in your database, and sending recovery link to appropriate address.
Storing the recovery token in session data will likely be cumbersome for some users, as phihag described. Such tokens are usually stored in regular database. Note, however, that they are password-equivalent: once obtained, they can be freely exchanged for a password. Because of that, they need to salted & hashed (in the same secure manner that is applied to passwords themselves) before storing in the database. This also means that your recovery handler must salt & hash the incoming token before searching for it in your database.
The best solution is use email address as username,then user just have to remember his email address.And you just only have to validate user's email address.