I have a simple web application set up where admins can create users. Users do not create themselves. All an admin has to do is enter a username and an e-mail and a temporary password is sent to the user for them to login. This e-mail is sent in plain text format. If the user is logging on for the first time, they are required to change their password and enter a security question and answer. The user obviously has to know their temporary password in order to login for the first time and this is the only way I know of letting them know (through e-mail). The other option would be to have the admin call the user and tell them over the phone or in person their temporary password, but this is not practical. How could I handle a situation like this?
I typically use a temporary url based on an invite record on the back end. Essentially you create an invite record and generate a hash based on some information perhaps the users email address, a timestamp and a random value. Store the hash as part of the invite record and then send them a url with the hash as the parameter.
When they click the link lookup the invite and validate that it exists and has not been used - then allow them to setup their password and invalidate the invite.
It gets rid of the need to send any sort of password and you can set an expiry on your invite records if you want as well.
The scenario you describe is very common- emailing a temporary password and requiring it to be changed on first login. Unless you have a specific problem with this model I see no reason not to use it. Having an admin call users can get complicated- I would avoid this at all costs.
You can generate a custom url with a password and user hash as argument where the user has to log itself. The hash will be difficult to retrieve if the attacker does not have the information
Related
Lots of questions about email verification here on SO, but none seem to cover my scenario.
We would like to add users ourselves after an intake meeting. Our representative has a form to enter some details like company name, VAT number, contact data (which contains an email field), ... This data is saved in Firestore.
After this, an email is sent to the supplied email address which contains a link that takes the user to a form where his/her email address is displayed with a password and a password confirmation input field. When submitting this field, the user is created.
But now the user receives an email asking to confirm their email address. I assume, for security and privacy reasons, there's no way I can set the user's email address as verified.
I've looked at customizing the verification email, but that doesn't seem to solve my problem.
Creating the user with a random password after the intake meeting also doesn't seem to be a solution, as the user still has to verify and then reset the password in 2 steps. Or can I somehow redirect after the email verification to the 'set password' page? That would be an acceptable solution.
Is there any way to achieve the desired flow described above?
As a general workflow, you could achieve this using a Cloud Function along with either database system. You can also make use of App Check to further secure this process.
Representative adds base user information in their portal. Store the data securely in the database of your choice.
Send the user an invite email containing a short-lived verification token linked with the email added by the representative (this could be generated and fired off using an onCreate Cloud Function once the invitee's data is added to the database). This token should follow some standard like JWT so you can deserialize the contained email address or be exchangeable for the underlying email address.
When user clicks/copies the link to their browser, present them with an input form asking for the desired email and password. Note: the email field should be editable! The rep may have used an email the new user doesn't want to use with your platform.
If the token is still valid and not consumed, continue with the next steps.
If the token has expired and not consumed, send another email to reconfirm their email and restart this step.
If the token is already consumed, show an error and don't continue.
Submit the email, password and emailed token to your backend via a Callable Cloud Function.
Sign the user in using the authentication token returned by the function on success. Show an error otherwise.
In the callable function for creating the user:
Confirm the request comes from your app (if using App Check)
Confirm the validity of the emailed token
Pull the data the representative entered from the database linked with the emailed token's original email address.
Using that data, the updated email, the new password, and emailVerified=true, call the createUser API.
Using the User ID from the returned UserRecord, create the user's profile data in the database and also create a Custom Authentication Token.
Once their data has been created and the token generated, return the authentication token as the result of the request.
I have a list of people with all their personal information (name, first name, date of birth, email, etc.). I created an account for each of these people in my database. I'm using Firebase.
Since I already have all my user's info, I don't want them to type it again when signing up to my website.
So I created a system using a custom token for authentication. I send them as a parameter of an URL to every one of my users.
When the user clicks on the link for the first time: he gets redirected to the signup page with all the fields pre-filled (name, date of birth, email, etc) except for the password. He types the password he wants and gets signed up.
When the user clicks on the link every other time: he gets redirected to the login page. A simple email + password interface with the email field already pre-filled. He types his password and gets logged in.
This is working great BUT I'm wondering: is this bad practice to do so?
Is this insecure to let anyone who gets the email create an account in the name of my user? Should I assume that someone, other than my user, may have total access to my user email account? Should I be prepared for this eventuality?
Since I already have all my user's info, I don't want them to type it again when signing up to my website.
If you already have the user's information, and you are allowed to process it, then it's a good practice to not let the user do something that it's already done.
is this bad practice to do so?
Not at all. That seems to me like a practice that is present almost everywhere. If you want to edit the profile data, you always have the existing data already pre-filled. The user has just to verify it or change it if needed.
Is this insecure to let anyone who gets the email create an account in the name of my user?
That sounds not like the best option if someone else can use that URL and create an account on behalf of the user. Most likely you should consider letting the user create the account only if it can validate the data through an SMS, or any other service that is specific to that user in particular.
Should I assume that someone, other than my user, may have total access to my user email account? Should I be prepared for this eventuality?
Yes indeed. You should always prepare for that. Never trust the users. There's not a perfect world out there.
I need to add some authorization/authentication logic to an existing web form. Essentially, a user will enter their email address, then I check that email address against an existing database, and if it exists I send an email to that address containing an activation link to the web application. Once the user clicks that link, I want their client to be considered "authorized" for a short amount of time (like their browser session, for instance). They can then access certain pages until their authentication expires.
This would be extremely easy to do using custom ASP.NET forms authentication, but after doing some research there seems to be many more options today in terms of authorization/authentication. Things like ASP.NET Identity 2, Katana/OWIN, and more, it is getting to be quite overwhelming.
I'm looking for suggestions on the simplest way to currently implement something like this in an MVC4 application. I should be able to upgrade the application to MVC5 if necessary.
This is essentially the same process most password resets use, so you can pretty much approach it the same way:
Create a table to track these "authentications". You pretty much just need a column for the token, a column for a datetime, a column for a boolean. The datetime can either track the creation date and time of the token, which you'd then use in your code to calculate if it's too old based on your desired time frame, or you can track the expire date and time of the token and then simply check in your code if that expire date has passed or not. The boolean would track whether the email address has been confirmed, via having followed the link with token in the email you send out.
In your initial form, you collect the email address and combine this with a salt and one-way encryption to produce a token. You send the email with a link that includes that token. Save the token and the appropriate datetime value in your table.
On the page the user goes to after clicking the link, you use the token from the URL to lookup the matching row in your table, check the date value, and set the boolean to true for confirmed. Then, store the token in Session.
On each subsequent request, check 1) there's a token in Session and 2) that that token is still valid (lookup it up in the database and check the datetime and confirmed status). If the token doesn't exist or is no longer good, delete the row, remove the token from Session, and redirect the user to the original email address collection form. Otherwise, allow the user to view whatever content is there.
The simplest way, is to have a database table for the users, and do checking for user authentication and if it's use FormsAuthentication.RedirectFromLoginPage, The identity framework gives you more options for security and encryption also for group and role management.
http://msdn.microsoft.com/en-us/library/ka5ffkce(v=vs.110).aspx
A customer of ours complained about login password recovery using plain text password. The only workaround I know is auto-login with encripted username and passord in the query string.
What other options exist to increase the password recovery security?
Thanks.
You can send them a URL that lets them reset the password themselves.
You could create a database table that stores, at the very minimum, a user id and a hash value.
Send the user a link that includes the hash, and on the receiving page look up the associated information and allow the user to reset the password to the account. Which I'm hoping you store in the database as a hash value. Plain text passwords should never be stored or sent out.
Just be sure that the link either expires or is deactivated once the password is changed. Otherwise someone could visit that link whenever they want and change the password.
Along the same lines as Brandon's excellent answer, here is what we do:
Do not store passwords in plain text, or even a decryptable value. Always store passwords using a 1-way hashing algorithm. This means only the user can ever know what the plain-text password is.
When a user forgets their password, present them with a form where they enter their email address, and click submit.
When they submit their email address, create a table row with 2 major pieces: The first is a password reset token (we use a Guid for this). The token should be timestamped, so that you know when it was created, and when it expires (ours expire within 2 hours of submission). The second piece is a secret code that the user will have to enter in order to reset their password.
Send an email to the user, with a link to a page that will accept the token and secret code. When they click the link (or visit the page and enter the code manually), you can then present them with a page that lets them change their password without knowing its previous value.
Using a time-constrained token is a good idea, because if the user's email account is later compromised, the criminals can't use the email to reset the password -- assuming of course that the email account is not compromised within 2 hours of the password reset request.
I wouldn't send out the actual password of the account in plain text to the user's email address. The reason for this is because if someone hacked the users email address now they have their actual password. Most likely this password will be used for other systems as well.
The alternative is to send an encrypted querystring that links to that user and allow them to change their password based on some sort of security question or demographics you have specific to that user.
Facebook uses a matching of friends images to names. If you have their DOB and address you could use that (not that secure). Or you could set up specific security question and answers which would be better.
I just wanted to ask the procedure of email verification, whats the best method. So far i have a class that stores the information from the register.aspx form, then i send out an email to the user, but what should i send him, should i send the user a guid?.
Also my membership class that stores the register data is stored in a session, is this a good idea, becuase if the user session times out then the membership class will be nothing and the user will be prompted to register again in a Session Timeout webpage, is this a good method?
But what if i send the user a guid and then store the user data to the database with the guid and then check the email guid with the corresponding user guid in the database, what should i do?
Also i have a Regular expression that checks that the email is valid, its not that good yet and i havent tested it properly, is there free email verification api's out there?
I am using ASP.NET VB.
Here is what I would do:
1) Ask for user's email
2) Validate the email using Regex
3) If valid, create a Timestamp (DateTime.Now), append with user's Id and any other useful information that I need. We can use some appropriate delimiters.
4) Encrypt the data and build a URL with the encrypted token and email to user
5) When user clicks, decrypt the information, check the timestamp (perhaps there is a timeout required) and use user's Id to get its data from database.
This is in addition to the already accepted answer - I wouldn't limit the email validation to checking the Regex syntax only.
There's a free email verification API I've been using that checks a number of factors, including syntax, typos, SMTP & MX-Records (which verifies the actual existence of the email address), if its a free or disposable email, etc.
They're offering a thousand monthly requests for free - mailboxlayer.com
Save the data to the database, including the GUID. Set the status of the record to "inactive". Send the email, with a link back that includes the GUID. When the link is clicked, set the registration record to "active". Only "active" records can log in.
You can't effectively validate an email address with a regexp - search this site for explanations of why.
In .Net you should validate email addresses like this. See this question for details.
MailAddress address = new MailAddress(input)
This throws an exception if the email address is invalid.