Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 2 years ago.
Improve this question
Most of the websites says "username or password is wrong" whenever we typed wrong password.
Why are they not saying "your password is wrong"?
So that if someone is trying to guess a valid username and password they are not told "Yes, you managed to guess a valid username". That may or may not be a useful thing for any given site if usernames are visible in other ways.
Just ignore the security issue of saying "Your password is wrong".
First we can check whether it is possible to say "Your password is wrong".
I posted this question in our college group and I felt one answer from the group is worth positing here.
A website can say that 'your password is wrong' only if the website is
sure that you typed your username correctly. How do the website know
that you typed your username correctly? There is no way to know that.
The authentication failure may occur in three ways:
You may enter correct username but wrong password.
You may enter correct password but wrong username.
You may enter wrong username and password .
The website process it as given below.
a. If the username is not in database, the website can't say that 'Your username is wrong'. Because the website don't know whether the password you entered is your correct password.So the website can say 'Username or password is wrong.' only.
b. If the username is in database, the website can't say that 'Your password is wrong'.
Because the website don't know whether the username you entered is your correct username. So website can say 'Username or password is wrong.' only.
Apart from security, it may also be a 'lazy' design choice too. Why bother checking seperately if the username is wrong or the password is wrong, when you can just write one query and output whether it was success or not, ultimately the user will know themselves if they got one or the other wrong.
It can also be sure laziness or code cleanliness too. Simple example below.
If( password != submittedpw || username != submittedusername)
{
Print 'username and or password is wrong';
}
The above is much quicker to do than
if (password != submittedpw)
{
Print 'password is wrong';
}
elseif (username != submittedusername)
{
print 'username is wrong';
}
Related
I've noticed that when logging in and inputting the wrong username or password, websites usually tend to hide from you which of these pieces of data is wrong. So for instance, instead of saying "Wrong password", they would only say "Wrong username/password".
I understand that their main goal is to disallow the user to try different passwords for a certain username. However, you can find out if a user exists by simply trying to register to the website with it. Thus this scenario would be possible in any case.
So why not tell the user immediately that the password they inputted is wrong? Is it only because it would make is easier to find out if the user exists (and then be able to try to crack the password for it)?
Some clarification on this would be much appreciated.
However, you can find out if a user exists by simply trying to register to the website with it.
Not if done correctly.
Signup:
Step 1: ask for email and password
Step 2: check email and follow directions within
if account with entered email already exists... the email should be something to the effect of "someone has tried to signup to Coolwebsite.com using this email address. If this was you and you have forgotten your password, click here"
If strong passwords are used (enforced), the password is usually harder to guess than the username.
Not knowing which part of the credentials is wrong, makes it much harder to guess both.
But, there are cases where this does not help much. E.g. when the username is equal to the user's e-mail address.
So, the only reason for not telling is to make it harder to guess. But it also is a valuable reason. Even when there is no rule that covers all cases.
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.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
What security benefits password and username provides over just single password as login?
If username must be unique, then other users cannot have that username and user can be mapped to user account with that id. When attacker brute forces against username and password, it same as attacker would brute force against single password. But with single password attacker can try to access all accounts with same password brute forcing.
After you are logged to application, you session is authenticated with single password, which is session id. So attacker could try to login to all accounts by bruteforcing session ids. Of course session ids are usually very long and therefor very hard to bruteforce.
What if application generates automatically password tokens and adds always unique prefix (length of prefix is stored in database) for passwords that what is mapped to specific user. So that password is actually combination of username and password, but user doesn't know that? Will that kind of setup have same security as username and password system?
When thinking about a single password approach I can see a number of possible issues, for instance if you are allowing users to set their own passwords then just having password as login credentials opens up your application to massive security flaws.
The most common scenario is that a user will sign up and use a password such as their name, or some other commonly used insecure password thus making it easy to brute force.
Also consider the fact that as the number of users grows the number of acceptable passwords to access your site also grows which makes it easier for brute force attacks to work. Even with auto generated passwords this is the largest issue I would be concerned with.
Thirdly, I come along and try sign up to your site, I type in my password "Bob1" now what if another user has entered the password "Bob1" ? Do you inform me that password exists? Two users cant log into distinct accounts with the same password.
The main issue here to consider though is that users are used to typing a username and password. I personally wouldnt want to sign up to a website where I just have to type in a password, and most importantly I wouldnt want to use a web site where my password is auto generated and hard to remember.
If you are concerned about security (as you should be) then I suggest enforcing strict password rules (expiry time, length, content) and educating your users about the flaws of insecure passwords. On creation of the password you can check it doesnt match any info the user has entered such as name/ date of birth etc.
Overall I would say username / password combo is better than single password for both security and usability reasons.
Also see http://xkcd.com/936/
If you use only password, then someone could type a word like 'helloworld' and log in to a random account.
Coz there would be someone who is using this password.
There are many who would use familiar phrase as password. Its users convinence.
Such type of loophole dosent exist in username-password combination.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed last year.
Improve this question
Cheers,
We started implementing biometrics authentication in our web system and came to a doubt. We're going to use a third-party solution for performing it which is going to be called via a web service.
There are going to be four kinds of authentication:
Regular one: username/password
Challenge
Fingerprint
Cellphone
All users will be authenticated using 1. Optionally, some of them may also require 2, 3 or 4. What would be a good way of verifying which authentication type is required for a specific user?
This is something new for me. Initially, I thought about passing the username from the login page to a web service, which would query the database to check which authentication type is required for this user. Then, depending on the result, the second authentication form would be shown on the screen. Obviously, some extra check would be performed after the user hit the Submit button.
Am I on the right path, or there are better solutions for this?
Thanks,
I guess that would work. Maybe it is an option to do some sort of query in the background (AJAX?) when the username is filled in, so you can dynamically add extra inputs to your login form.
However, this has one potential issue: everybody that knows someone 's username can find out what authentication is required. If that is not wat you want, maybe just ask for a username + password to login to a reduced privelege mode. Then, as you suggested in your question, this reduced privelege mode may require extra credentials to continue to the more secure environment.
You could even make it so the reduced privelege mode will grant access to some of the features, while others require extra authentication (for example: posting a mesage would require basic auth, changing passwords might require all four).
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