I have to agree - we regularly get connections dropping in China and I have team members regularly get locked out because of trying to connect on a poor quality connection.
I wish we had not pushed TeamViewer to our colleagues abroad in years gone by, as we're now stuck with third parties who expect us to use it.
Very dissapointing reply from TeamViewer.
Are you serious right now? That's the answer?
CLEARLY, Team Viewer was created and desgined by team members who are no longer existent within your company.
You guys are unable to update and change the code, I'm willing to believe that.
If you'd like some consultation on proper DR Testing, Dev, QA, ...any ITIL needs at all... reach out to me.
Your answer solidified my desire to NOT use this software anywhere currently...
Didn't realize you were still in Beta as it's clearly not Production-Ready. You should probably warn users of that before roping them in.
Who are you trying to fool?
This "brute force protection" is counting connection attempts that never even got to the password exchange phase and connection attempts to computers that are assigned to us with easy access.
^ Very good point! Plus, what's the value in "adding" to our list if that's not the case? Is our own credentials not worth some sort of whitelist?
Brute force protection is not only there to protect the remote side.
Even if you try to establish too many connections quickly to multiple different devices, this is still covered by brute force as there are too many requests being sent to the server that can be used to overload our servers, this is why there is no "Override" button.
Also, please read up the thread. One of our supporters, Jeremy has replied multiple times to this thread with the same answer. I am definitely not the first staff member here.
Making sure that the server is not overloaded or attacked is clearly to our customers advantage.
I'm not sure how you could argue that making sure the service works is purely to our advantage and not to our customers.
"Brute force" is a term that refers to password cracking, not denial of service attacks. Are you saying that a human manually tapping the refresh button 10 times in 10 seconds is enough traffic to be classified as a denial of service attack by the teamviewer network? That requires a lot more explanation before it will be plausible.
But if we assume that's true, that implies the teamviewer network is way too small to meet its demands due to being underfunded or poorly architected.
But let's assume that this network problem is actually intrinsic to all remote desktop systems rather than just teamviewer and any higher performance on other services is a result of them temporarily operating at a loss in order to try to compete with teamviewer. In that case, the development team should take a long hard look at the use cases "flaky or intermittent connection", "old or overburdened pc", and "intermittent pc uptime". It should be designed so people can connect and stay connected in these cases without having to manually poke the button until they get connected or banned.
Or they can just keep telling their PR people to spin it as a good thing.
I have to chime in and agree here. There are enough bugs and holes to jump through when setting up TeamViewer--multiple aborted logins are kind of par for the course. This timeout/security parameter should be left up to the user to adjust in Preferences; or there should be some quick way to override, like e-mail validation or 2-factor authentication.
I can't complain too much since I'm using the free license just for my home, but this happening to someone with a paid license during an important meeting would be a disaster. It really is something you folks should consider changing if you haven't already.
I am sorry but you (when I say "you" I mean the whole TV support who have answered to this thread) keep running away from the main point brought up here by most of the users.
I believe most people who have commented here will agree that WE UNDERSTAND the security need of this feature, HOWEVER, you cannot apply something like that WITHOUT warnings to the user. In ANY kind of system there will always be some kind of warning or notice that failure attemps will have a cost, and this cost NEEDS TO BE INFORMED.
If you could at least:
1) Warn the user BEFORE IT HAPPENS that after "x" attemps it will get locked out; and/or
2) Inform the user HOW LONG WILL TAKE to get the connection restored
If you would only apply those two things I am 100% sure that this thread (and others similar to it from my Google search about the issue) would be reduced drastically and less worry for you too. LET THE USER KNOW HOW IT WORKS in as much advance as possible, that's really simple.
I am not even going into the details of DoS technical details (as I agree with other users that this has nothing to do really with DoS attacks), just implement that and I believe most people will be happy.
I have a 12v paid license, and have been unable to help a staff of the company I am System Admin at because of that.
PLEASE LISTEN TO YOU CUSTOMERS, that's all.
I've been waiting for an hour and still cannot connect .
Ho wlong are we supposed to wait?
this is ridiculous.
Scotty and other admin - your attitude towards paying customers that are complaining about a feature that is clearly broken ( you guys state 10 minutes - some of us have to wait hours) isn't going un noticed. We are an MSP, have hundreds of remote agents and are now moving away from TeamViewer. Great going and we are going to make sure we let all of our other MSP's we deal with what garbage and **bleep** service you guys provide,
We had 3 remote nodes that have DEDICATED agents installed start doing this today. Client had an ISP issue which we were assisting remotely and since the connection dropped every few minutes we got "flagged" by this POS software and now cannot log in. Had to sign up for another service for remote support and since TV made us do that we are moving ALL of our clients to new solution.
This should really be changed to only count failed logins.
This limit just hit me when connecting to a flaky machine, I've disconnected and reconnected about a dozen times in the last two minutes and now it's telling me I have to sit and wait.
Brute force protection is a good thing, but valid correctly-authenticating connections are not a brute force.
I want to second this. I have a linux web server that I check every morning and every morning I need to attempt to connect to it between 3 to 6 times for TeamViewer on this server to "wake up" and start accepting logon requests. Sometimes it doesn't wake up and I exceed the number of times I can connect.
I agree that you need security but I now sit waiting for "some time" which may be 15 min just because my connection dropped and I pressed retry too often. SO..
I fully agree with implementing security, BUT let me access the management console and remove the lock in 1-2 min rather than wasting 15 min of my time and more importantly wasting 15 min of my customers time - I'm just losing money/time/patience, my customers are losing faith in me fixing the issues they have and thats far far worse.
I also note that any progreammer with a small brain could implement a try 4 times then sleep 15 min then try again process - this is not the right fix but thats another thing...
so in summary yes please do keep me and you secure but let me have some control rather than using the brute force method of a timeout.