I am new to firebase and I am trying to handle firebase user authentication in React.js. I did manage to create users with email and passwords. But, now I would like to send the user an Email link to reset their password.
My code currently look like this.
// This line of code belongs to the top
import { auth } from '../firebaseConfig'
//This part goes under the React component
<p onClick={async () => {
try{
await sendPasswordResetEmail(auth, // My Email Id)
alert('Password reset link has been sent to your email')
}
catch(err){
alert(err)
}
}}
>Forgot your Password ?</p>
However, I do not get any error messages and I do get the alert message that says "Password reset link has been sent to your email." Unfortunately, I didn't receive any email. Note that I have given my own email id as the parameter for testing purposes.
firebaser here
Did you check your spam folder? We recently see a lot of the emails from Firebase Authentication ending up in the user's spam folder or being marked as spam in a system along the way. This is being tracked in this status message on the Firebase dashboard and in public issue #253291461.
To reduce the chances of the messages getting marked as spam, consider taking more control of the email delivery yourself.
As a first step, consider using a custom domain with your project. Email that comes from a custom domain has less chance of being marked as span.
As a second step, consider setting up your own SMTP server.) for delivering the email, so that the emails are not being delivered from Firebase's shared infrastructure anymore.
While these steps are more involved, they typically will drastically reduce the cases where the messages from Firebase Authentication are marked as spam.
Full Guide Based on Frank's Answer
Firstly create a new email account you can use to relay the Firebase emails through the SMTP server with. I personally chose Gmail, but I tested with Outlook and it also works.
You can now find an SMTP server host that will work for your scenario. If you're sending less than 1000 emails per month you can find free and reliable hosts. I chose SMTP2GO's free option.
Now you've found the SMTP host, add the email address you've chosen as a single sender email (note that if you do own a domain, you can alternatively use that to send emails).
Note that you will have to verify the email, usually by your host sending a link to the email's inbox. Make sure to check spam.
Once verified, navigate to where you host allows you to add SMTP Users and add a new user. This will allocate an SMTP username and password.
Navigate to the Firebase console, and choose the Authentication option from the sidebar (within the Build product category).
Go to Templates → SMTP Settings and enter the details of your SMTP server. The username and password fields are to be filled with the SMTP user login you created in the step above.
It is better to use TLS, but I believe SSL should work too but it is untested.
Click save, and you're all set up - but there may still be steps to perform depending on your email provider.
Provider Specific Steps
If the emails are being sent to an account managed by Google you will have no issues with your emails being quarantined by anti-spam policies and it will work immediately.
If you are using Outlook, you will have a different problem on your hands. Outlook's built in defender will most likely have auto-quarantined your email under multiple policies - that bit is important.
These policies are likely to be both spam and phish policies. If you unblock one of them, the other will catch it and re-quarantine.
Unblock both policies for the email address, and test. You can see the status of quarantined messages in Microsoft 365 Defender app under Review → Quarantine. Please note that you will need to be an administrator to add global allow policies to your email accounts.
If this still doesn't work it is likely that your company has an additional external filter (as mine did), and you will have to add the IP's manually to the Tenant Allow/Block Lists spoofed senders tab.
Related
I'm familiar with mailto:// links; that's not what this is about.
This is more akin to Sniper Links, which are useful to reduce friction in the process of confirming a new user's email address. We've just sent the user an email, and we want to give them a one-click way to go find it.
Sniper Links, as described at the link above, are great for that, but they're limited, in that:
The user must have a web-based email service.
We must be able to determine the mapping between email hostname and email provider (e.g. "some.guy#gmail.com" should go to the Gmail interface).
Those are mostly solved problems. Most people these days do use web-based email, and many who instead choose to use dedicated apps can use a web-based client. This is not universal, of course.
Mapping between hostname and provider is sometimes trivial (like the #gmail.com example above), sometimes not (#somecompany.com -> Google Apps is less obvious). If it's not directly obvious from the hostname, an MX record lookup will reveal the truth in the case of Google Apps and a most of the other big names in corporate email hosting. Services like ZeroBounce offer APIs to do the lookup and translation for you, for a fee.
But there are users whose email addresses do not have web interfaces, or for whom the URL of the web interface is not easily determined. For these users, I'd like to be able to bring up their preferred email client (assuming the browser -- or the underlying OS -- knows what it is).
I know that a mailto:// link will launch the default email client (whether web or app) and start composing a new outgoing message.
From a web page, is there a way to launch the default email client without starting a new outgoing message? I'm assuming this would take the form of a URI scheme, but it could also be a JavaScript API call or something else entirely.
Bonuses:
Also cause it to navigate to the inbox
Navigate, search, or filter such that we're likely to find our specific message (based on sender, date, subject, mailbox, etc)
Navigate to the precise message we just sent
No, that is not possible. Browsers won't open Apps "without" a reason. This could also be a major security risk, if they would do.
I'm considering building a website user authentication system using only one-time-passwords: users would get one in the email each time a normal password is normally used e.g. for signup, sign-in, risky actions and account deletion.
Some problems that I see with it that don't seem critical:
Can't change password to invalidate all existing sessions - can work around by storing sessions server-side and having a way to invalidate them for the user
Anyone can check if a certain email is registered in the system - doesn't seem like a critical problem for a generic website
Anyone can request an OTP for any email - will be dealt with using API limits per remote connection and a limit of 1 unused OTP per hour
I'm not seeing this method mentioned or used in the wild though. Does it have any major drawbacks? Many thanks!
OTP-by-email only is safer than password-only (it's basically like forcing the user to change their password every X hours).
I want to both address some of your non-critical points, and highlight some drawbacks.
Non-critical
Invalidating sessions
You don't have to store all sessions, only the invalidated ones, and only for the max duration of a session.
Checking that a user (email) is registered
That actually is a problem - it tells you that the email owner uses this website, which is a privacy issue, however minor.
But moreover, it's an attack vector. An attacker can scrape your user list, or just go attack that user on other sites, presuming that this email exists and links to a real human. Moreover, they can issue excessive OTP requests on their behalf, which I'll address in a bit.
All that said, there's no reason which this problem would manifest just because of OTP. A user can request OTP, and you can always reply with "If the email address hello#world.com is registered, a one-time password has been sent to it". This only has a slight usability implication.
Anyone can request OTP for any email
If an attacker can flood your site (from different IP addresses) with requests for OTP for hello#world.com, either you block this user (namely, that user has been DoS'ed), or you the site will flood the user's mailbox, which can get that mail server to flag the site as a spammer.
This could also be done in normal sites with password-reset emails, but that's why you typically want your user list to be secret.
Bigger drawbacks
Usability
OTP-only login assumes that the device from which you're logging in is also logged into the mail account linked to this site. Otherwise, the user has to log into the mail account in order to log into your site.
Single-factor authentication
The security community is pushing towards multi-factor authentication, where password is usually the first factor. A good practice would be to at least allow 2FA to users who choose to.
Account lockout
If a user's email account is no longer accessible for whatever reason (e.g. they used their work or university email), they can't log in, or even change their email address to their new one.
Email activity
If the site is heavily used, then it will be sending a lot of emails, to various public email services, continuously, all the time.
This alone may cause the site to be flagged it as a spammer, or even ratelimited.
If it does get ratelimited, some users will not be able to log in.
We are using OpenDS for SMTP account status notification to notify users when their password is nearing expiration. The SMTP account status notification handler works fine to notify the user and a list of Server admins when the password is soon to expire but we are not able to find a way to have the customer's name in the email.
The notification Handler has no issue pulling the customer's email address and also referencing the password policy to correctly identify the pending password expiriation, so why not also identify the customer by name in the email? All this information is available so how would a variable be set to pull and use this customer information?
The notification handlers are quite powerful but definitely under-documented.
It's possible to identify the user by mail in the email. I've looked at the code of OpenDJ (the actively developed branch of OpenDS, http://opendj.forgerock.org), and you can reference any attribute from the user entry within the template.
More specifically for the mail attribute of the user, you should use this property in the template (templates are under config/message/ directory) :
%%notification-user-attr:mail%%
I haven't tested, but it should work.
I hope this helps.
Ludovic Poitou
PS: I've been told by our technical writer, that all tokens that can be used in the template messages is actually documented as part of OpenDJ administration guide : http://opendj.forgerock.org/doc/admin-guide/index.html#account-status-notification
I have made a VB.NET application. I have read I tutorials that how to use SMTP to send emails from VB.NET, and finally I got one working.
But I have an issue with it, I don't want to bother the user to input all his details like, SMTP server name and all those stuffs.
I just want that a user input their Usename and Password and all other necessary details gets available for the application. Same like thunderbird, as when I enter my Usename and Password in Mozilla thunderbird it automatically get all the other required data and configures my email account.
Now what I want to accomplish is that, a user should fill in their details i.e. Usename and Password & the email using their Usename and Password should be sent to the email specified in the program.
To explain more about the kind of my project is, when an error occurs I want the user to take a screenshot of it and email me it using this method. So that I can look into the bug.
There is no automatic way of doing this. Each email setup is different and there is no automated configuration specification.
Thunderbird has a built in database that it's developers built and maintain to offer this functionality. See: https://support.mozillamessaging.com/en-US/kb/isp-database
You could do the same using the #domain.tld to enable you to match the users email provider with your database.
Microsoft Exchange does offer an automatic configuration endpoint, but I don't think it would prove useful to you as it isn't guaranteed to include SMTP information.
I'm wondering what the best method is for creating a forgot password function on a website. I have seen quite a few out there, here are a few or combination of:
passphrase question / answer (1 or more)
send email with new password
on screen give new password
confirmation through email: must click link to get new password
page requiring user to enter a new password
What combination or additional steps would you add to a forgot password function? I'm wondering about how they request the new password and how they end up getting it.
I'm operating on the principal that the password cannot be retrieved; a new password must be given/generated.
Edit I like what Cory said about not displaying if the username exists, but I'm wondering what to display instead. I'm thinking half the problem is that the user forgot which email address they used, which displaying some sort of "does not exist" message is useful. Any solutions?
I personally would send an email with a link to a short term page that lets them set a new password. Make the page name some kind of UID.
If that does not appeal to you, then sending them a new password and forcing them to change it on first access would do as well.
Option 1 is far easier.
A few important security concerns:
A passphrase question / answer actually lowers security since it typically becomes the weakest link in the process. It's often easier to guess someone's answer than it is a password - particularly if questions aren't carefully chosen.
Assuming emails operate as the username in your system (which is generally recommended for a variety of reasons), the response to a password reset request shouldn't indicate whether a valid account was found. It should simply state that a password request email has been sent to the address provided. Why? A response indicating that an email does/doesn't exist allows a hacker to harvest a list of user accounts by submitting multiple password requests (typically via an HTTP proxy like burp suite) and noting whether the email is found. To protect from login harvesting you must assure no login/auth related functions provide any indication of when a valid user's email has been entered on a login/pass reset form.
For more background, checkout the Web Application Hackers Handbook. It's an excellent read on creating secure authentication models.
EDIT: Regarding the question in your edit - I'd suggest:
"A password request email has been
sent to the address you provided. If
an email doesn't arrive shortly,
please check your spam folder. If no
email arrives, then no account exists
with the email you provided."
There's a trade-off being made here between ease of use and security. You have to balance this based on context - is security important enough to you and your users to justify this inconvenience?
Send email with new password.
FORCE a password change when they arrive and key in the new password.
This ensures that the person who wanted the password will be the only only getting in to the account.
If the email is sniffed, someone could get in to the account (of course), but the real party will discover this immediately (as their password you just sent them doesn't work).
Also send confirmations of password changes to the users.
If someone get the new password, and then an email saying "thanx for changing the password", they're going to be rather puzzled and will talk to an admin if they didn't do it.
Using the email verification/password reset link will give you better security.
If you look around this is how most websites do it and people are pretty used to this verification, so I'd recommend using this type of authentication.
I would think (gbrandt's) Option 2 would be a great method if it is combined with some personal information you already have for the user. i.e date of birth.
When the user requests a new password (reset) via entering his email address, he also has to enter a correct date of birth (or something else) before the password is reset and a new one is emailed to the user.
Only those who know him well can possibly annoy him by resetting his password! It cant be a stranger or a bot
Upon 5 or 7 bad email-address & date of birth combinations the user is emailed that his password has been requested to be reset and has failed due to an incorrect credential. Then password resetting for that account is suspended for 24hrs or any desired period.
(if too many users contact the webadmin regarding this email he'll know someone is trying to maliciously attain information from your website/app)
What do you guys think?
Option 1. is not a good idea, as generally his becomes easily guessable by others. Sarah Palin's personal email (Yahoo I think) was hacked in this way by a third party.
The other options are better and previous posts have outlined the detail.
The idea I was thinking about was to sign the data in the link that is sent to the user. Then, when the user clicks the link and the server receives the call, the server also gets the encrypted part and can validate that the data was untouched.
I have implemented a JAVA project for this use case. It is on GitHub, open source. It answers your question perfectly... implemented in Java.
As for the link in the email - it generates the link, plus validates it upon usage.
There are explanation for everything (and if something is missing - let me know...)
Have a look: https://github.com/OhadR/Authentication-Flows
See a Demo here.
This is the client web-app that uses the auth-flows, with the README with all explanations. it directs you the implementation: https://github.com/OhadR/authentication-flows/tree/master/authentication-flows