I'm trying to decide what to put in a dialog box that tells the user their login doesn't work, there is probably a duplicate. The system uses email addresses as user names, then requires a password.
Right now, I'm using "Email Login" but that just sounds stupid.
For instance:
1) Application Starts, recognizes that it has never been run.
2) Prompts user to create a new account.
3) User puts in an email address and password to use as their new credentials.
4) Well, looks like they've already got an account probably. (This is the most likely case the account creation would fail but I'm using an API and I can't be 100% this is why it failed)
5) I ask them to try again with a different "email login".
Could not create account - try a different email login !
After I check with the API provider, I'll probably try to detect that it is in fact a duplicate account and ask them to try to authenticate that account with a password.
Tell them explicitly that their email address is already in use.
Call it an email address, thats what the user thinks of it as. The fact that you are using it as an id or a database primary key or a hash key is irrelevant to them.
Perhaps: An account already exists for this email address. If you already have an account but forgot your password, please click [here], otherwise please choose a different email address.
I agree with mgb that the best choice is to explain the problem and how the user should proceed.
I would just call it what it is: an email address. I wouldn't suggest that they try a different one, though. Just ask them if they already have an account and, if so, to try logging in with the address/password. If they continue to have problems, give them a contact that they can use to get help.
There is a distinction between the process of authenticating ie logging-on/login and the options a user can use ie. username, userid or email address.
As more websites are having allowing users to login with email address it doesn't pay to be ambiguous, do your users a favour and label the field 'Email Address:'. This way your users are clear on what is expected in the field. If you label it "login:" or something else vague they'll be subtly fooled into thinking they might have created a username when creating their account and try all the usernames they usually use before trying email addresses.
Related
I want to let user to reset password in case he/she forgot his/her password without sending reset code to his/her mail box. Actually I don't want to use emailing reset password system.
Is there any way to let user reset his/her password without using email in secure way?
Is 'security question' using safe?
Or what is safe to use?
The safety of the secure question will depend on the difficulty of the question itself. If you don't want to use the mail() function then you can try either of the following:
You can send an OTP to his registered phone number.
You can use more than 1 secure question to identify the user and then allow him to reset the password. But make sure that the standard of the question is high.
For eg., avoid easy questions like name of your first school, name of the birthplace, etc. These questions can easily be answered by any other person close to the user.
Try questions like- What is the name of the city where you got lost?, What is the name of the teacher who gave you your first A?, etc.
This will be safe as well as help you avoid mail() function.
Safety can be improved with
OTP on mobile.
asking user to validate their personal information like:
email address,
last name,
date Of Birth,
last 4 digits of social security Number. etc..
two layer Reset. send two different codes to (primary and secondary/mail and mobile) and verify both of them.
if you have users registered mobile number. You can use One time password to authenticate users identity before letting him reset the password.
I am very curious to know some of the points regarding registration and login related points as a developer points of view. Please see below the steps for any online account which is publicly open for all,
CREATE USER ACCOUNT : Insert the data entered by user along with a column activate which default value is 0
SEND A LINK TO ACTIVATE : a link has been sent to user email at the time of registration
ACTIVATE THE ACCOUNT : user clicks over the link and the link is verified and update the column 'activate' with value 1
Why to sent a link & verifying is necessary which I supposed that is not utmost required. I asked to clients why u want such verification and i get the answer almost same e.g. checking the authenticity of the user and it'd be helpful to stop the duplicity of the user.
but practically at the time of user login, i suppose it is useless to verify each time the activate column along with password for every user.
I would appreciate if u explain the points which is very important regarding my concern.
This is really a slippery slope, but there are reasons. Obviously spam users will try to create accounts as quickly as possible, for spam reasons. Email and captcha verification will handle this.
Another is the issue of clumsy or accident-prone users that will forget their passwords, which can be worked around by email reminders/resets. Sadly, users may try to add fake email addresses(or mistyped ones) and lose access to their accounts, requiring admin intervention. Simple verification can force users to get their account into a self-rescuable state before adding any data.
I'm wondering what the best behavior is when a user requests a password reset for an email that doesn't exist.
Context: user is not logged in. They just enter an email and hit a reset button.
If I tell the user requesting the reset immediately that the account doesn't exist, that's both a bit of security hole and a privacy issue.
If I do nothing and it's an innocent mistake (they thought they had an account), they'll be wondering what the heck happened. Most mysterious option, least subject to abuse.
I can send an email that says a password reset has been requested but there's no account (and should be ignored blah blah blah). This seems the least noxious but it is a little subject to abuse.
Update: On further consideration, I don't really so how 1 is a big deal since they can get the same information by simply trying to sign up/use the same email ... unless I'm missing something ...
I personally would go this way:
User enters e-mail address.
Screen says "request will be processed, e-mail has been send" or something along those lines.
If there is no account linked with this e-mail address: don't send a mail, but don't tell the guy requesting.
If there is an account linked with this e-mail: send the reset e-mail including the usual "if this wasn't you simply ignore this mail, if you suspect abuse please contact $foobar"-message.
Here is why i would NOT tell anyone whether an account is linked with this e-mail address: Privacy. If you told everyone, everyone could check if $person is using $service.
Figured i would include why i wouldn't send a mail if there was no such user: Why should i? The user will probably either know which email address he used or try several at once (or only wait a short time span). Of course there are cases in which it would be a bit more userfriendly if one would send those mails, but they aren't important enough to negate the abuse potential.
There is not much abuse potential if only one website does that stuff (as long as they wouldn't send multiple mails in a short timespan), but imagine every webservice going this way. You would just have to collect a few of those services and then emailbomb someone 'you' dislike, without hitting any spamfilter!
Personally, i'm a fan of:
The user enters an email.
Whether or not the email exists, say that it has been requested, and if you do not receive an email shortly, try again or contact us.
In the email, state a password request was submitted, and if it wasn't the user, then to ignore the email.
Also,
If you're worried about bots scraping your site for emails, add a Captcha.
If you're worried about people hacking accounts, add a second layer that prompts for a secret question answer.
In my opinion the third option is the best compromise between user-friendlyness and security. Option 1 seems to be to big of a privacy issue. Using option 2 the user can not know if he has an account, but registered with another email address or if the reset system doesn't work.
I would do something like this
Ask for the username or email
If that email or username is present, send all the email to the person, with the reset password.
Finished :)
For a website, I would like users to be able to log in using either their unique username or their email address.
However, this site will potentially allow multiple user accounts with the same email address. (For instance, they may be the same person working for two different companies, etc. Also, for business reasons, each user account is associated with only one company. So if users work for more than one company, they have one login for each one.)
Here are some possible ways to handle this when the user logs in with an email address:
If more than one account matches the email address, AND the password (hashed of course) matches at least one of the passwords for an account with this address, then do one of the following:
A. Tell the user that their email address is associated with more than one account, so they will need to log in using their username instead.
or
B. Same as A, however if the password matches exactly one of the account's passwords, just accept it and log in as that account.
I would like to go with B. However, using the password to differentiate between two accounts seems like it might have some obvious security pitfalls (that I may be overlooking), or even some non-obvious ones.
Would this be a good solution, or is there a widely accepted "best practice" for this?
The best practice for this is to have one account. Your database would contain records indicating which users have access/membership in which companies.
Most sites use the email address + single password as the primary identifier. People are used to it and it works. Go with that.
If people want other information associated with their login, such as other accounts, they can certainly share a login and then select which account to use after login. It's not part of the login, but it is associated with it.
Setting up multiple logins can lead to trouble as it requires more management, and it increases the likelihood of people being lazy about keeping their password secure. When you need to change your password, what then? Change them all? KISS = keep it simple, stupid.
You could allow single sign it to point to a "select your account" page on which the user decides which alias they wish to use for the current session.
If you go with "B", what happens if the user chooses the same password for both accounts? How will you choose which account to login to automatically and how will the user ever be able to login into the second account? Messy.
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