I’m trying to get through the Amanda setup for openHABian (openhabian-config menu 52). At some point it requires me to configure the “Mail Transfer Agent” exim4, points me to read:
I have some questions to this “guide”, as not everything makes sense to me. I also think exim should be optional, as I don’t think it’s a desirable or even viable option for many.
Mail server type: mail sent by smarthost (received via SMTP or fetchmail)
This doesn’t make sense to me on several levels. First of all, what is “smarthost”? A very brief Wikipedia article seems to indicate that it’s either an SMTP server or some kind of MTA, but this is all very unclear to me. The phrase “received via SMTP” is also confusing to me, as you usually send via SMTP and receive via POP3, IMAP or some other protocol. In any case, sending should be all that is relevant here. “Fetchmail” is also unknown to me, but it seems to be a software for receiving e-mail using POP3, IMAP etc - which again doesn’t seem relevant here. All in all, I’m not at all sure what information I’m supported to have to fulfill this point. The only way I know to send e-mails is using a SMTP server.
System mail name: FQDN (your full hostname including the domain part)
This doesn’t make sense to me either. The FQDN or what? Of the SMTP server or my local system? My local system doesn’t have a FQDN, but the information in parenthesis seems to indicate that it’s the FQDN of the local host.
IPs that should be allowed by the server: 127.0.0.1; ::1; 192.168.1.100 (replace the last address with your openHABian server interface IP>)
Other destinations for which mail is accepted: <hostname> <hostname>.<domainname> <domainname>
Machines to relay mail for: Leave empty or 192.168.xxx.0/24 (replace with your local network)
This is confusing as well. “be allowed by the server” is ambiguous, I assume that’s what hosts are allowed to send using this MTA, but it’s not entirely clear. These things also seem to overlap, what is the difference between “relaying mail for” and “be allowed by the server”?
The biggest problem with all of this is that I’ve got no available SMTP server to use, and I suspect that’s the case for many others as well. As I’m sure most of you know by now, Google requires OAuth2 authentication to use gmail now, which I very much doubt is available for exim4. Google requires the developers of the software to enter some agreement with them, which reportedly costs quite a lot of money, to receive “Google approved” OAuth2 tokens (or something like that). The end result is that, for all intents and purposes, gmail no longer work for applications not “approved” by Google. Using so called “app passwords” isn’t available unless you enable two factor authentication, which leaves you at risk of being “locked out” of your account the next time you lose your phone, it’s stolen, it breaks etc, which makes this an obvious no-go.
I know that it’s possible to rent SMTP server access from other providers, but is it really necessary to make this a requirement for backing up openhabian? I also think the documentation should describe this whole situation, it seems like more and more providers come up with ridiculous schemes like OAuth2 to prevent people from using “alternative software” for handling e-mail.
I haven’t tested if it also works to just cancel the exim setup process.
If you don’t want the ability to send mail from your system, just enter whatever you like so you get a non-working exim setup.
Well it would if you looked at it from another angle.
The guide just tells you what option to select, literally.
You don’t have to understand what a smarthost is.
All the terminology and setup code is from the exim Linux package/SMTP world. I know it’s confusing to many but way out of scope for openHABian to explain or adapt.
I don’t know all the details but as said it’s originating from the exim package not from openHABian so cannot be changed anyway. I guess it’s your box’s FQDN as it might be used as the host part in a mail address but I think it’s irrelevant to our use case.
No, actually. You can create (non-OAuth2) password tokens for your Google account for use with applications and use that as the password in exim.
I’ve added that info to the guide.
I wasn’t aware it requires 2FA (I believe it didn’t by the time I built/documented this).
But you can use some secondary fake Google account for that purpose if you like to have the ability to receive Amanda reports.
Happy to take any docs PR but to me that’s out of scope. I’ve already conquested various rabbit holes - exim itself being one - just to get this whole backup stuff working, now I’m tired.
It sort of works, but I’d say it’s confusing. I don’t remember exactly what I did, but I managed to back out of the exim setup as a result of not knowing what to fill in. After that it seemed to continue the “regular” Amanda setup, but since I thought I would end up with an invalid config, I aborted that too. The next time I started the Amanda setup, it never launched the exim setup, so it had probably already made some stub configuration that was enough for it to not trigger. Still, I (obviously) don’t have a working exim setup, and I think it’s pretty confusing. Wouldn’t it be better to just ask if the exim setup should be launched or not?
I see. It sure seems like the exim terminology is from the 70’s or something like that, when Internet was between universities and everybody had static IPs, FQDNs and everything was open and simple, but I guess it would all have made more sense if I had continued the setup and seen the actual questions. I still wouldn’t have anything to specify as FQDN though.
That said, I’m not expecting an explanation in SMTP or general terminology. I’m quite familiar with this, as I’ve run corporate e-mail servers in the past. What confuses me is both what I consider “strange terminology” and the fact that it’s not entirely clear to me what the information is being used for. Some of these things might be needed for receiving e-mail, which exim can do too as I understand it, and if that was clear to me I wouldn’t have to worry about them.
I think “lowering the bar” for getting through all of this would be desirable so that more users will be able to use the backup. I can’t even imagine how confused I would have been if I had no idea how any of this works.
I think you’re correct, I think it was true earlier, but that Google at some point decided to deny if to users without 2FA as an “incentive” to enable 2FA. It seems to me like they are hell-bent on forcing everybody to use 2FA anyway, they have already made it so that if you enable it, you only have 7 or 10 days to change your mind, or you’re stuck with it. I assume that they will simply require it at some point, and that gmail won’t be a viable alternative for those that don’t want to rely on an Android or iOS phone to be able to use it anyway.
Google is really the problem here, not all the existing e-mail software, but they have managed to capture a large part of the market by offering “free” (as long as they get access to all your e-mail of course), relatively unrestricted, e-mail for all these years. I tried to dig up my ISP’s SMTP server, and I managed to find some old documentation, but it doesn’t seem to work. Some years ago it would be pretty much unthinkable to not have a possibility for e-mail with your ISP, but I guess the lack of demand for this has made them drop this - and now Google has a lot of power over this.
I don’t think that’s an option anymore. As far as I know, they now require a (working) phone number to create an account, and they tie it to your phone number and your real identity using this. In any case, my long-term goal is to get rid of anything Google in my life, so I’m not tempted to sign up to anything Google that I’m not already using. In addition, the same limitations would apply (OAuth2 or 2FA), so I don’t quite see what it would achieve?
I understand. I’ll have to come up with what I’d consider a good solution before I’d want to advice others what to do, and there’s always the problem with the DCO that threatens to make any effort I make useless.
I’ve been considering simply running a simple mail server myself, which I’d use for various monitoring and just drain using POP3. It would have quite a few caveats though, both that I would get error messages when trying to fetch e-mail when not connected to my home network, and the limitations with POP3 itself (the e-mail is moved to the client and is no longer available on the server for other clients).
So, at this point, I haven’t gotten any further than once again cursing Google from promising not the be evil, and then turning out to be maybe the worst of them all…
That’s not the only way to set up TFA. There are several ToTP apps you can download to any of the supported operating systems. BitWarden (and I’m sure others) even has a command line interface. I’m not saying that you need to consider these, just pointing out that TFA does not necessarily require a phone.
Physical tokens like Yubi Keys also do not require a phone.
As with many things, if the free services do not provide what you want, there are alternatives. You can pay for an alternative service like Proton or set of a VPS and a domain name that supports email. There are other alternatives of course too. Google and Hotmail have the vast bulk of the market but no one is forced to use them. But you have to pay for that service if you don’t want them to monetize your use of the service.
As a security specialist I really do not think that Google requiring TFA calls into the category of being evil. There was very good reason why they did away with support for allowing apps connect to their servers, they were a source of constant attack and abuse. Reading your email to serve ads to you, that’s evil. Taking actions to secure their own servers and the accounts of their users, inconvenient for some but not evil.
I’m aware of the (usually grossly overprices) hardware dongles that can be used, but as I see it, that’s even worse than relying on a phone. I’d have to carry around a fragile USB dongle that would surely break after living in my pocket for some time. The USB plug itself is terribly fragile, so even if they made the housing waterproof and properly shock resistant, the plug will always be the weak point.
I’m also vaguely aware that there are some software solutions, although I haven’t studied what their limitations are. As I see it, any one such solution is fragile in its own way, and the only way to make it reasonably reliable would be to have at least 3 different TFA “code generators” registered. I haven’t been able to figure out what exact limitations Google place on this, what solutions they “support” and how many you can register at once etc. Given that they try to “trap” you in TFA, I’m not very tempted at activating it and risking not getting out of it again either, which would otherwise be the easiest way to find out exactly what is possible.
The fundamental problem with TFA, as I see it, is hard to get around though. I want to be able to do what I need to do by only relying on what I know, not what I “have”. So, if my house burns down or are taken by a flood, I don’t want to also be locked out of every service in this world at the same time. Yes, I know that I could rent a bank box and put some device there, but that’s simply one step further than I’m willing to go.
For me, “security” means first of all the security that I won’t lose my data and services. My secondary concern is that somebody else gets access to it, but honestly, when it comes to things like gmail, I have no faith that it’s private anyway. If I want to keep something private, I will encrypt it myself. The current “trend” in “security” seems to be only concerned with “unauthorized access”, while completely disregarding “loss of data security”. While that’s off topic here, you see the same with hard drive encryption schemes using TPM chips etc - it’s insanity - so many people will lose their data without understanding this before it’s to late. The “remedy” of putting everything in the “cloud” means that all ideas of “privacy” is null and void anyway, as whatever you put there is data that is really out of your control.
The one place where I would want something like TFA is for changing password. If somebody else is able to change my password, they can prevent me from accessing my own data, which would be what I am most concerned with. Still, the very principle of TFA, relying on something that you possess, is fundamentally problematic when maintaining access to your data is concerned.
If I could find a “properly redundant” solution, I could probably live with TFA though, but I don’t quite see how to protect yourself if everything you own is lost in some disaster.
Sure, you can buy anything with money. I’m not sure I agree that’s quite “fair” though. It used to be included in your Internet subscription, but these “free services” have largely made that option go away. The real challenge is the e-mail address itself, changing e-mail address is a real PITA that takes a long, long time to complete. I’ve done it once before, and I’m not planning to repeat it if I can at all avoid it. I don’t know how many hundred places it is registered, but it is many. This was always the problem with having an ISP provided address, ISP’s would come and go, you would switch ISP, and your address would keep changing. Hotmail and similar was never an option since they required you to use proprietary protocols or webmail. Google on the other hand, promised to provide POP3 and IMAP also in the future, and that was what made them so appealing to me at least. A paid service, in addition to often being unreasonably expensive (e-mail is an extremely simple/cheap service for them to provide if you drop webmail), doesn’t really solve the fundamental problem. I have no way to know how long this or that company is going to stick around, so I don’t know if I can keep my address.
A VPS wouldn’t solve anything either, it would be the same as running it on your own hardware: You are blocked from sending e-mail to the “big ones” like Microsoft or Google unless you server is “approved” by them. If you jump through a lot of hoops, you might be able to get them to open access for your server to deliver to them, but they will probably still flag everything that comes from it as spam. I’ve been down that road before, and it’s not very tempting. I already have domains I could use, that’s not where the problem lies. The idea that everybody would have to do this themselves simply isn’t viable.
As I see it, it’s the same old bullying from the “powerful players” to force everybody to comply with their terms, no matter how unreasonable. The reason I blame them is that they have made the other options that would otherwise exist disappear with a combination of bullying and offering it for “free”, and now that they have “shaped things to their liking”, they use this as “leverage” to blackmail people into compliance.
I’m sorry but I fail to see how this helps their “security”. First of all, it’s not Google’s loss if my account is compromised, it’s mine. They won’t care either way. Second, they still allow standard authentication if you accept TFA, so the potential for attacks is unchanged. I have no problem with them requiring SSL or other protocols as long as they are open and available to everybody. The problem is that they block access, like they have now done with OAuth2 by requiring each developers to enter agreements with Google, and to pay them money, to be able to use it: https://binaryoutcast.com/projects/interlink/release-notes/
As I see it, this has nothing to do with security and everything to do with control. They use their dominant position to shape the world as they like. I don’t know what their goal is with this, but I’m sure it’s not something that does us users any good. As with most restrictions imposed these days, “security” is merely used as a “trojan horse” to make people accept it without asking questions.
Why? When you register a ToTP (RSA Token, Authy, Google Authenticator, BitWarden, etc.) at the time of registration you also generate a set of backup codes. If for some reason you lose your ToTP app/device, you use one of the backup codes to log in and register another one. Each code can only be used once. That’s your backup. Print it out and put it in a safe place, put it in an encrypted zip file in the cloud somewhere, or what ever else make sense to you. You don’t need to register more than one ToTP. I’m pretty sure most services that support ToTP won’t let you anyway. But you can change it after the fact if you need to move to a different solution or, for some reason, you’ve lost access to an old ToTP provider.
The fundamental problem with that is there is only so much you can remember. For most people it’s pretty much impossible to remember unique passwords or pass phrases for every service they have to log into. That leads to password reuse which opens a huge vulnerability should any one of those services get hacked and expose that password. So such self reliance ends up causing new problems.
I’m not trying to convince you of anything but I think you are vastly overstating the fragility of TFA and understating the risks of avoiding it. But everyone has to make their own risk assessments.
Maybe based on what you’ve read or been exposed to but that is not usually the case. I can assure you that availability is given equal attention to confidentiality and integrity when it comes to research, design, and implementation both in academia and in industry.
Only if they are not taking backups which, if you care about your data is the absolute least you can do.
Only if it’s not encrypted. You should not put anything on any computer not your own that isn’t encrypted if it’s even remotely sensitive. But the thing is, if availability is your primary concern, these cloud servers are about as good as it gets in keeping data and making it available. You can’t hope to come close to the same availability numbers at home.
You call the service and say “I’ve lost everything and need to reset my account.” That will work for most important stuff like banks and the like, probably not for services like Google and Facebook.
You store your ToTP backup codes off premise. If your primary concern is your house burning down (e.g), keep a copy of your backup codes somewhere else. If on a cloud somewhere, encrypt it with a password you’ll remember. Then even in a disaster and you lose everything you own, those backup codes still exist and you won’t be locked out of anything (just make sure where you put the backup doesn’t require TFA to get back to it). Keep a backup on your phone which you are likely to have with you. Send it as a physical letter to a relative. Chisel them in stone buried in the back yard. Do all of the above and more. what ever makes you feel safe.
Much of the time you can also configure multiple TFA mechanisms (google supports four). So if you lose one, you can use one of the others. Unfortunately the others usually include SMS which isn’t the best.
I’ve been a gmail user since it was a private invite only service. I don’t recall them ever saying they would support POP3 and IMAP forever. Given Google’s track record, assuming that Gmail itself will be around forever is a bad bet. And they do still support POP3 and IMAP. You just have to deal with TFA to use it now. When Gmail first came out TFA was pretty much only something used on internal networks by banks, the military, etc. Now it’s considered the least a service an offer. Things change.
So buy a domain and set up the email service to use your domain.
Almost no one needs to do this though. Only those of us who run home labs and other types of stuff where we might need our home computers to email us have this problem. That’s a really small population.
It’s unreasonable to assume that such a small population of users, a collection of users who have the knowledge and skills to work around the road blocks, should trump a company from securing their free service for everyone.
It’s there loss too because they have a legal responsibility to take reasonable actions to safeguard their users and their user’s data. They also have a legal duty to safeguard their own services and servers.
There were active and unrelenting attacks that used the “less safe account login” against their users and themselves.
It is different because it doesn’t use your password. Each app get’s its own revokable password that is randomly generated (i.e. has nothing to do with the password you use to log in). That means, for example, some script kiddie can’t buy a block of emails with passwords from a data breach and try them out until they find a few that work. Then they can use those accounts as relays in a spam or phishing campaign. How would you feel about availability after Google freezes your account because someone has been spamming with it?
The potential for attacks is much reduced with the app password scheme, the mitigation is much easier, and the impact is much reduced because each password can be configured to only allow access to the Google service you want. It’s not all or nothing like before. For example, you can set it up to allow just access to Mail or Calendar or whatever.
Of course if you go through Oauth2 (which OH’s mail binding doesn’t support but it would be cool if it did and which costs nothing for an individual to use since the request rates for most of the APIs offer enough free requests to server an individual user without needing to start paying) the ability to refine what is allowed to be accessed is even greater (e.g. can send email but not read or access anything else).
Multi-factor authentication has been the recommended the minimum for sensitive computers/accounts by NIST and others for at least a decade. It’s standard practice across most industries. It’s required in government and military systems by NIST 800-53. Legally, for banks and HIPA related services, it’s required to at least offer it as an option. In the dozen years that I’ve done cyber security professionally I’ve yet to encounter a single professional who things TFA is a bad idea and I’ve encountered many who think it should be required.
For something as important as your email, which some banks asininely only offer as the only form of TFA, activating it is probably the least you could do to protect yourself as well. A common attack is gaining access to your email, calling your back to reset your password and then getting the authentication code from the email and then emptying your account.
TFA isn’t some new fangled scheme by Google and other big tech companies to screw over the little guy. It is an industry best practice and considered to be the very least they can do to protect their end users.
You clearly know more about the details here than me, so I can only explain my reasoning from where I stand. I could, and probably should, find out more of the details to educate myself better, but most times that I try to get to the bottom of something I usually end up having to read the standards. Reliable information, as opposed to just hype and anecdotes, are often hard to find. It’s not very tempting to sit down and read standards regarding a subject that really doesn’t interest me that much, and that is being “forced upon me” by others (Google in this case).
In any case, my reasoning is this: If “they” (whoever is the “issuer” of said ToTP device or software) can “recreate” the algorithm that will generate codes that comply with whatever sequence is “registered” with my “generator”, why can’t I do that myself? Why do I have to depend on somebody else to stick around for this? Also, who “counts” what code has been used and not? It seems like I’d have to trust “them” in some form. Any “security” system that is based on some kind of trust system that I don’t control (like the SSL CA hierarchy) is basically worthless to me. I can’t verify this myself, I just have to “take their word” for it - so what’s it really worth? I trust the average person on the street much more than I trust the average corporation or government.
Any code that I have to store which also make me depend on a third party isn’t really safety to me. On the other hand, if these codes in themselves contain everything needed to recreate the “generator”, aren’t they really just long passwords? If so, it seems to circumvent the whole basic “concept” of TFA. It sounds to me like you could just as well require two passwords then, and two passwords are no better than one as long as the total number of bits are the same, so what’s the point of the whole scheme then?
My main point is that I don’t want a ToTP provider though. If I had a need for one, I’m sure I could find a solution that I’d consider “reasonably safe”, depending of course on what I was going to use it for. When it comes to losing access to my e-mail, I just don’t see why I should have to accept any such risk (assuming that gmail doesn’t cease to exist, in which case I’m f… anyway).
The other thing is practical usability. An USB dongle is out of the question for me, I am “nervous” every time I have to plug in something USB for a short while, because I know how easy it is to break both cables and the ports on your motherboard if I happen to bump into it. I disconnect USB devices as soon as possible, and have to try to “remember” to be extra careful as long as they are inserted. So, basing my access to my email on such fragility is simply out of the question for me. Phones are also very unreliable, especially the so called “smart” phones. I can’t rely on my phone both being in working order, and being where I am when I need it. I’ve generally stopped wearing my phone with me since I had to switch to a “smart” phone. As I see it, a software solution would thus be the only reasonably practical solution for every-day use (I don’t know how often they will trigger the full TFA process, which would also play into all this). I can’t rely on a software solution to always be available when I need it though, as it will have to rely on some specific OS or whatnot to run. Thus, I’d need to have multiple different mechanisms to use, one that is convenient and used most of the time, and at least one fallback solution that is less practical but still possible to use.
I don’t think many such persons exist, but unique passwords aren’t required either as I see it. It’s up to each to have their own strategy for this, but I look at “how important” each service is to me before I decide how to handle it. For the most important things I have unique passwords. For less important things, I use passwords of different “levels” depending on importance and trust. If the “service” is a web page that I have no reason to trust not to “leak” my password, I will use a “low-value” password. I’ve found that the absolute vast majority of things I have to create accounts for, are of little of no importance to me if somebody “impersonates” me or in worth case changes my password and locks me out. Sure, it would usually be irritating, but it wouldn’t really matter beyond that.
I also think the whole problem of leaked passwords is a big problem with a simple solutions - if every password database used proper salts it wouldn’t be a real problem. This is an area where I would like to see laws. But, as usual, instead of putting the blame where it should be, it’s the users that have to bear the burden and the blame, by being labeled as “irresponsible” because they reuse passwords. This is also one part of this that makes me “resist” every time I’m asked to swallow some camels by losing my freedom to work as I want, having to spend money or live with cumbersome, impractical routines.
I’m in no doubt that it’s being taken into account for corporations, governments, the military etc - I would be shocked if that wasn’t the case. I’m talking about what they push onto us “consumers”. This is a non-issue when used to authenticate yourself with for example a corporation. In fact, I’m fully in favor of using TFA in such scenarios, because there’s no risk of being “locked out” there. If an employee lose their device or it dies or whatnot, they can get a new one by proving who they are. The “chain” can be reestablished. This is completely different with Google. They don’t care, they aren’t willing to spend resources on verifying that you are who you claim to be. If you fail to qualify by following whatever rules they dictate, you lose access - permanently. There’s nothing you can do about it, and that’s what makes all the difference. I have used TFA with my bank since I stopped going there physically, and if that wasn’t an option I wouldn’t have accepted that my accounts were available “online”. To be honest, I’m still somewhat uneasy that security isn’t good enough as it is with TFA, because I don’t have the full overview over how they deal with it internally (for good reason, the public shouldn’t be aware - but it still makes it hard to trust).
Come on, that’s just not fair. I’m one of the probably very few that actually make an effort in this regard, but it’s very impractical, not to mention expensive, to properly back everything up. I’m appalled by how bad the open-source backup tools I’ve tried this far are, and it’s pretty obvious to me that most people don’t do this. Tape drives are still the only really viable solution as far as I can tell, and they are super-expensive even second hand. Tapes aren’t that bad, but the drives and the SAS controllers are just out of reach for most people. For a backup to have any real value, it must be “offline” and go back some time. Otherwise, malware or mistakes can wipe out your backup just a easy as your original data. You also need to give yourself some time to discover that something is lost before the backup is overwritten.
I think it’s way to easy to just say that “if you don’t have a proper backup, you don’t deserve to keep your data” (I know that’s not what you said literally, but I’ve heard this so many times that it’s what is has come to mean for me). Sure, if you haven’t backed up (all) your data, you run some risk. If you use low quality drives, don’t run RAID or even worse, store your data on SSDs, you run an even higher risk. That still doesn’t give corporations the right to decide to screw you over and make sure that you lose your data in cases where you otherwise wouldn’t.
I had to “rescue” a laptop with a bad drive for someone not long ago, and I did what I always do - but the disk in another computer and do what I can to retrieve as much data as possible without writing to the drive. Most of the time (as long as it’s a HDD), I’m able to get most of the data out. This was the case here too, the user didn’t “miss” any of his data when I was done at least. But, the OS installation was a lost cause, it was impossible to save after having moved what was readable to a new drive. So, I finally had to give in and install Windows 10 from scratch. I don’t do that lightly either, because I know how it can take months to get every application set up so that you reach “full productivity” again. Regardless, I did so and installed and configured software to the best of my ability. To my big surprise, I discovered, quite accidentally, that Windows had encrypted the whole drive during installation, without mentioning it. It turns out that since I downloaded an “updated” installer and the motherboard had a TPM chip, this was just done “automatically”. I’m was outraged. Luckily I happened to notice it and removed the encryption, but if the same problem had occurred and the drive was encrypted, everything would have been lost. Even worse, if the motherboard containing the TPM chip would have died, all the data would also have been lost. This is the kind of thing I’m talking about when I say that they don’t seem to care for “data availability” for consumers, together with Google deciding to make people risk losing access etc.
Availability is my primary concern, but that doesn’t mean that I want all my data to be available for every corporation (willing to pay), every government and anybody that hacks either of these. Encryption is problematic when it comes to ensuring “availability” for the same reason as with the “tokens” discussed above. If you lose access to the decryption key, you lose all your data. As such, I prefer to store all non-sensitive data non-encrypted.
When you say that I can’t hope to come close to the same availability at home, I wondering if you’re talking about slightly different things. It’s not so much a problem for me if the data happen to be “unavailable” for a limited time, while waiting for spare parts of rebuilding something. What is a problem is to lose the data permanently, and in that sens I trust the “availability” of what I control much more than what any “cloud provider” can provide. Sure, they probably have better “hardware-safety” than I do, but: Many more factors can make me lose my data, they can go bankrupt, they can be sabotaged, and most importantly: I have no way to know how they actually treat my data. It’s not that long since I read about one of the big camera manufacturers’ “cloud” losing all the images of their customers. They were able to salvage the thumbnails… so at least you could have that as a reminder of what you had lost.
I’m not saying that I have a contract with Google where they guaranteed this. But at the time I picked gmail, my primary concern was to not have to change my primary e-mail again, and from what I could figure out, the signal at that time was that it would stay available. That was the basis for the choice I made at the time, and it was the basis for all the other people I recommended to switch to gmail.
I’m not saying that having TFA is bad - I’m not saying that having OAuth2 is bad. It’s all great for those that want or need it. What I think is bad is forcing it on everybody. I wouldn’t even complain if they required OAuth2 as long as they still allowed “app passwords” in combination. But they don’t. They used to allow “app passwords” also for non-TFA enabled accounts. Somebody made a decision to change that. How is this decision driven by security concerns? How come that they tighten the requirements and introduce pay-to-play at the exact same time as they block non OAuth2 access?
As I’ve said before, I don’t know what they ultimate goal is, but I’m pretty sure it’s nothing good. I don’t think they are done either, I expect things to get even worse than they are now - more restrictions and obstacles. I obviously can’t know for sure, but if it walks like a duck…
It is clear now that this is what I should have done 20 years ago. But I didn’t, because I (naively) believed Google at the time. Doing it now means that I have to change address again, which I haven’t yet “admitted to myself” that I really have to do yet.
That said, even having my own domain isn’t perfectly future-proof. As we have seen lately with greed creeping in from every direction, prices for domain names can suddenly increase a lot. So, it’s hard to know today if I’m able to afford renting a specific domain in the future. I have been of the opinion that our government should assign an e-mail address to each inhabitant for a long time, that we’re allowed by law to “take with us” just like we can with phone numbers. I don’t have much hope that it will happen though.
It requires a randomly generated seed which is protected like a password once registration is complete. That seed is like a private key in PKI. If you have the seed you have the credentials. To reduce the risk of the seed being compromised, many (but not all) ToTP clients will not make that seed available to you. But BitWarden will.
But then you have nothing more than a backup code. The only thing that’s different is you don’t have to register a new TOTP with the account if you lose the old one. You have a series of letters and numbers you need to backup somewhere.
You don’t. I personally run a self hosted VaultWarden which is an alternative FOSS implementation of BitWarden and works with all BitWarden clients. (Note the BitWarden server is also FOSS, I like Vaultwarden because it’s lighter weight).
I believe that KeePass has a ToTP plugin. The nice thing about KeePass is it’s serverless (though synchronization across devices becomes a problem.
What ever is authenticating the login. If you are using a backup code to log into Google, it’s Google who recognizes the backup code and strikes it from the list upon successful authentication.
It’s very easy to generate a new set of backup codes. In the rare cases where I’ve needed to use a backup code I’ve just gone ahead and generated a new set.
You are not giving “them” (not certain who you are referring to here) anything more than you are giving “them” with a password based login. You seem to trust passwords just fine. A backup code is just a password, salted and hashed on the server side like any other password. The ToTP seed is also hashed and salted on the server side I think (I haven’t looked into that).
And let’s assume that you are using a ToTP that’s totally compromised. You are no worse off than you are now because you still need the password. Since the likelihood that the ToTP is compromised is incredibly low (hasn’t happened yet but in the future ) you are significantly better off than using just a password alone.
Sort of. The backup codes definitely are. The ToTP codes are randomly generated passwords that only last for about 30 seconds. But if someone were to compromise the seed then they too would be able to generate the codes. This is why best practice is, once the ToTP is started up that the original seed is protected to the same degree that a login password would be on the server side and often made inaccessible on the client side (unless you write it down during the registration process).
When implemented properly, (i.e. the seed is “thrown away”) the time based code gets strongly tied to that device/service. If you have the proper code you’ve shown that you possess the device that you’ve registered and there’s your second factor. When implemented more loosely (e.g. like BitWarden does where you can get at the seeds and set up another ToTP generator) it is less strongly tied to the device registered and then yes, it’s more like just requiring a second password.
The backup codes are intended and expected to be printed off and stored somewhere safe so that they too become something you possess in a way.
But you are the one demanding that you want to keep the seed where you can see it. You are the one looking for ways to somehow control everything end-to-end in a way that weakens the security of the implementation. The way it’s supposed to be used is:
the seed is only presented at time of registration; in fact usually a QR code is used so you don’t even see the seed
once confirming the seed was successfully added to the authenticator app/service a series of ten or so backup codes are presented with instructions to print them out and store in a safe place
the authenticator app/service protects the seed as does the client
What risk are you accepting here though? That you will be locked out of your email? That’s what the backup codes are for. That you will be locked in to some third party app? There are tons of providers, including FOSS implementations, and you can move from one to the other easily. If you suddenly lose access to a provider, that’s what the backup codes are for (or alternative forms of TFA like SMS, you can have many different forms of TFA enabled but you only need to use one of them to get logged in).
Again, I’m not trying to convince you to change or do anything differently. But it irks me when people immediately jump to “Google is changing something, it must be for evil purposes”, especially when they are making a change that is considered by the computer security world to be a good move toward adopting what is already considered a best practice. And especially when incorrect assertions are being made about how it works and how it’s used.
All the major authenticator apps/services provide Windows, OSX, and Linux clients in addition to browser extensions and Android and iOS apps. Most of the apps you find require a third party service except for KeePass which is strictly local (which opens up new problems of synchronization between devices).
Usually the TFA is only required once per device (there’s a little “remember this device check box”) until you clear your cookies. After that first time you only need the password. The TFA is there to protect against new logins from new devices, though it’s best if you use it every time. But convenience needs to be weighted against security so this provides a happy medium.
And yet, I still assert if the one primary and most important thing you care about is availability, you have to have backups.
It’s not that they don’t care, it’s that you, me and our family are not their primary customers. For Google, the advertisers are their primary customers. For Microsoft, large businesses are their primary customers. They don’t make significant amounts of money from our purchases. It doesn’t help them meet their bottom line to cater to us.
So, if you care about most of this stuff, you’ll have to do some work on your own. We can cry and complain all we want but it won’t change anything.
So most users will get reasonable backup using stuff like OneDrive, Google Drive, Apple iCloud which happens pretty automatically. For everyone else, it’s gonna take some work. Whether it’s fair or not, there it is. We can pay (either through money or having our content monetized to sell adds) or we have to do the work ourselves.
They are not forcing it on everyone. They are forcing it on a small minority of users who were using an insecure and under active attack mechanism for authenticating third party software for access.
Because that login path was under direct attack. Google was spending a significant amount of time and effort playing wack-a-mole through that login path.
And the OAuth2 costs have always been there, or at least have been there for the past six years or so. That’s not new. They’ve always charged based on the number of requests through a given OAuth2 token.
I’m not sure that the need for some kind of monitoring is that rare. I agree that it’s definitely not “most people” that need it though, but I wouldn’t be surprised if it were maybe 2% of users, which is still a lot of users.
That said, the inability to use the SMTP server isn’t my main “concern” with this. It also limits which e-mail clients you can use to a select few, strangling many open-source alternatives for example. As far as I know, Thunderbird is the only open-source client that still works with OAuth2, and that’s because Mozilla is sufficiently large to make an “agreement” with Google.
As I’ve already said, I have a really hard time believing that this is motivated by “genuine concerns”. The reason is that I don’t think their “implementation” makes sense if that were the case. There’s no reason to not allow non-TFA accounts the use of “app passwords” (which is what is needed for alternative software to work). Neither does it explain the monetization bit.
When it comes to “legal responsibility” Google seems to be able to get away with pretty much what they want to, and this far no government has been able to contain them sufficiently as I see it (except maybe Russia and China, but they use “other methods”). So, as I see it, the law only applies to Google when it suits them.
As I’ve already stated, I fully understand the “benefit” of this, and I wouldn’t complain at all if they allowed non TFA users to use this. I think it’s great to use “passwords” without the ability to change the “master password” for example.
But, technically the login is the same as the “old one”, so when it comes to “protecting their infrastructure” I struggle to see the difference.
Again, I’m not arguing against TFA where it’s appropriate. I’m arguing against forcing it on people in situations where it’s not appropriate, like when the risk of loss of access is a bigger threat than the risk of “unauthorized access”, and where a reasonable protection against unauthorized access is still achievable by other means.
That is outrageous. I don’t even think my bank has my e-mail address, I have absolutely no correspondence with them using e-mail. If they give people access to other people’s accounts based on the control of an e-mail address, the bank is completely irresponsible and should face legal action - and be forced to bear the loss themselves.
If I were in such a crazy situation that I had no choice but to live with such a bank, I would absolutely use TFA and every other thing I could think of the protect my e-mail. But, that still doesn’t make it all-right to force it on all those that aren’t in that situation.
Ultimately, Google provides a “free” service to you (i.e. they make money from your data instead of you paying them). You are not forced to use their service. Google is under no obligation to provide any services to you, me or anyone else. The fact that you’ve come to rely on one way of interacting with their service and they’ve now changed things is, frankly, not their problem. It is their service, they get to dictate how their users (who are not their customers) get to interact with it. Their motives don’t matter. You follow their rules or you go elsewhere.
But, regardless of their motives, moving to requiring TFA is considered a good thing by pretty much every computer security expert in the field (government, academia, freelancers, etc.). It greatly increases the security of Google’s servers as well as our individual accounts and, despite your fears (which stem largely from ignorance) with no real risk to access.
You don’t have to use it, but every decision comes with a cost. In this case it comes with the cost of requiring you to do some work to access your gmail in this way:
set up TFA and create an app password
find or create an email client that lets you manually set up the OAuth2 with Google under your account; unless you are doing something weird you won’t be making enough requests for it to start costing (note this is different from something like Mozilla implementing the OAuth2 for you) OrangeAssist - Google Assistant Integration has an outline
set up an email account with some other provider and configure Gmail with forwarding rules to forward everything to that new account
It’s starting to become clear to me where we fundamentally disagree. I think it’s a risk if anybody else has the “seed” - you think it’s a risk if I have it. It helps if I have the “seed” because I’m not relying on anybody else to create a new “generator” if that is needed. But, it still doesn’t take away the huge liability that somebody else will have it. They can’t hash and salt these keys, they must be stored in a way that means that they can be decrypted if they need to be used, so it means that their storage is very vulnerable both to governments, hacks and I still have to trust the company not to sell it.
That’s interesting, thank you for the information. I will have to look into that if I end up being forced into TFA.
This comes back to the same point - i do not trust anyone else, especially (for profit) corporations. Having somebody else “guard” my seed and require codes from me to give me access to it, it’s safety in my view. It’s the opposite. They make it difficult for me to access, and easier for others (than me being the only one having the seed).
Merely having to store backup codes is a “potential compromise” as I see it. I never write down passwords, neither on paper or digitally. That’s my primary protection, the only way to get them is to torture me, in which case I probably have bigger worries. Having to have long backup codes that is as good as impossible to memorize thus represents a potential compromise. Not only do I need to make sure that I don’t lose these, I most also make sure that nobody else can access them. At the same time I have to trust some company out there not to give away or lose my seed. To me it just seems like a whole lot of trouble for little or no gain.
Let me explain how I view passwords. They are secure as long as nobody else knows them, and of course that the authentication implementation is sound so that you can’t bypass without knowing the password. I’m not giving them away, so that means that their remaining vulnerability is the hashes they are stored in (and, of course any storage where they are encrypted, which I avoid to the degree that is practically possible). Protecting them against brute force is easy for now at least, it just requires a level of complexity that makes it very unlikely that anyone will crack them. That leaves dictionary attacks, which you can also do a lot to protect yourself against by not using anything that would be likely to exist in a dictionary. Proper salting also strengthen both these considerably. If a hash algorithm is completely compromised, all bets are off, but it’s not a very common occurrence as far as I know.
So, to sum it up, any compromise to a password will come from the service that I want to authenticate with. I don’t trust them at all, which is why a “password strategy” that is a balance between risk and usability is necessary.
If I am to consider TFA completely compromised (because I can’t prevent my “provider” being compromised, and I can’t even trust that I will know if it is), all it represents to me is a lot of extra hassle and the potential for lockout. So, I AM worse off than without it. For TFA not to represent an “improvement”, it must more than make up for the extra risks and disadvantages it introduces.
In my e-mail where I keep nothing even remotely sensitive and use an unique password that I consider very unlikely to be brute forces or dictionary attacked, the sum for me is that this is a negative. The calculation might be different for others, but my evaluation for my situation stands. I also doubt that I’m the only one in this situation.
If the seed is thrown away, and you can trust that it really is (which isn’t easy), you will need an alternative method to reestablish the whole chain if the generator is lost or broken. Since that’s not an option here, such an implementation represents a huge risk for lockout. The only “mitigation” is fallback to SMS or whatever the alternatives are, but they also require a lot of things to be in place that I don’t control (like that I have a working phone, a working subscription, that the cellular network is working etc).
While these “fallback solutions” are necessary as long as there are no “manual” way to reestablish the authentication, they also weaken the security of the whole solution.
I’ve explained above why I want to control everything - it’s very simple: I’m the only one I can really trust, and to some degree persons to which I have a close personal relation. My trust in corporations is zero, and I don’t even trust that they will inform me if I am compromised. For any security solution to have any value for me, I must control the whole chain.
I usually compare it to the locks to our house. I’m sure you could pay some company to unlock your door remotely by identifying yourself with a camera mounted outside the door. I would never consider that though, it would both compromise who could access my house, and I would risk being locked out for a number of technical and human reasons. I just wouldn’t make any sense. The only way I can trust that the lock protects my home, is if I know exactly where all the keys are. If that’s the case, I might as well consider the door unlocked.
I’m sorry, I too didn’t think it mattered because the original topic was “sort of” resolved in the sense that it’s clear that “somebody” will have to sit down and figure out exactly what the parameters do before it’s possible to make the documentation clearer. I do see how the thread as it is now probably is more confusing than explaining to somebody looking for information on the “real” topic though.
There isn’t much overlap between the the topics, so it should be relatively easy for a moderator to split it and put the TFA/Google discussion in an appropriate place. Feel free to do so if you so wish.
I’ll try to be brief, although that’s noe exactly a strength of mine, but I want to answer at least some of the points raised.
Yes, that’s the only “risk” I’m worried about in this situation. Especially because so many other services use the e-mail as the “confirmation mechanism” if somebody else goes wrong. The email content I’m not that worried about, since I use IMAP and have everything cached on multiple computers.
I don’t disagree with that, I’m only saying that I don’t think that gives corporations the right to make decisions on users’ behalf that greatly increases the risk of data loss, end without any doubt in my mind will lead to a lot of unnecessary loss of data.
Frankly, I struggle to see how what you’re saying here and what I’m saying differ. I just didn’t explain why (I assume) that they don’t care, I just stated that they don’t. I never meant to insinuate that they don’t care about their bottom line, only that they don’t care about their users. As a user, not an advertiser, that’s what matters to me.
I disagree completely with the last part. Of course I will have to take my own precautions, but that doesn’t mean that I can’t speak out when I see something I think is wrong too. In fact, I am strongly opposed to the whole “don’t whine, just submit” attitude many people have. I believe that’s exactly how you let “evil” prevail.
This is the part of this whole thing that I react the most to, and that I often suspect to be the motivation for some of these moves (I’m not saying that this is the motivation for Google’s TFA enforcement, I’m not quite sure what I think their goal is with that yet). It’s clear that “the big cloud providers” are very eager to force, seduce or otherwise convince people to put all their data in their “clouds”. Since we know that they only care about money, they must have a plan to make money from this in some way, and I doubt that’s from getting people to buy expensive subscriptions for cloud storage. So, I suspect that they plan to use people’s data in ways that most people can’t even imagine, like “profiling” them and selling these “profiles” to the highest bidders so that they can be commercially or politically manipulated for example.
When I see things like “automatic encryption” of data that users never asked for, nicely presented as “increased security” without explaining the actual consequences, I associate one with the other. Call me “conspirational” is you want to, in light of what has been going on for years already, I call it being realistic.
No, they are forcing it on everybody, even if only a minority notices (I have no idea about the actual number). All those that already have TFA enabled or use OAuth2 capable clients, no longer has the option to make a different choice.
Here you’re starting to “irk” me a bit too. First of all, I think it’s “low” to refer to things you disagree with as “ignorance”. I fully understand and accept that you know more than me about the topic, but I feel that I know enough to make my risk assessment based on my criteria. I haven’t seen anything you’ve said make my assessment invalid, I’ve just seen to you see risk differently. I do not trust people I don’t know that are out to earn money, regardless of how “trustworthy” they claim to be. It’s simply worthless to me. You obviously see this differently, and it seems to me like you think that whoever has the most expertise on a topic, is the most trustworthy. Especially if they make a business out of it, then they just have to be trustworthy. We simply disagree strongly at this point, and I think that’s fine - I just don’t think ignorance has anything to do with it.
Also, I don’t need a “lession” i Capitalism. I know exactly what the “capitalistic rules” are (that you can basically do whatever you want as long as you can get away with it, if it serves your share holders). I just happen to disagree with it.
I’m not claiming that Google has broken the law, I’m not claiming that I have a legal case against them. I’m claiming that they behave immoral, which is completely different. I understand that the norms for what is moral and not also varies, I can only speak for my values. From my viewpoint, this is clearly immoral, and I think it borders a betrayal. I’m not claiming that they are unique in exercising such immoral behavior, on the contrary, they are in good company with many other big corporations. But, I must admit that I see Google as getting closer and closer to being “one of the top offenders” (in total, not with this issue alone).
If it’s “OK” to use your huge resources to wipe out most alternatives, and then turn around and exploit those “trapped” as a result, then it surely must be OK to do what Putin is currently doing with energy too. It’s quite similar after all. He has, by exploiting poor people and the environment, produced oil and gas cheaper than most others can for years. As a result, many other sources have stopped producing and shut down. Especially Europe, but also the world at large, have come to rely on the fact that Russian oil and gas serve “their part” of the market. This gives him leverage, which he now uses for all that it’s worth to try to blackmail the rest of the world into letting him kill, torture and rape Ukrainians with impunity. To me this is clearly immoral behavior, you seem to think it’s OK as long as he haven’t broken any “rules”.
It also quite common that corporations, organizations, people do things that we don’t think is OK without treating their customers badly. It’s not the customers that suffer when mining companies wreak havoc to the local environment with poison, flooding or a destroyed environment. It’s not the customers that suffer when animals are treated cruelly, usually the customer “benefits” because it makes the production cheaper. Likewise, it’s not the customers of human trafficking rings that suffer.
Most of us have no problem condemning actions that harm either their “products” (users, slaves, animals or nature) or third parties. You may choose to see it differently, but don’t try to claim that my moral judgment is somehow invalid or “based on ignorance”.
Wasn’t planning on replying at all but feel the need to address this one thing.
There is no shame in not knowing things (unless it’s willful). Much of your rejection of ToTP in particular seems to stem from not understanding how it works (which you stated more than once). That is all that I meant when I used the word “ignorance”. No offense was intended.
As for the rest, I think this discussion is over. I never was trying to convince you to change anything with the way you are doing things. My only reason for replying at all was to correct what I see as incorrect information and asserting motives which too, seem to come from not knowing much about the state of the art in computer security.
) you are significantly better off than using just a password alone.