Amid Apple developer site outage, users report unauthorized password resets

Reports on social-networking and microblogging sites may signal security trouble for Apple.

Apple's Dev Center, the member's only area for paid developers, has been down for about two days, for no given reason. Stating, "we'll be back soon," Apple said Thursday that the site was "undergoing maintenance for an extended period."

Apple's developer entrance site, however, remains up andworking fine.

Friday rolled on, and the site's outage continued. iOS and OS X developers began to get cranky, particularly during a time in which iOS 7 and OS X Mavericks are in beta and developers remain eager to get their hands on the latest software bits. 

Existing application developers are unable to access any part of the developer site -- including downloads, help, guides, support, and crucial developer tools. More worryingly, developers that need peer support are unable to access Apple's developer forums, where paid application writers discuss all things software.

The site's message changed late Friday to state the maintenance is "taking longer than expected." It added: "If your program membership was set to expire during this period, it has been extended and your app will remain on the App Store."According to posts on various sites, iTunesConnect and app provisioning are working fine, but the developer portal site appears to be taking the brunt of the issue.

Rumblings across social networks and developer forums point to concern that Apple may have suffered a security breach, similar to an attack on Dropbox last year, which led to a spam attack on many of its users. The logic is that any scheduled maintenance would likely not come at a time during beta testing.

Emergency maintenance, such as to patch or fix a security flaw or lapse, could happen at any time and without warning.

Twitter has also been abuzz with reports that users have received password reset e-mails, including some repeated attempts, as reports from Neowin and Hacker News noted.

Not every developer has received an Apple password reset request -- whether authorized by Apple, or sent as a result of an attacker or hacker attempting to reset a developer's password without permission.

(We also checked other keywords, such as "google reset" and "microsoft reset," and even "account reset" on social-media sites, and nothing appeared particularly out of order.)

A number of Apple developers on Twitter responded when asked if they had received a password reset e-mail. This seems to point toward a spattering of password reset e-mails rather than Apple forcing its users to change their passwords.

Tumblr co-founder and Instapaper creator Marco Arment said in a tweet Saturday afternoon: "The longer it goes, the more I believe the security-issue theory."

But if it is a security issue, there still remain unanswered questions over what happened.

Apple, a company that is notoriously secretive, will have to not only admit to its users what happened to cause the outage and downtime but also explain in precise detail what happened, when, how, and ultimately why.

The unauthorized password reset e-mails that have been landing in in-boxes over the past 24 hours likely have nothing to do with a flaw the company patched in March. A flaw in the iForgot password reset system could have allowed an attacker to reset an account with just an e-mail address and date of birth. 

At this point, in true style for the Cupertino, Calif.-based technology giant, it's not saying anything to any effect. We've put in questions to Apple, but did not hear back by publication time.

We'll keep this article updated as and when more comes in.

Read More

Google to make 2-step verification

 mandatory, phones to replace 

passwords

The rise of mobile devices and persistent connectivity, as well as apps and cloud services, has put us all at potential risk when it comes to online security. Simply put, it's no longer as basic as using strong passwords and strong encryption on websites and services. According to a recent effort by Google in making its systems more secure, the company is looking into implementing smartphone tagging, life-long tokens, and requiring two-step verification on its services.

This is part of Google's revolving five-year roadmap for security. The last time Google made an effort to map out its big-picture security plan was in 2008, and it's now high time to do a revamp. During that time, Google planned an implemented two-step verification, which required both a password and a key before granting access to a user's account — originally sent as a six-digit code via SMS.

This has only been optional, though, and Google wants to ”rollout a change to our login system in which we will be much more aggressive.” What happened since 2008? A lot, apparently.

Google cites a few things that have pushed the company to become more aggressive in its security stance. First, in 2008, smartphones were not yet as popular as they are today. Eric Sachs, group product manager for identity at Google, says that they did not see it coming. “Five years ago, this level of smartphone adoption was not predicted.” And so with the popularity of smartphones today, Google will weave in security and authentication with mobile devices, as well as back-end improvements.

High friction, but only at the start

According to Sachs, Google does not have qualms with increasing the so-called friction in logging in, if only to improve security. “We don't mind making it painful for users to sign into their device if they only have to do it once.” The key here is that you only have to be inconvenienced once — such as by keying in both your password and a key, like one sent to your mobile phone via SMS or generated by an authenticator app. The next points of access or login should be token-based. Other apps and services should never have to ask for your credentials again, for as long as you have access to your mobile device.

Instead, Google's proposed login methods would involve your mobile device of choice — your Android smartphone for instance. In place of keying in your password to access a third-party service, for example, you can simply approve your web login by approving it from an alert on your smartphone.

As alternatives, Google proposes using technologies like NFC to “bootstrap” logins. For example, you can login to a service by tapping your smartphone onto an NFC terminal on your notebook computer or other device. Of course, this assumes both devices support the technology, and Google actually envisions such a login method for Chromebooks. But because the company does not have control over other manufacturers' hardware, Google is still going to look for acceptable standards that can work across different devices and platforms. The same goes for third-party applications, as not all developers and services use OpenID and OAuth.

Google knows you

Going beyond unlocking and authentication, though, Google's plan for security is much more sophisticated. An added factor would be determining behavioral patterns and raising flags when usage deviates from these patterns. “We are beginning to experiment with apps on the phone that display notifications about risky behavior on an account.” For instance, you might usually access web apps and services from a certain location or during a certain time of the day. If you suddenly access it from another place (another country?) and at a strange time, then Google might ask you to approve the action on your mobile device before proceeding.

Apart from these systems, Google also espouses smarter hardware that will improve security and the platform for accessing apps and services. The company notes that systems like biometrics will be a good addition, although there are still issues with fingerprint or facial recognition, among others.

What Google says is difficult at this point is account recovery. “Account Recovery is our achilles heel,” says the white paper. Google says it should be easy enough for the real user to access, but still difficult for malicious hackers to crack. “Bad guys will try to hijack accounts through account recovery systems, but this poses hard challenges since the recovery systems have to help the real owner who has truly lost access to those other factors,” Sachs writes.

Another big concern is that security risks have grown because malicious hackers have found better ways to monetize hijacked accounts. As such, they are willing to go through lengths to get into these accounts.

Google is confident about the results of its earlier 2008 five-year security plan, and is hopeful that its 2013 plan will also result in better security for both end-users and developers. You can check out the draft report, PUBLIC DRAFT: Stronger Consumer Authentication – 5 year report, from the source links below. Google has also prepared a slide deck for a simpler presentation.

Read More