Saturday, March 14, 2015

Google password works on Gmail but nowhere else? Congratulations. You're enrolled in Google Advanced Security.

Ugh. File this on under #FirstMilleniumComputingRIP or #YosemiteRequired or #iOSForEveryone or #aWatchFuture.

A friend got an email a few weeks ago from Google, warning her that some had tried logging into her account from Galati Romania and somewhere in Kyrgyzstan. I didn’t see the original email, but I gather Google recommended she change her password. I don’t know if Google said anything about other consequences. The implication was that Google blocked those accesses [1], much as your credit card company routinely blocks the Moscow charges you never hear about.

By the way, if this happens to you, walk through the Gmail security checklist.

I don’t know if Google mentioned anything in the email about additional security measures, but what she noticed was that she couldn’t use Gmail on her home computer. It said “password incorrect” though she was using the right password.

It took me 30-40 minutes to figure out what was going on. I created a new user account to confirm it wasn’t anything on her Mac running OS X Lion [2]. Then, guessing that Google had enrolled her in some new enhanced security program, I went looking around Google’s security settings and I found an “Access for less secure apps” setting [4]

6

I also found this notice …

4

and I could see where our legitimate logons had been blocked (but marking those as legitimate did nothing) …

5

I can’t find Access to Less Secure Apps controls on my own Google accounts [3]; I think it’s automatically enabled after an account hack or if you click the “Secure your account” link in “Notifications and Alerts” or in the “Devices & activity” above. (Maybe this was mentioned in the email from Google? That would be nice.)

If Access for less secure apps is on, then this article applies:

Allowing less secure apps to access your account - Accounts Help

Google may block sign in attempts from some apps or devices that do not use modern security standards. Since these apps and devices are easier to break into, blocking them helps keep your account safer.

Some examples of apps that do not support the latest security standards include:

The Mail app on your iPhone or iPad with iOS 6 or below
The Mail app on your Windows phone preceding the 8.1 release
Some Desktop mail clients like Microsoft Outlook and Mozilla Thunderbird …

… 

To help keep your account secure, we may block these less secure apps from accessing your account, and you’ll see a “Password incorrect” error when trying to sign in. If this is the case, you have two options:

Upgrade to a more secure app that uses the most up to date security measures. All Google products, like Gmail, use the latest security measures.

Go to Allow less secure apps and choose “Allow” to let less secure apps access your Google account. We don’t recommend this option because it may make it easier for someone to gain access to your account…

Yeah, all you get is a “password incorrect” error. Which is wrong of course, your password is fine. Problem is, Mail.app for OS X isn’t designed to say “Google doesn’t like me”. It tries to connect, gets rejected, and renders this as “password incorrect”.

Once I figured out the problem I found Google’s April 2014 security blog announcement:

Google Online Security Blog: New Security Measures Will Affect Older (non-OAuth 2.0) Applications

… beginning in the second half of 2014, we’ll start gradually increasing the security checks performed when users log in to Google. These additional checks will ensure that only the intended user has access to their account, whether through a browser, device or application. These changes will affect any application that sends a username and/or password to Google.

To better protect your users, we recommend you upgrade all of your applications to OAuth 2.0. If you choose not to do so, your users will be required to take extra steps in order to keep accessing your applications.

You do know what version of OAuth OS X Mail.app uses, don’t you? Oh, wait, does Mail.app even use OAuth?! It appears so as of 10.0.3 (Yosemite); I suspect Google considers any OS X app (Mail, Calendar, Contacts) prior to Yosemite to be less secure.

There’s a bit more useful information in this April 2014 ghacks.net article. I’m sure you read that one regularly to keep your Google services working smoothly! As noted in the article, you can enable Access for less secure apps [5]. That took care of my friend’s problem.

Sigh.

My friend asked me what regular people do. My answers was, unfortunately, they don’t/can’t. The writing has been on the wall for a few years — civilians should not own “computers”. They should a single iOS device [6] and do everything through Apple [7]. This kind of thing is only going to get worse.

- fn -

[1] But what about the accesses Google might not have blocked? Google Account security now lets you see what devices have signed in from where over the past 28 days as well as review your security notifications. Between those and reviewing your Account Permissions you can get a rough idea if an unsophisticated attacker got by Google’s secondary defenses.

[2] I also have a Lion machine the kids use a bit. It’s no longer being updated of course, and I should probably retire it.

[3] I checked both my 2FA and non-2FA Google Apps/Google accounts and didn’t see it on any of them.

[4] First I went through her access history and authorized a number of them. Turns out that’s pointless, Google just provides that to keep us confused. 

[5] Or enable 2FA. Google 2FA is less of a PITA than it once was, but it’s not ready for civilian use. Too many ways to go wrong, especially when a device is stolen.

[6] I don’t think Android is a good choice. Sorry. The single best choice for most is probably an iPhone 6+. There’s an unmet need for an flip-phone-like compact device that provides simple phone services to a companion iPad. Maybe Apple Watch version 3 will do that.

[7] if Apple doesn’t do it, then give up.

 

Tuesday, March 10, 2015

H2O Wireless - getting a nano SIM for your upgraded phone - and keeping your old H2O number.

H2O Wireless is a rock bottom ultra-cheap AT&T MVNO. We use it for the 3 kids and their iPhones, with very minimal data services (Find Friends, email, Find My Phone — everything else is more locked down than even Emily and I).
 
Child #2 costs us about $40 a year - the minimum to keep his account open. He doesn’t talk or text much and is almost always on WiFi. He plays games. #1 costs about $10 a month — he does SMS, iMessage, and a few other apps. His data usage is primarily Apple’s utterly mysterious “iTunes Accounts”.
 
#3 runs through $10-20/month — she might end up on our AT&T plan. Lots of texting.
 
Our total child cellular service bill with H2O is about $25-$30/month. Hard to beat for 3 kids. In theory there are no data services with the H2O per minute plan, but we installed the H2O Profile and we get “4G” data. (Though on #2’s i5 if I enable LTE the tower boots us off the network)
 
Of course there’s a downside to the low end of the network. Although H2O’s web site has improved significantly over the past few years, service can be tricky to get. Some things are hard.
 
Things like … getting a Nano SIM so my son could go from a dying 4 to a used 5 [2].
 
The first time I called H2O Support (1-800-643-4926) I was told I could use the number transfer request screen and transfer the number from H2O to H2O, providing a fresh SIM number and an IMEI. Warning: this does not work (at least, not entirely, and not for us).
 
On a second call I was told that only H2O reps can do the transfer. You have to buy a fresh H2O Nano SIM and call them with the “ActFast” code. They will then try to activate the phone with the new SIM. Sometimes it works, but for some numbers/SIMs it doesn’t. (Life at the low end.)
 
In our case I ordered an H2O “Smart SIM” on Amazon for 0.01 [3]. I called support with the SIM in the phone; surprisingly there was no wait. The support person was able to activate the phone, interestingly he didn’t need the IMEI. The initial signal was very weak, he told me to “dial”  ##21# — that supposedly requests service from the tower. It did seem to boost the signal.
 
I’d already installed the H2O profile, but I deleted the old one and reinstalled. I found he could get “4G” data (not bad), but when I tried to enable LTE the tower cut us off. (H2O says per-minute plans get no data, so I can’t complain.)
 
After the transition the web site says #2’s balance is intact. Which is pretty good, because after years of paying for the number with minimal use he has quite a nice balance.

[1] not backed up by the way, so you need to reinstall if you do a restore

[2] I actually cut down his old Mini-SIM to nano-size and it worked, but I’ve never been able to get data on his SIM. So I wanted a fresh Nano.

[3] I’ve ordered several Amazon SIMs. The first time I did it I assumed it was a scam. It doesn’t seem to be, I think the sellers get money from H2O and the like every time a SIM is activated. They’re $15 from the H2O site.

Saturday, March 07, 2015

Transferring eNom domain with associated Google Apps services to Dreamhost: 2015 Edition

It’s hard to imagine now, but once upon a time Google gave big stuff away. Until Dec 2012 anyone could get extended family Google Apps services and a companion domain for a pittance — $10 a year.  Today I still have most of the features of Google’s $50/user/year ’Apps for Work’, but I only pay for domain registration. [4]

Naturally I acquired quite a few Google Apps services, either directly from Google or through Dreamhost (referral link) [1]. Today I still have 10 Google Apps suites. 

The ones I got directly through Google were registered with eNom. This worked reasonably well until Google ended their first generation payment systems, so each eNom account had its own payment data and was completely independent from all others. Since then I’ve been slowly migrating accounts from eNom to Google.

Very slowly! I last moved a Google Apps associated eNom domain in 2009. Yeah, six years ago. [2] Over the past few weeks I’ve moved two more, enough that I’m getting the hang of it. The process is similar to what I wrote about years ago, but there are some added security steps.

I’m going to try to document what I did here — as much for me as for anyone else. Don’t trust what I write though — read Google’s documentation as well, they include registrar specific advice as well:

Key Concepts 

If you understand these concepts things are a lot simpler:

  1. There are 3 independent services involved in this process:
    1. Google Apps services
    2. DNS services (primarily CNAME and MX, the latter is email specific and is particularly old and crotchety).
    3. Registrar services (ex: management of kateva.org, including pointing to DNS services for Kateva.org wherever they might be.)
  2. One business could provide all 3 services [3] or each service could be with a different service. Throughout the process below Google provided Google Services, but I started out with eNom providing both DNS and Registrar services. Then I moved DNS services to Dreamhost. Seven days later Registrar services completed their move to Dreamhost.
  3. The things that connect a Domain to Google Apps are…
    1. Google stores the name of the domain in its records
    2. DNS entries that point to ghs.google.com. When you enter a URL the Domain Name Server sends the request to ghs.google.com, it looks up the domain name and handles it. (Similar magic for MX records).

Steps to follow

This assumes you’re paying for full featured Dreamhost hosting [1]. Quick steps here, more notes below.

  1. Go to eNOM domain settings on Google Apps. Confirm contact information email works. Don’t use contact email that belongs to the domain you’re moving.
  2. Go to Dreamhost, add the domain you’re going to move to Domains Hosted per DreamHost CNAME record instructions as a fully hosted domain under your Dreamhost username. Yes, you can and should do this before you actually move the domain. You’re setting up DNS services at Dreamhost and soon you’ll tell eNom to use those instead of eNom’s native services.
    1. Go to Manage Domains and “Add Hosting” choose Fully Hosted. I put everything under my one username.
    2. Click the box for Google Apps. Dreamhost will configure standard CNAMEs and especially MX records.
    3. Add additional CNAMEs as needed: calendar, docs, drive, blog based on what you see in your eNom records. Don’t need to repeat DomainKey entry used to verify with Google (?). The A record that Dreamhost creates is used to redirect the naked domain to ‘www’.
  3. Go to eNom settings and change eNOM DNS information to use Dreamhost. (ns1.dreamhost.com, etc) Once you do this eNom is now only your registrar.
  4. Confirm DNS still works and can send email to address in domain. I’m not sure how long this takes, 
  5. NOW, Request unlock of the eNom domain by email (see example below. Yes, by email and include your eNom password!). Once this is processed you’ll get two emails from Google, one with authorization key (EPP key).
  6. Go to Dreamhost Reg Transfer, request transfer using the EPP key and complete form. Pay for new registrar service, seems to vary from $10 to $10 depending on domain. Initiate transfer. You’ll see a notice that a 7 day countdown has begun. Dreamhost shows something like this:
    Screen Shot 2015 03 10 at 9 11 24 PM 
  7. About 30-40 min later you’ll get an email from Dreamhost at your official domain email contact that you verified above. Click the link. Go to approval page. Agree. See “your response has been recorded”
  8. Receive notice from Google in 1-2 hr (no action required unless wish to cancel)

    STANDARDIZED FORM OF AUTHORIZATION
    DOMAIN NAME TRANSFER - Confirmation of Registrar Transfer Request

  9. Receive notice after 7 days that is complete. Now go to Dreamhost. Lock the domain. Enable auto-renewal. Test email and google services.
  10. LAST: Google tries to renew registration, fails, sends note domain moved. However, Google never fixes up its Domain settings on the legacy account, they always show “enom” (sic) as registrar.

Sample of eNom letter

GoogleClients@enom.com

Please unlock this domain, disable Google ID Protect, and send authorization code. Thank you!

Domain : yourdomainame.com
Password : u5yhtt5p965965 (your eNom pw, not your Google pw. Get this from Google Apps Domain Settings.
Customer service PIN : (if you know it, optional)

This is what eNom sends if you ask how to proceed.

 Greetings ,

To transfer your domain, you're going to need the domain to be unlocked and the authorization code for the domain. I can assist you with both of those if you can give me the domain password that Google supplied you. (Note: this is NOT your Google Apps login password.)

When you registered the domain, Google set up a privacy protect service and I will disable that in order for the transfer to be successful.

Also, please be aware that in order to transfer the domain, it needs to be 60 days after registration. This isn't an eNom-specific rule - this is a rule for all registrars set by ICANN.

Please e-mail me back with the domain name and password and I can get started on getting you the information you need.

If you don't know your domain password, follow these steps to find it:

Enter your domain name at the access login screen (http://access.enom.com), with AAA as the password, then copy the verification code. Click "Log In" to submit the information.

Put the name in again and then click on the "forgot password" link and it will be emailed to you at the address on file with Google for your domain name.

***IMPORTANT: Remember log into your domain manager at http://access.enom.com to ensure your Registrant and Administrative contact information is valid BEFORE transferring the domain name***

Alternately, IF YOU DID NOT CHANGE THE PASSWORD, you may also recover your Google domain password using the following steps:

To access your Advanced DNS settings, please follow these steps:

Log in to your account at admin.google.com.
Click on the Domains icon on your Admin console dashboard. You may need to click on More controls at the bottom of the screen to find the Domains icon.
Click on the Advanced DNS settings link associated with your Primary Domain.
To make changes to your DNS settings, sign into your DNS console with the login information provided on this page.
When you access Advanced DNS settings, you'll be directed away from Google, and to the domain registration partner that registered your domain name. This is currently available in English only.

Regards,

Google Advanced Domain Support

Provided by eNom, Inc.
email googleclients@enom.com

and this is what you get from eNom after you unlock:

Thank you for proper verification of domain ownership by supplying the domain password.

The domain has been unlocked, ID Protect has been disabled for transfer and your authorization code has been sent to the following email address in a separate e-mail. Please check your spam folder or filters as this is often captured.

***IMPORTANT: Remember log into your domain manager at http://access.enom.com to ensure your Registrant and Administrative contact information is valid BEFORE transferring the domain name***

YOUR EMAIL HERE

If the above email address is invalid, please log into the access control panel (http://access.enom.com) and update the contact information. Once the email address has been updated please reply back at your earliest convenience so that we may resend the EPP/ Authorization code.

Your domain is ready for transfer.

As a note: the transfer process does take 5-7 days for the domain to arrive at the gaining registrar. Once started by you, there is nothing you need to contact us about again. You can however ask us to confirm if the domain is pending transfer should you need to check.

DNS Result after setting up in Dreamhost as fully hosted with Google Apps services

Screen Shot 2015 03 10 at 8 34 37 PM

Additional Custom CNAME (copied from eNom) that I added (some, like ‘sl’ are really exotic. Don’t worry about it.)

Custom cname

Miscellaneous artifacts

Some sample email excerpts:

-

We have requested your domain.com to be transferred to DreamHost! First, your admin contact will receive an email with a link to approve the transfer from us. They will then receive another email from the current registrar with instructions on how to approve the transfer from their side. Typically, transfers take about 7-10 days to go through. You will receive an email from us when we've learned if the transfer has been approved or denied. Note: If you'd like to also host with us, please visit "Manage Domains" now.

-

Domains must be "unlocked" at their current registrar or the transfer will fail. Domains may not be transferred within 60 days of their initial registration or their most recent transfer! You should do any name server changes (e.g. to ns1.dreamhost.com, etc) before transferring! You must make sure you have access to the admin contact email currently listed for your domain! You will receive an email from do-not-reply@dreamhostregistry.com with instructions on how to complete the transfer to DreamHost. If you do not receive it in a few hours, please check your spam filter. The entire process may take 7-10 days or longer before it is complete!

- fn -

[1] Dreamhost has worked well for me for many years. I you sign up and use my PROMO code of KATEVA you get $50 off the 1st  year (I get $47.)

[2] That freaks me out a bit, I vaguely remember when 6 years was more than yesterday. 

[3] Recently Google began providing domain services itself, but i don’t know much about it.

[4] Ok, so you can still get Google Voice (thought it’s a bit trickier than it once was). That service has saved me thousands of dollars on mobile phone calls to Canada.

Fixing Google Chrome Mac Update Error: 12 - success after years of failure.

I’ve been waging a desultory war on a Google Chrome Mac Update Error 12 bug for years. I can’t remember when Chrome updated itself correctly on my Mac, but I didn’t really dig into the bug. I figured Google would fix it sooner or later, in the meantime I’ve been manually downloading Chrome installers every few months (not a great idea obviously).

Today I gave up on Google and started work on the bug. The key to finding the answer was logging into my admin account, starting Console, clearing the log, then watching what showed up as I started Chrome and opened the About screen while Chrome tried to update and generated the usual error: 12 message. I saw something like this:

 …. CODE SIGNING: cs_invalid_page(0x1000): p=809[GoogleSoftwareUp] clearing CS_VALID …

Searching on that string I found an old AskDifferent post on a related topic. That pointed to 

 /Library/Google/GoogleSoftwareUpdate/GoogleSoftwareUpdate.bundle/Contents/Resources

where, like Daniel Azuelos, I found these file dates. 

Screen Shot 2015 03 07 at 11 35 16 AM

Yeah, 2012.

The fix is to quite Chrome, delete  /Library/Google/GoogleSoftwareUpdate (root Library, not User), reinstall Google Software Update Installer and restart. Then you get something like this:

Screen Shot 2015 03 07 at 12 02 44 PM

Yeah, 2014. A bit better.

Then, still from my Admin Account, I ran Chrome and stepped through several versions of the Chrome About screen:

 Screen Shot 2015 03 07 at 11 35 50 AM

then

Screen Shot 2015 03 07 at 11 37 41 AM

Do the relaunch, then ..

Screen Shot 2015 03 07 at 11 37 57 AM

Setup up Automatic Updates for All Users (I’ll be impressed if this actually works!):

Screen Shot 2015 03 07 at 11 38 08 AM

First automatic update in my memory.

I suspect this problem arose from years of several intersecting bugs — some belong to Apple’s famously buggy permissions infrastructure, some related to how Google interacts with people who run OS X as non-admin users, some related to how Google Chrome/Updater manages install errors, some related to how Google mangled OS X Library structures over the years.

Once I’d fixed the problem I read Google’s tech support note more carefully (with Mavericks/Mountain Lion their sudo instructions only work if you run as admin, they kind of left that out). This is the relevant bit:

Run the following command. Be careful to enter the command exactly as written:

~/Library/Google/GoogleSoftwareUpdate/GoogleSoftwareUpdate.bundle/Contents/Resources/GoogleSoftwareUpdateAgent.app/Contents/Resources/install.py --uninstall. It may result in a "No such file error"; the next command will address that.

Now run this following command. Again, carefully enter the command exactly as written:

sudo /Library/Google/GoogleSoftwareUpdate/GoogleSoftwareUpdate.bundle/Contents/Resources/GoogleSoftwareUpdateAgent.app/Contents/Resources/install.py --uninstall

The first command runs against the User account library. Google acts like there’s ONE user account on the machine, instead of say, an Admin account and many user accounts. Anyway, I didn’t have anything like that in either my Admin or Non-Admin account.

The second is closer to the real fix, but look back at 2012 files. There’s no Install.py file there. The answer was to delete parent folder in /Library, not to try to run a non-existent installer.

PS. MarsEdit image upload really needs a lot of work. Hope the new competition from Blogo will help. Also, this is relevant.

Thursday, March 05, 2015

Work around for the Lion Connect As bug

There’s a bug in Lion that causes all network connections to Connect As the current user. You can’t Disconnect and then get a username/password prompt; if you click Disconnect you’ll briefly see the “Connect As” button flash by. Then you’re back as the current machine account.

I think the bug hits when the username on the Lion machine matches the user name on the remote machine.

There are several workarounds, but this is the easiest for me.

Go to Finder:Go:Connect to Server. Look for something like: 

afp://Molly_afpovertcp._tcp.local

Now put the username you want to use on the remote server in there:

afp://myname@Molly_afpovertcp._tcp.local

Now you’ll be asked the password.

(Yeah, still have a Lion machine. Old dual USB MacBook with a swapped drive. Won’t die.)

Sunday, March 01, 2015

How to find the damned MAC address for an Airport client so you can configure access times

There is such a thing as too few features. 

Apple stripped a lot out of Airport Utility between v5 and various v6 iterations. Among other things they made it much harder to find the MAC address for a connected device. You need this address to control access times.

The trick is to Option-double-click the base station to get the Summary tab, from which you can see the MAC address. You can’t copy paste that address however. To do that run the terminal command [arp -a]. Look up the IP and MAC address, that you can copy paste.

Of course you may find copy-paste isn’t all that useful. I tried a copy-paste operation into the MAC address field of Airport Utility 6.3.2 and the “Save” button stayed unclickable. I had to type the MAC address in character by character to enable the Save button.

Dumb. Really.