Fix for VLC audio dropping out every few seconds

largeVLC

(tl;dr version – AirServer, and/or some other AirPlay device, is the culprit)

I’ve been running into a problem with VLC recently, in which audio playback experienced regular dropouts every few seconds. Having found the fix, I thought I’d share it on here for the sake of those Googling for a solution.

No matter what media file I played back – .mkv, .mp4, .avi, .mp3 were all tested and showed the issue – I still got the sound dropouts. Checking the VLC ‘Messages’ log showed that it was seeing a change in ‘audio configuration’ and resetting the audio output module.

I checked my Mac OS X Sound preference pane, and realised that it showed the remote AirPlay output devices that I had recently created by installing the excellent AirServer on another Mac on my network. I also realised that the problem had been apparent since about the same time that I set up the AirServer instance on the remote Mac.

AirServer broadcasts the existence of its AirPlay interfaces on a regular basis to any devices that are listening. Once a Mac receives an AirPlay advertisement, it updates its list of available audio output devices.

VLC detects this update, and rescans the available devices, which is in principle good behaviour (you would want it to react if you changed the default output device in the Sound preference pane, for example). Unfortunately, instead of immediately restoring output, it takes a second or two to fill its output buffer and start playing audio again.

This happens every time the list of output devices change – which, as I’ve mentioned, happens every time AirServer broadcasts its existence. Stopping the AirServer instance fixes the issue. It is quite plausible that the same problem will arise if you have other AirPlay receivers broadcasting their existence.

Disabling the “Rebroadcast Automatically” setting in the AirServer preference pane significantly reduces the occurrence of dropouts (but does not remove them entirely). Doing this will impair auto-discovery, but allow devices already aware of the AirServer instance to continue to send audio and video to it.

Thinking about my impending move to California

Murrica.

Murrca.

As most of you know – primarily because I won’t shut up about it – I’m moving to California in October to start a job at Facebook. Living and working in the US has been in the back of my mind for a few years now, but I never really acted on it because I was comfortable and happy working where I was. That changed after the takeover, and when Facebook dropped me an email saying “we think you’d be a good fit, fancy interviewing?” I did a lot of thinking.

Initially, I didn’t respond. I have so many ties and relationships in London, and it seemed unnecessary anyway, as I didn’t think I’d make it through the interviews. I’m clever and capable, and I’m quite proud at that, but I’m rubbish at interviews and the hiring bar was high – this was Facebook, after all.

One morning, on the way to work, I decided to send an email back and see what happened. Worst case scenario, the only thing I risked was my time on the interviews. The three phone interviews were arranged, and to my surprise, they decided that they liked me enough to fly me out for a day of in-person interviews.

Landing in California, I suddenly started to get excited. Maybe I could do this. I settled in the hotel for a good night’s sleep after I arrived, and by chance I ran into the guy staying in the hotel room next to me. He was a VMware employee from Boston, in California for a training course. We had a chat about what he was up to and what I was up to. Over a cigarette, he offered me a few tips about American interview culture, and we shot the shit about technical trivialities.

This was the point at which I knew that I really wanted this job. I’d been in California for a matter of hours, and completely by chance, I’d run into a friendly, technical guy. The sampling size was admittedly small, but if he was representative of the culture of the area, this is something that I wanted to be a part of.

I took the Caltrain into San Francisco the next day, armed with an iPad containing my library of technical ebooks. Finding a coffee shop next to a river, I ordered something ludicrous, sat down with a notebook, and started to refresh my memory with more motivation than I’ve ever experienced before.

I alternated between the coffee shop and the riverside to keep things fresh – an hour of coffee, an hour of fresh air. By the end of the day, my friend Julia had finished work and I got the chance to meet up with her to play with her birds and grab a quick drink while talking about the area. I was constantly catching myself getting overexcited and reminding myself that I wasn’t there yet.

I headed to the Menlo Park campus the next morning and was blown away. The culture, facilities, and environment were everything that I’d hoped for. Art on the walls, both impromptu work by employees and commissioned pieces by recognised artists. MAME cabinets that read your employee badge and allowed you to compete against your colleagues. A sodding ice-cream parlour.

The five hour-long interviews went fairly well. I tripped over a few times, but hopefully managed to get across that it was mostly a lapse in memory rather than a lapse in understanding. I was by no means certain that I’d nailed it, but at the same time I’d probably have thought the same thing if everything had gone perfectly. Once finished, I grabbed a few minutes with a friend of mine who works there, packed up my things, and headed to the airport for my flight home.

A few days passed, and I picked up the phone to the guy that I’d been working with to the news that they’d decided to make me an offer. I don’t think that any human being has ever said the word ‘yes’ as quickly as I did. He offered me feedback on my interview – that they felt I was a generalist, knowing a bit about everything, and that the Facebook environment would give me a chance to dig deeper on some of the things that I tripped over, which was completely accurate – and we talked about the process between here and starting in October.

The biggest hurdle was the US visa. I would be applying under the H-1B nonimmigrant visa programme. While my qualifications and lack of any criminal history would make my acceptance fairly certain, there were only 65,000 new H-1B visas issued each year.

The process worked like this; between the 1st and 5th of April, USCIS would accept any and all comers to apply for H-1B visas. If less than 65,000 applied, all were processed. If more than 65,000 applications were received, a random selection ‘lottery’ would choose 65,000 applications to be processed. This was my first stumbling block, and checking the trends on the number of applications in previous years, it looked like the allocation would indeed be oversubscribed.

The final number of applications received was approximately 124,000. The chances of success were just over 50%.

See, the thing is that if I apply for something late, or incorrectly, or don’t provide the information, and because of that I don’t succeed, that’s my fault. It’s something that I can control and take measures to avoid. Random selection is completely out of my, or anyone else’s, hands, and it really did get me worried.

However, I was lucky enough to be selected in the lottery, and passed through the application process once processing started, as expected. My visa was approved, and I started talking to the relocation company who would be handling the move.

It was at this point that my brain decided that now would be a really good time to be difficult about the whole move. This is where I am now. One minute it’s excited to have an opportunity to get involved in such a huge project, with great people, in a great place, with a great culture. The next, it’s worried about losing ties with the people that I value; I don’t go out a lot, so a lot of my interaction is through the Internet, which won’t change. It’s just nice to know that a lot of the people I know are in visiting range, so that when I do want to see a human face it’s possible. That will change in California. Even my American friends, for the most part, are very distant.

While I’d prefer not to go into detail, there are other complications and bridge-burnings which – while I’d love them not to be – are implicit with a move halfway across the world. I had to make a decision, and I know that I’ve made the logically and rationally correct one, but the heart and the brain can be real dicks to each other sometimes.

I’ve never wavered about moving forward with this since sending that first email. It’s going to be difficult and stressful in the short term but there’s the promise of a much longer-term reward in terms of happiness and success. Knowing that you’re doing the right thing, however, doesn’t preclude the negative thoughts and emotions that a process like this can dredge up.

Anyway; forward to a new start.

I’d like to thank a few people who’ve really helped me out in the process of getting all of this sorted out. Firstly, my family, whose emotional, practical, and financial support have removed a number of roadblocks that could have made the whole thing a lot harder. Ben, Sam, Julia, MBM, and anyone else I’ve forgotten who have been there to provide perspective and advice from their own experience. Those who will remain nameless at my current workplace who could have made the process much more difficult for me to their own benefit, and chose not to. Last, but by no means least, Phil, Sami, Sherrie, and everybody else involved at Facebook for all their support and assistance during the application and interview process.

Tagged , , ,

Password storage vs. data integrity: all hashes are not created equal

An FPGA board, used to build custom hardware cracking engines.

An FPGA board, popular for hardware cracking.

I’m still not shutting up about hash functions. The main reason for this is that they’re interesting and neglected by many developers, leading to compromises causing more problems for users than ever.

What I’d like to deal with here is the difference between a hash designed for fast integrity checking, and a hash designed to protect passwords (or other credentials) against brute-force attack.

Pick your hash carefully

When storing passwords, the temptation is to use whichever modern hash function is most easily accessible. Many users mistakenly consider SHA-1 secure; even vaguely technical people might even consider one of the SHA-2 hashes secure for password storage. It helps that these are nice and simple to use, usually provided by your language’s OpenSSL bindings.

Let’s go through the common hash functions and talk about their usefulness for password storage.

Anything earlier than MD5, including DES crypt(3)

Step away from the keyboard.

MD5

MD5 is a fast hash, unsuitable for protection against brute-force cracking, and has been cryptographically broken for a while now in certain situations. MD5 is not only easy to implement in hardware, but is actually well-suited to processor features like SSE2, further increasing the cracking speed.

The risk of using it is just not worth it unless you have no other option, even though there are plenty of situations where it’s still treated as secure – many SSL certificates, for example. This is not a good example to follow.

SHA-1

Another fast hash, vulnerabilities in SHA-1 are well-documented. It’s still in widespread use, unfortunately, and should be considered only slightly better than MD5 for the purposes of security. SHA-1 is also designed to be well-suited to hardware implementation, meaning that attackers with access to FPGA and ASIC hardware, or even a GPU cluster, can blitz their way through a list of hashes. Not recommended.

SHA-2

Covering SHA-224, SHA-256, SHA-384, and SHA-512, the SHA-2 hash suite was designed to address the shortcomings of SHA-1. It’s another fast hash designed to be easy to implement in hardware, so there’s no significant protection against brute-force attacks, but to date (2013-04-12) there are no significant attacks against it. If one of the slow hashes aren’t an option, salted SHA-2 is the way to go.

PBKDF2

This is where things start to get interesting. PBKDF2 isn’t a hash function in itself – it’s a key derivation function, designed to apply a salted hash such as SHA-2 a number of times to force brute-force attacks to take longer.

The key to security using PBKDF2 is using a sufficient number of rounds, but it’s somewhat flawed in that the number of rounds required to take time n on a CPU will take a significantly lesser amount of time on a GPU, FPGA, or ASIC cracker. Unless you have an ASIC in the first place and can calibrate your number of rounds for 500ms on an ASIC in day-to-day use, your protection is only significant against crackers that are CPU-based too.

Better than nothing, ubiquitous, and its sequential construction allows for an increase of the number of rounds at any time completely transparently to the user.

bcrypt

Mature and effective, bcrypt was first implemented in OpenBSD. It’s even more resistant to brute-force than PBKDF2, and is the go-to choice if you want to use something that’s been in use for a while. Like PBKDF2, it has a sequential construction allowing for transparent increase in number of rounds as processing power improves, but it’s also processor-bound meaning that GPUs, FPGAs, and ASICs can hammer it.

scrypt

The shiny new toy of the bunch, scrypt is less mature than bcrypt, but has an entirely different construction. Instead of being processor-bound, scrypt is memory-bound, meaning that it not only resists CPU-based brute force attacks but requires a huge amount of memory to run in parallel on GPUs, FPGAs, and ASICs. This significantly increases the cost of the hardware required to mount a hardware brute-force attack, without placing enormous demands on systems that verify hashes as part of standard password authentication.

It’s a very exciting algorithm, with an ingenious way of resisting hardware brute-force attacks. It is, however, fairly new – something that (quite rightly) makes cryptographers a bit twitchy.

Costs of cracking

The designer of scrypt analysed the approximate cost of hardware required to brute-force passwords of various lengths in one year, using different hash algorithms.

Costs of hardware crack strings of various lengths in a period of one year

Costs of hardware to crack strings of various lengths in a period of one year

This chart assumes cryptographic security, and refers only to brute-force time. Still, assuming scrypt remains strong, it’s the clear winner here.

Denial of service concerns

One side-effect of processor-hard or memory-hard hashes is the risk of their use for a denial of service attack. By the very nature of the fact that they’re hard to run in parallel, a service that checks hashes can be overwhelmed with requests, either maxing out the processor or filling available memory very quickly. This is relatively simple to take care of in your code, rate-limiting the number of password attempts, but should not be ignored.

Just tell me which hash to use!

If you’re verifying data integrity, one of the SHA-2 hashes is probably the way to go. If you’re storing password hashes, properly calibrated bcrypt or scrypt will give your users the best security.

The Password Security Megapost

With ‘cloud’ services meaning that so much of our critical data resides with offsite managed systems these days, password security has taken a leap into being one of the most critical arenas of personal information security. Your email address is public, so your password is the only thing that stops attackers from helping themselves to your email, address book, calendar, social networks, cloud storage accounts, and so on.

Password security is harder than it used to be

With cloud services having such huge uptake, an issue that used to be of lesser importance has suddenly been promoted. Of course, the construction of your password (and as such, its resistance to guessing) is important, but you also need to consider password inference.

The thing is that cloud services are such juicy targets for attackers that they will be compromised. The worst-case scenario for a situation like that is one where the attacker is able to get a copy of the email/password pairs, either in plain text or encrypted form. Ideally, the passwords that are stolen are salted and hashed – this shouldn’t give you the impression that your password is safe, though. All that salted and hashed data gives you is time to change your password.

Now, assume that the attacker has either stolen your passwords in plaintext, or cracked the salted hash – something that gets easier every day. If you haven’t changed your password, that attacker now has access to your data on that one single service.

What you’ll generally find, however, is that once a list of email addresses and passwords has been cracked, the primary target is your email account. If you use the same password, the attacker now has access to the Holy Grail of your Internet presence.

Your email account is the most important account you have

Someone else having access to your email account is a disaster. It’s potentially even more of a threat than someone getting access to your online banking account. Why? Password resets.

If you forget your password, which happens more often than you might think, sites need an automated way to ensure that only the account owner can reset it. The traditional way to do this is by email – you enter your username or email address into the site, and if it can associate a valid account with the email address provided then a unique reset link is sent out to that email address. This means that attackers could issue a password reset for anyone, but wouldn’t have access to the unique reset URL in the email.

That is, unless they have access to your email account.

It doesn’t stop there, either. Many webmail services provide easy setup for mail forwarding. While this is very useful, an attacker could (and they do – I have personally dealt with a situation like this) set up a rule to forward a copy of every single future email sent or received to an anonymous account that they can keep an eye on.

There are a huge number of sites that send your username and password to you after you sign up. This is terrible practice, but it is common. If a forwarder is in place, every time you sign up to a site that does this, the attacker gets a copy of your login details.

Not good.

Individual password security

Let’s start at the natural beginning – choosing a good password in the first place. I’m sure that you’ve seen the traditional rules a thousand times. Use lowercase, uppercase, punctuation symbols, and numbers, and make it a long password.

It’s more complicated than that.

The use of l33t – the replacement of letters with similar-looking numbers, like ’4′ for ‘A’ and ’3′ for ‘E’ – has become so common that password crackers check for it. A good cracker doesn’t just work in alphabetical order, it uses real-world observations about peoples’ password habits to make the most likely guesses first and reduce the time required to crack. A good first pass for a password cracker will be a list of words, then the same list of words with l33t substitutions, then the same list of words with a single character of punctuation at various places. It will then combine each word with each other word, and run the same check of a single character of punctuation with the combined words.

That process is a massive oversimplification, too. A huge number of passwords have been compromised over the years, and the designers behind password cracking tools have analysed peoples’ habits. Your best defence to defeat this is something called entropy.

Entropy is the only thing that matters

Entropy is a measure of randomness. To optimise password entropy, you need a password that can contain (note: not “does contain”, because that rule would decrease the entropy simply because it is a rule) an indeterminate amount of characters from the full set of typable characters.

This is great, but it does end up making passwords that humans can’t memorise. If you use a password manager – something I recommend and will talk about later – this isn’t a problem. However, if you’re keeping it in your head, the ideal password is one that optimises for the perfect balance between entropy and ease of memorisation.

This was covered by xkcd a while ago -

xkcd: "Password Strength"

xkcd: “Password Strength”

The ‘correct horse battery staple’ method shown above is actually pretty good when optimising for both memorability and security. Dumb brute force cracking would take a very long time, because while you lose out on character variability you gain in password length. It’s not as good as a password of that length made up of entirely randomly selected characters, but that’s a consequence of also optimising for memorability.

It’s worth bearing in mind that replicating this scheme exactly is probably a bad idea – I can guarantee you that hash crackers will add ‘four concatenated words’ as a cracking scheme if they haven’t already – but I’m sure you’re capable of coming up with something similar.

The xkcd comic also brings another point to mind: “password” is a misnomer. The correct term should be “passphrase” – a memorable phrase that is meaningful to you but meaningless to others (and can’t be inferred by others) makes a good password simply because of its length. Unfortunately, some less enlightened services cap your password length, sometimes even as low as 8 characters. There’s not a lot that you can do about that, other than not using the service. In the situation of being capped at 8 or so characters, you’re better off forgetting about optimising for memorability and just going for security if you can.

Stay aware of breaches

There’s no way to know about every breach out there, but usually when a significant number of account usernames and passwords are compromised they end up getting posted online as proof. A few services have appeared to take advantage of this – ShouldIChangeMyPassword will email registered users if their email address shows up in any publicised breaches, and PwnedList will do the same. It probably makes sense to sign up for both.

LastPass (which I’ll cover later) users benefit from their partnership with PwnedList in the form of the enabled-by-default LastPass Sentry. If any of the usernames you have saved in LastPass appear in publicised breaches, you’ll get an email.

Two-factor authentication

One way of beefing up security is the use of two-factor authentication. Traditionally, this means that to gain access you have to verify something you know (a passphrase) and something you have (a device, usually generating a code that changes over time). While there exist dedicated hardware tokens for this purpose, the easiest way to achieve it is by making your mobile the thing that you have.

This is the approach taken by Google in its Google Authenticator mobile app, which has an interface that allows it to be used by other applications such as LastPass (more on that later) and Dropbox. Google Authenticator also supports sending codes by SMS for those without smartphones. Microsoft eschews a mobile app and uses SMS codes to verify certain sensitive activities on your account. Blizzard’s Battle.net Authenticator also uses time-based keying in a mobile app, as does the well-hidden Facebook Code Generator which also offers SMS codes. If a service offers two-factor authentication, it’s usually a very good idea to take advantage of it.

The best password is often one that you can’t remember

Remember when I said that if we want to optimise for entropy, we need a truly random password of significant length? These passwords are pretty much impossible to remember, with the possible exceptions of the ones that you use multiple times a day. Using a password manager to generate unique, random passwords for each service you use means that breaches are contained to the site they occur on as there’s no sharing of passwords, and the time you have to get the password changed before it’s cracked is as lengthy as possible.

I consider there to be four good options as far as password managers are concerned.

LastPass

My personal favourite, LastPass is itself cloud-based. Alarm bells are ringing at this stage, I’m sure, but they don’t skimp on security. With a custom number of rounds of PBKDF2 brute-force protection running on a passphrase of unlimited length to protect the encryption key, Google Authenticator support alongside other methods of two-factor authentication (including a paper-based one), inbuilt integration with PwnedList called ‘LastPass Sentry‘ to notify you if your passwords are breached, incredible browser integration, and fantastic mobile apps, it’s an outstanding solution. There’s even a ‘security checker’ to warn you about which passwords are strong and which are weak, and it’ll even warn you if you use the same password twice.

The basic product is free, and for all features, the premium version is only $12 per year. Strongly recommended.

1Password

1Password has been on the market for a long while now. Originally for Mac OS X only, it has fairly recently been replicated for Windows and iOS. Android has a read-only app, but it’s not great, so if you’re not a fan of the Apple ecosystem then it might be one to avoid.

This is a shame, because 1Password is actually pretty good. It supports storing your encrypted data on Dropbox, and even has an HTML and JavaScript version for accessing your passwords on a Windows or OS X machine where you have access to your Dropbox but don’t have 1Password installed.

If you don’t want to use LastPass because you don’t trust its cloud storage aspect, but you want a nice user interface and good browser integration,1Password is a good choice.

PasswordMaker

PasswordMaker is the odd one out of the bunch. Instead of storing your passwords, it uses the URL of the site that you’re visiting (or any custom text, if you want to use it for non-Web resources) along with a passphrase and set of parameters to generate a password.

The idea is that every time you visit the same site, you’ll generate the same password, so there’s no need to save it. There are concerns about entropy here, but it can generate some seriously strong passwords as long as your master password is strong and kept private.

By the fact that it uses the real domain name of the site you’re visiting, there’s some inbuilt protection against some forms of phishing – if a site other than the one you expect asks you to log in, you’ll end up generating a completely different password.

It’s very lightweight, runs on pretty much every platform out there, and is free.

KeePass and KeePassX

An open-source contender, KeePass and its multiplatform counterpart KeePassX (which I’ll refer to jointly as KeePass from now on) work with a ‘container file’ that you can do what you want with. It’s strongly encrypted, so it’s feasible to keep it on some form of shared cloud storage.

Unfortunately, usability and browser integration suffer with KeePass, especially on platforms other than Windows. Still, it’s got a large degree of uptake, so it’s an option worth trying out.

It’s open-source, so both the code and price are free.

That’s about it

If you follow even some of the tips I’ve outlined above, you’ll be leaps and bounds ahead of most users in terms of password security. I’d love to know if you have any suggestions, tips, or tricks yourself – let me know in the comments if you do.

Cats and Bleeps: a bit of IDM silliness

Venetian Snares are an IDM outfit known for being completely unintelligible. With the notable exception of the excellent Szamár Madár, I can’t make heads nor tails of them.

That said, there is a wonderful little bit of silliness hidden at the end of their album Songs About My Cats.

It’s not really something that you can hear by listening to the album, so I’ve made a quick screencast to show you. It’s only a couple of minutes long, and it’s very, very cool.

Tagged , ,