File Under: Blog Publishing, Web Apps

Massive WordPress Attack Targets Weak Admin Passwords

Image: CloudFlare

If you’re using the popular open source blogging tool WordPress to power your website, you may be vulnerable to a new web-based attack.

If your WordPress admin pages suddenly become sluggish, unreachable or you’re unable to log in there’s a good chance your site is being attacked.

According to CloudFlare CEO Matthew Prince, the attack is using brute force against WordPress’ admin pages using the old default username “admin” and then trying thousands of passwords. There’s nothing new about that approach, but what makes this attack different, and particularly potent, is that the attackers have some 90,000 unique IP addresses at their disposal.

For its part CloudFlare has pushed out an update that “detects the signature of the attack and stops it.”

Popular WordPress Host HostGator reports that it too has “seen over 90,000 IP addresses involved in this attack.”

WordPress creator Matt Mullenweg has also weighed in, pointing out that it’s been over three years since WordPress used the username “admin” as the default for new installations.

However, there are no doubt a great many sites that still have — whether they use it or not — the “admin” user account hanging around in WordPress. It’s also worth noting that, while this attack appears limited to trying the “admin” username, a more sophisticated approach could do the same thing, but with unique usernames — for example, find the most frequently used account name on the public site, assume it’s an admin account and run the same attack against the admin pages. So far that hasn’t happened.

“Here’s what I would recommend,” writes Mullenweg on his blog, “if you still use “admin” as a username on your blog, change it, use a strong password, if you’re on WP.com turn on two-factor authentication, and of course make sure you’re up to date on the latest version of WordPress.”

Unfortunately, given the number of IP addresses that seem to be at the attackers’ disposal, other common security measures — like tools that limit logins by IP address — aren’t going to be terribly effective against this attack. Short of getting rid of the default “admin” account (if it still exists), there isn’t a whole lot you can do to stop the attacks (unless you want to use a web application firewall like CloudFlare or ModSecurity). Be sure to contact your hosting company if you think your site has come under attack.

File Under: Responsive Design, UI/UX

What the Tablet-Laptop Hybrid Means for Web Developers

Hybrids. Image: Screenshot/Webmonkey.

The advent of hybrid laptops that double as tablets or offer some sort of touch input has greatly complicated the life of web developers.

A big part of developing for today’s myriad screens is knowing when to adjust the interface, based not just on screen size, but other details like input device. Fingers are far less precise than a mouse, which means bigger buttons, form fields and other input areas.

But with hybrid devices like touch screen Windows 8 laptops or dockable Android tablets with keyboards, how do you know whether the user is browsing with a mouse or a finger?

Over on the Mozilla Hacks blog Patrick Lauke tackles that question in an article on detecting touch-capable devices. Lauke covers the relatively simple case of touch-only, like iOS devices, before diving into the far more complex problem of hybrid devices.

Lauke’s answer? If developing for the web hasn’t already taught you this lesson, perhaps hybrid devices will — learn to live with uncertainty and accept that you can’t control everything.

What’s the solution to this new conundrum of touch-capable devices that may also have other input methods? While some developers have started to look at complementing a touch feature detection with additional user agent sniffing, I believe that the answer – as in so many other cases in web development – is to accept that we can’t fully detect or control how our users will interact with our web sites and applications, and to be input-agnostic. Instead of making assumptions, our code should cater for all eventualities.

While learning to live with uncertainty and providing interfaces that work with any input sounds nice in theory, developers are bound to want something a bit more concrete. There’s some hope on the horizon. Microsoft has proposed the Pointer Events spec (and created a build of Webkit that supports it). And the CSS Media Queries Level 4 spec will offer a pointer query to see what sort of input device is being used (mouse, finger, stylus etc).

Unfortunately, neither Pointer Events nor Media Queries Level 4 are supported in today’s browsers. Eventually there probably will be some way to easily detect and know for certain which input device is being used, but for the time being you’re going to have to live with some level of uncertainty. Be sure to read through Lauke’s post for more details and some sample code.

Mozilla Reconsiders, May Support WebP Image Format

WebP versus JPEG. Click the image to see the full size examples on Google’s WebP comparison page. Image: Google[/caption]

Want your website to load faster? Slim your images. According to the HTTPArchive, images account for roughly 60 percent of total page size. That means the single biggest thing most sites can do to slim down is to shrink their images.

We recently covered how you can cut down your website’s page load times using Google’s image-shrinking WebP format. Unfortunately, one of the downsides to WebP is that only Opera and Chrome support it. But that may be about to change — Firefox is reconsidering its decision to reject WebP.

The change of heart makes sense since most of the objections Firefox developers initially raised about WebP have since been addressed. However, Firefox hasn’t committed to WebP just yet. As Firefox developer Jeff Muizelaar writes on the re-opened bug report, “just to be clear, no decision on adopting WebP has been made. The only thing that has changed is that we’ve just received some more interest from large non-Google web properties which we never really had before.”

Whatever the case, if Firefox does land support for WebP it would help the fledgling format cross the line where more browsers support it than don’t, which tends to be the threshold for wider adoption.

If you’d like to experiment with WebP today, while still providing fallbacks for browsers that don’t support it, be sure to check out our earlier write-up.

File Under: HTML5, Web Standards

W3C Drops ‘hgroup’ Tag From HTML5 Spec

Image: Screenshot/Webmonkey.

If you’ve been using the HTML5 hgroup tag, now would be a good time to stop. The hgroup tag is in the process of being removed from the W3C’s HTML5 specification.

While the official reason for hgroup‘s demise is the lack of support for hgroup semantics — the W3C requires two “reasonably complete implementations” — hgroup is fraught with accessibility problems and lacks many compelling use cases.

The hgroup tag was intended to be a way to group h1-h6 tags, for example a header and a subheading, but the semantics behind the tag mean that only the first header in an hgroup is visible to any accessibility API. As Steve Faulkner, co-editor of the HTML5 spec, writes on the W3C mailing list, this “effectively removes any notion of a subheading semantic for users and any way for it to be conveyed via an accessibility API.”

In other words hgroup ends up being semantically no different than a div tag, which is why Faulkner called for hgroup to be removed from the spec in the first place. As of this writing it’s still there, but Faulkner says he’s “working on the edits” (which will include some advice on how to handle groups of header tags).

So what should you do if you’ve used hgroup in your code? Well, if you can, consider removing it. But the browser support — which is limited to parsing and CSS — won’t likely change. And it’s also possible that some compelling use case will come up that motivates the W3C to add it to the HTML 5.1 spec (one hopes with better semantic rules) and browser to support it. In the mean time though, slowly step away from the hgroup and no webpages get hurt.

File Under: JavaScript, Location

‘Hyperlapse’ Turns Google Street View Into Beautiful Short Movies

Hyperlapse: turning Google Street View into movies. Image: Screenshot/Webmonkey.

Hyperlapse is quite simply the coolest thing we’ve seen on the web in quite a while. Not only is it creative and beautiful, it’s a great reminder that there are still a few APIs left out there that allow you to make cool stuff.

Hyperlapse is a JavaScript library that stitches together Google Street View imagery to create short “hyper-lapse” movies (time-lapse movies with movement).

The code behind Hyperlapse consists of Hyperlapse.js, Mr Doob’s Three.js and “a modified version of GSVPano.js“. The project is the brainchild of Teehan+Lax, the same design firm that built the interface for Medium.

The site uses WebGL, so you’ll need a modern browser like Firefox or Chrome to see it and create your own.

The only thing Hyperlapse is missing is an easy way to embed your custom Hyperlapses in another page. In lieu of an actual Hyperlapse, here’s a video showing what’s possible.