The main concept behind the paper is that the most common type of attack against a password-protected system is a brute-force attack which relies on a popularity-sorted dictionary. The proposed protection is to prevent any password from becoming popular enough that a statistical attack is likely to succeed.

There are a number of problems with this idea, however. First, a goal would likely be to prevent any password similar to a popular password from being used. However, if passwords are stored as hash-values (or salted hash-values) there would be no way to compare and find similarity. Storing the passwords as plain-text would solve this problem but introduce a vulnerability if the attacker obtained the password-database. Second, if the popularity is stored as a numeric value an attacker who obtains the database can determine that N users have the same password and use that information to pick a likely passwords. Similarly, an attacker can attempt to create a new password and determine if that password is popular by consulting the database, which would allow the attacker to concentrate on only the most popular passwords.

Herley, et al address these issues by proposing that popularity be stored as a count-min sketch and ensuring false-positives in the data. The count-min sketch is a data structure which relies on the results of multiple hash functions. An array is kept for each hash function recording the number of times that particular hash-value is used. When checking if a password is popular, the lowest number of times reported for the hash-value determines the number of times the password has been used. Collisions in the hash functions allow protection against similar passwords (see Figure 2). This number can be compared against a threshold to determine if it is too popular. False positives in the data help insure that an attacker who gains access to the sketch will not be too greatly aided (section 3.3). False positives are contributed by the collision in hash functions as well as restricting the counters in the sketch to have a maximum increment. Passwords which use these counters will all appear equally popular, forcing an attacker to waste time trying all of them.

A problem with this approach is that the number of organizations which can create an effective popularity count-min sketch is limited to organizations with a large number of users. A possible solution would be to have a shared count-min sketch among organizations, but that would make it easier for an attacker to obtain.

A proof-of-concept implementation of a count-min sketch will follow soon.

Everyone knows about Pong – the little game that you all played on your TI-83 in high school when you were supposed to be paying attention in math class. Along with all the other games you played on your calculator – I’m hoping to play with those later. Anyway. I’ve always had an interest in 3D graphics and how they relate to games. I did some dabbling in OpenGL last summer and it was painful to say the least. I’ve also been dabbling with Python lately, so the next obvious step was to figure out how to do graphics in Python. There a lot of libraries to do this (pygame comes to mind), but I decided to use VPython. It provides all sorts of nice little things – namely the code to construct a shape.

from visual import *
square = box( pos = (0, 0, 0), size = (3, 3, 3), color = color.green)

Nice. You can give the box a velocity by doing something like:

box.velocity = vector( 5, 0, 0 )

Then you can update the position of the box accordingly using your basic physical relationships. You know, Vf = Vi + at, and all the other stuff you learned in physics. Unless you took Physics 1A with Professor Corbin at UCLA, in which case you learned all sorts of other cool stuff and aren’t sure how you passed the class. But I digress.

I started this project just trying to learn how VPython works, and I ended up implementing a version of Pong that is playable, but slightly boring. There is no score display, end-of-game info is displayed in the console, and there is no vector math implemented. Therefore, the ball always bounces at a 45 degree angle from the wall or the paddle. This is both unrealistic and boring. I’m no mathematician, and I don’t currently have the time to implement the vector math. I’ll leave that as an exercise to the reader. If you do end up implementing it, please let me know. I’m sure I’ll get around to it eventually, I just have finals coming up in the next week so it’s low on the priority list.

Anyway. That’s what I’ve been up to lately. I’m working off and on on doing a Tetris clone, and I’ll probably eventually get to Space Invaders. Maybe not with this library though. I’ll probably pick up something else (maybe a new language). Maybe I’ll go back to OpenGL or DirectX if I’m bored enough (and in a slightly masochistic mood). For those who are interested, the code is uploaded here. Comments and edits appreciated. Thanks for reading!

To test the service, I modified the excellent script created by Manu J.

#!/bin/sh
 
cur_dns=`cat /etc/resolv.conf | grep "nameserver" | tr -cs '0-9.' '[\n*]'`
 
for i in "lifehacker.com" "facebook.com" "manu-j.com"  "reddit.com" "tb4.fr" "bbc.co.uk" "intmain.net"
do
  for j in "4.2.2.2" "8.8.8.8" "208.67.222.222" $cur_dns
  do
    echo "\n$i\n$j"
    for k in $(seq 1 100)
    do
      echo `dig @$j $i | grep Query | awk -F ':' '{print $2}' | tr -cs '0-9' '[\n*]'`
    done
  done
done

My two changes were to grab the DNS servers defined in /etc/resolv.conf and to query each service 100 times. Of course, the only downside to this test is that it does not account for the DNS server caching the result of repeated queries. This effect shows up in a few of the graphs (included below).

Google’s DNS service is very consistent in speed, but is also consistently slower than any of the other servers tested. Google’s DNS service also shows very little difference with repeated requests, except for the lookup of intmain.net, where the first request took significantly longer than the others. Similarly, Google’s DNS took over 2 seconds to respond to a request of reddit.com. The final ordering is as such: the fastest in most cases was the DNS servers local to the network (except for uncommon sites, which took between 100ms and 150ms for the first request), followed by 4.2.2.2, followed by OpenDNS, and trailed by Google Public DNS.

I encourage you to perform the same (or similar) tests on your own computers and share the results. It’s very hard to tell if the differences in response times are caused by latency or lookup time, but it is clear that the best DNS servers for me to use are the ones local to my network at UCLA.

Eggert spoke about several things, including how he became involved with free software, his take on the free software community, how to get involved in free software, and projects he thinks would be great to have done.

Eggert mostly became involved with free software as a result of what he calls laziness. Essentially, he got tired of re-patching emacs to work on his (unusual) architecture, so he started submitting patches to Stallman. From there, he just continued submitting patches.

Similarly, Eggert thinks that the best way to get involved in free software is to just start contributing. In order to get noticed, he recommends that people pick “medium-sized” patches; not something small enough that another person could do in 15 minutes, but also not large enough that it makes any major changes. An example of a “medium-sized” project would be patching to take advantage of multi-core systems. Since most programs currently are designed with a single-core architecture in mind, some significant improvements in speed could be obtained by moving it to multi-core. Doing something like this would help to build one’s reputation in the meritocracy of the free software community.

In terms of the future, Eggert thinks that we need new languages to properly take advantage of multi-core. In particular, he mentioned projects like Hadoop are steps in the right direction. Additionally, he thinks that the current shell is too complicated for non-trivial tasks.

Anyway, happy halloween!

All Engineering students — particularly those in CS — are invited to hear
Professor Paul Eggert speak on Open Source software, how he got involved over
his career, how he has contributed. The GNU Core Utilities project includes
such all-important programs as “ls”, “cp”, “sort”, “echo”, “cat”, and many more.

Wednesday, October 28, 2009
6 PM
Boelter Hall 4760
Details: http://linux.ucla.edu/sean/eggertflyer.pdf

Paul Eggert is a lecturer in the Computer Science department here at UCLA. He
teaches operating systems, programming languages, software development, and
more.

map <space> /

All you VIm users out there know how to search for text – this enables me to search with the space bar, which feels more natural and quicker than having to type a special character.

set nocompatible
set number
set columns=80
set ruler
set background=light
set wrap!
syntax enable

This turns off emulation of bugs from Vi, enables line numbers, restricts my window to 80 columns, displays some basic information about where I am on a line, tells VIm to use fonts optimized for a light background (corresponds with my terminal colors), turns off word wrap, and turns on syntax highlighting. These options are all configured for programming.

set showmatch
set ignorecase
set hlsearch
set incsearch

This is extremely useful for searching in a file. The first line highlights matching braces, which is very nice for nested statements and complex conditionals. It also makes searching case-insensitive, highlights search matches, and starts searching with the first letter that you type. If you pay close attention when searching you only ever have to type the minimum amount of letters to find what you want. I find this greatly speeds up moving through a document.

set autoindent
set smartindent
set tabstop=4
set shiftwidth=4
set expandtab

These settings tell VIm what to do with tabs and indents. The first two lines tell the program to format indents according to the file type. As long as you’re using a C type language, this works extremely well. The second two lines tell VIm to use 4 spaces when the tab key is pressed, and the final line expands all tabs into spaces. This helps remove compatibility problems between tabs and spaces.

set vb t_vb=

This just turns off those pesky beeps when you enter an invalid command. Instead, the screen flashes for an instant. Much nicer in my opinion.

set gfn=BitStream\ Vera\ Sans\ Mono:h14

This sets the default font for the editor – Monaco Size 10. My current favorite programming font on OS X. Anyway, that’s a bit of a discussion about my .vimrc. The full file is below for anyone who wants to read the whole thing or copy/paste it for their own use.

".vimrc
"Author: Eric Hertz
"Date: 10.14.2009
"
"This is a configuration file for VIm, the terminal text editor. Feel free
"to use this however you wish.
 
"Key mappings
map <space>  /
 
"Interface settings
set nocompatible
set number
set columns=80
set ruler
set background=light
set wrap!
syntax enable
 
"Search settings
set showmatch
set ignorecase
set hlsearch
set incsearch
 
"Indent settings
set autoindent
set smartindent
set tabstop=4
set shiftwidth=4
set expandtab
 
"Audio settings
set vb t_vb=
 
"Font settings
set gfn=BitStream\ Vera\ Sans\ Mono:h14

My name is Eric, and I’ll be one of your regular authors here on int main(). You’ve probably already read a little bit about me from the post that my friend Sam put up earlier, but I’ll start with a quick introduction and background . I’m a second year Computer Science student at the University of California, Los Angeles. I consider myself well-versed in C, C++, and Java, primarily. I also enjoy (if that’s the word) working with assembly on occasion (I’ll post a discussion of some assembly topics later on). Anyway. That’s a little bit about myself. I’d also like to state here that if any of our readers have side projects that they are working on and would like an extra set of eyes or hands, feel free to email. Now that I’ve dispensed with the introductory remarks, let’s dive right into today’s topic.

I feel that as a reader, I would be hesitant to read and trust someone’s opinion on things unless I knew that they actually had some experience with the things that they write about. To that end, I’d like to start this blog by talking about a program that I was a developer on – AudioGuardian. This begs a bit of background information, I’m sure. This project started as part of a competition back in February 2009. I participated in SS12 put on by ProjectPossibility, an organization aiming to make technology more accessible to the disabled community. AudioGuardian was originally named MobileSoundNotifier, and its purpose was to alert hearing-impaired users of hazards in their environment. I will append links to the project’s webpage, the project wiki, and the SVN if any of our readers would like to see some of my “production” code. I quote that because it’s definitely hacked code – this project was completed over the span of approximately 30 hours. From scratch. With that said, here’s the links to the project information:

Project Webpage
Project Wiki

The SVN is linked from the webpage in the bottom right hand corner, if any of you enterprising developers would like to take the project and work on it yourself. It is licensed under the GPL, so keep that in mind. .

I guess you can’t really fork this project without knowing a bit about how we actually designed and developed the program. Coupled with the fact that this is a CS blog and not a self-promotion blog, I will now move into a technical discussion of the program. I’m going to keep this as high-level as possible so it will appeal to all audiences. Let’s get to it.

This application is built using J2ME, which is the Java 2 Mobile Edition. It has most of the capabilities of the full Java language, but it’s missing some key features. It does not support the Swing environment, so we used the built-in J2ME graphics library to build a primitive GUI. The programming paradigm is event-driven, like the majority of Java programs. A control loop listens for commands and acts appropriately. The basic application logic should be simple to follow. But that’s all academic and really not what you’re here for. Let’s get into the problems with working with audio.

The heart of this program is an audio analyzer. It listens to the surrounding environment and throws alerts when it detects sounds deemed dangerous by either us (the programmers) or the user. Those of you with a physics background may have heard of a discrete Fourier transform before. If so, you will know that this is a complex wave analysis algorithm used to translate a signal from the time domain to the frequency domain. This was important for our application because we cannot use the time domain to perform sound matching. The only correlating factors between sound waves are amplitude and frequency, which we have to use a DFT to extract from the data stream. Sounds simple, right? Without looking at any code (you can download the code yourself and look at it, it’s too long to post here), let’s discuss the issues here.

All microphones are not created equal. Every mic has a different sensitivity and different DC offset applied to the raw data stream. This was a problem for us, since we were doing development across different laptops with different microphones. To that end, we decided to build a calibration function that listens to the ambient environment and basically filters the offset and all the outside noise. This also had the unintended side effect of increasing the accuracy of the matching function. It also built cross-compatibility, so our application will work with any microphone out there. The program also had some problems processing data streams in byte array form. The Recorder class in J2ME had a nice little habit of including the file header when it passed the data to a byte array. This then caused garbage to be passed to the graphing function, which caused some serious inaccuracy and lag time in sound recognition. To fix this, we had to strip the file header ourselves. I’ll leave it to the reader to read the code and see exactly what we did.

Other problems we encountered:

The DFT itself was not easy to write. It didn’t help that J2ME was very poorly documented and as such we could not find a standard library. We ended up borrowing an implementation of quicksort from an outside source. It was optimized for use on pairs of data, which was what we were using for matching. Writing this alone took us almost an entire day of work, and then the rest of the time was spent building a GUI and other small features into the program.

One final problem was the issue of data persistence. We wanted to be able to store settings and data across instances of the program. Sounds simple, right? Write the data to a file and restore it when you open the program? Easy enough….until you look at how mobile phones and the J2ME stores data. We ended up using something called a RecordStore, which is actually an object in Java. It has to be opened before it can be used. It is indexed in a very counterintuitive manner – not like a normal array or vector of objects. We essentially ended up taking this RecordStore object and building our own suite of methods to store and access data, because the built-in functionality was not doing what we needed it to do. This took a large amount of time as well, and took brains away from cracking the DFT. All in all, however, we managed to get everything working.

Well, that was long. Hopefully I gave you all a bit of insight into that project, and a bit of perspective on what goes on in developing a mobile phone application when you’ve never done it before. If any of you have questions or would like me to cover something more in-depth, please post a comment or drop us an email. We also appreciate email if there is any topic you’d like us to talk about in general . See you next time.

What’s an Intrusion Prevention System? Well, it’s a software module that scans internet packets for malicious attacks and then blocks attacks. Modern security programs, like Norton Internet Security1, scan the contents of all incoming (from the Internet to your computer) and outgoing (visa versa) network packets for attacks that may harm your computer or originate from your computer and harm other computers. If an attack is found in any packet, that packet can be dropped and prevented from reaching/leaving your computer.

This was a very limited simulation. Packets all arrived in order, signatures were guaranteed to start with 6 constant characters and have a maximum length, and the use of a buffer was limited to 4500 characters. The hardest parts were making sure that offsets from the beginning of the stream were reported correctly and trying to minimize the number of times the same characters are re-scanned. One difficulty with the spec was that the implementation would never know that it was the last packet. Thus you had to maintain all characters relating to a partial match until you either matched a signature or were able to rule out a match, creating much repeated scanning of the same characters. I was not able to solve this problem elegantly in the assignment timeframe (although the professor was). Below is a class-diagram of my solution.

For my solution, I wrote an implementation of the Set (similar to STL Set) to store my detected Incidents and I created a Hash table for the signatures. I chose a set to store the Incidents so that I was guaranteed no duplicates, whereas I chose a Hash Table for the signatures for the O(1) performance. My set was unfortunately implemented as a circular linked list (with O(n) performance); it would have been much faster had I had the time to implement it as a Binary Search Tree. Packets were read into the buffer until there were at least 6 characters in the buffer. Once the buffer had sufficient characters, it was scanned against the hash table. My algorithm kept track of any partial matches—where the first part of a signature matched but the buffer did not contain enough characters to verify that the match was complete. If the algorithm was able to match a complete signature, it created an Incident marking the signature ID and the location in the stream. Once the entire buffer was scanned, the first part of the buffer was discarded up to the point of a partial match or the last 5 characters. Then a new packet is read into the buffer and we repeat! Since packets had a maximum length of 1500, and I discarded after each scan, the buffer was guaranteed to never reach beyond 3000 characters in size.

My solution was not very efficient. If the packet had included some parameter that described it as the last packet, it would have been quite simple to cut redundant scanning; just stop scanning as soon as you have reached a partial match in order to read in a new packet. However, this would create a bug in that incidents in the very last packet would not be caught if a partial match preceded that incident. Therefore, my solution had a bunch of redundant scanning and much more copying than would be warranted otherwise. This made my execution time rocket to about 10 times the Professor’s solution.

For those interested, my matching function is included below. It’s recursive, and probably like every other matching function, but here it is.

683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713

MatchType IPSImpl::match(const char* sig, const char* text)
{
 
  for (size_t k = 0; sig[k] != '\0'; k++)
  {
    if (text[k] == '\0')
    {
      if (sig[k] == '*' && sig[k+1] == '\0')
        return MATCH;
      return PARTIAL_MATCH;
    }
    if (sig[k] == '*') //if the signature has a wildcard
    {
      for (size_t j = k; j-k <= WILDCARD_LENGTH; j++)
      {
        if (text[j] == sig[k + 1])
        {
	  MatchType temp = match(sig + k + 1, text + j); //recur
	  if (temp != NO_MATCH)
	    return temp;
        }
        if (text[j] == '\0') //could be a match in next packet
          return PARTIAL_MATCH;
        }
	return NO_MATCH;
      }
      if (sig[k] != text[k]  &&  sig[k] != '?')
        return NO_MATCH;
    }
  return MATCH;
}