App passwords are 16 characters long and only contain lowercase letters, so from a security perspective they are rather weak (according to my password manager).
But I guess a hacker, trying to guess passwords, would get blocked after a while, because he/she had too many failed login attempts. If that’s the case then the whole system is secure again. Is that the case with Runbox?
Hello. There is an argument against changing passwords regularly. Some research has shown that people change them for variations of the same thing or for weaker passwords they can remember in the short term. A strong password you can keep for a much longer period is better for a lot of people.
While I’m thankful for any replies they don’t seem to answer my question–because Runbox app passwords are 16 character passwords that are provided by the system, I can’t change them (unless I’m doing something wrong). And I tested these provided passwords with my password managed (KeePassXC) and this program said they are rather weak passwords.
And I agree with Dave that it’s not a good idea to change passwords regularly. A UK government agency states the following:
Regular password changing harms rather than improves security.
@Peter Sorry for not answering your original question. We are looking at increasing the strength of app passwords, but we also have to make sure they aren’t too long people won’t use them. Some people don’t copy and paste them and just need to be able to read and type them in.
Yes, failed logins do get blocked after too many tries.
I definitely agree with Peter, I had the very same question when creating my account.
I am a bit suprised by this point after reading on the Account Security help page about app passwords that
Their value is in the fact you don’t usually type them in each time you log in using an email app
I thought that it was a pity to weaken the security of all users because a minority of them who do memorize random passwords like akqgucoejpghyurb (maybe simply allow users to bypass the random generation and let them set their own password after the appropriate disclaimer?). But well if RB implemented measures to prevent brute force attacks, then I guess that indeed it’s ok.
Could you please clarify whether this apply to the 2FA unlock code (which is not stronger that app passwords) as well?
Thanks.
Just wanted to mention that after evaluating (too) many email providers, I am happy to have found at Runbox a very good offer which I can finally recommend. Please keep up the good work.
It’s always a question of balance. We could let people choose their own app passwords (does any other service do this?) but some will click through the warning and then set a weak one. The impact is wider than the customer’s own account because most often compromised accounts are used to send spam and that affects the reputation of our service and all customers are affected.
I’ll have to check on this. I think the 2FA unlock code is part of the overall log in process so if that fails then the same rules apply to that as an account that has now 2FA. In other words, yes, it does apply to that too but I will check.
Thanks for the kind words, they are much appreciated
Yes and no. The 3 other services i tried before Runbox have a different account system : main account with 2FA for administration only + mailboxes with password only. Since i’m not a webmail user, i didn’t mind having no 2FA but only an “app password” on my mailbox account, but obviously it would not be fair to compare this design to yours.
Good point. Keeping a good reputation of your SMTP servers is indeed a top priority (that’s the reason i left my initial provider for) and probably requires a lot of efforts. That said, i gues that you would apply to custom app passwords the same password strength valdiation rules as for the main account so they woult not be that weak (well, as weak as for users not used to good security practices, not using 2FA at all).