3 ms·

> #include plug for FastMail - we know what we're doing. At the risk of sounding too negative, er... well, do you? I'm a paid FastMail user right now, and aft

> #include plug for FastMail - we know what we're doing. At the risk of sounding too negative, er... well, do you? I'm a paid FastMail user right now, and after first signing up a couple years ago, I filed my first and only bug against FastMail last month about the inability to use spaces in passwords. (I feel like it should go without saying, but it's painful to have to use symbols instead of spaces on mobile, and even a bit jarring at a real keyboard, and it makes password input prone to typos.) What I got in response was some handwaving about the problem that amounted to a "REQUEST DENIED". (In truth, I did find that a bit frustrating. The free email service I also use that's notorious for offering no support finds spaces in passwords to be perfectly acceptable, but the one I have a subscription for won't let me? The one whose benefits are frequently touted as including, "Believe us, it's totally worth it. Look how you can talk to a real human being." If the choices are not being able to talk to a human being but not needing to, and being able to talk to one who doesn't accept that there's a problem, much less provide a solution for it, then the former pretty clearly wins out.) But the frustration from that ends up amounting to a minor one wrt the digression that the developer who was responding went on to write: > Probably later this year we plan to require client specific passwords for all external software. When we do that, we won't allow people to use their login password for IMAP/POP/SMTP/etc clients, you'll have to use a generated one. At that point, the only login place for your password will be the web browser Okay, so here's how my security setup works now: Create a very secure password, and then... just use it. Every time. I.e., do not ask Thunderbird to save it, and do not set up a client to receive messages on mobile. In the proposed new scheme, users will be forced to choose between memorizing whatever unmemorable thing the generator spews out for a non-web client, or enter it one time and set up their clients to save it. Which is no choice at all; the latter is effectively the only one available (see "unmemorable"). What this all means is that your pursuit of trying to make account access more secure actually ends up demanding that it be very un- The end result is that at some point "later this year", I'm going to have to take the same approach as noinsight and run my own mailserver[1], point my domain away from FastMail, and hope that my request for a refund will be granted due to the conditions changing during the middle of my subscription. 1. https://news.ycombinator.com/item?id=9790053 https://news.ycombinator.com/item?id=9790053

brongondwana 11y ago
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.
- carussell 11y ago
  I'll say the same thing I said in the bug: 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. How are you guaranteeing this?

brongondwana 11y ago

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.

carussell 11y ago
I'll say the same thing I said in the bug: 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. How are you guaranteeing this?