# How Dumb Do You Want Them To Be? (Passwords)

It is this time again where I have to change my UGA password. Now, the rules have tightened — I can’t re-use an old password. What those who make these policies should know is that such rules make passwords less secure, not more.

How so? I have three tiers of passwords. My first tier is rough, with high entropy. They may look like a malformed perl script, except they are not. Good luck brute-forcing those. I use those to secure my primary computers. And since these are difficult to create in a reasonable way so I can memorize them, I do not change the first tier very often. Every few years, I create a new set, usually longer than the previous one. Apart from that, I do not share them, I do not store them, I do not write them down.

Passwords in the second tier are less demanding: Not as long, and usually without special symbols or maybe one to satisfy some minimum requirements. I use them for systems that I trust less (and this clearly includes UGA’s systems, whose mail servers are in Microsoft’s hands). Some of these I write down (unlike Tier-1 passwords, which are in my head only). I still think that my second tier passwords are reasonably secure.

My third tier passwords are related to those in tier-2 in difficulty. but I reuse them often, for example for websites where I don’t care if it gets cracked or stolen. I use those specifically for web sites where I am forced to fill out those inane “security” questions, such as my mother’s maiden name — “security” has to be in quotes, because a hacker won’t find it particularly hard to find the answers on the web. And this means that while demands for the regular passwords become stricter over time, the “security” questions open a backdoor that makes the passwords rather irrelevant. So, a third tier for web sites whose security is low to begin with.

What about UGA’s new rule, then? I can’t re-use a good password, so I have to use something that I can easily memorize. A practical solution presents itself with a Tier-3 password that has a two-digit counter, such as FobHasO#01 (meets requirements of length, upper- and lower case, special symbol, and digits). And every time I have to change the password, I simply count up. Next time, this would become FobHasO#02. And I have to write down where the counter stands. And I re-use those for other sites with similar requirements to limit the number of passwords that I have to manage.

Essentially, a feel-good attempt to make passwords more secure clearly leads to passwords that are less secure. So how dumb do you want to make password security?

Ah, yes. Two-factor authentication. Passwords become less secure, so let’s add another layer of inconvenience. Moreover, 2FA is often turned off when you reset the passwords and fall back onto those “security” questions. Plus — and this will get interesting — what do those rare people do who do not have a cell phone, and who do not want to have a cell phone?

# How Smart Do You Want Them To Be?

Today, every Thing seems to be smart. From smart phones to smart appliances to smart… whatever. Some of these devices are probably justified, but do I need a smart door lock? Or a smart light switch? Often, “smart” simply refers to the ability to control the device from a smartphone. I’ll let you decide if you want to pay for this convenience with an involuntary invitation for Russian hackers to do a virtual tour of your house. However, there are certainly cases, in which the price for “smart” is no longer acceptable.

Recently, I ran across a “smart” circuit breaker in Italy. A photo is on the right. Notice the typical breaker bar (black) in the oval opening at the bottom of the device.

A circuit breaker is an important safety device. If the circuit runs a higher current than the wiring allows, there is a real risk of fire and other damage. Therefore, a breaker typically trips after a few seconds of overload. The short 2-3 second delay serves to prevent tripping by commonly encountered startup transients of heavy loads. The delay should not be longer, however, because each second of overload increases the risk.

Not so the breakers I am writing about. These actually wait for several minutes. And while they wait, they display a message “Ridurre Carico…” — Reduce current. Helpfully, the message continues “Too much current … reduce current … by 17%”.  The breaker was protecting a small apartment, which admittedly had a number of high-wattage devices, including a washing machine, two water heaters, a stove and, yes, a toaster. Using each of them individually was fine, but any combination of two devices caused the breaker to trip after several minutes.

What gives? If the breaker is intended to protect the circuit, it should trip almost immediately. Since it does not, I have to assume that its purpose is not protection but reeducation. After the apartment goes dark, you find your flashlight, go outside, find the breaker box, and reset the breaker. It then continues to tell you by how much your current load… no, I’d better call it allocation… is exceeded. Now you have a few minutes to turn off your electrical load(s), or the breaker trips again. Based on my observations, I assume that these devices are supposed to reduce overall power consumption rather than protect the house.

Is this the future of “smart” devices? The municipal government — if my assumption is correct, of course — imposes some arbitrary current limit and cuts you off it you don’t obey… comply, I mean. It feels to me as if this is a tent flap already being lifted by the camel’s nose. This is not voluntary. It is imposed.

How would such a breaker change people’s behavior? Those who lived in the apartment simply made sure that the loads were turned on sequentially, not simultaneously. An annoying inconvenience, to be sure, but certainly not the presumed power savings. In fact, if this was my apartment, I’d build a device that sequentially connects the power loads depending on a simple priority schedule.

If my assumption is correct, we have yet another example of overreach by the authorities with minimal benefits at best (and who defines what counts as benefits?)

There will be some who applaud such measures and likely call for even more stringent controls, such as disallowing sequential use of high-power devices. After all, it is for the common good, right? For those I have the following question: Where do you draw the line? At what point would you consider a government intrusion into your private lives unacceptable? Because with “smart” devices, under government control, there is no limit to government intrusion. And once “smart” devices are widespread enough, controlling them centrally is but a small step. Remotely control your power consumption? They already do that, see above. Turn off your A/C at 5:00 pm? Definitely possible. Monitor your water consumption and give you a ticket if you shower too much? Sure, why not. Remotely open your smart door lock for a no-knock warrant? No problem here. Warrant? How old-fashioned…

If this is truly the future of smart devices, I think we need to put a foot on it. After all, who needs the Stasi when all these functions can be automated and centralized?

If the future of smart devices includes imposed government access, we need to ask with the words of Juvenal, Quis custodiet ipsos custodes? — Who guards these guardians?

# dd to the rescue

Recently, I needed to rescue a DVD (legally owned!) with read errors by making a copy. In Linux, the “device dump” or dd command can be useful, because it can read past disk errors and thus salvage whatever is intact. For example,

dd if=/dev/sr0 of=rescued_dvd.iso bs=2048 conv=noerror,notrunc iflag=nonblock

tells dd to perform low-level read (blocksize 2048bytes) from the raw device, i.e., /dev/sr0, to write whatever was salvageable to the file “rescued_dvd.iso” and to skip over errors (most importantly, the conv=noerror parameter). Fortunately, I realized that there is something even better, a neat utility called ddrescue. In principle, ddrescue performs the same low-level read, but it is optimized for failing hard drives — and this prompted this post.

I have rescued my share of hard disks, often for colleagues who came to me as a last resort. There are several tricks with which data from a failing hard drive can be recovered — even in cases that seem hopeless. Typically, Windows gives up first, claiming a nonexistent or unformatted disk (hint: don’t accept the offer to format the drive!). Here are some steps that I found useful to follow:

Turn off the computer. Don’t even bother shutting down. The write operation is more critical than the read operation, and any attempt to write to a failing hard disk makes matters worse. And Windows writes a lot to any drive during boot and shutdown.

Attach the drive to a Linux computer. Some computers have a hot-swap e-SATA connector. An external SATA-to-USB cradle is useful, too. Worst case, attach it internally (with power down) and boot it up. DO NOT ALLOW THE O/S MOUNT THE DISK!

A first attempt can be made by mounting the drive read-only (!) and trying to read as many files as possible. Often, 80 to 90% of the data can be recovered in this fashion.

Next, ddrescue comes into play. Since the low-level device is accessed, the drive does not need to be mounted. Let’s assume the drive maps to /dev/sdd. In the simplest form

ddrescue /dev/sdd disk_rescue.img

starts ddrescue and tries to image the entire drive to the file disk_rescue.img. Note that this is a raw read operation, and the image file will be as large as the entire drive capacity. For example, if you image a 1TB hard disk, you need to have 1TB free space — if necessary, use a separate hard disk.

The interesting feature of ddrescue is that it attempts to read good sectors first (to salvage as much as possible, assuming that the drive keeps degrading), then repeatedly reads the bad sectors — often, repeated reads are rewarded with a random success. This process can take days, literally. When the process is finished, mount the image file and examine what you salvaged.

DISCLAIMER: This article is not intended as advice, and the author assumes no warranty, either explicit or implied. If you have critical data, consult a professional data recovery service.

# Raspberry Pi: Auto-starting a control system at boot time

Micro-sized computers, such as the Raspberry Pi, become increasingly popular as high-end replacements for microcontrollers. If a control program needs to be run in the Raspberry Pi, we would often like it to start automatically at power-up (much like a microcontroller would behave), or, more precisely, at boot time.

The information in this post can be found in various places on the Internet. It is nothing new, and I consider this to be a sort of yellow sticky note for myself — plus everybody else who might find this interesting.

Typically, the Raspberry Pi boots up and presents a login screen, either a text-mode console (TTY) or an X-window-based GUI. In either case, we need to manipulate the boot process. I assume that you (the reader) are familiar with text editors, the command-line interface, and with simple Linux behavior, such as the fact that you need to have root rights to edit files in /etc (and, for that matter, know what /etc means).

Step 1: Create the user account under which the program will run

You probably don’t want to run your application program with root privileges. Therefore, let’s create a dummy user under whose account the application will run. Let’s call that user “app”. Since we need that user to have a valid login, you also need to create a strong password. You know… if it looks like a Perl statement, you are doing something right. Note: After you added the user (e.g., with “adduser”), you may need to add this user to several groups to provide access to I/O functions. Relevant groups could be, for example, plugdev, dialout, or gpio.

Next, install the application program and verify that it works. You do this by logging in under the new user “app” and starting the program as you would normally do.

Step 2: Auto-login the new user

Now, we will modify the boot table so that the new user is logged in automatically whenever the Pi is booted up. The relevant file for this purpose is /etc/inittab. Normally, this file spawns six TTY console logins (getty) to allow normal login. Choose one console (TTY1 is the one that shows up on boot, but any other console works, too). Let’s assume we log in the user on TTY2. Fairly far down in /etc/inittab, you’ll find a block that looks like this:

1:2345:respawn:/sbin/getty 38400 tty1 2:23:respawn:/sbin/getty 38400 tty2 3:23:respawn:/sbin/getty 38400 tty3 4:23:respawn:/sbin/getty 38400 tty4 5:23:respawn:/sbin/getty 38400 tty5 6:23:respawn:/sbin/getty 38400 tty6 

The first column is the TTY number. The second is the runlevel under which this TTY is activated. The third column is the action (respawn) and the fourth is the command to respawn. We now change the second line to

2:23:respawn:/bin/login -f app tty2 < /dev/tty2 > /dev/tty2 2>&1

Instead of starting a getty on TTY2, we now start a login (the -f flag specifies the user name). Also, we redirect standard input and output from/to TTY2 (i.e., the device /dev/tty2). Note also that we don’t really need “app”‘s password here. The password is useful when you need to manually login to troubleshoot.

If you reboot the system now, you should see that user “app” is automatically logged in on TTY2. Neat.

Step 3: Auto-start the application when “app” logs in

There is a file in each user’s home directory, named .profile, which is executed by the login shell. Note: If the login shell is bash, make sure that neither .bash_profile nor .bash_login exist, because those override .profile.

Complete this step by editing /home/app/.profile and appending the command to start your application. This is what it could look like towards the end of .profile:

# set PATH so it includes user's private bin if it exists if [ -d "$HOME/bin" ] ; then PATH="$HOME/bin:$PATH" fi  # Autostart the control program  $HOME/start_my_control.sh 

The actual start of the application is now performed in a script called “start_my_control.sh”, and you can use that script file to set any environment variables, provide command-line arguments etc. as needed.

What to do when the program has a GUI and requires X window?

Disable the automatic start of the X window system on TTY7 and instead use “startx” to start the X window system from the user’s login in Step 3. Then use the window manager’s autostart feature, which depends on the window manager (xfce? lightdm?) you installed.