So we have an FAQ link which amounts to "too many clients have bugs around spaces in passwords". I'm not as certain that this is true as it was when we instituted that rule, but it definitely was at the time.
As for the autogenerated password thing. You might have followed that Google are making it more and more difficult to "just use your very secure password everywhere" as well, because they find that it leads to a higher account compromise rate than per-device password or oauth. We also see a higher account compromise rate than we would like, and so we have to design our processes to be robust against human error and phishing.
What we might do for the zero point something percent of users like you is offer a way to re-enable password based login for clients (just like Google do) after you read a warning pointing out the security downsides of not having selective revokability and guarnteed non-password-reuse of device passwords.
I can appreciate the problem of people using clients that are broken, but why does this matter here? Thunderbird is not among them. So why are we discussing whether a customer would be able to successfully use their client to access the account of someone else who has spaces in their password? (Also, could you share the data you have about those clients?)
> You might have followed that Google are making it more and more difficult to "just use your very secure password everywhere"
I haven't followed this. Do you have a link? But again I ask: why does this matter? What do Google's actions have to do with using either FastMail or running your own mail server?
> What we might do for the zero point something percent of users like you
... uh?
> is offer a way to re-enable password based login for clients (just like Google do) after you read a warning pointing out the security downsides of not having selective revokability
Again, this is a way of responding to something that is completely orthogonal to the problem. Having control over the passphrase has nothing at all to do with whether you can or cannot issue multiple ones for use on different clients so that you can maintain revocability. This isn't a complaint from me, because this is never going to come into play for me given the way I'm accessing things, but it's so weird to continue hearing approaches like this that are, with respect to the thing being discussed, just... sideways.
> and guarnteed non-password-reuse of device passwords.
Google are doing it because the risk landscape has shifted from people signing up fraudulent accounts to people stealing existing accounts in good standing and using them to spam. You can rate restrict new free-trial accounts, but it's harder to rate limit long standing good accounts without annoying legitimate users - but once their account is stolen, that means a fair bit of spam can get out before reports come back or we can block the limit.
The zero point something percent comment - most users aren't at your level of proficiency - and we do have to play the percentages here. If 10% of our users get phished and their accounts used for spam, you can't send email reliably through us any more because we'll be on every blocklist in existence.
The vector for accounts being stolen is almost never weak passwords - it's phishing or viruses or password reuse. We just don't see people enumerating passwords. You flat out don't need a super strong password, it makes no difference beyond not using one of the top 1000 most common passwords (unless our entire password DB gets stolen, but that's a different class of risk - whole system vs individual)
Well, we can't guarantee that you don't go ahead and use it on another service of course, but by generating the device access token ourselves, we can be sure that you aren't reusing a password that you are using somewhere else.
You can already do this yourself, we support alternative logins, including one-time passwords - but as I said, it's about the percentages, we need to make it easier for average people so that more accounts are more secure.
Carussell: have you ever worked in first-line support?
To paraphrase a friend: "If I never hear the phrase: Why isn't my email working? I have an iphone...", I'll die happy."
I can appreciate that it's nice to be able to use space as a character, any reason you can't just substitute "." or "," on mobile (in terms of UX, obviously)?
Btw, I have no affiliation with fastmail.
> and guarnteed non-password-reuse of device passwords.
This should be easy to guarantee at creation-time:
For user A, all devices a...x
When generating a new device password p
Check p against all historical device passwords
for devices a..x
If no match, use p
Else generate p' and try again
When a valid (non-reuse) password has been found, it can be stored in non-reversible form (salt+hash, optional stretching).
I would too like to know what fastmail actually do, though.
As for the autogenerated password thing. You might have followed that Google are making it more and more difficult to "just use your very secure password everywhere" as well, because they find that it leads to a higher account compromise rate than per-device password or oauth. We also see a higher account compromise rate than we would like, and so we have to design our processes to be robust against human error and phishing.
What we might do for the zero point something percent of users like you is offer a way to re-enable password based login for clients (just like Google do) after you read a warning pointing out the security downsides of not having selective revokability and guarnteed non-password-reuse of device passwords.