Chrome’s malware warning page. Image: Google.

Hopefully you’ll never need it, but if your site does get hacked Google has set up a new site dedicated to helping websites that have been hacked.

The “Help for Hacked Sites” section of Google’s Webmaster Tools offers up articles and videos to help you not only recover from compromising hacks, but take steps to make sure it doesn’t happen again.

Part of what makes hacked sites difficult to deal with is that oftentimes developers don’t even notice that they’ve been compromised. “Hacks are often invisible to users,” says Google in its new help section. “For example, unbeknownst to the site owner, the hacker may have infected their site with harmful code which in turn can record keystrokes on visitors’ computers, stealing login credentials for online banking or financial transactions”

Google has an 8-step program for unhacking your site, which include basics like identifying the vulnerability that was used to compromise your site, as well as how to request a review so Google will remove the dreaded “this site has been compromised” message from its search results.

For more info and all the details on what to do if you’ve been hacked, check out the new Help for Hacked Sites section of Google’s Webmaster Tools.

Inspectocat says “never store private stuff in public places.” Image: Github

GitHub has temporarily shut down some parts of the site-wide search update it launched yesterday. As we mentioned in our earlier post, the new search tools made it much easier to find passwords, private ssh keys and security tokens stored in GitHub repos.

GitHub hasn’t officially addressed the issue, but it appears to be blocking some of the security-related searches that were posted earlier in this Hacker News thread.

GitHub’s status site also says that “search remains unavailable,” though in my testing searching worked just fine so long as you weren’t entering words like “RSA,” “password,” “secret_token” or the like.

Most of the passwords and other security data exposed were personal — typically private ssh keys to someone’s server or a Gmail password — which is bad enough, but at least one appeared to reveal a password for an account on Chromium.org, the repository that holds the source code for Google’s open-source web browser. Another reportedly exposed an ssh password to a production server of a “major, MAJOR website in China.”

Unfortunately for people that have been storing their private security credentials in public GitHub repos what GitHub’s search engine revealed is nothing new. Google long ago indexed that data and a targeted site:github.com search will turn up the same exposed security info, which makes GitHub’s temporarily crippled search a token gesture at best.

If you accidentally stored sensitive data on GitHub the most important thing to do is change your passwords, keys and tokens. After you’ve created new security credentials for any exposed servers and accounts then you can go back and delete your old data from GitHub.

Given that Git, the version control system behind GitHub, is specifically designed to prevent data from disappearing, deleting your sensitive data takes more than just the Git command rm. GitHub has full details on how to get your sensitive data off the site. As GitHub’s instructions say, “if you committed a password, change it! If you committed a key, generate a new one. Once the commit has been pushed you should consider the data to be compromised.”

Image: HolySkittles/Flickr.

Firefox users can install HTTPS Everywhere directly from the EFF site. There’s also an alpha release available for Google’s Chrome web browser. Unfortunately, limited add-on APIs mean that HTTPS Everywhere isn’t available for other web browsers.

Once it’s installed, the HTTPS Everywhere extension makes it easy to ensure you’re connecting to secure sites by rewriting all requests to an HTTPS URL whenever you visit one of the thousands of sites HTTPS Everywhere supports.

Why all the fuss about HTTPS? Well, every time you log in to a website through a plain HTTP connection, you expose your data to the world. It’s a bit like writing your username and password on a postcard and dropping it in the mailbox. Think of an HTTPS connection as an envelope to protect your postcard from prying eyes.

The problem gets a bit more complicated than just HTTPS though. Most sites already use HTTPS to handle your login info — that’s a good first step — but once you’re logged in sites often revert back to using an insecure HTTP connection.

So why doesn’t the entire web use HTTPS all the time? The answer is slightly complicated, but the primary reason is speed. HTTPS can’t be cached on CDN networks, which means pages may load slightly slower than they would over standard, insecure connections. For smaller sites the added costs involved with HTTPS certificates make HTTPS more expensive. However neither of those stumbling blocks have stopped Google, Facebook, Twitter, Wikipedia or the thousands of other sites large and small that now offer HTTPS connections.

The EFF is still a long way from its long term goal of encrypting the entire web, but with more sites supporting HTTPS connections every day the web is slowly but surely getting more secure.

After three years as lead author and editor of the OAuth 2.0 specification, Eran Hammer has stepped down from his role, withdrawn his name from the spec and even quit the OAuth working group completely, frustrated with what he now calls “a bad protocol.”

OAuth 2.0 is a rewrite of the original OAuth spec, which offers a secure way to sidestep the dilemma of having to hand over passwords to third party sites and apps to access user data. Google, Facebook, Twitter, and Yahoo are among the high-profile sites that have embraced OAuth in some fashion.

Unfortunately, according to Hammer those same big names are at least partly responsible for making OAuth 2.0 the fiendishly complex and convoluted spec that it has become. Hammer is not the first to question the usefulness of OAuth 2.0. In fact, we’ve previously argued that OAuth 2.0′s complexity is hurting the spirit of API experimentation on the web.

Hammer isn’t just questioning OAuth 2.0, he’s abandoned it entirely and completely erased himself from the project, calling it “a bad protocol… bad enough that I no longer want to be associated with it.”

In Hammer’s view OAuth 2.0 is “more complex, less interoperable, less useful, more incomplete, and most importantly, less secure” than its 1.0 cousin.

The problem according to Hammer are the “enterprise” edge cases which do nothing for the vast majority of developers other than make OAuth 2.0 more complex. As Hammer writes, “that is the enterprise way. The WS-* way. 2.0 provides a whole new frontier to sell consulting services and integration solutions.”

So what should you do? Well, as RSS developer Dave Winer says, “OAuth 1 is fine.” Indeed, OAuth 1.0 works and it’s much more accessible for smaller development teams — you don’t need Google’s engineering team to turn out a secure implementation of OAuth 1.0. Hammer has similar advice, writing, “if you are currently using 1.0 successfully, ignore 2.0. It offers no real value over 1.0.”

Of course the departure of an editor doesn’t mean OAuth 2.0 is going away. It remains, like many other standards, under the auspices of the Internet Engineering Task Force (IETF), which also oversees protocols like SMTP and TCP/IP.

Google’s Chrome browser will stop relying on a decades-old method for ensuring secure sockets layer certificates are valid after one of the company’s top engineers compared it to seat belts that break when they are needed most.

The browser will stop querying CRL, or certificate revocation lists, and databases that rely on OCSP, or online certificate status protocol, Google researcher Adam Langley said in a blog post published on Sunday. He said the services, which browsers are supposed to query before trusting a credential for an SSL-protected address, don’t make end users safer because Chrome and most other browsers establish the connection even when the services aren’t able to ensure a certificate hasn’t been tampered with.

“So soft-fail revocation checks are like a seat-belt that snaps when you crash,” Langley wrote. “Even though it works 99% of the time, it’s worthless because it only works when you don’t need it.”

SSL critics have long complained that the revocation checks are mostly useless. Attackers who have the ability to spoof the websites and certificates of Gmail and other trusted websites typically have the ability to replace warnings that the credential is no longer valid with a response that says the server is temporarily down. Indeed, Moxie Marlinspike’s SSL Strip hacking tool automatically supplies such messages, effectively bypassing the measure.

“While the benefits of online revocation checking are hard to find, the costs are clear: Online revocation checks are slow and compromise privacy,” Langley added. That’s because the checks add a median time of 300 milliseconds and a mean of almost 1 second to page loads, making many websites reluctant to use SSL. Marlinspike and others have also complained that the services allow certificate authorities to compile logs of user IP addresses and the sites they visit over time.

Chrome will instead rely on its automatic update mechanism to maintain a list of certificates that have been revoked for security reasons. Langley called on certificate authorities to provide a list of revoked certificates that Google bots can automatically fetch. The time frame for the Chrome changes to go into effect are “on the order of months,” a Google spokesman said.

This article originally appeared on Ars Technica, Wired’s sister site for in-depth technology news.

Major e-mail providers, including Google, Microsoft, and Yahoo are teaming up with PayPal, Facebook, LinkedIn, and more, to implement a new system for authenticating e-mail senders to try to prevent the sending of fraudulent spam and phishing messages.

The protocol that powers e-mail, SMTP, dates back to a more trusting era; a time when the only people who sent you e-mails were people you wanted to send you e-mails. SMTP servers are willing to accept pretty much any e-mail destined for a mailbox they know about (which is, admittedly, an improvement on how things used to be, when they’d accept e-mails even for mailboxes they didn’t know about), a fact which spammers and phishers exploit daily.

Making any fundamental changes to SMTP itself is nigh impossible; there are too many e-mail servers, and they all have to interoperate with each other, an insurmountable hurdle for any major change. So what we’re left with is all manner of additional systems that are designed to give SMTP servers a bit more information about the person sending the e-mail, so that they can judge whether or not they really want to accept the message.

The two main systems in use today are called SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail). Both systems use DNS to publish extra information about the e-mail sender’s domain. SPF tells the receiving server which outgoing servers are allowed to send mail for a given domain; if the receiving server receives mail from a server not on the list, it should assume that the mail is fraudulent. DKIM embeds a cryptographic signature to e-mail messages and an indication of which DNS entry to examine. The receiving server can then look up the DNS entry and use the data it finds to verify the signature.

These systems are not perfect; though both are used widely, they haven’t been adopted universally. This means that some legitimate mail will arrive that doesn’t have SPF or DKIM DNS entries, and so mail servers can’t depend on its presence. Common legitimate operations can also break them; many mailing list programs add footers to messages, which will cause rejection by DKIM, and forwarding e-mails causes rejection by SPF. As a result, failing one or other test is not a good reason to reject a message.

These systems also make it hard to diagnose misconfigurations; receiving servers will typically just swallow or ignore mails sent by systems with bad SPF or DKIM configurations.

The large group of companies, which includes the biggest web mail servers and some of the most common corporate victims of phishing attempts, is proposing a new scheme, DMARC (“Domain-based Message Authentication, Reporting & Conformance”), in an attempt to tackle these problems. DMARC fills some of the gaps in SPF and DKIM, making them more trustworthy.

DMARC's position within the mail receipt process (illustration by dmarc.org)

DMARC is based on work done by PayPal in conjunction with Yahoo, and later extended to Gmail. This initial work resulted in a substantial reduction in the number of PayPal phishing attempts seen by users of those mail providers, and DMARC is an attempt to extend that to more organizations. As with SPF and DKIM, DMARC depends on storing extra information about the sender in DNS. This information tells receiving mail servers how to handle messages that fail the SPF or DKIM tests, and how critical the two tests are. The sender can tell recipient servers to reject messages that fail SPF and DKIM outright, to quarantine them somehow (for example, putting them into a spam folder), or to accept the mail normally and send a report of the failure back to the sender.

In turn, this makes SPF and DKIM much safer for organizations to deploy. They can start with the “notification” mode, confident that no mail will be lost if they have made a mistake, and use the information learned to repair any errors. DMARC also allows recipients to know if a domain should be using SPF and DKIM in the first place.

Without a global rollout, DMARC can’t solve all phishing and spam problems. The companies that have signed up to support the project include major recipients of phishing attempts—the various free e-mail providers—and sites against which phishing attacks are regularly made. Mail sent between the organizations will be verified using the SPF/DKIM/DMARC trifecta. Anyone using the major mail providers and the major services should see a substantial reduction in fraudulent mail. Senders and recipients who want to receive similar protection can implement DMARC themselves by following the specification that the DMARC group is working on.

Given the constraints imposed by SMTP, we may never get an e-mail system that is entirely free of malicious and annoying junk. SMTP e-mail was never designed to be trustworthy, and systems like SPF and DKIM are constrained by the inadequacies of SMTP’s design. Nonetheless, mechanisms such as DMARC can still make a big difference, and with the support of these major companies, e-mail might get that little bit safer.

This article originally appeared on Ars Technica, Wired’s sister site for in-depth technology news.

Illustration by dmarc.org

A worm previously used to commit financial fraud is now stealing Facebook login credentials, compromising at least 45,000 Facebook accounts with the goals of transmitting malicious links to victims’ friends and gaining remote access to corporate networks.

The security company Seculert has been tracking the progress of Ramnit, a worm first discovered in April 2010, and described by Microsoft as “multi-component malware that infects Windows executable files, Microsoft Office files and HTML files” in order to steal “sensitive information such as saved FTP credentials and browser cookies.” Ramnit has previously been used to “bypass two-factor authentication and transaction signing systems, gain remote access to financial institutions, compromise online banking sessions and penetrate several corporate networks,” Seculert says.

Recently, Seculert set up a sinkhole and discovered that 800,000 machines were infected between September and December. Moreover, Seculert found that more than 45,000 Facebook login credentials, mostly in the UK and France, were stolen by a new variant of the worm.

“We suspect that the attackers behind Ramnit are using the stolen credentials to log-in to victims’ Facebook accounts and to transmit malicious links to their friends, thereby magnifying the malware’s spread even further,” Seculert said. “In addition, cybercriminals are taking advantage of the fact that users tend to use the same password in various web-based services (Facebook, Gmail, Corporate SSL VPN, Outlook Web Access, etc.) to gain remote access to corporate networks.”

Facebook fraud, of course, is nothing new. Facebook itself has acknowledged seeing 600,000 compromised logins each day, although that accounts for just 0.06 percent of the one billion Facebook logins each day.

This article originally appeared on Ars Technica, Wired’s sister site for in-depth technology news.

Using Google search over SSL means that your search terms are encrypted, so prying eyes can’t see what you’re searching for, nor can they see the results you get back. Google’s efforts to provide an encrypted search page are just one part of a broader move afoot on the web to shift more traffic over to the more secure HTTPS protocol.

Why all the fuss about HTTPS? Well, every time you search Google or log in to Twitter or Facebook over a plain HTTP connection, you expose your data to the world. It’s a bit like writing your username and password on a postcard and dropping it in the mailbox. There is a better way, the secure version of HTTP — HTTPS. That extra “S” in the URL means your connection is secure, and it’s much harder for anyone else to see what you’re doing. Think of the extra “S” as the envelop that keeps prying eyes from looking at your postcards.

Although the HTTPS version of Google does, in Google’s words, “provide you with a more secure and private search experience,” it’s worth noting that it doesn’t stop Google from tracking your search terms and other data.

Google Operating System, which tracks all things Google, dug up a post on the Google Support Forums where a Google employee says that Google is “running an experiment with some percentage of Chrome 14 users where we send them to SSL search.” That means that some Chrome users may find themselves using the HTTPS search page without even realizing they are.

Chrome 14 is still in beta, so in order for this to affect you, you’ll need to be using the beta channel.

Of course even if you aren’t part of Google’s effort to expand Google Search over SSL, doesn’t mean you can’t configure your browser to use the HTTPS search page by default. Firefox fans can just install the HTTPS Everywhere extension. Chrome and Chromium users can simply right-click the URL bar, choose “edit search engines” and then look for the Google entry. Just click edit, add an “s” to the end of the “http” and you’re done. Internet Explorer users can head to the IE add-ons page and create a new search provider using the form.

Photo: Joffley/Flickr/CC

See Also:

• EFF Wants to Secure the Web With “HTTPS Now” Campaign
• HTTPS Is More Secure, So Why Isn’t the Web Using It?
• Firefox Security Tool HTTPS Everywhere Hits 1.0