I have a public-facing website that is used to manage business infrastructure equipment for my clients. A security breach on this website could cause expensive problems for clients.
A number of different websites--mostly banks, health care, and government--disable the "save password" dialog from appearing in Firefox, IE, and other browsers citing security concerns. I'm talking about the box/bar that appears after you enter your login information, so the browser can auto-populate the username/password fields for you the next time your visit that site.
My question is not how to disable, because that is answered in the Disable browser 'Save Password' functionality question.
What I want to know is:
What are some cases in which it is absolutely essential to disable "save password" functionality? Do such cases exist?
Does this technique really provide any additional security? In other words, won't people find a way to leak their passwords despite your best efforts?
Do users complain about removal of "save password" functionality?
Any other thoughts on when to disable "save password" functionality?
I complain about it ;-) I was actually just thinking about this today because my online banking site disables password autocompletion and it's really irritating.
While not a majority of computer users, there are plenty of people who know how to manage their passwords securely, and for them it's really irritating when websites disable the password field autocompletion because it means they need to do something like, say, writing the password down, or picking a simple one that's easy to remember - neither of which makes them happy, because as I said, these are people who take password security seriously. Using a browser's password manager is pretty much the best compromise between security and convenience we have. And the annoying part is, if a website tries to disable autocompletion there's no easy way to tell some browsers to ignore that. (In Firefox it requires hacking some Javascript file)
This also ties into the thing Joel once wrote about how users, erm, people like to be in control of their environment. They're much less likely to use (or at least like) a program or website that takes it upon itself to decide that they can't be trusted with a password manager.
Question is, in what cases does it help when you don't allow saving passwords
Someone breaks into your home, gets access to your PC, visits the site and now has access - uhm, somehow abstract idea
You loose your Notebook/Netbook, someone finds it, cracks your password (hopefully you have one in your Whateverbook), browses to the site and has access
Both are more by chance than anything else. Someone who wants to get access to an account will use spyware like keylogger. But when there is a keylogger on your PC, disabling the save-password-feature would'n help anything.
Do users complain about removal of "save password" functionality?
Yes, absolutely. Users never like it to be domineed.
You need to do some basic risk assessment :
How critical your application is?
If it's an online banking application risking a client loosing their investments because they used a public computer or their notebook nicked, this is not a good idea, so disable it.
Security vs. Usability is not an easy battle you need to do some sacrifices. But also if you've got two factor authentication you might not disable it because only that password wouldn't be enough to transfer money or doing other dodgy stuff.
How frequently used?
If this is a web-mail or a service like twitter just enable it. Otherwise you'll piss off so many people.
I don't like web sites those disable it, because I know what to save, what not to save and the risk I'm taking. However normal users wouldn't, therefore you should do the hard decision for them.
Also there are other non-obvious risks you need to consider:
Publicly used computers
Old HDDs in Ebay
After an exploitation all attackers will look this data first, because they know it's a good loot.
There have been client-side attacks / weakness released only focused on auto-completed passwords and usernames.
1) "What are some cases in which it is absolutely essential to disable "save password" functionality? Do such cases exist?"
There is no well defined general rule as such. It totally depends on the the kind of services that are provided to the user and their relative importance. For example, net banking web sites have this functionality disabled whereas a normal web-based email site or a online discussion forum would rather leave the save password feature tuned on. It all depends on what you are offering to the user and it's relative importance.
2) "Does this technique really provide any additional security? In other words, won't people find a way to leak their passwords despite your best efforts?"
Yes. This technique at least blocks off one possible way of password stealth. But, it does not guarantee no password stealth in any sense. From the most trivial ways of password stealth, to keyloggers that capture key strokes, to even bruteforce mechanisms or to even phishing sites that resemble your web site, the routes of password stealth still remain open. You are just blocking off one of the ways thats it.
3) Do users complain about removal of "save password" functionality?
Depends on the user really. Some who realise the the importance of the save password feature being disabled would not complain about it anyway. And those who are just lazy to re-enter the credentials everytime should not be worried about. Afterall, user security is privacy is much more important than user frustration because we are dealing with important data here and we disable the save password feature for the good of the user only.
4) Any other thoughts on when to disable "save password" functionality?
This again is like question 1). It all depends on the importance and the aftermath/cost to pay of loosing the password.
I would never disable password saving. You are just as likely to increase the risk as to decrease it. Example:
User logs into your website for the first time, and manually enters their password
User visits a malicious site, which installs a keylogger
User visits your site again, enters the password again, keylogger sends user's password to the thief.
If the user had saved their password instead, they would not have had to type it again in step 3, and so the keylogger could not have been used to steal it.
I've just run into this from the other end (having to disable the "save password" functionality) and for us, it's an audit issue. Some audit frameworks view this as a security issue (person A has certain rights into an application [web-based], they save their credentials into the browser, person B gets into the application using person A's account because person A walked away from their computer without locking it).
This isn't to say that there should be other controls in place (forcing Windows to lock, etc), but that there are sometimes "valid" reasons for why some websites don't allow you to save your password.
All these answers are about protecting user data. I'm currently working on a site where the sensitive data is on the other side - the provider, for a fee, gives access to this data and wants to make sure that nobody except those paying are accessing it.
Obviously the users in this case may not be as careful as they would if the data were theirs.
And so we try to disable the save password functionality.
I know that especially in the US, bank security is lax. Bank sites shouldn't even use password protection, as it completely fails to protect against even simple keyloggers.
Related
I got very concerned reading this genius post by Aza Raskin.
What are the non-browsers solutions to defend against TabNabbing? Are there any?
"Tab Nabbing" is not a new attack, Mr Raskin is ripping off other researchers work. PDP from GnuCitizen discovered this back in 2008.
The biggest threat as I see it is Phishing. To be honest I don't think there is a good solution to stop phishing. This particular issues I think should be fixed by the browser. Eventually Firefox and Chrome will get around to fixing it. To be honest SSLStrip is a bigger threat that all browsers face, which can be used along side this redirection attack. Currently chrome has a fix in the form of STS and Firefox in the form of HTTPs Everywhere. Using noscript will also help mitigate this redirection attack attack.
One thing that will prevent this sort of thing from happening is two factor authentication using something like an RSA token (unfortunately only one bank in this country provides this method).
The RSA token is a little USB stick sized gadget that has a continuously changing serial/sequence number on it, and it is issued to you (each stick has a different sequence of numbers). When you logon to your bank's website, you have to supply you log/pass, and also the current number on the RSA token - that number changes every two minutes. That means that if the bad guys collect your login details they have less than two minutes to login to your account before the current RSA sequence number changes and the captured login details become impossible to reuse.
This 2 factor authentication is not the silver bullet though, i don't see Google rolling this out for your random Gmail account, and neither will Facebook. It should be mandatory for financial institutions and online government departments, this will cut the scope of this type of attack. It is a commonly used protection mechanism for remote access to company website portals and remote network logins, and it is quite successful for this.
This still hasn't answered your question though - how can you as an website author or owner prevent this? You can't, unless you don't run third party scripts, and regularly check your pages to make sure you haven't been compromised and had a script inserted. You should never consider trying to scan any third party scripts, because they can be obfuscated to an incredible degree which you can't possibly scan for. If you do run third party scripts and feel strongly enough about this, then you might want to setp a machine which all it does is automated UI tests on your web site - it is an easy enough thing to set up with some basic tests and just leave it testing your live site every 30 or 60 minutes looking for unexpected results.
Like he suggests, use the password manager. There are quite a few other problems that can happen if you type your password every time. For sites that the password manager doesn't work, you're screwed. Client certificates ftw.
I just visited the page which you mention and my free virus checker (AVG) immediately detected a threat (I presume that he has an example on the page) and warned me of a Tabnapping Exploit.
So that's one, easy, possibility
In a recent project I put a captcha test on a login form, in order to stop possible brute force attacks.
The immediate reaction of other coworkers was a request to remove it, saying that it was inapropiate for that purpose, and that it was quite exotic to see a captcha in that place.
I've seen captcha images on signup, contact, password recovery forms, etc. So I personally don't see inapropiate to put a captcha also on a place like that. Well, it obviously burns down usability a little bit, but it's a matter of time and getting used to it.
With the lack of a captcha test, one would have to put some sort of blacklist / account locking mechanism, which also has some drawbacks.
Is it a good choice for you? Am I getting somewhat captcha-aholic and need some sort of group therapy?
Thanks in advance.
Just add a CAPTCHA test for cases when there have been failed login attempts for a given user. This is what lots of websites currently do (all popular email services for instance) and is much less invasive.
Yet it completely thwarts brute force attacks, as long as the attacker cannot break your CAPTCHA.
It's not immoral per se. It's bad usability.
Consider security implications: the users will consider logging in to be time consuming and will:
be less likely to use your system at all
never log out of your system and leave open sessions unattended.
Consider other forms of brute-force attack detection and prevention.
Captcha isn't a very traditional choice in login forms. The traditional protection against brute force attacks seems to be account locking. As you said, it has it's drawbacks, for example, if your application is vulnerable to account enumeration, then an attacker could easily perform a denial of service attack.
I would tend to agree with your co-workers. A captcha can be necessary on forms where you do not have to be authorized to submit data, because otherwise spambots will bomb them, but I fail to see what kind of abuse you are preventing by adding the captcha to a login form?
A captcha does not provide any form of securtiy, the way your other options, like the blacklist, would. It just verifies that the user is a human being, and hopefully the username/password fields would verify that.
If you want to prevent bruteforce attacks, then almost any other form of protection would be more usefull - throtteling the requests if there is too many, or banning IPs if the enter wrong passwords too many times, for instance.
Also, I think you are underestimating the impact on usability. A lot of browsers provide a lot of utilities to deal with username/password forms and all of these utilities are rendered useless if you add a captcha.
I would like to address the question in the title—the question of morality.
I would consider a captcha immoral under the following circumstances:
It excludes participation in the application to those with physical or mental challenges, when the main portion and purpose of the application would otherwise not make such an exclusion.
The mechanism of the captcha exposes users to distressing language or images beyond what would normally be expected in the application.
The captcha mechanism as presented to the user is deceptive or misleading in some way.
A captcha may also be considered immoral if its intent is to exclude genuinely sentient machine intelligences from participation for reasons of prejudice against non-humans. Of course, technology has not yet advanced to the level at which this is an issue, and, further, when it does become an issue, I expect human-excluding gates will be more feasible and common.
Many popular (most used) mail server doesn't have it?!
What are your thoughts about this issue in regards to an e-commerce environment?
Do you think it is wise to turn autocomplete off on all sensitive input fields such as passwords (for log-in areas), or will this just inconvenience the client?
I hate websites that do that. It is the client's decision if they want to save passwords or not. What is particularly irksome is that this attribute breaks OS X's native KeyChain support. So, even though the user has stored his password in a secure file, and authorized themselves and the application to use it, the website still thinks it knows better. Just plain annoying.
An eCommerce application I worked on several years ago underwent a security audit and one of their recommendations was to disable autocomplete for sensitive fields.
It wasn't a strict requirement, but it probably will be at some point, given how eCommerce standards are these days..
Unless it is a highly-secure site, I would tend to leave autocomplete on. If it is for a password field, the browser will prompt the user if they want to save the information, at which point the user can make their own decision.
I really dislike that when I start to type in my credit card number and it lists all of the numbers I have used in the past, as well as the 3 digit code. Not cool IMO.
It depends what you mean by e-commerce. In Internet banking you should disable autocomplete. In online shopping - not necessarily.
It's worth remembering that autocomplete does not force remembering passwords. User has to agree to store their credentials, so they always can reject.
I concur. By habit, I leave autocomplete on. However, there was a project for the air force I was working on that had a requirement to disble autocomplete. Really depends on your requirements.
I actually don't think i've ever seen "autocomplete" work on a password field.
Autocomplete(when you start typing something in a form field, and the browser popups up a list of suggestions), and asking the browser to remember your user name and password are two different things.
If you're talking about the browser feature that remembers your username and password, i'm not aware of a way for you to disable that on the user's machine.
I use password/form managers like 1Password and RoboForm specifically to get around websites that disable autocomplete; these add-ons typically ignore the website's preferences in favor of their own more sophisticated logic.
Most e-commerce sites disable autocomplete for credit card fields. They store and redisplay the info when an authenticated user returns, then only require the user to re-enter the CVV. This way the site gets users to sign up (otherwise, they'd have to re-enter the full CC info every time), keeps the CC info masked on subsequent visits, and only burdens the user with entering a three-digit number. (It's also a small way of building secure practice around CC numbers so users will hopefully be more protective of them.)
Keep in mind that setting autocomplete on/off only addresses confidentiality of data for shared environments, i.e. more than one person accesses the same browser. For example, if your app were intended for a classroom, then it would make more sense to disable autocomplete entirely since the app will be re-used in the same browser by many different people.
Consider it an (in)convenience feature, not a security feature. You can't protect users from every dumb mistake when sharing browsers (like not logging out) and, to be nicer to dumb users, it won't have any bearing on client-side attacks like keyloggers. If the shared environment isn't secure, then your app can't do much to protect its users.
The talk of internet town today is the SNAFU that led to dozens of Facebook users being led by Google search to an article on ReadWriteWeb about the Facebook-AOL deal. What ensued in the comments tread is quickly becoming the stuff of internet legend.
However, behind the hilarity is a scary fact that this might be how users browse to all sites, including their banking and other more important sites. A quick search for "my bank website login" and quickly click the first result. Once they are there, the user is willing to submit their credentials even though the site looks nothing like the site they tried to reach. (This is evidenced by the fact that user's comments are connected to their facebook accounts via facebook-connect)
Preventing this scenario is pretty much out of our control and educating our users on the basics of internet browsing may be just as impossible. So how then can we ensure that users know they are on the correct web site before trying to log in? Is something like Bank of America's SiteKey sufficient, or is that another cop-out that shifts responsibility back on the user?
The Internet and web browsers used to have a couple of cool features that might actually have some applicability there.
One was something called "domain names." Instead entering the website name over on the right site of your toolbar, there was another, larger text field on the left where you could enter it. Rather than searching a proprietary Google database running on vast farms of Magic 8-Balls, this arcane "address" field consulted an authoritative registry of "domain names", and would lead you to the right site every time. Sadly, it sometimes required you to enter up to 8 extra characters! This burden was too much for most users to shoulder, and this cumbersome feature has been abandoned.
Another thing you used to see in browsers was something called a "bookmark." Etymologists are still trying to determine where the term "bookmark" originated. They suspect it has something to do with paper with funny squiggles on it. Anyway, these bookmarks allowed users to create a button that would take them directly to the web site of interest. Of course, creating a bookmark was a tedious, intimidating process, sometimes requiring as many as two menu clicks—or worse yet, use of the Ctrl-key!
Ah, the wonders of the ancients.
The site could "personalize" itself by showing some personal information,
easy recognizable by the user, on every page.
There are plenty of ways to implement it. The obvious one:
under first visit, the site requires user to upload some avatar,
and adds user's id to the cookies. After that, every time the user browses
the site, the avatar is shown.
When I set up my online bank account, it asked me to choose from a selection of images. The image I chose is now shown to me every time I login. This assures me that I am on the right website.
EDIT: i just read the link about the BoA SiteKey, this is apparently the same thing (it sounded from the name like a challenge-response dongle)
I suppose the best answer would be a hardware device which required a code from the bank and the user and authenticated both. But any of these things assume that people are actually thinking about the problem, which of course they don't. This was going on before internet banking was common - I had a friend who had her wallet stolen back in the 90s, and theif phoned her pretending to be her bank and persuaded her to reveal her PIN...
When the user first visits the site and logs in, he can share some personal information (even something very trivial) that imposter sites couldn't possible know - high school mascot, first street lived on, etc.
If there's ever any question of site authenticity, the site could share this information back to the user.
Like on TV shows/movies with the evil twin. The good twin always wins trust by sharing a secret that only the person who's trying to figure out who the good twin is would know.
You cannot prevent phishing per-se but you can take several steps each of which do a little bit to mitigate the problem.
1) If you have something like site-key or a sign-in seal, please ensure that these cannot be iframed on a malicious website. Just javascript framebusting may not be enough as IE has security="restricted".
2) Be very consistent about how you ask for user credentials - serve the login form over SSL (not just post-back over SSL). Do not ask for login on several places or sites. Encourage third parties who want to work with user data stored on your site to use OAuth (instead of taking your user's password).
3) You should never ask for information via email (with or without link).
4) Have a security page where you talk about these issues.
5) Send notification on changes to registered phone, email, etc.
Apart from above, monitor user account activity - such as changes to contact information, security Q&A, access, etc (noting time, ip, and there are several subtle techniques).
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.