passwords

In the electronic battlefield that is 2019, the realm of password security is fraught with dangers. Websites from companies big and small leak like sieves, storing user data in completely unsecure ways. Just about the worst thing you can do is use the same password across several services, meaning that an attack on one gives entry to multiple accounts. The challenge is to generate a unique and secure password for each and every application, and [Ilia]’s way of doing that is called HashDice.

No, it’s not a password manager, or an app – it’s a simple method that can be readily applied by anyone with the right tools. A simple dice is used to create random numbers, which are used to select words from a list to form the basic secret phrase. This is then combined with the name of the service or application to be accessed, the date, and a salt, before hashing using the SHA256 algorithm. The final hash is then truncated to create the password. You can do it all on a device that’s airgapped from the world, ensuring your core secret is never exposed, thus maintaining security.

There are some pitfalls to this method, of course. Many websites make things harder by requiring special characters or enforcing length limits on passwords. [Ilia] helpfully suggests several workarounds for this, but admits that no system is perfect in the face of these obstacles.

Security for anything you connect to the internet is important. Think of these devices as doorways. They either allow access to services or provides services for someone else. Doorways need to be secure — you wouldn’t leave your door unlocked if you lived in the bad part of a busy city, would you? Every internet connection is the bad part of a busy city. The thing is, building hardware that is connected to the internet is the new hotness these days. So let’s walk through the basics you need to know to start thinking security with your projects.

If you have ever run a server and checked your logs you have probably noticed that there is a lot of automated traffic trying to gain access to your server on a nearly constant basis. An insecure device on a network doesn’t just compromise itself, it presents a risk to all other networked devices too.

The easiest way to secure a device is to turn it off, but lets presume you want it on. There are many things you can do to protect your IoT device. It may seem daunting to begin with but as you start becoming more security conscious things begin to click together a bit like a jigsaw and it becomes a lot easier.

There are innumerable password hacking methods but recent advances in acoustic and accelerometer sensing have opened up the door to side-channel attacks, where passwords or other sensitive data can be extracted from the acoustic properties of the electronics and human interface to the device. A recent and dramatic example includes the hacking of RSA encryption simply by listening to the frequencies of sound a processor puts out when crunching the numbers.

Now there is a new long-distance hack on the scene. The Cerebrum system represents a recent innovation in side-channel password attacks leveraging acoustic signatures of mobile and other electronic devices to extract password data at stand-off distances.

Passwords are supposed to be secret, like the name of your childhood pet. In contrast, you carry your fingers around with you out in the open nearly everywhere you go. Passwords also need to be revocable. In the case that your password does get revealed, it’s great to be able to simply pick another one. You don’t want to have to revoke your fingers. Finally, and this is the kicker, you want your password to be hashable, in order to protect the password database itself from theft.

In the rest of the article, I’ll make each of these three cases, and hopefully convince you that using fingerprints in place of a password is even more broken than using a password in the first place. (You listening Apple and Google? No, I didn’t think you were.)

The idea started with the concept of a dedicated device to carry a complicated password; something that you couldn’t remember yourself and would be difficult to type. [Dan] also decided it would be much better if the device didn’t need its own power source, and if the user interface was dead simple. The answer was a wrist-band made up of a USB cable and a microcontroller with just one button.

To the right you can see the guts of the prototype. He is using a Teensy 2.0 board, which is capable of enumerating as an HID keyboard. The only user input is the button seen at the top. Press it once and it fires off the stored password. Yes, very simple to implement, but programming is just one part of a competition. The rest of his time was spent refining it into what could reasonably be considered a product. He did such a good job of it that he received an Honorable Mention from Hackaday to recognize his execution on the build.

Fabrication

[Dan] came up with the idea to have a pair of mating boards for the Teensy 2.0. One on top hosts the button, the other on the bottom has a USB port which is used as the “clasp” of the belt buckle. One side of the USB cable plugs into the Teensy, the other into this dummy-port. Early testing showed that this was too bulky to work as a bracelet. But [Dan] simply pivoted and turned it into a belt.

[Kenji Larsen] helped [Dan] with the PCB-sandwich. Instead of mounting pin sockets on the extra boards, they heated up the solder joints on a few of the Teensy pins and pushed them through with some pliers. This left a few pins sticking up above the board to which the button add-on board could be soldered.

To finish out the build, [Dan] worked with [Chris Gammell] to model a 2-part case for the electronics. He also came up with a pandering belt buckle which is also a button-cap. It’s 3D printed with the TechCrunch logo slightly recessed. He then filled this recess with blue painter’s tape for a nice contrast.

[Dan] on-stage presentation shows off the high-level of refinement. There’s not a single wire (excluding the USB belt cable) or unfinished part showing! Since he didn’t get much into the guts of the build during the live presentation we made sure to seek him out afterward and record a hardware walk through which is embedded below.

[HeadlessZeke] was excited to try out his new AT&T wireless cable box, but was quickly dismayed by the required wireless access point that came bundled with it. Apparently in order to use the cable box, you also need to have this access point enabled. Not one to blindly put unknown devices on his network, [HeadlessZeke] did some investigating.

The wireless access point was an Arris VAP2500. At first glance, things seemed pretty good. It used WPA2 encryption with a long and seemingly random key. Some more digging revealed a host of security problems, however.

It didn’t take long for [HeadlessZeke] to find the web administration portal. Of course, it required authentication and he didn’t know the credentials. [HeadlessZeke] tried connecting to as many pages as he could, but they all required user authentication. All but one. There existed a plain text file in the root of the web server called “admin.conf”. It contained a list of usernames and hashed passwords. That was strike one for this device.

[HeadlessZeke] could have attempted to crack the passwords but he decided to go further down this rabbit hole instead. He pulled the source code out of the firmware and looked at the authentication mechanism. The system checks the username and password and then sets a cookie to let the system know the user is authenticated. It sounds fine, but upon further inspection it turned out that the data in the cookie was simply an MD5 hash of the username. This may not sound bad, but it means that all you have to do to authenticate is manually create your own cookie with the MD5 hash of any user you want to use. The system will see that cookie and assume you’ve authenticated. You don’t even have to have the password! Strike two.

Now that [HeadlessZeke] was logged into the administration site, he was able to gain access to more functions. One page actually allows the user to select a command from a drop down box and then apply a text argument to go with that command. The command is then run in the device’s shell. It turned out the text arguments were not sanitized at all. This meant that [HeadlessZeke] could append extra commands to the initial command and run any shell command he wanted. That’s strike three. Three strikes and you’re out!

[HeadlessZeke] reported these vulnerabilities to Arris and they have now been patched in the latest firmware version. Something tells us there are likely many more vulnerabilities in this device, though.