Develop Reference

How can I synchronize wordpress users with firebase ones in python?

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.

How to implement OTP based verification before letting the user to create a new password using pyotp?

I am very new to Django rest framework. I am building APIs for my mobile application.
In forgot password module, I have the below flow
Ask user to enter mobile
check existence
If exists - > send OTP
Verify and let user create a new password.
But in this case, I would like to know the way of handle the below situation.
When one user requests otp and waiting for it to verify, meanwhile another user requests for OTP
At this time, how to handle the both users?
I thought of
creating the dictionary and save the user id as key and otp as value in views.py to verify particular user.
store the otp temporarily until it verifies.
Which is the secured way and any alternative for this kind of scenario?

You should create a table look like this:
===== UserOTP =====
user: foreign-key to user
code: CharField, random generated code here (or token)
create_date: auto-fill created datetime
used_date: nullable datetime field
Then on each password reset request create a row on this table, send generated code to user via SMS or Email,
And then on another end-point receive the code from user and check it (for expiration and used before, belongs to this user and etc.) then continue password reset process.

There is a better way to do this, since otp are for temporary use, there is no use case for storing them in database, we can use hashlib.blake2s(b'otp', key=b'secretkey').hexdigest() to generate a hashed string and send it to user and then accept the same hashstring in the otp verification request and check for truthy of hashstring generated from user shared otp, this is oneway to handle otp verification.
The hashlibs blake2s accepts only bytestring, and you can also use any other hashing algorithm for this purpose. I am also open to ideas if there are any better ways to do this, please update in comments.
Using sessions would be better choice as it works for both django and djangorestframework.

Convert hashed password to string werkuzeug python

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.

Recover a salted and hashed password in python

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 password reset procedure?

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.