Hello! I means that there is a risk of DOS attack on the remote users by sending of many password reset request. Such request can send without authorization anyone who know emails of remote users. I know that the CAPTCHA does not reliably prevent from such attack but this better than nothing. I think that You can add the CAPTCHA on the re-enter email window, which appears after pushing onto "Password Reset" button. Alternatively, You can to implement a restriction for a number of password reset request in the time interval. I understand that in each time only one link to reset password is valid, but if user recieved about 50 links per hour He will not be able to use the system. Thanks, Andrew
Comments Johan Allard LiquidFiles This has already been implemented in the form of blocking ip addresses after too many failed attempts. The default is to block for 15 minutes after 5 failed attempts within 5 minutes but is configurable (Admin -> Settings). Not a big fan of CAPTCHA's - they may have their place in much more public places like forums and similar but the likelihood of a CAPTCHA ever appearing in the Filetransfer appliance is very, very, very small. April 7, 2012, 16:52 Alexander I was not talking about the failed login attempts, and to prevent unauthorized successful not limited attempts to reset the password for an remote user. A large number of such attempts result in the inability of working of the user in the system. April 9, 2012, 16:35 Johan Allard LiquidFiles Me neither, at least not exclusively. The brute force detection works on the login, password reset and account validation functions. April 9, 2012, 16:48 Alexander How brute force detection works on the password reset? Password reset works without any authorization. Anyone who knows the address of the remote user can reset his password as many times per unit time April 9, 2012, 17:20 Johan Allard LiquidFiles The password reset function doesn't actually reset the password, but emails a link that when the user clicks on the link will prompt them to reset the password. So as long as no one else have access to the email of the targeted user, nothing will happen with that users account and they can continue to use their existing password. April 9, 2012, 17:59 Alexander Well, but the level of training of users, especially remote, very low, and they will click on the reset password link, instead of working. April 9, 2012, 18:16 Johan Allard LiquidFiles A captcha would not have replaced any of the current functionality. We would still have needed to send an email to confirm the identity of whoever requested the password reset. So a captcha would only have made things more complicated than they are now. April 9, 2012, 21:45 Alexander I don't ask You to replace any current functionality for CAPTCHA, I would like to extend anti-DOS mechanism with CAPTCHA. I see the following dangerous moments without CAPTCHA: 1. Anybody (not a user of system) can to initialize the password reset for external user - without any authorization! So, external user will recieve many links to password reset - this is a DOS attack for single external user. 2. Any group of computers can initialize the password reset for many external users (by trivial script) - this is a DOS attack for File Transfer system. There are not any settings to prevent a large number of password reset requests for a single user or to system. April 9, 2012, 22:18 Johan Allard LiquidFiles 1. Why wouldn't someone take their farm of attack computers and send emails directly where the emails would be randomized instead of sending through the Filetransfer appliance where every single email would be from the same system user, formatted in the same way so that they would be trivial to filter an delete. The attack would just be much more expensive to perform than the obvious attack directly. Or they could employ 100 workers in a 3rd world country at $2/h to send password requests, captcha or no captcha, at least a few thousand every hour, that would be way cheaper and a captcha wouldn't solve the problem. 2. No it isn't. Serving up the password reset page is not resource intensive in any way and sending emails is not resource intensive. If someone would want to attack the Filetransfer appliance with a DOS attack, it would be much better aimed at a place which doesn't have any bruteforce protection at all, or just the front page if they wanted to consume bandwidth. Actually, adding a captcha anywhere would consume more cpu to generate the image so that would make the DOS attack much easier to perform rather than without. Again, a captcha would just make the problem worse than without, and be annoying for users. The only place where I could see a captcha be useful is with places like Gmail where they saw that people started generating random email addresses to send spam with. Adding a captcha made it much more expensive to do so (until you figure out that $200 for 100 workers at $2/h can create a lot of accounts in little time and is a lot cheaper and easier than building computer systems). But there's an actual end gain for the attacker (send spam through legitimate servers hosted by Google) and they waited until there was an actual problem. They didn't start annoying their users until they had to. With the Filetransfer appliance, if someone wanted to send an email, they can just do that directly through your email system. That's a lot easier than sending it through the Filetransfer appliance. Or have you actually seen this attacks on the system? Someone trying to DOS the Filetransfer appliance by sending password reset requests? April 9, 2012, 23:18 Alexander I see that You permanetntly against CAPTCHA... 1. I mean that I need to close any whole to prevent unauthorize sending mail to our external partners using OUR resources. If anybody can directly send spam to our external partners (without using our Company resources), it's a problem of external client and his internet provider. If attacker use OUR resources, it's MY problem. 2. You review the professional hacking - I revew an individual hooligan or non-professional small groups of teenagers. They never to pay to 100 workers, they will write bad (but own) script. Well, if You don't want captcha, can You to implement of restrictions of password reset request number for one external email for a time period? April 9, 2012, 23:53 Johan Allard LiquidFiles I am, I have yet to see a use case where captcha's increase actual security, rather than solving perceived security problems with no actual threat behind them without making things worse in the process. The problem with the theory of hooligans or non-professional small groups of teenagers is that there's nothing for them to be gained. They will send a lot of emails yes, will they see any evidence of it? No. Will the bring the system to its knees? No. Will anyone know what they did? Well, one person, who will in worst case contact support before marking all and hit delete. That's hardly a great threat, sure, it's annoying, but it's hardly a threat. And as you can see from the release notes, the Filetransfer appliance is constantly improved, in various aspects. Security being one of them. Limiting the response rate to an individual recipient makes sense and is likely at some point to make it into the product. The more people that vote for the feature the more likely it is to happen and sooner. It's not going to make it into the next major release, but we'll see after that. April 10, 2012, 06:37 Johan Allard LiquidFiles Actually, enabling bruteforce detection on successful password reset attempts turned out to be trivial so that will be included in the next release. And I'd say that's as good as this is going to get. If someone launches an attack, they will be able to send 5 emails every 15 minutes. This is for something that's a nuisance at best and not really a problem. And if you wildly disagree with this assessment I suggest that you upgrade to the latest version and turn off all remote user accounts all together and store all accounts in LDAP. No local accounts - no password resets. April 10, 2012, 10:10
