I am creating user registration page with email activation link in Laravel 5.1.
I send activation link to entered correct email address. How to find activation
link is click from correct email address where I send mail
To give you an idea how this could work:
When user registers generate a per user unique token for the new user (e.g. 60be22f4-e849-4676-b64b-c3493e8709e0)
Save this unique token in your database along with the user name and password
Send this unique token along with your activation email (e.g. as a link: http://my-domain.com/user/confirm/60be22f4-e849-4676-b64b-c3493e8709e0)
When a user clicks this link search for the unique id in your user table and mark this user as active/confirmed.
There's a pretty simple way of doing this:
Store a 'secret' for each user in your database, this should be generated on the first creation and shouldn't change for the life of the user in the system. Secret could be a simple string like 'ajchdu8'
Set up an activation route that contains the user ID and their 'activation signature' like so http://yourdomain.com/activate/{user_id}/{signature}
Create a mechanism for generating and comparing those signatures and use the secret for each user as a way of making user only that user can activate their account (or who ever you give the URL to anyways)
The signature is basically just a hash of things that we know about the user but doesn't change in the database so it could just be a hash of user id and their secret then by providing the user id in the link you can look up in the database the user by the id to get their secret and any other details you require to verify the signature.
Related
I would like to use Stitch to sign up users. Each user must have a unqiue email and a unique user-name.
This is important for applications like chats or forums, where users should not be forced to reveal their email when communicating.
I already implemented login with email and password as described here: https://docs.mongodb.com/stitch/authentication/userpass/#authenticate-a-user
The problem is:
How to securely save a user-name on signup? I could store a users desired name in a collection and merge it into his custom user data after initial login. In order to do that, I would need to grant the user write privileges to whichever collection holds pending names. This is unsafe, since he could now change the name after the fact or even change other peoples names while they are pending.
The user needs to choose his name at the time of signup. At this time the user is still logged in via anonymous credentials. Hence, I can not restrict users to changing only their own data since they are at this point sill anonymous. I see no way of linking a users data to his future account at the time of signup. Any idea to change that?
It would seem strange, if stitch lacked the functionalities to easily sign up users with a unique name/handle in addition to email address.
I haven't used your exact software but in general I would approach the problem as follows:
When someone starts using the application anonymously, create a user object. The user at this point does not have a reserved (i.e. globally unique) user name, or email address, etc. But the user still has an internal identifier.
Associate user-visible state with the user object. This could be done through server-side sessions or signed cookies. (Unlike unsigned cookies, cryptographically signed cookies permit server to store what would otherwise have to be stored in the server-side session in a cookie, and trust that the client hasn't tampered with the information by e.g. changing the user id).
When user registers, set the user name, email address, etc. on the existing user object. User id remains the same and allows the user to continue to have access to their anonymously-generated data.
Have a process for deleting anonymous users that don't register after some time.
I am doing a web application using Eclipse EE. I have a module which is supposed to reset user passwords and sends the user (via email) a link to a page where they can reset the password. Any insights please?
The main steps would be:
Provide a "forgot password" page where the user can enter her email address
look up the entered address but don't tell the user any details. Don't output a message like "email address not found" as it would allow a malicious user to look up valid email addresses. Better give them a message like "you'll receive a link to reset your password if the entered email address is registered".
Create a strong unique random identifier to associate it to that reset-request. E.g. use a cryptographically RNG provided by the framework and combine it with something unique like e.g. a GUID.
Store that unique identifier along with that reset-request in e.g. a table in your database and put a timestamp to that record. That's important as you'd want the user to be only able to reset her password within a fixed time frame.
Send an email with that unique identifier put as a query parameter in a link to your application. E.g. https://yourapp.com/pwreset/?requestID=7392af1747ce3781
Fetech the requestID parameter at your pwreset-controller and look it up in your database. If the request comes in within a reasonable time frame based on the initial request timestamp, then let the user reset her password.
Delete successful request-records from your database, so that a sent pw reset link can only be used once. And periodically delete expired records.
Use this as a starting point. As I'm no crypto expert, you may one have a look at this approach ;)
As far as I know, on the new Facebook API, there is no way to get the Facebook username. Also, if the user registered to Facebook, his or her account might lack an email address if he or she logged in with a phone number.
However, I am working on a project, where, upon login with Facebook, if the user does not have a user, then the Facebook login is interpreted as a registration. Since, according to my best knowledge, there is no way to get the Facebook username using the API, I am using the email field to generate a username, taking into account only letters.
However, in some cases, the username generated this way is duplicated, or the Facebook account does not have an email address. The best solution I can think about is to redirect the user to a form where he or she can enter the email and/or the username, but that would not help the user-experience.
Is there a way to gather these data without making the user enter them? Or something close to it?
First of all, you should always present the data you want to store to the user BEFORE you store it, and let him change it.
That being said, the (App Scoped) ID is the only thing that is really unique, you can either use the email directly (if the user is already registered, just add the Facebook ID to your database) and present an input field if there is no email - or generate a username with his first and last name. Present the chosen username to the user and let him change it, or tell him that it already exists.
After all, wouldn´t a user WANT to choose his username?
If you want to make it smooth for the user and don´t want to bug him in anyway, you can just store his Facebook ID. Or just use the email directly as username (including the # sign and the domain), as i wrote above. If that´s not good enough, you need to implement your own routine to auto-generate usernames. There´s no general logic from Facebook to do this.
As far as I can think, there are two reasonable ways to reset a user's forgotten password.
Have the user enter their email address and a new plaintext password is sent to their email address.
A link is sent to their email address which has a UID number in the URL. Clicking on this takes the user to a form on the website where they can choose there own new password.
Which method is preferable and why?
If method 1 is used, perhaps a third party could read the email and obtain the new password.
If method 2 is used, what is to stop someone methodically going through UID codes to try and access the form to change a user's password?
The best pattern would be :
User requests password reset. Best is to do it through username, and
don't indicate if the username exists or not (to avoid possible
users listing through a script)
You generate a record in a new database table with userid, datetime
of request (= current datetime), and a GUID you just generated
You send a mail to the user, pointing to password reset page with
the GUID (not the userid) as parameter
On this page, you should check that the GUID is existing, and
eventually you could put some expiration date (=the user has 1 day
to reset, for example)
Don't forget to mark the record as "used" (with an extra field in
the table) when the user reset his password, so that you can stop an
eventual second try...
It could possibly even more secure, but that is already quite good I think....
OWASP has a good checklist of https://www.owasp.org/index.php/Forgot_Password_Cheat_Sheet
Here is a quick summary of steps:
Gather Identity Data or Security Questions
Verify Security Questions
Send a Token Over a Side-Channel
Allow user to change password
Verify if the sender is the real user by asking verification questions.
Do not send password on the personal email that is not on the planate employees list.
Do not add the word "password" to the title or body of the email.
Make sure to send separately the username and password.
For Office 365 user, direct them to the forgot my password area or send this link https://passwordreset.microsoftonline.com
Don't get intimidated by the user, escalate to IT manager if the need arises.
Many sites implement different methods and I am having a hard time deciding on which method would work best for my site.
My user profiles contain the following data:
username
password (in hash/digest form)
email
I'd like the password reset method to be secure, user-friendly, and efficient.
You should add two fields, reset_code and reset_expiry
This is the process for a secure password reset functionality.
User selects "Forgot password".
User prompted for email/username.
If valid, generates a GUID, and stores it in reset_code and also stores Now()+24 hours in reset_expiry in the database against that particular user.
Then it sends an email to the email address with a link to confirm the password reset. This email would contain a link to your website with the user's username AND reset_code embedded. (This stops a malicious user resetting a third parties password just by knowing their email)
Once the user clicks on the link in the email, they will be directed to your website.
Your website will validate that: the username and reset_code matches, and the current time hasn't exceeded the reset_expiry time.
If all is okay, we can complete the password reset. This can be done by either:
a) Onscreen a new randomly generated password
b) A new randomly generated password via email
c) The ability to enter a password of his/her own choosing
You should not store the passwords of your users, not even in encrypted form. You should only store the hash/digest necessary for authentication. Then, you can't "recover" the password (because you don't know it), you can just reset it, and/or give the user a temporary one-time password that allows him to set a new password.
Update: if you are doing the above, the standard procedure is to have a "require-password-reset" form. The user enters his id (typically his email) and a "token" (eg, a random string) is generated, stored in some table with some expiration date, and sent to his email along with a link to the "password-reset" form. In this form the token is checked, the user is allowed to enter a new password, and instructed to attempt a new login.
Update 2: A small privacy issue might arise: What should we do if the user id (email, user name, or whatever) entered in the request form does not exist in our database? To output a message "User does not exist. Check the id and retry." may be ok, but in some cases it would cause a privacy problem: anyone can check if other someone is registered in your database! If you want to avoid that, you must output the same message ("a mail has been sent with instructions...") even if the user wasnt found (and hence a mail was not actually sent).
Similar privacy issues advise to just output the message "login incorrect : bad user or password" when the user tries to login unsuccessfully - don't disclose if it was an incorrect user or password.
I agree with Leonbloy. Storing the password leads to trouble like the Gawker incident from a few weeks ago (1.5 million userid/pwd combinations were discovered and published).
You should, however, have a "reset password" function that e-mails the new password to the original e-mail address used to open the account.
There should be no provision for changing the e-mail address during the password reset. If the user doesn't have access to the old e-mail account anymore, too bad. Abandon the account and start over.
And use a good Captcha on the reset screen.