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.
Related
I am trying to find the best practices for forgot password functionality via sending a link to reset password i.e. sending an email with a one time token to the registered user. The token will be stored in the database and when the user clicks the link, we check the token and allow the user to set a new password.
Best practices while designing forgot password function -
The token must be unpredictable, that's accomplished best with a
"really" random code which is not based upon a timestamp or values
like the user-id.
Like a password, the token should be hashed, before storing it in
the database. This makes them useless for an attacker, even if the
database is stolen.
The reset-link should preferably be short to avoid problems with
email clients, and contain only safe characters 0-9 A-Z a-z
(base62 encoded)
The token should have an expiration time within single-digit hours.
The token should be marked as used,after the user has
successfully set a new password.
When a user changes their password or requests another password
reset, expire all tokens already associated with their account.
These are some of the points I found. What can be other security issues that should be considered ?
Sources:
Secure password-reset function
Ycombinator News
A couple other practices I've seen:
Check user is on the same machine/browser/IP as the one where the reset password request was triggered (unless it was initiated by admin/system).
Rate-limit number of reset tokens that can be generated for an account.
It should also be noted that the best practice is usually to use an established library rather than inventing your own mechanism, as too many things can be overlooked.
I have the same question and found the OWASP Forgot Password Cheat Sheet.
Also few things that I would like to add:
Usually if user entered non existing email sites anyway shows message "pwd restoration link was sent". This is due to prevent hackers from determining that user with the email exists in system. But IMHO it's better to say user that email is not exists because usually it may not remember email used during registration.
It is better to add some additional personal question to user like a birthday date. If hacker stole user's email it makes harder to receive reset link. But since reset link may be sent to user by site admin the question with birthday must be on change password page which is opened by link.
Hackers may automatically send a lot of letters to some user. Some sites uses a CAPTCHA near email field to prevent this.
After successful changing of password all active sessions should be closed and user must be logged out. Thus even if hacker is logged in he will logged out.
It is a good idea to hash a restoration ticket like a password. Here should be used the same hashing algorithms like with password: Argon2, SCrypt, BCrypt.
After user restoration password it is good to mark it a possible fraud and for some time (like a week) do not allow to make some critical actions, like withdrawal money from account.
Also some sites are sending a letter to user that it's password was changed. They do this when user was logged normally changed it manually but maybe it is good to send the same latter when pwd was reseted.
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.
My question is almost the same as this one
only difference is that users has an option to register (provides his username and password).Users should only have one account registered, if the user has the same email I merged those accounts. and my application has another method for logging in which is via Facebook.
What I basically do is
When The User visits the for site for the first time, he or she then
gets created a User Account where the it only has Username ,password
and mail address after that third-party identity record is created
and then paired with the local account.however the Users table will
have an empty Username and password, but the email will be filled
with the users email that we have retrieved from the third party
service provider
And the Second Scenario
Users attempts Register to the site. check if email exist if the
email exist but it is registered using a third party account, Use
the user populated form and insert it to the user account paired
with the third party account, in short if the users email exist in the database I
will just merged the locally created account and the third party
account.
Now my question is my approach secure and credible? if not what is the best way to merge accounts and at the same time if the user registers with the same email(the one from the third party account) and he has a third party account, those account would be merge?
The way I look at this, there is only one account. One email, one account period. There might be various attributes associated with that account, like for e.g. linked to a set of OAuth credentials etc. But fundamentally there is only one account. If your user has registered once using a social account and then try to register again on your site, send them over to the social site which they used to register the first time and ask them to login there. Then log them into your site automatically. If the user has an account with your site and then tries to register again with a social account, tell them that you already have an account on the site and ask them to login. IMHO, keeping separate accounts and trying to merge them is a messy idea.
I would provide two sets of behavior, one when logged in and one when logged out.
When logged in, you provide the ability to link to new third-party accounts. For example, you sign up with email address and password, then log in, then you can link your Facebook account. To link your Facebook account you authorize with Facebook and then store the Facebook information in that user account record.
When logged out, you must log in with existing credentials. If, when logged out, you try to create an account with an existing email address, you either prevent the log in, saying "an account with that email address already exists", or you immediately challenge the user to log in to merge the account (in which case it works like the logged in case when linking an external account, only with the order of authentication operations reversed).
In case it's not clear from the above, I recommend having a single user account and a way to record linkages between that account and external accounts. You can do this in NoSQL buy just adding fields to the user document or you can do this relationally by having a table representing external accounts with a foreign key linking them to the user ID.
Beware not to use oAuth 2.0 !
The lead author himself resigned as it's not as safe as the 1.0 version.
You should prefer oAuth 1.0 or OpenID.
You can also have a look at Persona from Mozilla
Currently on my website, users login with their login id and password, they are also required to enter their email when they register. Both login_id and email column on the users table have unique index. users table also stores other data associated with the user such as gender,last_name,first_name but these are optional (nullable) fields.
There are two changes I would like to make to the website.
The first one is, users can use their email (in addition to login_id) to login. For new users, when they register, they no longer need to provide a login_id because they will be using their email to login.
The second change is, they can login with facebook. For new users, if they login with facebook for the first time, their facebook uid will be obtained and stored in my database. This means I will have to add a facebook_uid column on the users table.
For existing users, when they login with facebook for the first time, I should first obtain their email address from their facebook profile and then check if there already exists a record using that email in the users table, if yes, their facebook uid will also be stored on the facebook_uid column on that record.
According to facebook, its platform supports two different OAuth 2.0 flows for user login: server-side flow and client-side flow. Which one or both is required for this use case?
Also, what problems can be anticipated when I implement the features like I describe above?
You could take either approach for this, it's entirely up to you. Both methods will give you the data you need, it's a question of how comfortable you are working on the back vs front end. You just need to ask for permission to access to the user's email address.
Problems that could happen: I'm not sure but there may be legal restrictions on storing the user's Facebook ID. Also, what if someone (not me, an evil person!) registers with my email address and you don't validate that they really have access to that address - then when I log in via Facebook, the app will assume we're the same person and the evil hacker now has access to my account. Unlikely scenario but could happen...
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.