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.
Related
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.
Before posting this question I searched and found that lot of questions were asked on "how to implement single user session" in different tools or frameworks.
But my question is why should we implement single user sessions?
I discussed with some friends and did some research on Google and I could find two reasons:
1. Some applications can potentially maintain "user working state" of a user, so if they allow more than one sessions then it can mess up the "user working state".
2. Some tools/applications need this for implementing licensing. Because the license allows only fixed number of users so implementing "single user session" will prevent the misuse.
Both of the above points are not related to security. Is there any other reason why it is considered a good security practice?
Thanks,
Manish
From a security point of view, single user sessions can help a user detect that their account is being used elsewhere. For example, upon logon if a user receives a message that their account is already logged on at another location, they will be alerted to the fact that their credentials have been compromised and that they should perhaps change their password.
Apart from that, I can only think of it being a good security mechanism to protect content (i.e. licensing that you covered in point (2)). However, there may be a secondary advantage to preventing multiple logons per account - users are less likely to share their credentials with other users if the account cannot be used simultaneously. Therefore their account details are likely to be kept more secure as the details have not been emailed to friends or colleagues.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
There are lots of ways to create a login form for web apps and most of them are flawed one way or the other:
Passwords are transmitted/saved as clear text
The login dialogs are subject to XSS attacks or SQL injection
Is there an example or tutorial how to create a secure login form?
I agree with Carlos about lack of "perfect" secure system, not only for login, but for any other component. The only thing to do is to minimize risks by following best practices, but always keeping in mind that total safety doesn't exist, so your question is quite difficult to answer, although there are some good examples out there nothing is perfect, security is a very fast evolving topic.
For me the main things to solve are:
-Data transmission: The user is always going to type a password and this has to be sent to your system before it was processed, so there is a high risk of being intercepted if you are using an open channel. To solve this you MUST use transport the data over an encrypted channel (SSL), no other way unless you drop the common password (for example using one-time use tokens, or delegating the authentication to a third party, like Facebook connect or openId). See "How to Make a Secure Login Form with SSL"
-Input Sanitation: To avoid XSS and SQL Injection consider any input that comes from a client as a potentially risk point, therefore you have to perform validation against anything that comes form outside --> doc. Another good practice is never use the inputs directly on queries, use as bind variables in prepared statements or stored procedures.
-Password Storage: Password should always be stored encrypted with a one way hash algorithm, so even in the case of someone accessing your DB, there is no way to recover the original passwords. Also use techniques as Salting, Hashing multiple times, etc... Also be careful to choose an algorithm that is not weak or outdated (like MD5), which can be broken by brute force easily with the increasing CPU power.
-Infrastructure: Have your machines, OS, frameworks, libraries always updated to avoid bugs and 0 day attack. Any system today is enormously complex, and the system is as secure as it weakest component.
-Other Things to Consider: Review your security policy regularly to see if needs to update anything, implement password policies (expiration, reuse, etc...), log access, use monitoring tools for your systems, etc etc etc
And after all that, you can still be sure that if someone has enough time and resources, your system will fall.
Your question, can't be that agnostic, and must be divided in your two main concerns:
Transmitting passwords in the clear.
Xss, Sql injection.
No system will be declared secured per se, but you can try your best to minimize the risks by using proven concepts.
So let's say you have the chance to design your own "secure system", what do you need?
At minimum you will need a basic set of tools:
Client side data encripting: (Javascript here, i think you will find lots of info of how to send your data in data 64 or something like that, remember you are searching for one way or two way encription)
DB Encription: (One way-two way encription, but never save passwords in the clear)
SQl injection: (mysql_real_escape_string() comes to mind).
Every language has some sort of protection built in, it is when building large projects that sometimes we may forget to sanitize some querys
I repeat no system will ever be declared secure, however you can add some other security measures as in:
access_tokens = timed-strings that allow to validate user login.
captcha_after_few_intents = you should add this definitely.
block_account_after_few_trys = pain in the * for users, but definitely worth it.
login_token = store a token unique for that user, and use it in all GET/POST transactions
SSL
From Bank Security:
Automatic gsm devices that generates RANDS and access_tokens valid only for a short time.
mouse keyboard: evitates keyloggers
random_access_question:
check_random_account_country_change = let's say user is from albany and next day he logs in from south america, that should maybe raise a flag to your system.
I'm sure you will find plenty of advice somewhere, but remember you at end will end talking html, and some js, your main defense is on the server side, so be good, or be good at it.
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?
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.