What are all the available 2FA/2SV/MFA/MSV options for 3rd-party mail programs to log into Google mail servers after May 30th 2022 - General Questions and Answers

With the Google changes after May 30th, 2022 of requiring OAuth2 or 2FA/2SV/MFA/MSV authentication to log into the google mail servers using a third-party mail client but with OAuth2 requiring monetary hurdles for free app developers, what that means is we may need to consider some form of 2FA/2SV/MFA/MSV if we don't want to use OAuth2 (or, in my case, where I can't use it because it creates a google account on the phone in most implementations).
I believe that 2FA/2SV/MFA/MSV can be a variety of "different things" but I'm almost completely unfamiliar with what those multiple "else" things might be.
Can someone help us flesh out _what_ those multiple MFA things might be?
Here's a list I came up with searching about where I ask others to help flesh it out so that we each have a list of what our choices might be.
1. OAuth2 (usually using an on-device Google Account), or
2. Autoforward Google mail to a non-Google account, or,
3. 2FA/2SV/MSV/MFA via a variety of authenticators, such as...
a. app passwords
<https://support.google.com/mail/answer/185833>
b. Some kind of "2FA/2SV/MSV/MFA authenticator" app
<https://support.google.com/accounts/answer/1066447>
such as...
FreeOTP Authenticator
<https://play.google.com/store/apps/details?id=org.fedorahosted.freeotp>
Google Authenticator
<https://play.google.com/store/apps/details?id=com.google.android.apps.authenticator>
Authy
<https://play.google.com/store/apps/details?id=com.authy.authy>
FreeOTP+
<https://play.google.com/store/apps/details?id=org.liberty.android.freeotpplus>
etc.
c. USB tokens
d. Time-based one-time passwords (TOTP)
e. SMS 2FA
f. Use the phone's built-in security key
<https://support.google.com/accounts/answer/9289445>
g. Use a physical "security key"
<https://support.google.com/accounts/answer/6103523>
h. Get a one-time security code from another device
<https://support.google.com/accounts/answer/2917834>
i. Enter one of your 8-digit backup codes
<https://support.google.com/accounts/answer/1187538>
j. Sign in using QR codes
<https://support.google.com/accounts/answer/9283368>
k. Set up a "trusted computer" for sign in
<https://support.google.com/accounts/answer/2544838>
l. Sign in with "google prompts"
<https://support.google.com/accounts/answer/7026266>
m. Any others?
I realize some of these may be duplicates and others may not apply so that's why I ask others to help flesh out for everyone what exactly are the 2FA/2SV/MFA/MSV options available after May 30th 2022 for third-party MUAs to employ.

Related

Dashwire - Is it secure?

I have an account with Dashwire. I like the service, but worry that it does not seem to be a secure site. Does this mean that it is possible that someone could see all the associated data (like contacts and texts) on my phone if they are able to hack the Dashwire website?
From their website:
Dashwire said:
In the event that you place an order through the Service, your credit card information will be encrypted using SSL technology before being transmitted over the internet. Because any other personally identifiable information you submit to Dashwire is purely voluntary and should not be of a particularly sensitive nature, we employ our standard security measures with respect to this information and do not use special encryption methods at this time. Dashwire user accounts are secured by user-created passwords and HTTPs when signing in. Please note that Dashwire cannot guarantee the security of user account information. Unauthorized entry or use, hardware or software failure, and other factors may compromise the security of user information at any time.
Click to expand...
Click to collapse
While I can understand a disclaimer or two, to me, that's a pretty bold statement that security isn't a number one priority.
Especially when I log into http://my.dashwire.com/ it is not a secure site, which tells me that neither is the information it pulls from my phone.

Trust Google Drive??

http://www.askmen.com/entertainment/tech-news/google-drive-licence-agreement.html
Gets u thinking actually. :-\
Sent from my epic touch with plenty of ICS treats to go around!
Wow that's crazy, will uninstall it now !
Thanks for the link !
You should probably read this. http://www.theverge.com/2012/4/25/2973849/google-drive-terms-privacy-data-skydrive-dropbox-icloud
Don't believe the hype. They need to have permission to use your content to provide services that process, index, copy to servers, translate, display, etc...anything they do to provide the service needs to be covered in legalese.
The part they gloss over in the "be very afraid" blog posts and articles is that "The rights that you grant in this licence are for the limited purpose of operating, promoting and improving our Services, and to develop new ones."
They also don't mention that the associated privacy policy that also governs how your information is used explicitly states that your personal information is not used for purposes outside that policy without your consent.
http://www.google.com/policies/privacy/
But if anyone is worried at all about keeping their data in the "cloud," they should honestly trust no one. Unless they are encrypting your data before storing it, all the services need the same permissions...Dropbox, iCloud, etc...
http://www.theverge.com/2012/4/25/2973849/google-drive-terms-privacy-data-skydrive-dropbox-icloud
Everyone can make their own choice, but I'm not concerned. I wouldn't keep truly sensitive materials in ANY unencrypted repository. For everything else, these solutions are mighty convenient and secure enough for me.
Unprompted install, exfiltration route
So Drive is now on my device although I never asked to install and never even heard of it until I saw it as an active task. com.google.android.apps.docs
Now we have an unprompted install that provides a direct connection to Google docs without prompting for login credentials. (It is apparently using the login for gmail as a universal login).
So without any action on their part or any notice, a user's entire Google Docs can exfiltrated by compromising their phone. Nice.
It is so easy for a user to get taken by accident. Many don't know that when they preview attachments in gmail they can go to Google Docs and they certainly won't know about Google Drive on their Android as it doesn't even drop an icon during an unprompted install.
Drama much in here?
You're already using an Android device, which is linked with your Google account. Google recently updated their Privacy Policies so that it is now the same across the board. Your Gmail account has the same Policy as your Google+ account, your Youtube account, your Google Voice account, your Google Reader account, and (wait for it....) your Google Drive account. If you're okay with the policy as it applies to the content stored in your email, why is the policy as it relates to file and document storage an issue?
And, as has been mentioned in posts referencing the Verge article, the file storage policies are pretty much the same with the other major cloud storage providers - iCloud, Windows SkyDrive, Dropbox, etc. Your data remains your data, and nothing will be done to disclose it.
As for an "unprompted install", I'm going to guess that you previously had Google Docs installed. When Drive went public, it was also announced that it was essentially a continuation of Docs - an update, if you will. When you installed the Docs update from the Play Store, you automatically got Drive. Congratulations.
If your phone gets compromised, the bad guy would have access to a lot of juicy data in addition to just your Google Docs. Your Dropbox, for instance, would be unprotected. As would your Gmail, Calendar, Contacts, work email, Latitude history, Google+ posts, stored passwords in your Browser, etc. Let's look at this realistically and not just panic over a sensationalized story.
Hi, i'm in Italy and i speak quite well english, i have to say I'm using google drive from 6 days ago and I've never had any problem with my files so i Trust and if u saw the last internet privacy policy of google in the begin of 2012 we should have saw they don't computing or manipulate our file, simple check the integrity of the sequence of bit stored in the cloud... sorry for my totaly bad english, I hope I was helpful... thanks for consider my post...

[Q] Is there a way around Exchange email -no root- rule

My employer just opened up Android native email capability (to receive work email, calendar, apps) for my Note i717. Problem is, they won't allow Rooted devices.
I know there's several (6 I think) security certificates that get installed, but I was wondering if there's a way around this no-root rule.
1. If I unroot, get all certificates installed and then re-root will it nullify the certs?
2. Does anyone know enough about certs to answer if they're something that can be backed up and restored if I move to a different ROM in the future?
I've scoured the forum and have found info on bypassing the credential logins, but not pertaining to these questions above. Answers would be greatly appreciated.
It isn't really a rule...depending on your environment
b3furuya said:
My employer just opened up Android native email capability (to receive work email, calendar, apps) for my Note i717. Problem is, they won't allow Rooted devices.
I know there's several (6 I think) security certificates that get installed, but I was wondering if there's a way around this no-root rule.
1. If I unroot, get all certificates installed and then re-root will it nullify the certs?
2. Does anyone know enough about certs to answer if they're something that can be backed up and restored if I move to a different ROM in the future?
I've scoured the forum and have found info on bypassing the credential logins, but not pertaining to these questions above. Answers would be greatly appreciated.
Click to expand...
Click to collapse
Unless your company is using a type of MDM platform (Codeproof, Good, MobileIron, AppSense), they will not be able to detect that you have root access to your phone. Some companies instruct users to install a separate MDM application in order to access their email. Most Exchange servers can be connected to without installing the MDM software. If they don't force an MDM client, they won't know you are rooted.
Depending on the version of Exchange, you can use a 3rd party email app like K-9 to access the email which would also bypass the additional security policies that will be installed if you were using the built-in Exchange support. I use Touchdown, therefore the app is protected by a PIN but not my phone, so I can still unlock the phone without having to type a 6 digit number every, single, time.
The way I see it, the company's data is still protected, and I am not overly inconvenienced, it is a win-win.
Unless your company is using a type of MDM platform (Codeproof, Good, MobileIron, AppSense), they will not be able to detect that you have root access to your phone. Some companies instruct users to install a separate MDM application in order to access their email. Most Exchange servers can be connected to without installing the MDM software. If they don't force an MDM client, they won't know you are rooted.
Depending on the version of Exchange, you can use a 3rd party email app like K-9 to access the email which would also bypass the additional security policies that will be installed if you were using the built-in Exchange support. I use Touchdown, therefore the app is protected by a PIN but not my phone, so I can still unlock the phone without having to type a 6 digit number every, single, time.
The way I see it, the company's data is still protected, and I am not overly inconvenienced, it is a win-win.
Click to expand...
Click to collapse
Apologies, I did forget to mention they instruct to install Mobile-Iron.
Their process is such:
1. Install Mobile-Iron
2. Encrypt Device & set 6 digit pin
3. Install Certificates
4. Email configuration
5. Sync email, calendar, clients to phone
They do note "If your device is rooted, this process will not complete successfully."
Reviewing the steps, it looks like the whole process is done within Mobile-Iron.
No dice so far
Still can't find anything on the net for this. If anyone can help answer this I'd greatly appreciate it.
I'd love to be able to check on emails without having to open and boot my laptop. Also, it would be great to have my calendar sync so I don't miss meetings.

SplashID v7 upgrade security issue

Besides the issues SplashData has with their SplashID v7 android upgrade losing many customers data, there is also a very worrying security issue which splashdata ignores = and actively censors, my messages regarding this on their FB page have been deleted and I am blocked from commenting our writing there)
Here is the issue:
The new SplashID version 7 had a cloud sync feature (30 day free trial, then for a fee). When first starting the upgraded version (which may have been installed automatically on Android if one allows auto upgrades!), one first has to again enter one's email address/username, and then the password (which is the one used to encrypt one's database containing all one's private, sensitive data!). Then the upgrade asks whether one wants to try the cloud sync feature.
Even if one declines and opts to stay with the existing Wi-Fi sync feature only(which does not need a cloud account), the upgrade goes ahead and automatically creates such a cloud account on splashdata's servers.*and it uses the same password* for this. (In fact as further part of the upgrade procedure one needs to log into those cloud servers using that password after receiving an activation link in email.
So, splashdata leaks the master password which one uses to secure one's most private data (credit card pins, login password etc) into their cloud, without telling that this will be fine, not asking permission.
There is no info whether the password is stored securely (doubt it), whether it is in ask cases transmitted securely (doubt that too) and anyhow, once this has happened one had lost control over that most important password. It's burnt.in the wild, out of one's own control
Note that changing the password on one's own copy of SplashID us a good idea after that, but any old copy of one's encrypted database that might still live on any old disk backup, cloud service (dropbox etc) or SD card somewhere, us now vulnerable.
And because splashdata in their 'wisdom' associated one's email address (and thus identity) with that password, it's easier for hackers to fund it.better companies than splashdata have lost password in the past.
It is even a very bad idea to user the same password for s cloud service as one uses for securing one's private data. Forcing this into users without permission or warning is almost criminal.
Sent from my GT-N7000 using Tapatalk 2
sejtam said:
Besides the issues SplashData has with their SplashID v7 android upgrade losing many customers data, there is also a very worrying security issue which splashdata ignores = and actively censors, my messages regarding this on their FB page have been deleted and I am blocked from commenting our writing there)
Here is the issue:
The new SplashID version 7 had a cloud sync feature (30 day free trial, then for a fee). When first starting the upgraded version (which may have been installed automatically on Android if one allows auto upgrades!), one first has to again enter one's email address/username, and then the password (which is the one used to encrypt one's database containing all one's private, sensitive data!). Then the upgrade asks whether one wants to try the cloud sync feature.
Even if one declines and opts to stay with the existing Wi-Fi sync feature only(which does not need a cloud account), the upgrade goes ahead and automatically creates such a cloud account on splashdata's servers.*and it uses the same password* for this. (In fact as further part of the upgrade procedure one needs to log into those cloud servers using that password after receiving an activation link in email.
So, splashdata leaks the master password which one uses to secure one's most private data (credit card pins, login password etc) into their cloud, without telling that this will be fine, not asking permission.
There is no info whether the password is stored securely (doubt it), whether it is in ask cases transmitted securely (doubt that too) and anyhow, once this has happened one had lost control over that most important password. It's burnt.in the wild, out of one's own control
Note that changing the password on one's own copy of SplashID us a good idea after that, but any old copy of one's encrypted database that might still live on any old disk backup, cloud service (dropbox etc) or SD card somewhere, us now vulnerable.
And because splashdata in their 'wisdom' associated one's email address (and thus identity) with that password, it's easier for hackers to fund it.better companies than splashdata have lost password in the past.
It is even a very bad idea to user the same password for s cloud service as one uses for securing one's private data. Forcing this into users without permission or warning is almost criminal.
Sent from my GT-N7000 using Tapatalk 2
Click to expand...
Click to collapse
Ouch, that sounds a bad idea. If the user doesn't want a remote account made, they should respect that. Can you give me any more details about this, I would like to contact them and request some proper response to this. While they might not be leaking the plaintext password, anything that can be "opened" with your password is a significant enough leak, as it would allow an attacker to verify they have the right password.
pulser_g2 said:
Ouch, that sounds a bad idea. If the user doesn't want a remote account made, they should respect that. Can you give me any more details about this, I would like to contact them and request some proper response to this. While they might not be leaking the plaintext password, anything that can be "opened" with your password is a significant enough leak, as it would allow an attacker to verify they have the right password.
Click to expand...
Click to collapse
Not much more that I already said. I am a long-time user of their SplashID (Mac) Desktop and Android app to store all my credit card, bank acount and yes, many systems passwords in.
The database they use is encrypted with a 'master password' which one has to enter on ones' Android (or iPhone, etc) or Desktop everytime to
unlock and decrypt (in memory), so that one access the data.
The same password is used on both the mobile and desktop of course.
A few days ago, an upgrade to SplashID v7 was made available on the Google Play store. I don't allow 'automatic' updates (though I am sure a lot of folks do!), but this time I also did not really check what the upgrade offered, and clicked 'UPDGRADE ALL' when it was offered along with a nunber of other upgrades. So it got installed.
When i subsequently opened SplashID again, it told me about all the shiny new features (cloud sync etc) and as normal asked me for my password (it also asked for my email address. I though that this was for them to check my purchase/license ans what features woudl be enabled)..
I thought that it would then show me my data. But wrong. Instead it offered me a selection whether I want to use the new 'cloud sync' feature (30 day free trial, later for $$), or stay with the normal 'wifi sync'.
I opeted for the latter (because I don't trust having my data sent to the cloud).
Anyway, the next thing I get is a message: (paraphrasing) "we have created your cloud account, you will get an email and will have to verify your email). Sure enough, I get an email:
Thank you for signing up for SplashID Safe Personal Edition!
To activate your account, please verify your email address by clicking the link below: Verify Email
Then check your email for our SplashID Safe Welcome message.{/QUOTE]
The link goes to: https://www.splashid.com/personal/webclient/login.php
I had to again ther enter my email address, and *the same password* that I entered before (which I thought would be for my private data-store).
Yes, that same password was used to create my account on their cloud server, even though I opted for the Wifi Sync *only* and never
asked for a cloud-sync.
Nor did the app tell me that the same password would be used to secure that aco****.
The issues with this are self-evident:
a) my most secure password, the one used to secure my data on my mobile and on my desktop is now 'leaked' to their cloud account
b) I have *no* idea how secuerly that password was transferred (in clear, encrypted, just a hash), nor how securely it is stored
c) it clearly is linked to my cloud-account on their website, so
- someone somehow learning that password could 'verify' it by accessing that account
- if someone hacked their system and accessed their database, that link would be apparent to them
d) I have nost *all control* over securing that password myself. It is 'burnt', 'in the wild'
e) Any pass backups of my secure SplashID database that may live on SD cards of mine, on backup disks, which may have
been copied to the cloud (dropbox, others) are now vulnerable. It is no use for me to change this password here now, as
old copies that may still exist somewhere are still encrypted with this password (and I cannot change them back).
Yes, I am trying to limit exposure for that password data file as much as possible, but eg Titatium Backup may have at some point in teh past backed it up and copied a backup to the cloud (yes, that is also encrypted, but once that featire failed).
More that that, of course users who are not as security conscious may have opeted for 'could sync'.
While I have not tried this feature myself, it sounds to me like thsi does copy the teh data to SplashID's cloud and
there secures it too only with that one single password.
So many users wh may not have thought all this out may have opted for the 'CloudSync' trial, and not only have their
password 'leaked'/'burnt' now, but also have all their data in the cloud, again secured only with a password that is no longer in their sole possession.
In fact, any secure, trustworthy system would have
a) been *very* upfront about what they are going to do with the password and the cloud account
b) used a separate password to secure the cloud account
c) only stored my encrypted copy of the database in their cloud, without *them* having the password for it
d) done any syncing on the client (ie, transfer the complerte encrypted password to the mobile or desktop where the comparisonupdates would happen) and then copied back again a secured file, that was encrypted on the mobile).
Click to expand...
Click to collapse
More discussion on SplashID's own site: http://forum.splashdata.com/showthr...ically-send-in-background-to-splash-id-server

Can you migrate Authenticator app data to new phone?

I'm planning on getting a new phone in the next few months. I'm a windows 10 hold out. One of the main reasons holding me back besides finances right now, is the microsoft authenticator app, which I use very heavily for personal and work. I probably have over 20 accounts setup.
I know I will have to disable and setup TFA again for all those accounts on on a new app with whatever device I ultimately end up with. But I'm wondering. In the future going from android to android device, is there an easier way to migrate authenticator apps?
I've never used the Microsoft app but I think it uses a standard method similar to Google Authenticator and others:
https://en.wikipedia.org/wiki/Time-based_One-time_Password_algorithm
You might be able, somehow, to export the secret key and other parameters (these could be common defaults).
But I bet apps don't allow that easily in order to protect it from unintended disclosure.
Maybe there's a way to sync to an online Microsoft account, and from there sync the new phone? Microsoft Authenticator is available also on Android.
What I do when adding the info for a new account is write down the secret key, and any other parameters, in a password manager. From there they can be entered into other apps, or used directly.
hkjo said:
I've never used the Microsoft app but I think it uses a standard method similar to Google Authenticator and others:
https://en.wikipedia.org/wiki/Time-based_One-time_Password_algorithm
You might be able, somehow, to export the secret key and other parameters (these could be common defaults).
But I bet apps don't allow that easily in order to protect it from unintended disclosure.
Maybe there's a way to sync to an online Microsoft account, and from there sync the new phone? Microsoft Authenticator is available also on Android.
What I do when adding the info for a new account is write down the secret key, and any other parameters, in a password manager. From there they can be entered into other apps, or used directly.
Click to expand...
Click to collapse
Yes it uses the same method as the Google app. I don't have any loyalty to the Microsoft app, that's just what was available for me on Windows. But sadly, no they don't have any MSA sync feature, otherwise I would gladly keep using the Microsoft app on when I do make the switch. I do jot down the secret key or the extra one use passwords when available, but there are several that don't offer one and you just take a picture of the QR code. Or at least, I didn't notice it.
But mainly my question is: Is there an authenticator app, be it google or some other brand that will actually migrate the TFA stuff from device to device. I've gotten so used to using TFA but now that I have so many accounts, it's a task I dread, having to deactivate and reactivate TFA just because I need to upgrade my device.
Here's one password manager that's supposed to support TOTP:
https://play.google.com/store/apps/details?id=keepass2android.keepass2android
It's probably more complex to use than stuff like MS/Google Authenticator.
A short search on the web suggests even Google Authenticator doesn't have a simple way to export/import or sync across devices.
But there are other suggestions here:
https://android.stackexchange.com/questions/63252/how-do-i-back-up-google-authenticator

Categories

Resources