How to force the user to enter his recent password before changing it? - firebase-authentication

I'm building a page for a Flutter web application using Firebase Auth where the user can change his password. For security reasons, I want the user having to enter his recent password before being able to set a new password.
To achieve this, I tried to use the reauthenticateWithCredential()-method from Firebase.
Problem is, this only seems to work if the user hasn't signed in recently. If, on the other hand, he has just signed in, he can change his password without giving the right credentials (or even without giving any credentials at all).
So is there a possibility to prevent the user from changing his password without providing his correct recent password, no matter if he just signed in half a minute ago? Did I overlook something?
As far as I know it isn't possible to get the password from Firebase, so the only two solutions I can think of atm are
To sign out and re-sign-in the user, given he has entered the correct credentials, and then change the password, or
pass his password from the login to a variable on the change-password-screen, just in case it should be needed...
However, both methods don't seem to be appropriate for practical and/or security reasons.

Related

PHP: hashing password and making text available

I think i get the whole password hashing and verifying login as I got it working with php. however I need an answer and some advise and I dont mean dont eat yellow snow!! :)
I want to store the passwords of users in a hashed format, however I have a need where by I need to be able to see or use given password so I can help the customer fix there issues as a technician.
Now passwords are first created by my system then issued to customer, however users have the choice to change their passwords if they so wish.
username is also created by system.
Now that being said:
I had 2 thoughts both of which I have no idea how to do so some pointer or an answer would be great.
idea 1:
is to have a button on my site to show only the technicians the user password on demand. so they can copy and paste to the site.
Idea 2:
I was also thinking that rather than see the password. I could have some way to transfer the password into the site to create an auto login into the website.
So technician would have a button that they press and the password is sent to the site to auto login with the hashed password.
Thanks in advance.
To give technicians access to a user account, there is no need to know the users plaintext passwords. It is the job of your application to restrict access, so you can create an admin role which is able to impersonate a user.
Making passwords recoverable weakens the security of your site immensly.

When a user is changing his password, is there any reason to prohibit him from using any password that he may have used in the past?

I am implementing forgot password feature for my website, and while looking at other websites for best practices, I found that gmail enforces this, no other site I looked at enforced this constraint.
There is a lot of rather out-dated ideas about passwords and password security.
If a user has a password compromised -- and then however many days later they change it -- the attacker is now blocked from the system.
Should that user ever go back and re-use his old password, then the hacker might decide to retry that account/password and regain entry into the system.
Of course, it opens up a whole new set of problems. Make it so a user can't remember his password and they will start writing them on sticky notes taped to their monitor.
Personally? On all the sites I've worked on, I've never thought it important to add password expiration /or/ limits on what passwords may be (re)-used.
I would have thought it provides little to no added security. You are trusting the user to not lose their password but I guess it can go both ways.
If they have to choose a new password then they may have to write it down or be more likely to forget it again however if they have a new password it is less likely that someone who knows a password they use could use it to access your website.
Either way make sure you are storing the hashed password for comparison and not plain text.

phpBB Password Authentication on Custom Site

I have been looking for the past few hours on how to user the phpBB login script on a custom site. I think I'm just not searching for the right things.
A while ago, I created a phpBB site and have over 900 members registered through phpBB. I am currently face-lifting this site and redoing the user registration along with all of the other custom code I have.
My problem is, I want the users to be able to log in as usual, though I want to input them into my new database so everything can run smoothly. I mainly need their username, password and old ID#, but I don't know how to use phpBB's password authentication or where to find it
The statement needs to look something like this:
On Login, grab username and password variables:
if the username is not in MY database, check phpBB database.
If the username is in phpBB database, check to see if the password is correct **(This is the part I don't know how to do)**
If the password is correct, input the username, user ID and the password (encrypted my way) into MY database
Login
If the password is incorrect - error
if the username is NOT in phpBB database - continue
if the username is not in MY database - input username and encrypted pass into my DB
login
Where can I find a script to authenticate the phpBB user's passwords? I don't care how the script is done, I know that's a secret, I just need to be able to authenticate passwords so that I can make sure it's the same user
I do have access to the phpBB database, I just need a way to authenticate their password
I would rather delete the quesion, but here's the answer:
Check here: http://sunnyis.me/blog/secure-passwords/
and when you download the PasswordHash.php, change all of the $P$ to $H$. It will work. Strange how it creates a password, every time it creates, it's different. But the CHECK part of it makes sure it checks it correctly, no matter what hashed pass it creates.

How to securely set up cookie-based authentication in classic ASP?

What would be the most secure method of using cookies to authenticate users in a classic ASP website?
I don't want to use the ASP Session object as the session cookie times out after a while, and I'd like the user to be able to keep their login to the website active between separate browser runnings.
However, I don't want to just create a cookie containing their user ID as that could be easily forged - so what are my options here? I guess some sort of encryption but I don't really know what the standard methods of doing this is.
Your options here are pretty much limited.
Get your users to log back in again; best security approach.
This obviously applies much wider than just ASP.
The best way would be to hash the password... you should be doing this in any case where you store it in database.
The hash is a cryptographic function - when you run a string through it (eg password) you get out a long code. If the input is the same, the output is always the same.
But (this is the important bit) its mathematically virtually impossible to reverse the process - to start with the hashed value and work out the password, other than brute force (someone hashes dictionary, or random strings and looks for output that matches the hash they have).
So when the user sets up account, they put in their desired password, but you hash this, and store that. Similarly in the cookie, after they login you store the hash, not the password, and this has is compared with the hash in the db.
The downside is you can't send a password reminder since you don't know the password - to you'd have to send a password reset link and have a system to do that.
If you're really paranoid you might double hash, eg when they login the password is hashed once and stored in cookie. Its then hashed again and compared with the password in db (which is also double-hashed).
Don't Do It
Maintaining a user login quote "...between separate browser runnings" is not secure. IMHO, when you close the browser a previous login should be gone. Suppose your visitor was using a community pc at a coffee shop.
If you maintain this login the potential for the next community user to open the browser, navigate to your website and "poof" they are automatically logged in as the previous user.

Should password reset pages automatically authenticate users?

Many lost password workflows usually result in a page which is reached by a temporary link emailed to the user. This link then takes them to a page that asks for a new password.
Upon entering the new password should a user be forced to logon manually, or should the password reset page authenticate the user automatically which would reduce the number of steps and thus complexity of the process for the end user?
I often encounter password reset pages that make me reset my password and then login which feels like I'm logging in twice for no good reason.
I quite like drupal's method: The user gets sent an email with a link in it which will log them on once; upon logging in with it they are given the opportunity to change their password.
I don't know of any significant advantage to forcing the user to re-enter the password that they just entered twice. If someone does, I'd be interested to hear about it.
You should make it auto login. Don't see why you would make the user login.
If it's because of bot protection, just add a captcha when the user logins using the link.