USB-C

Unlike the change from USB-mini to USB-micro, the move USB-C isn’t just about a new connector. Yes it is nice that the connector goes in either way up, but there is much more to it than that. Here are a couple of bonus features that I’m keen on:

  • USB Power Delivery (PD): This allows compliant chargers to provide much more power than previous USB standards, and means that it can be used to charge devices including laptops such as recent MacBooks and various models from Lenovo. You really can have one charger that will charge a MacBook Pro, a Lenovo T480s, your phone or many other things. Behind the scenes the device asks the charger to increase the voltage from USB’s normal 5v to 9, 15 or 20V. Current goes up to a maximum of 3A at most voltages, but may be up to 5A at 20V to provide 100W of power. This is similar to various proprietary schemes such as Qualcomm Quick Charge or OnePlus Dash that allow for faster charging of mobiles, but with the benefits of standardisation.
  • Alternate Mode: This allows the USB-C port to double up as an HDMI, DisplayPort or Thunderbolt port. Again standardisation means that you no longer need a vendor specific adaptor, the same one will work across a range of devices.

These features can be used at the same time, a single USB-C port can be charging your laptop at the same time as connecting USB devices and providing video output. Wikipedia informs me that you might only get USB 2.0 if the video signal bandwidth requires too many lanes (wires), but for many purposes that’s more than adequate.

There is one note of caution that I should add here: some people have reported issues with cheap cables damaging devices. These issues specifically relate to USB-A to USB-C cables, as you might use to charge a phone with a USB-C port from a traditional USB-A port. It is therefore worth sticking to known brands, I use the OEM supplied or Anker branded ones.

If you’re looking to buy any USB-C accessories then read on for my notes on the ones I’ve used. These have generally been “field tested” with a range of MacBook models (including MacBook Pro and MacBook Air models), Lenovo T470s and Lenovo T480s laptops and my GPD Pocket 2. I’ve also used the power adaptors to charge my phone (a Sony Xperia X2 Compact) without issues.

Power adaptors/chargers

When looking at adaptors with multiple output ports I’ve found a lot marketing that I think is misleading, that gives the total power output of the charger rather than a per-port figure. So a device might be listed as 60W when in reality that means it can deliver up to 45W via a USB Power Delivery supporting USB-C port and separately up to 15W via 1 or more traditional USB-A ports. Anker produce an adaptor listed as 60W that can only output 30W of that via the USB-C port. Read the detailed description carefully!

Some devices will charge slowly off a charger that supplies less power than they need, while others may need to be turned off or put to sleep to do so. In some cases the device will simply refuse to charge if it can’t get sufficient power (about 45W for the Lenovo devices I’ve tried).

Both the Mac and Lenovo OEM chargers work well, but if you’re looking for something from a third party (perhaps to give more USB charging ports or for travel purposes) there are various options available. These include:

USB-C Hubs

These can really function more like a dock, as you can connect the charger, your monitor, networking and other things to the hub and then you just need to connect the single USB-C cable from the hub to your laptop when you get to your desk.

The first (Anker) ones we tried got rather hot and not everyone found them totally reliable at connecting and disconnecting to Lenovo laptops. We’ve since started buying this AUKEY model and feedback has been much better. The list of ports it has is pretty comprehensive: HDMI 4k, VGA, SD & Micro SD Card Slots, Gigabit Ethernet, 2 USB 3.1 Ports and 100W USB-C Power Delivery input/pass-through.

If you’re not interested in the USB-C Power Delivery pass-through then there is a much greater range of devices, often substantially cheaper.

Password security

I missed World Password Day a couple of weeks ago, but it’s still a good time for a reminder about password security.  To underline the importance of this, the full data from an incident that occurred to LinkedIn in 2012 is now readily available online. LinkedIn’s servers were broken into and account details of 164 million users were obtained by the attacker, including password hashes in 117 million cases. It is supposed to be hard to convert a password hash into the actual password, but unfortunately LinkedIn used a very poor hashing scheme and this means that the vast majority of these passwords have now been cracked.  Troy Hunt has more information on that breach if you’re interested, but the simple message is that if you had a LinkedIn account in 2012 it is very likely that the password you used is now known to many unsavoury characters.

There have been many many other similar incidents, see https://haveibeenpwned.com/PwnedWebsites, so even if you’re not affected by that particular incident you should read on.

What should you be doing:

  • Don’t re-use passwords between sites. If one site gets breached,
    in the manner that LinkedIn was, then re-using passwords between
    sites allows the attackers to break into your other accounts.

You almost certainly won’t be able to remember enough different passwords, so you’ll need a “password safe” such as http://keepass.info/ or https://lastpass.com/ or the saved passwords feature built into your web browser.

  • Use a strong password. That’s one that can’t be easily guessed by a person or a computer. It must not be in a dictionary or common password list and should be suitably long (at the very least it should be 8 characters, ideally it should be 12 or more).
  • Consider enabling “2 factor authentication” where it is offered.  This means that an attacker can’t break into your account using just your password, they need something else – the “second factor”.  Many sites support using your mobile phone as the second means of authentication, either by sending you a code in an SMS message or by using an app such as Google’s (which is also supported by Dropbox and Microsoft).

That’s the important message, but if you’re interested then you might want to read on.

How are passwords cracked?

Depending on the type of attack they’re able to carry out the attacker may only get a few guesses, or they may get thousands, millions or even billions per second. A critical question is how many guesses the attacker gets. This leads us to consider two types of attack.

First “online” attacks. These are where the attacker using the normal application log-in process, often connecting to the web page of a service over the internet, and attempts to guess the password. A secure system should limit the rate of password guess attempts allowed, for example by locking your account for 15 minutes after 5 incorrect attempts.  This way a system would limit an attacker to about 500 guesses a day.  Hopefully the system would also alert the administrators to such a sustained attack!

An attacker’s first day of guesses would probably look something very much like this: https://github.com/danielmiessler/SecLists/blob/master/Passwords/10_million_password_list_top_500.txt

Update (2019): Attackers are increasingly using “combo lists” as the basis for these attacks. Instead of trying many passwords against a small number of usernames they simply work through a large list containing millions of known username and password pairs. Each guess they make uses the exact username/password combination that was found in a previous data breach, such as the LinkedIn one mentioned above. This type of attack is effective because many users do re-use the same password in multiple places.

The second attack is an “offline” attack. It is normal for systems to store passwords as hashes. These are based on a one-way function such that you can see if an arbitrary password matches the hash but can’t calculate the password from the hash. What an attacker who gets hold of the hash can do is guess repeatedly. The speed at which they can guess is limited only by the computing hardware they have available and the speed of the hashing algorithm. Some algorithms, such as bCrypt designed for storing passwords, are engineered to be slow. Others, such as MD5 and SHA, that are intended as general purpose hashes are designed to be fast. Storing passwords using these general purpose hashes is a poor idea. With the right hardware, which you can rent from Amazon Web Services for $2.6 an hour, it’s possible to make billions of guesses per second against them.

Attackers may use a large dictionary to try to guess passwords – and not just a regular dictionary but dictionaries specifically put together to contain things people use as passwords, such as the ones available from here: https://crackstation.net/buy-crackstation-wordlist-password-cracking-dictionary.htm

For short passwords they may try a “brute force” attack, in which they literally try every possible combination of letters (or letters, numbers and common symbols). This becomes impractical as the password gets longer. Depending on the password complexity (whether it contains a mix of upper and lower case, numbers and symbols or not) it is likely that a brute force attack will become impractical as the password reaches 8 to 12 characters in length. Length is critical here: A password that is 11 characters long and contains just lower-case letters is actually stronger against a brute force attack then an 8 character one containing a mix of upper and lower case and numbers.  Randall Munroe wrote one of his XKCD cartoons about this.

When might an attacker be able to use an offline password attack?

I hope that’s given you a bit more background information to help you keep your accounts safe.

Let’s Encrypt

For many sites, especially those run by individuals or small charities, the cost of obtaining an SSL certificate has been the main barrier to HTTPS everywhere.  Even sites that really should have been accessed via an encrypted connection, such as those where users or administrators were asked to log in with passwords that they probably also use elsewhere, were often left using plain old un-encrypted HTTP.

The importance of encryption has never been higher.  Mobile devices and laptops are ubiquitous, and with them comes the use of WiFi hot-spots.  Sniffing traffic from unsecured hotspots or setting up fake access points is child’s play.  The solution to this is HTTPS, which will authenticate that you’re connecting to the correct server and then provide end-to-end encryption of the communication.

But HTTPS only provides the guarantees that we want if the site operator obtains a signed certificate that is trusted by our web browser.  Typically this meant paying for it.  Some organizations, like CAcert, attempted to run an authority that provided free certificates.  Unfortunately they were never trusted by the major browsers, which significantly limited their utility.

Historically you also needed to worry about your site having its own IP address, but that’s now a thing of the past thanks to SNI which is supported by recent versions of all major browsers.

Fortunately we also now have a solution to the problem of having to pay for the signed certificates. The solution comes in the form of Let’s Encrypt, an organization supported by the EFF, mozilla and many others.  They are a truly free certificate authority, who issue certificates for free and use a high level of automation to keep their own costs low.  They’re currently in a “public beta” phase, but you can use them right now to obtain certificates for your website.

To obtain a certificate from Let’s Encrypt you use their script.  This can attempt to work in an entirely automated manner, assuming that you’re running a supported web server and that it can parse the server configuration correctly.  I prefer a little more control, so I use it with its “webroot” plugin.  It needs access to the web root in order to prove to the certificate authority that you’re the person who is really in control of the website.

# ./letsencrypt-auto certonly --webroot \
--webroot-path /srv/web/www.mysite.org/ \
-d mysite.org.uk -d www.mysite.org.uk

That will generate the appropriate keys and certificates and place them in /etc/letsencrypt/live/mysite.org/. Now you just need to configure your web server to offer up the new certificate. For an Apache VirtualHost (on port 443 for HTTPS) you need to add lines similar to the following:

SSLEngine on
SSLProtocol all -SSLv3 -SSLv2
SSLCipherSuite !aNULL:!eNULL:!EXP:ALL:!ADH:!LOW:!EXP:!MD5:!3DES:!RC4
SSLHonorCipherOrder Off
SSLCertificateFile /etc/letsencrypt/live/mysite.org/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/mysite.org/privkey.pem
SSLCaCertificateFile /etc/letsencrypt/live/mysite.org/chain.pem

If you don’t have a webroot, perhaps because the site is entirely dynamically generated by a web application, then things will be harder. There is a manual method of obtaining certificates, but that’s not the recommended approach. Better would be to serve files from the web root if (and only if) they exist, and pass all other requests through to the web application. Using Apache this should be possible using the magic of mod_rewrite:

DocumentRoot /srv/web/mysite.org/
RewriteEngine On
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_FILENAME} -f
RewriteRule ^/(.+) /$1 [QSA,L]

Finally, I should note that the certificates produced are only valid for 3 months. So you’ll want to automate their renewal, probably on a monthly basis. For example, using cron:

25 6 3 * * cd /root/letsencrypt; ./letsencrypt-auto renew

Thanks to efforts like Let’s Encrypt and standards such as SNI I hope that in the near future we really will see HTTPS everywhere. Or at the very least nearly everywhere, and certainly everywhere that asks you to log in.