23 July, 2011

Passwords, part three of two

This post and more specifically, this comment make me want to write a few more sentences on the topic of password selection. First off, the article is a good read, and talks about what kinds of bad passwords people chose.

Now for the frequent objections I get to the method I suggest. They all some some truth to them, but none of them are convincing enough not to use this system.


1. Someone can figure out your password generating rule if they get to look at one of them.

An example: okdufgo3fa. Can you tell that this is a password for Facebook? Could you tell that erdufgo3ga would be the corresponding Gawker password? You probably can, at least if you have two, and if you took a few moments to go through the most obvious ways to do that. There are two issues with this: One: This is a problem where you have to find a pattern. Humans brains are ridiculously good at anything pattern-related. Computer chips on the other hand are incredibly bad at it, especially if you start to use rules which are obvious to humans, but arbitrary to computers, such as "put all vowels in front of the consonants (facebook becomes aeoofcbk). Computers don't even know about vowels.

This directly leads us into our second point: We have CPU power in abundance, but not human eyes. No hacker would bother looking at thousands of leaked passwords personally, trying to figure out the rule for every one of them. And since everyone else has a password like '12345', why should he even bother?

Conclusion: Nobody will take the time to break it, and even if, it's not actually as easy as it sounds.


2. What do you do when you have multiple accounts for the same service?

Completely different, yet the same underlying issues. What does it mean to have two accounts at the same service? Well, two user names use the same password. But how is a hacker going to know which two user names match? He cannot even do this via brute-force, because all the people that chose '12345' will crowd the list of duplicates. Again, this comes down to the fact that a hacker won't even bother.

And secondly, how is someone going to use that knowledge, if they do not have your other account name? They cannot infer the rule to generate more passwords (since they only have one example), they cannot break into your e-mail or your bank, and most importantly: When a service gets hacked, you lose both your passwords there to begin with and usually not just one. In the end, this does not make any difference at all.


3. Some services require you to change your password from time to time.

In that case, there is no useful way out of it. Your chosen rule will probably not adhere to anything like this. But compare it to any other system of choosing passwords: You would also have to change your password every few months. In the end, no system can cope with this to begin with, so the best way to handle such an egregious exception is to make it one: You will have to remember a specialized (frequently changing) password for just that service. I would recommend not using the service, because that's just a huge bother.


4. Restrictions on character range or length.

This only really applies if you chose a bad function that does not include one or two digits, and is very short. The easiest way to avoid the issues is by selecting a function which will always result in 9-12 characters, and have exactly two letters in it. I know of no web-service where such a password would not work. Except for my bank account, where only letters work, so I have to write that password down on paper. It figures that my most important password is the one I have to treat the most risky, by writing it down.


Overall conclusion: There are some small issues with the system, but they are less impractical than any other system would have, facing the same problems.

Addendum: Nobody has yet pointed that out except for Randall, but the real issue of passwords is mostly length. 20 lowercase letters are way harder to solve than a combination of letters, capitalisation, punctuation and numbers if they only last for 8 characters. You can just use a very long static string in this system, and you're fine.

Synology DNLA transcoding alternative

I am a happy owner of a Synology NAS (a DS411j). The DS offers DNLA support, so I could theoretically just plug my TV into the ethernet, and watch all my accumulated movies and anime easily. Sadly, the TV is too cheap to have any decent codec support. Usually, one would install Serviio or another DNLA server onto the DS, as described here.

But annoyingly, the DS411 only sports a tiny ARM CPU which cannot keep up with transcoding difficult codecs (h.264 to mpeg2). The solution? Do all the transcoding over night, and not while you are watching it. This solves the issue of lack of processing power, and results in a neat directory full of files that actually work. The obvious tradeoff being hard drive space, but then a DS411j has four disk slots and hard drives are dirt cheap.

Follow the directions over there to bootstrap the NAS, install ipkg, wget, ffmpeg and yasm. Also execute these two lines if you get an error message about libraries not found when you try to start ffmpeg:

cp /opt/lib/libbz2.so.1.0 /lib
cp /opt/lib/libz.so.1 /lib

After that, use a script such as this

#! /bin/sh
SOURCE_DIR="/volume1/input"
TARGET_DIR="/volume1/video/transcode"
for a in "$SOURCE_DIR"/*.mp4 "$SOURCE_DIR"/*.avi "$SOURCE_DIR"/*.mkv
do
 if [ -f "$a" ];
 NEW_NAME=$(basename "$a")
 COMPLETE_NAME="$TARGET_DIR"/"$NEW_NAME".avi
 echo $COMPLETE_NAME
 then  
  if [ -e "$COMPLETE_NAME" ]
  then
   echo "Already converted: $a"
  else
   echo "Converting: $a"
   ffmpeg -i "$a" -y -vcodec copy -vbsf h264_mp4toannexb -copyts -acodec ac3 -ab 128k -ac 2 -map 0:0 -map 0:1 -sn -f mpegts "$COMPLETE_NAME"
  fi
 fi
done

to automate the conversion. It will check whether a file was already converted, and if not, automatically start to do so. Note that the parameters for ffmpeg work for my Panasonic Viera, you might have to use a different set of codecs. You can check the Serviio forums for a good selection of transcoding profiles, and then trial and error your way to success.

You can then set up a cron job (more on that later) and make your script run automatically every few hours. If there is nothing to convert, it will immediately terminate.

Open issues:

  • If anyone with more .sh-knowledge than me could improve upon this and add recursive folders and some such, I'd very much appreciate it.
  • I also cannot get my Synology to find these newly created files very quickly, it takes a long time until the DNLA service finally displays them. Is there a quick way to add them to the index?
  • I cannot get .wmv videos to convert, ffmpeg seems to fail to read them. It might be my selection of them, or a general issue, I don't know yet.