No code question, but rather an application design question. If a user attempts to log in to a web application and provides an unknown username (or email) it seems to be common practice to report back "Unknown username/password combination" or something thereabouts. I.E. it is ambiguous about whether the user got their name or their password wrong.
For "forgot password" pages, it is common to see a request for an email address which the user can use to reset their password. If the user again types in an unknown email address, is it better to show a success page, potentially confusing a user, or show an error page, potentially revealing the fact that the user has signed up for the application. It feels like a privacy concern if I show the error message, but a very small one.
I was personally just affected by this on my development server when I had forgotten that I had recently reset my database. I couldn't figure out why my reset password email wasn't coming through. It wasn't until I finally did a select * on my user table that I realized that I wasn't technically even signed up.
Related
I'm starting to size up a project where I feel security needs strike a little closer to home. What tools and techniques could I look at to attempt to raise an alarm when a valid login is used, but the owner of the login has given it away or had it stolen. I would prefer ASP.NET, then MVC 3, oriented stuff.
This is not a silver bullet, but perhaps you should consider employing some kind of two-factor authentication. For example: when a user creates an account with you, you require that she provide you with a phone number where she can receive text messages as part of the registration process. Then, when she attempts to log in, you text her a temporary authentication code to be used in combination with her username and password.
This ads an extra layer of security to the system, because an attacker would have to both know her username and password and have physical access to her cell phone in order to compromise her account.
I hope that's helpful.
Seems like you would get a lot of false positives... but you might try checking what IP address the login is coming from. Most people will log in from the same IP address most of the time, so when that changes, it's at least a warning sign. If you want to be very strict about security, you could maintain a whitelist (for each account) and require that they get their IP address added to the whitelist before logging in.
My bank (Chase) does this by checking a secure cookie during my username/password login. If the cookie is missing or corrupted, they require a second form of authentication, which is either a code sent via text to my phone number on file or via email to my email address on file. Once the second form of authentication is complete, they set the secure cookie and then I can login from that browser with only username and password.
Implement your own Membership provider and add field locked to model,
check for user being locked on login and do some actions
It might be useful to think of the factors of the Authentication process, so that you can be sure that you are sufficiently covering things. You can easily get ridiculous with the layers of assurances, but I happen to find that most banks now have a variation on a simple model. All of this is, of course, over SSL
User submits account name. Additionally, you can require a secondary piece of information, last 4 of account number or year part of date of birth.
Optional, but a good idea: present the user with a counter sign, that is something that verifies the identity of the server. The user selects this at registration and should be looking for this every time they attempt to log in. This aids in preventing phishing.
System checks to see if the current system using IP lookup or cookie is associated with the account. If not, presents challenge question along with password input. Otherwise, presents just the password input.
Complicated, but can actually be done in 2 pages and more secure than is usually required.
I've presented this workflow to a few bank clients and they usually remove one or two of the checks for a balance of user friendliness.
With phones with text capabilities being so common, the idea of SMS verification code as mentioned by others is also a good idea, though I haven't implemented this in a system yet, personally.
I'm using asp.net's built-in membership provider with security question-and-answer enabled for password recovery against a SQL Server 2005 db. For some users, this works fine and they're able to receive their passwords. For others, and it's not clear what separates the two groups, the security answer is never properly processed. It doesn't matter if the answer is correct or incorrect, the page merely reloads without confirming or denying the request.
As for events, VerifyingAnswer is being triggered, but not AnswerLookupError (if answer is incorrect) or SendingMail (if answer is correct). I ran a SQL trace during one instance, and the aspnet_Membership_GetUserByName stored procedure is being called, but nothing else gets called after. I would expect that aspnet_Membership_GetPassword would be called, which passes the security answer as a parameter, but it isn't.
Update: I was able to resolve the issue. In my case, I am catching the events and using email addresses from another source (ie. not the membership database) tied to the user making the request. The problem is that the PasswordRecovery control chokes if there is not an email address in the corresponding asp.net membership record, even though I'm not relying on it being there.
I think the reason I didn't realize this before is because I would've expected that requirement to trigger an issue immediately after entering the user name instead of additionally prompting the user to answer the security question. I fixed the issue by sticking an email address in every membership record.
net website, i would like to implement forget password. I am using following steps
Form having input box for login Id and email Id and CAPTCHA
when user enter details and submit, at backend after validation new password is generated and replaced old password at database.
New passowrd is send to user at email.
Please help me whether i am doing right or not?
Is there any other secure mechanism for the same?
[EDIT]
Thanks, i got your reply. Really this is a secure mechanism. But here i have few doubt
What message should i shown to user when he enter loginId and email address at forgotten password page?
Whether message would be same for valid user and mallicious user?
Advantage of using CSRF token? Any help / link
When user click on link then what should i do; because as i guess user should automatically loggin into their account -then after that i have 2 choice (first) send new password automatically to user (second) new form will shown to user where user will enetr old password and new password twice?
Please help?
I can see why you'd want a CAPTCHA, but I'd take a different approach.
When a password reset is requested check that a reset has not already been requested for that account within the last X minutes. If a password has already been requested ignore the reset request.
Check the IP requesting the password reset. If that IP has requested a password reset in the last Y minutes ignore the request.
If the checks in 1 & 2 pass check the account exists. If it doesn't ignore the request.
If we've gotten this far generate a one time token, which expires in Z minutes and a password reset URL which encompasses this token. Email this to the registered email address. When the URL is loaded prompt for a new password and reset.
For those who believe that you should tell the user where the email has gone I strongly disagree. This is "information leakage", even if you do limit it to the domain name. For example say I've registered on JeffAtwoodEatsBabies.com as blowdart. If Jeff had requested a password reset for me and you showed the registration domain then he'd see idunno.org. This is my personal domain and thus Jeff would know the blowdart user is, in fact, me. This is a bad bad thing. I should not have to register using hotmail or gmail or whatever in order to protect myself from your code showing an email domain to all and sundry.
In addition you shouldn't be showing error messages at all. No matter what happens, a username is not actually registered, or too many requests have been made or the sky has fallen you should be telling the user that the password reset procedure has started. Informing a user that an account doesn't exist is more information leakage.
One final thing you could do is add a CSRF token to the reset request page, so it cannot be driven from other web sites.
Followup
So to answer your further questions.
What message you show is up to you. "Instructions for resetting your password have been emailed to the registered email for this account" is one idea, but really it's down to your audience.
Already addressed above.
Wikipedia is a good starting point. How you do it depends on your platform and is a complete other question! For ASP.NET you could look at my codeplex project, http://anticsrf.codeplex.com or look at ViewStateUserKey.
When the link is clicked I would first validate the token in the URL against the username it's being applied to then I would either allow the user to enter a new password, or generate a new one and email it. You can't prompt for the old one, as the whole point is the user has forgotten it!
There are many ways this has been implemented. As you said, generating a new password and sending it to the registered email address is one method. I wouldn't suggest you go that route though, as my password would be reset everytime somebody tried guessing my password.
Instead, the best thing I've seen to date is simply emailing the registered email with a link that will begin a password reset process. You may even let the user know which email address to check by showing a masked version of their email address used in registration:
An email was sent to ********#hotmail.com. Please check your inbox to continue.
Be sure to keep in consideration those of us who may forget which email address were registered with - typically a few security questions are a great way to make that information available.
I've done that recently. When the user enters their username or email address, we generate a unique token and email it to them as part of a link. Upon receipt of that email, they click the link, and are automatically logged in, taken to the my account screen, and prompted to reset their password.
Of course, this relies 100% on the security of the email client, but it's hard to beat from a usability perspective.
You shoud check the answer to the question : Can anyone provide references for implementing web application self password reset mechanisms properly? from D.W. on security.stackexchange.
It is the most complete answer I found on the subject. I also suggest you to read this article : Everything you ever wanted to know about building a secure password reset feature
I have designed login page for one of our website where I have used following resources
Login Name and Passowrd lable and textboxes
Combo box for multilingual support
Submit button.
Now to make this page more secure I am planning to use following extra points.
CAPTCHA/ RE-CAPTCHA
Number of Retry: block after 3 unsuccessfull login attempt.
I have seen these extra things by visiting other sites. I would like to know
Whether these extar point makes somediffrence for security?
How should we implement number of retry? When should we again unblock user account.
What is right approach?
You could use ASP.NET's login control and the default SQL membership provider. If you do this, implementing the number of retries before a user is locked out is as easy as setting a config value.
Take a look at MSDN here, and scroll down to "Using the SQLMemberShipProvider" section.
Look at the NoBot control from the AjaxControlToolkit (http://www.asp.net/AJAX/AjaxControlToolkit/Samples/NoBot/NoBot.aspx). That provides some "bot protection" without the user needing to decipher a captcha.
General - Require a strong password and limit the login tries/user (not IP/cookie). If you add a five minute lock-down for a user name after three fails a bruit force attack would take more years than you site will live (dictionary attacks are not possible since you require strong passwords)*.
Protect your users - In your form, don't post the password in clear text, post a hashed version eg.
md5([your domain] + [password])
The reason you add your domain is to protect the hash of the password from the server owner (you), so if your user DB get hacked the hashed passwords you stored are useless even if your users use the same password on multiple sites. If you like stronger hash you could look for some SHA version. Make a js script that replaces the password with the hashed one before sending. Remember to have this hash calculated on the registration page, never let the password be sent from the browser in clear text. You don't want to know it!
http://en.wikipedia.org/wiki/Cross-site_request_forgery, also have your server sign the cookie values to make cookie forgery harder.
Encryption - Either use TSL/SSL or get a RSA script and encrypt your form data with your severs public_key.
Man-in-the-middle - The hardest threat to guard against, I guess that https is the easiest way but a trusted certificate costs money. If you self sign users today don't bather to look if it's the right cert or not, this requires too much form the users. Buy a cert or hope you don't have a man-in-the-middle.
I would never use re-captcha for login since a lock-down of user name is more effective and less disturbing for a user. Though re-captcha is good for account registration so you don't end up having a lot of scripted accounts.
Limiting login tries/username could be used to block a user to log in. Bruit force attacks are still available since they can attack a lot of usernames and not only one, thus keeping the attack under the limit/username block. But for a site with few (less than 10.000?) user accounts you should be quite safe.
If you are updating an existing site that has had security issues, captcha can't hurt. If it is a new site, is it public or for internal use? You can always add this later if you run into issues. If there are sensitive materials, you'll get more mileage out of enforcing strong passwords from users (though this can be annoying to them) than you'll get out of captcha (also annoying).
Several options here. You can record IP address on each attempted login and record failed attempts. 3rd fail from same IP inside of 15 minutes blocks further attempts (every attempt fails with locked account message). Additional attempts reset the 15-minute "timer." Really, there is no timer, but with each attempted login, the log it checked to see whether it has been locked within the last 15 minutes.
The login attempt log can be stored in many ways -- often a database table. There may be value in keeping a record of every login (in case there is ever a breach), or maybe you only want failed logins. Optionally, you could remove failed logins from the log when the user successfully logs in. You could have a database routine that cleans up the table from time to time of failed login records that have exceeded the waiting period (15 minutes, or whatever).
Obviously, 15 minutes is arbitrary -- this can be 1 minute or 24 hours or until the user calls your customer support line to get it reset.
I am developing an app which I should design a page for users who forget passwords and send email to them the new passwords. I am using ASP.NET Membership and password format should be hashed.
My problem is when sending mail has been failed, password has been changed and wow! no work can be done.
what is your solution?
You should send users an email with a link, where they can confirm password reset (otherwise you could reset passwords to other users by guessing their emails). On the linked page users would then confirm password reset (or even change it themselves).
But it's a better practice not to send passwords in any way shape or form. It's the most secure.
The process
Users request password reset by their email.
They receive an email with a link
Theyclick the link and provide a new password that gets hashed right away and stored in the system.
You could temporarily set the passwordFormat value for affected users to "Clear" in the aspnet_Membership table, assign them a password, and then work on getting the e-mail working.
Setting the aspnet_Membership.passwordFormat value to 0 changes the format to Clear text, which means it's not encrypted. It's not secure, but will allow login. After that, you can reset the password and it'll be changed back to 2 (Encrypted).
The user should change their password again, and hopefully the email will succeed.
If they entered an incorrect address, they should contact an administrator who can correct their email address.
If it is possible to tell if an e-mail is successfully sent before you actually commit the change to the database this would be a good option. This isn't always the case, but maybe it could work for your application.
Usually with my experience ASP will thrown an exception if the e-mail fails. If this happens don't do anything in the DB, if the mail goes through then change the password. That doesn't mean they will get the e-mail but you can't account for problems during travel of the e-mail anyway. The option above would apply after this fails. ;)
I don't know the support for such a feature in asp.net.
But, some website send you an email with a link to click (that expires in some days). Clicking which, will make sure you are committing to that action (i.e. password is changed only after they receive email & click the link they received).
ASP.NET also supports the question and secret answer approach to password recovery if email doesnt work.