I'm working on a web applications where - believe it or not- the users aren't required to provide their email address to sign up. These requirements can not change. The users will login to the system with an id and password just like any standard web site. The problem I'm facing has to do with user's that have forgotten their password. When they want to generate a new one, how do I verify their identity?
Initially, I was going to make the users choose a security question (from a list of 5) and provide an answer. If they ever entered the Forgot Password page, they would then have to enter their login id, as well as the answer to their security question. This seems slightly insecure, as the answer to these types of questions (mother's maiden name, birth town, etc.) are generally not that hard to acquire.
So here are some of my questions:
Are security questions the best approach to this problem?
If so, what are the best questions?
How many questions should a user be required to enter the answers for?
Is it necessary to put a CAPTCHA on the Forgot Password page?
Is it better for users to generate their own questions?
Any help/comments/literature on this matter would be greatly appreciated.
I can't recall the location, but if you do a google search on knowledge based authentication, you'll ifnd that Q&A authentication is very weak. One significant problem is entropy (possible randomness) of potential answers and of actual answers. If you ask for a favorite color, there's really only a very small list of colors that most users will select. This might be worth 1 bit of entropy. Then, if you asked a second question, such as the city where you grew up, this might get you another bit or two of entropy (in Mexico, there's something like a 30% chance for each of 3 cities for this answer).
One estimate that I saw was that, to get equal strength to an 8 character password, you'd need about 26 questions.
That said, you might be able to do other things to contact the user. You could try sending a text message to the user, instead of an email - does the user register a phone number? You might have the user store a certificate on their computer, which they can upload along with the password reset request (you'd have to make effort to ensure this cert was tied to the computer). You might do a post-signup thing, where the user could submit an email address.
Good luck!
Are security questions the best approach to this problem?
Since you cannot use any other means of authentication (such as email address, OpenID, etc.) this is the best you can do really. However, you could always add a "password hint" to the signup process.
If so, what are the best questions?
Is it better for users to generate their own questions?
It's much easier if you let the user write his/her own question as opposed to the stock "first car" or "first pet". This is a good failsafe as it (usually) provides a very difficult question/answer combo to randomly guess and is likely as secret as a password.
How many questions should a user be required to enter the answers for?
Allow for one question/answer combo.
Is it necessary to put a CAPTCHA on the Forgot Password page?
Well, there has to be some attempt to guard against brute-force attacks, especially from bots. I would use the same technology that SO uses: reCAPTCHA
Are security questions the best approach to this problem?
Absolutely not.
Password recovery needs to work for legitimate users and to fail for the bad guys. Secret questions do the opposite: hackers are really good at guessing them, yet legitimate users cannot remember their own answers. Research has proven this. And this is exactly why NIST is saying do not use secret questions -- i.e. knowledge based authentication.
You are trying to make it easier for the user in the event that he forgets his password, but unfortunately secret questions do the opposite. Users hate them, and they forget their answers, which only frustrates the user more.
By design, you do not have a way to recover the account when the user forgets his password. Don't make it worse by using secret questions. If you really want to make password recovery possible, then why not instead of forcing the user to choose and answer secret questions, instead require them to provide an email address or phone number and do password reset the exact same way that all the good websites do it?
Related
Browsing over the OWASP site, one can find the article where at the very bottom secret Q&A is ditched not only as ineffective, but as security backdoor to the system:
OWASP: Guide to Authentication
Questions and answers are back door credentials - they equate to the username and password for the user. Often such schemes use "Mother's Maiden Name" or other easily found information. If all systems use the same Q&As, it will be possible to break into many accounts using the same information.
They are unacceptable for the following reasons:
Collection of information about people without their explicit consent (such as "Mother's maiden name") is illegal in most privacy regimes. Such collection is subject to privacy laws, review and correction by the subject, and so on.
IT Security Policies and standards such as ISO 27000 prohibit the clear text storage of passwords, but almost all Q&A schemes store both the question and answer in the clear
The information in the answers is public for a goodly portion of the users of the Internet, and thus is found using public sources
Secret Questions and Answers have been publicly abused, most notably by the attack on Sarah Palin's e-mail account, exposing her use of her Yahoo free mail account for government business.
Then again, if you browse to:
OWASP: Authentication Cheat Sheet
You can actually find a link to password reset implementation that includes Secret Q&A as part of the process.
This makes it bit inconsistent to make a good decision whether Secret Q&A is bad practice or not. What I've come up with is the following conclusion:
If used as single method for password recovery, Secret Q&A is bad practice
If used combined with token delivered through independent channel such as e-mail or SMS, Secret Q&A adds another layer of security
If i.e. system is using reset token only that is sent over e-mail, if attacker has gained access to user's e-mail, then all applications that are using that e-mail address can be accessed by the attacker initiating password reset procedure.
If however, using token requires you to perform Secret Q&A steps as well, then regardless the e-mail is infiltrated, attacker still can't access the web applications.
This being said, there is still no best practice on whether Secret Question must be collected from the user, or user can be asked to select question from the list of predefined questions (usability scenario).
Additionally, it is unclear whether Secret Answer should be hashed (some mechanisms are hashing it, some are not), and same applies for user-supplied Secret Question.
Is there some other standard that defines all this beyond OWASP?
Should Secret Q&A be Used?
You already explained where secret questions should and should not be used, and why, quite well. They are almost always much weaker than a traditional username and password combination, but if used as secondary verification to another method, they can certainly add to the security of your password reset process.
Implementation
I would suggest using predefined questions over user defined ones. While a user can create a much stronger Q&A than you should probably force upon them, they can also set one like
"Q: A sweet fruit that keeps the doctor away," which you really can't prevent, but provides no protection at all.
Should the answer be hashed? Probably.
But if you are going to hash it, I would suggest doing things like setting it to all lower case first; things like capitalization are important in a password, but the point of a secret Q&A is that the (correct) user can come into it cold and give the correct answer. Allowing things like capitalization to break that is probably a bad idea. In fact, I might go so far as to remove anything that is not alpha-numeric, so that a period, dash, etc don't break the match. Of course, anything you do that removes entropy further weakens the secret Q&A, just like it would on a password, so you have to make a judgement call on just how critical your security really is.
Other Standards
I don't know of any other standard that goes beyond OWASP.
I've done some work at a few places now where passwords are salted and hashed in the database, but the answers to the security questions are stored in plain text. Just now, I signed up for the online portal for my hydro company, and in the account management section, the security question and answer are displayed to me.
Given that security questions and answers often allow a user access to an account in a workaround way, without requiring the password, why are they allowed to be stored in plain text? Especially since people often have a limited pool of security questions to choose from, so they likely use the same answers across many sites.
The problem with security questions is that they are by design completely insecure. The reason that they are stored in plain text is that they occasionally need to be looked at by humans and used by humans to verify that an answer is correct. If a user’s answer to their favorite food is “popped corn”, and they answer “popcorn”, that’s a valid answer.
Hashing the answers to security questions would require that the user know their previous answer exactly, just as if it were a password, and we already know that the user forgets their password (in those cases where the user is the one trying to access the account). The point of security questions is that they are real things that can be remembered and don’t have to be treated by the user as passwords.
Similarly, because these are not arbitrary answers in the way that passwords are, they are sometimes, as you noticed, displayed back to the user. This is so that they can change the answer when it is no longer correct. A password is an arbitrary response, but security question answers are not arbitrary. People’s favorites and even what or who they think inspired them can change over time. A user who is asked their favorite movie might choose the one they saw last night, and completely forget a year later that they ever rated it so highly.
For that matter, hashing the answers to security questions is of limited utility (mainly to security geeks who know to answer them randomly). Their very nature is that they are public. Hashing the model of the user’s latest car doesn’t keep the hacker from just reading their Facebook feed.
The secure answer to security questions is not to use them. Technically, they should be treated exactly like passwords, because for all practical purposes they are passwords. But if we hashed the answers to security questions, required users to choose strong answers, and didn’t allow them to use easily-guessable answers, then there would be no point to them.
Remember, the purpose of security questions and answers is to bypass not knowing the password. The more they’re treated like passwords, the more useless they become for that purpose.
There's no answer to "Why don't the answers need to be stored securely?", because they should.
A password is actually an answer to a security question too ("What is your password?"), so you should always hash answers to security questions too as it's a way to authorize a user.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
Browsing through Coding Horror, I saw this article on removing the user field from a login dialog.
It's an interesting concept albeit an old one from 2005. Nevertheless, I started thinking about it and wondered:
How would you be able to do this in a secure fashion?
If you identify the user by their password that means all passwords must be unique - yes?
If all passwords must be unique, what do you do when someone enters a password that's already in use?
You can't tell them it's already in use because that would give away someone else's login.
I can't think of a way one could implement this in a secure fashion...any ideas?
You do not identify users by password, you identify them by user name. You authenticate users by password. Just think a bit what does it mean to identify by password. I join the system, he asks me to enter my new password. I say 'foo', he says 'foo is already in use'. I say 'tyvm'', and open the login window. When prompted I simply enter 'foo' and he says 'Welcome Mr. President'...
No, there absolutely cannot be a requirement to have passwords unique, that would be a huge security hole in any system because it relies on information disclosure to function: by reveling a duplicate you disclose somebody's password. Even with name/password combinations, once you disclosed that 'password is in use' all I have to do is iterate through the list of accounts trying the password you just revealed to me, and one combination will succeed.
My first thought, which is also alluded to in the article, is to increase the password complexity requirements to avoid collisions.
16-byte GUIDs avoid collisions (every star can have 6.8×1015 GUIDs) well enough, so it shouldn't be too difficult. Obviously human-generated input isn't quite as random, but if you add in enough requirements like lowercase/uppercase/numbers/symbols/length, it might work well enough.
Well, I suppose you could look for some other piece of "uniquify-ing" data, to use in combination with the password. For a web app, this could be a hash inserted in a cookie, from a previous visit. It'd be hard to guarantee uniqueness (multiple users from a single profile on a single computer, for instance).
My bank takes essentially this approach, with my public IP address. It's a little annoying, actually. Every time my DHCP lease expires, my bank's website "un-recognizes" me, and asks one of several security questions, before I get the standard username/password screen.
Multiple-factor security uses something like this (a hardware key or hardware-provided identifier, in combination with a password).
This approach strikes me as overly clever, and clever's rarely the right way to approach security systems.
I believe you cant.
By entering your username you are providing your identity, by entering your password you are providing a means for the server to verify this identity.
Both are inherently required unless you have some other means of determining identity (IP, keycard, etc.)
Basically you cant expect anyone to believe you are who you say you are, when you don't say who you are!
I'm planning to add some vote up/vote down buttons to a website I run. This seems easy enough but I want to stop people voting multiple times. One solution would be to make them register before allowing them to vote but I'd prefer not to have to force them to register.
Is there are a reasonably straightforward way of doing this? Checking the IP address doesn't seem like a good solution, since it's possible that multiple users may come from the same IP address.
Cookies might be the answer, but a savvy user could delete the cookie. Any better ideas?
Sorry I don't have a useful answer, I just want to share my experience.
About 8 years ago I worked for a site that ran online polls. We once got hacked by some bots voting on some of our questions several hundred votes a minute.
I had to implement some emergency checks: IP address, cookies, and I really don't remember what else.
At the end of the day we decided to take the polls down. Those damn robots just didn't care. IP adresses were spoofed, cookies were being deleted, etc.
If you really really need the polls to be unhackeable I don't see any other way that requiring registration and using captchas to avoid bots signing up for new accounts.
And the sad thing is that this was just an entertainment site with polls on what's your favorite color and things like that.
The only thing we didn't tried was using captchas because they didn't exist at the time. That might have reduced non-human cheating a good deal.
Don't take this as any kind of expert advice on the matter, because that was the only time I had anything to do with online polls, but I remembered my story and wanted to share.
I think it really comes down to the nature of your website, and how accurate your results needed to be.
Using a cookie seems like the best option, but it depends on the target audience of your website. Would they be tech-savvy enough to try and beat the system to allow them to vote multiple times? If not, the risk should be fairly low and this would seem like the best approach.
Checking against an IP address, as you said, may be too restrictive. But if it's critical for all votes to be from unique individuals, this might be the better approach even if it means some legitimate voters won't get to vote.
I thought of another option, but I'm not sure if it's possible or feasible. If you could combine the IP address approach with a hardware based check (e.g. MAC address of NIC) this would eliminate the IP address approach being too restrictive due to NAT within a LAN. But it wouldn't help the situation where you have a computer in an Internet cafe used by different individuals.
You should also use captcha (for non registered accounts) to reduce the likelihood of voting bots. If someone wants to maliciously cast multiple votes, making it more difficult for them to automate the voting process through bots will help to hopefully reduce the occurrence of such behaviour.
So, you want to have each unique person have only one vote on each item. When a person tries to vote who has already voted before, you want to detect this. This means that you have to identify the person. There are no tricks to get around that.
Now, since persons can log in from any computer, identifying the computer doesn't help. This rules out IP checks and cookies, as well as anything else based on the user's hardware.
How to identify a person? You can't. You can only force them to identify themselves, by providing unique credentials, like a social security number (I think this is often used in Korea), a passport number, or similar. This, of course, doesn't help if you don't check it, since anyone can make up a 10 digit number with little chance of collision.
Even having the user register doesn't really help per se -- they can just register another account.
I wonder if you could make it a multi-step process, to make it more difficult for BOTs.
Registering, or some similar task, gets you Cookie-A, and then when you vote you get Cookie-B, but if you have Cookie-B and don't have a suitable matching Cookie-A your vote doesn't count. If you try to re-register on the same machine that can be detected by you already having Cookie-A. Going through the steps too fast is treated as a BOT.
We had a psychometric test, with many questions, and users had to make thoughtful answers. An answer in sub-N seconds was someone just pressing buttons to get through it. We never told them that their answer was too quick, we just marked the data as "suspect".
So anyone trying to go straight to the Vote Button won't work. They would have to do Step-A, then Step-b then Step-C in order.
To re-vote I would have to clear cookies, re-register, read the blurb-page (whatever) and finally re-vote, all in the right order, and not too fast.
Requiring JavaScript to be enabled may help, as may a Captcha system. Captcha could have some sort of delay - "Please watch as the two words appear" so that there are two words, shown one after another, but "real words" so that they can be easily memorised, and then typed in. Any response that is "too fast" is not valid.
At some point people will just become annoyed and not bother though.
Obviously you need to identify the user so he can only vote once. But identify the user does'nt mean you have to pop up a login screen. As said above you can ask for the email
address, ans use it as an identfier.
No one mention the way stackoverflow works, if the user has something to win (here reptutation) when becoming a register user and if the login process is as simple as giving an email address, then that's a win-win situation in wich the user is happy to login and vote, and you're happy to have him registered and voting things (and only once per question).
Jeff Atwood wrote an article about the "login barrier", wich may give you clues.
I once created a voting system for a contest. I was restricted from limiting votes by IP due to the fact that multiple people would be legitimately voting from the same IPs. As such, I went with the email confirmation method, requiring each voter to input an email address which a confirmation link was sent to, which, once clicked, would activate their vote and prevent additional votes using that address.
It did not work well. People created hundreds of false email addresses on various free sites.
What did work in the runoff vote, somewhat surprisingly, was adding the email address/vote pairs to a database but not immediately sending the confirmation emails out. Instead, I had a cron job send the batch of them every 15 minutes or so. This adds an additional complication for people registering many addresses, as they have to either leave them all open or remember the login info for each of them at some point in the future.
Of course, still easily bypassed for someone motivated enough, but it seemed to work well in this case.
I've never used a system like this, but try to identify a user by their browser's fingerprint. This jQuery plugin combines screen size, color depth, user timezone, and installed plugins to create a unique ID of a user. Definitely not foolproof, but it's a different approach.
There's no accurate way to avoid multiple votes from the same user, even if they don't delete cookies, they can use another browser, or another computer.
I think you should register user before he up / down vote. You can get a little piece of information from the user to get registered, so he does not bored or break his registeration. Afterwards he can update his account if he wants. IMHO this is the best solution.
As has been said there is no 'perfect' solution.
As an attempt at an imperfect solution, how about storing a hash of the IP address and the User agent.
This would mean that different users from a given IP, which have different browser user agents, can still vote.
Use a cookie-based approach, it is accurate enough for most entertainment-grade polls on the web. Stay away from IP restrictions. This would mean that only one person from larger companies gets to vote and that only one person in a family gets to vote.
Also a possibility:
let the user vote and fill out his emailaddress.
The user receives a confirmationemail with a link he needs to click in order to confirm his vote.
But this way, the user also has quite some overhead.
Or do this in combination with registered userss (who will not be forced to confirm)
I know that this is an old thread. In any case I suggest to use evercookie (http://samy.pl/evercookie/) to track a user that have already voted!
It's matter of how many identities a single person can control. The more harder you make for a single person to control multiple identities the more secure your poll will be.
For entertainment grade polls where the results doesn't matter, single cookie approach is enough. Very easy to circumvent if the user opens icognito windows.
Better protection can be obtained if you put a registration barrier, you can use OAuth based logins for seamless authentication, it would take some effort to switch accounts for more votes. But this doesn't stop the desperate ones to vote multiple times.
Even better if you send confirmation code in SMS. Though people may own multiple phone numbers, it's not common to have a considerable number of phone numbers to execute a fraud. But this approach costs money for you and can be abused by DoSing the server to exhaust all the SMSes.
If you want goverment-grade polls, where the votes can decide an election.
Then you should have the voters show up in the registration office to apply for the poll and let them choose one from the prepared PIN envelopes, which contains a long hash they can enter when casting the vote.
So unless the organizers commit a fraud then voters can't. This also ensures anonymity.
An old question but for to touch on new ways - these days there are many Poll services out there who work tirelessly to implement numerous measures to avoid dupe votes, and constantly tweak their systems to counter new ways people introduce to circumvent etc. Doing this yourself is a job in itself.
They even offer branding. And large corporations use them, so it's not like your company will look bad for outsourcing a poll.
If you need to do it yourself.
As has been said, registration is the only sure fire way. If it's really important to avoid dupe votes (i.e. it's not just fave colour or something trivial/fun) then you can also limit voting to a link you send to their email they registered with.
While still not fool proof (nothing is) at least you force them to have a genuine email address which they have access to.
This isn't too much trouble for users voting, but makes it fiddly to make many dupe votes - registering, waiting for email, using the link, etc.
You already named all usable solutions. ;) It's your task to decide now.
I'd recommend combining an IP and cookie check.
I'm looking for studies on the security effect of frequent password changes, looking at the security benefits / problems from having a mandatory password change every one or two months or similar.
Does anyone know of any?
Here is a research article on password policy. It mentions the frequency at which people should change their passwords and some other really interesting stuff. Below is an extract.
Some experts say that periodic
password changes will reduce the
damage if an attacker intercepts a
password: once the password is
changed, the attacker is locked out.
This assumes that the recovered
password will not give the attacker
any hints about the victim's current
password. In fact, periodic password
changes tend to encourage people to
design sequences of passwords, like
secret01a, secret01b, secret01c, and
so on.
This allows users to easily choose and
remember a new password when the old
one expires. Such sequences are
usually pretty obvious to an attacker,
so any one of the victim's old
passwords will probably provide the
attacker with a reasonably small
number of passwords to guess at.
The TechReport Do Strong Web Passwords Accomplish Anything? states “changing
the password frequently helps only if the attacker is extremely slow to exploit the harvested credentials.”
In my opinion, forcing people to change their password too often, reduces security because the only way people can remember so many passwords, is to start using stupid passwords like Computer123 or January1 followed by February1 etc...
A better idea is to reduce the frequency and then train people how to create strong passwords.
While not exactly the study you're looking for, it is closely related and might push you in the right direction. I have seen a few studies on the specific topic you're looking for, but can't find the references just yet.
Microsoft Security Guru advice: "Write down your password"
There are a number of bad things that can happen with passwords, and want to mitigate as many as possible without creating new problems. The "change your password" policy is there to mitigate the damage over time that could be caused if your password gets out, by limiting the window of opportunity for an attacker. While not the end-all of security measures, it can sometimes make a huge difference. As a security consultant, I have personally made (this year alone) many tens of thousands of dollars cleaning up messes that could have been avoided entirely if the company had changed important passwords at least yearly.
The danger of changing your password frequently is that you'll pick poor passwords. This makes the situation even worse, because it now allows attacks that would have otherwise not been possible.
The new wisdom, as mentioned in the linked article, is pick (or be assigned) a random password, possibly changed on a regular basis, and write it down somewhere that you keep safe. Obviously you don't leave it with your computer any more than you would leave you keys with your car. The justification is that people are already trained to know how to secure "things" but are naturally poor at securing information. So if you turn the password into a thing you can hold, then you can just secure it the same way you secure your keys. In practice, this works very well, however it tends to make IT departments nervous.
Update, August 2016:
This article: "Frequent password changes are the enemy of security, FTC technologist says" http://arstechnica.com/security/2016/08/frequent-password-changes-are-the-enemy-of-security-ftc-technologist-says/?imm_mid=0e6947&cmp=em-webops-na-na-newsltr_security_20160809
has been showing up everywhere this week, including Bruce Scheier's blog, O'Reilly's Security Newsletter, ArsTechnica, Slate, and NewsCombinator, and may be just exactly what you'd asked for earlier this year.
It references:
https://www.cs.unc.edu/~reiter/papers/2010/CCS.pdf
TL;DR summary: Stop expiring/changing passwords. It's a really bad security practice.
I don't know of any studies that exist, but to get you thinking about both sides of the issue, here's a paper against forcing password changes:
Managing network security — Part 10: Change your password
And an instructional site for an educational institute that makes at least a somewhat compelling case (Written by a Ph.D.) for forcing users to change their passwords frequently. These are the main arguments the site gives FOR forcing password changes, after the link to the page:
"Why Do I Have to Change My !#$%#* Password?"
If you're required to change your
password at least every six months,
someone who's hacked your password
and has been accessing your account
without your knowledge will
immediately be shut out once your
password is changed. Some may think
this is an uncommon scenario, but
people commonly sell an old computer
and forget to erase passwords they
may have saved for dialing in or for
accessing their email.
If you change your password at least
every six months, hackers who may be
trying to crack your password using
brute force (as described above)
basically need to start over because
your password may now have been
changed to some pattern they've
already tried and rejected.
Forcing a password change also
discourages users from using the same
password on multiple accounts. (Using
the same password on multiple
accounts is bad because then your
password is only as secure as the
least secure of the systems sharing
that common password, and if your
account does get compromised, the bad
guy suddenly has access not just to
one account, but to multiple
accounts, magnifying the scope of the
problem).
As far as "research" goes, these might not cut it, but seem to be at least a good introduction to both sides of the argument.
It's not a study, but Gene Spafford posted a short article that discusses the reasons why a policy of frequent password changes doesn't make much sense:
http://www.cerias.purdue.edu/site/blog/post/password-change-myths/
Passwords should be changed when you believe that your password may have been or may soon be compromised. Otherwise, it is usually a useless waste of time, and actually a security hazard. See this link:
http://old.news.yahoo.com/s/ytech_wguy/20100413/tc_ytech_wguy/ytech_wguy_tc1590
This is an excellent paper published in an ACM publication (from 2010) that discusses the cost-benefit analysis of security and user expectations.
http://research.microsoft.com/en-us/um/people/cormac/papers/2009/SoLongAndNoThanks.pdf
It does make the claim that changing passwords is certainly good advice, but it may not be worth the cost to the users since there is so little evidence to support the idea that we are safer with more frequent password changes. It really is such a good article.