Java 7's Best New Features

Java 6 is approaching its end of life release in February 2013, so here are some new features of Java 7 that will help you hit the ground running with the new JDK. A few of them are sure to be huge timesavers, like using Strings in switch statements.

Binary Literals

int j = 0b10101010101;

Underscores in Numbers

Let you quickly see how large a number really is.

int k = 1_000_000;

String Switch Statements

Use the new string switch statements to apply .equals() on the string:

switch(someString)
{
    case "Saturday": case "Sunday": 
        return "weekend";

    default:
        return "weekday";
}

Automatic Resource Closing

When you open streams in try blocks, they are now automatically closed.

try(InputStream in = socket.getInputStream();
    PrintStream out = new PrintStream(new BufferedOutputStream(socket.getOutputStream())))
{
    byte[] b = new byte[1024];
    int k = 0;
    while((k = in.read(b)) > 0)
        out.write(b,0,k);
}

// in and out will be cleaned up after this.

Multiple Catch

You can now catch more than one exception at a time:

try{

    // do stuff here

}catch(IOException | NullPointerException ex)
{
    // Handle either exception
}

New Diamond Operator

No longer do you have to declare the same type in the constructor and variable when you're providing types:

HashMap<String, Integer> myMap = new HashMap<>();

NIO

This is a huge topic, too long to be covered here; but there is a new library for working with various filesystems that abstracts away their differences, so you can use the same code to work remotely, locally, within zip files, etc.

Compute/Fork Join

Java now provides an interface for embarrassingly parallel fork-join tasks (such as sorting), just implement Compute.

Swing Improvements

• Draw on top of components, then erase the drawing, using JLayer
• Make translucent windows with .setOpacity(<float>) on a JFrame
• New HSV tab on JColorChooser.

Database Password Hashing

Okay, so you want to make sure your database is secure, no matter what your front-end is? Here is a simple script that does exactly that, hashes passwords in the tables as they go in with a salt and provides an easy way to check logins against the user table. If you want, you can even hash user-names too, that way even if your database is completely stolen it isn't insecure:

-- Users is a table, password hash, up to 100 chars, currently used is
-- sha1 because it is nativly supported in PHP.
CREATE TABLE `Users` (
 `usr_id` INT NOT NULL AUTO_INCREMENT PRIMARY KEY, 
 `username` VARCHAR(20) NOT NULL, 
 `usr_password` VARCHAR(100) NOT NULL
) ENGINE = INNODB;

-- Yes, secure things as they are added, using the username as a salt.  
CREATE TRIGGER user_input BEFORE INSERT ON `Users` FOR EACH ROW SET NEW.usr_password = SHA1(CONCAT(NEW.usr_password, NEW.username));

CREATE TRIGGER user_update BEFORE UPDATE ON `Users` FOR EACH ROW SET NEW.usr_password = SHA1(CONCAT(NEW.usr_password, NEW.username));

-- Checks if a user with the given username and password exists in the 
-- db, returns null if no and the ID if true.
delimiter |
CREATE FUNCTION CHECK_USER (usrname VARCHAR(20), password VARCHAR(1000))
 RETURNS INT DETERMINISTIC
 BEGIN
  DECLARE tmp INT;
  SELECT usr_id INTO tmp FROM Users WHERE username = usrname AND usr_password = SHA1(CONCAT(password,usrname));
 RETURN tmp;
 END|
delimiter ;

A small sample of the program in action:

    mysql> select * from Users;  
    Empty set (0.00 sec)  
      
    mysql> INSERT INTO Users (username, usr_password) VALUES ("Cookie", "Monster"), ("Big", "Bird");  
    Query OK, 2 rows affected (0.07 sec)  
    Records: 2  Duplicates: 0  Warnings: 0  
      
    mysql> select * from Users;  
    +--------+----------+------------------------------------------+  
    | usr_id | username | usr_password                             |  
    +--------+----------+------------------------------------------+  
    |      3 | Cookie   | 00c66ad8335364be46f67da3699be142189b2aa9 |  
    |      4 | Big      | 4e49d9c043ee8733f6019cc777d65421721333c7 |  
    +--------+----------+------------------------------------------+  
    2 rows in set (0.00 sec)  
      
    mysql> SELECT CHECK_USER("Big", "Bird");  
    +---------------------------+  
    | CHECK_USER("Big", "Bird") |  
    +---------------------------+  
    |                         4 |  
    +---------------------------+  
    1 row in set (0.01 sec)  
      
    mysql> SELECT CHECK_USER("Oscar", "Grouch");  
    +-------------------------------+  
    | CHECK_USER("Oscar", "Grouch") |  
    +-------------------------------+  
    |                          NULL |  
    +-------------------------------+  
    1 row in set, 1 warning (0.00 sec)  
      
    mysql> SELECT CHECK_USER("Big", "Baby");  
    +---------------------------+  
    | CHECK_USER("Big", "Baby") |  
    +---------------------------+  
    |                      NULL |  
    +---------------------------+  
    1 row in set, 1 warning (0.00 sec)  
      
    mysql>   

Note that while all hashing may be done in the DB, it is still recommended you do it server side/client side too, as passwords may end up in SQL log files if not hashed beforehand. Everything will still work even if a password is hashed multiple times.

Purely Pedantic Password Affirmation

PBKaC (Problem between keyboard and chair). Yes, people are the source of all problems in Computer Science, a computer does exactly what it is told to. But sometimes they can be the solution to problems too.

What if, when you entered a password, three things were sent back to the server?

1. A password hash.
2. A list of the times taken between keypress events for the password, hashed or something.
3. Some identifying information for the computer, plugins, whatever.

The server could check the headers sent back to see if this is a common computer used by the user, and if so check the password and move on with its day.

The server could also check the times between keypresses in the password for relatively spaced times in the way the user normally enters the password, providing a fingerprint for a particular user.

Suppose it normally takes me 30ms to reach from "F" to "T", and fifteen to get from "O" to "."; if the password was entered differently the user should be redirected to a secondary question page; either they broke a hand, or someone else entered their password.

Think of it as non-random password screening. It would stop bots in their tracks, and would create only a small problem for users.

The Uselessness of Passwords

The Public

Most people that put passwords on their computers assume too much about the security of the system they operate on. Rule of thumb: unless you have specified an encrypted hard drive, you don't have one. The password you put on your machine will keep me (or anyone else worth their salt) out of your files for all of ten seconds.

For Mac OSX a simple Command + S while booting up will do the trick (on old macs you can delete the first run file so the mac goes in to setup mode and requests a new username and password, that will then allow access to your files)

For Windows, how about an F9 to safe mode?

For linux, what about changing the boot options in your boot manager to go in to safe mode, or simply choosing the safe mode section?

For all operating systems, if your stuff isn't encrypted we can still pop in a linux live cd and copy anything we want over.

So, how do you keep someone from doing this? Well, it requires hard-disk encryption (which is dangerous, because if you forget the password, you're SOL, and if you write it down, there is no point). A locked boot manager, that boots directly to the hard drive (with a good password, different than the BIOS). A good, strong password, and requiring a user name upon login will help too. The computer must have a lock on it, as if it is stolen, most of your defenses fall, except the hard disk encryption if you have any.

Network/Computer Admins

So, what if you have a whole slew of computers?

"Aha!" the school computer admin exclaims, "I know, I'll disable users from booting in to safe mode, by setting an Administrator password, lock the BIOS so they can't boot Linux, disable running third party executables on the desktops, and, um, disable listing of the C:\ directory by students!"

This is a very real example taken from the school district I was educated at :) Hmm. Students have nearly unlimited physical access to the computers. I would just pop out a clock battery, and hit a pin, resetting the BIOS; maybe I did this, and maybe not. Maybe when I did it, the clock was reset to the year 1400 (before the epoch?) and software freaked out before I fixed it.

Oh, and by the way, if you type: file:/// in to Firefox it shows the listing of the root directory, easy enough to grab a password file from a trusted app, and then run it through your password cracker later (in Windows). Also look out for applications like AutoCad that allow command line access through their interface.

A note to the administrators of schools and businesses across the world:

• Your subjects are motivated to do what they want.
• They outnumber you
• They probably outnumber you enough to brute-force a problem
• You have other obligations

You will not win, assume every connection to your network is hostile, and client machines are always needing a re-image.