Rock of Ages

Even though I was only 13 when the 1980s ended, I think that it is definitely the greatest decade for television, movies, and music. It seems like there are plenty of others who share that opinion, since there’s recently been a lot of 80s nostalgia. But people trying to cash in on that nostalgia have to be careful to get it right, because almost doesn’t cut it. And Rock of Ages doesn’t even achieve almost.

Even in the 1980s, Los Angeles was full of people who have come to seek their fortune in the entertainment industry, so when Sherrie (Julianne Hough) stepped off the bus from Oklahoma, she was hardly the first country girl to think she could make it in the big city. Her excitement was dampened a little when she got mugged and the thieves ran off with her record collection, but it recovered somewhat when she landed a job as a waitress at The Bourbon Room, a popular nightclub that always seems to book the biggest names in music. One of the most famous performers, Stacee Jaxx (Tom Cruise) got his start as lead singer for Arsenal on that stage, and that’s where their last concert will be before he embarks on a solo career.

There are other aspiring musicians working at The Bourbon Room, and Sherrie is immediately drawn to Drew (Diego Boneta), who has a great voice but also suffers from stage fright. But when Arsenal’s opening act cancels at the last minute, Sherrie suggests Drew as a replacement, and he impresses club owner Dennis (Alec Baldwin) and his assistant Lonny (Russell Brand) enough for them to give him a shot. His performance also impressed Paul (Paul Giamatti), who manages Stacee Jaxx and is always looking for more talent, especially as Stacee continues to throw his life away with alcohol, women, and an intolerable personality. Of course if the mayor’s ultraconservative wife Patricia (Catherine Zeta Jones) has her way, then all of these filthy clubs will be shut down and the musicians will all be out of work.

Rock of Ages the movie is based on the musical of the same name and boasts a soundtrack featuring over twenty of the most well-known 80s rock anthems. Unfortunately, those songs are performed by the cast rather than the original artists, which means they’re autotuned, lip-synced, mashed up, given alternate lyrics, and otherwise destroyed. Occasionally, we only hear a couple of lines from a song, but in this case that’s more an act of mercy than one of heresy. I expected the music to be the only thing the film would have going for it, and while it’s true there wasn’t anything else of value in the movie, even the music was a letdown.

There are a lot of big names in the film, but they certainly don’t add anything to its quality, and I’m not sure I see the logic in casting a couple of relative unknowns as the lead characters, particularly when neither was alive at the time the events of the film were supposed to have taken place. The performances were universally bad (although sometimes intentionally so), and the decision to pair Tom Cruise with a costumed monkey named “Hey Man” probably would have been embarrassingly awful if the film hadn’t already been awful.

All of this comes together to result in a movie that is two hours of agony. The music is bad, but everything else is worse. Walking out of the theater, I felt like I might need a course of antibiotics to ward off any of the film’s nastiness that might have attached itself to me.

The Intouchables

There are some films which are so surface-level and obvious that merely hearing the premise is enough for you to make a pretty good guess at what the film will be. The Intouchables is exactly one of those films, and although it is completely predictable, it also manages to be rather entertaining.

The film features Philippe as an extremely wealthy frenchman whose sense of adventure got him into an accident that left him paralyzed from the waist down. He’s dependent upon others for just about everything, and when his current caretaker leaves, he must choose a replacement right away. Fortunately, there are lots of well-mannered and highly-qualified young men vying to be close to him and his money. And then there’s Driss. He’s not well-mannered, not qualified, and not at all interested in the job. He’s only there because the welfare office won’t keep paying him unless he can show that he’s going for interviews and at least making an attempt to get hired. He’s rude and pushy and just wants to get a signature and leave, but something about him strikes a chord with Philippe, and Driss ends up with a job offer.

There are a lot of aspects of the job which don’t appeal to Driss. Especially the part about taking care of a rich white guy to the point of having to do things like feed and bathe and dress him. But he’s also not particularly fond of being homeless, which is his current condition after his most recent episode of ticking off his family, and the new job comes with some pretty luxurious accommodations. So he reluctantly takes the job, but there’s absolutely no way he’s going to do the gross stuff.

Actually, a lot of the comedy in The Intouchables is derived from Driss emphatically stating that he will absolutely not do something followed by a hard cut to him doing exactly that. It’s just about the most obvious and lazy form of humor out there, but for some reason the audience seemed to eat it up. There are other sources of comedy in the film, and some of them are reasonably funny on their own merits, but it’s definitely not a laugh riot that will have you rolling in the aisles. But it is nevertheless mostly enjoyable and works fairly well as a buddy comedy. Plus, it’s a lot less self-congratulatory and racially-motivated than The Blind Side.

The film is apparently based on a true story, which I find surprising not because the story was turned into a movie, but because someone someone found the story worth telling on a large scale. It really isn’t particularly significant beyond the characters of Philippe and Driss, and the significance to them isn’t much more than friendship. It is entertaining but shallow, and as a result has no real lasting effect.

Prometheus

It looks like the next 80 years will bring some furious innovation. We’re going to get faster-than-light travel, ultra-realistic androids, hibernation chambers, flying laser balls, and misogynistic surgical robots. All of these and more are aboard the spaceship Prometheus when it sets off in 2091 for its two-and-a-half year journey to a distant planet.

But it all starts with ancient cave paintings. You’re probably familiar with the crude artwork created by members of earlier cultures, but you probably didn’t know that a lot of them feature alien imagery, often including the same planetary formation. By studying this formation in combination with celestial maps, anthropologists Elizabeth Shaw and Charlie Holloway (Noomi Rapace and Logan Marshall-Green) were able to identify that formation in the universe, and they were able to convince the mega-rich and mega-old Peter Weyland (Guy Pearce) to send them there, along with crew led by Captain Janek (Idris Elba) and overseen by Weyland representatives Meredith (Charlize Theron) and David (Michael Fassbender).

The Prometheus makes the trip without incident, and upon arrival they see evidence of intelligent life, but no creatures come to greet them (or attack them). They set the ship down near a large dome-shaped structure and send a team inside to investigate. There, they don’t find any living creatures, but they do find lots of dead ones, and some mysterious vase-shaped containers arranged in one of the rooms. But their exploration is cut short when they must quickly return to the ship in order to avoid a nasty storm moving in. And that’s when the real action starts.

The problem, though, is that the action is simply not good. The film is visually impressive but mentally lacking, with a number of elements that don’t make sense upon first watching the movie, and more flaws that continue to reveal themselves the more you reflect on the film. It’s hard to point out some of the more egregious logic problems without the risk of spoiling parts of the movie, but others (like some crew members seeming to meet each other for the first time after coming out of hypersleep) are evident within the opening moments.

Despite director Ridley Scott’s insistence to the contrary, Prometheus is absolutely a prequel to Alien. The films exist in the same universe, and Prometheus attempts not only to provide a glimpse into the origin of the creatures that we see in Alien, but into the beginning of human life as well. Along the way, it tries to get in a few potshots at a belief in God as a creator, although in a very “pot versus kettle” kind of way that only succeeds in highlighting its own logic problems while doing very little in the way of an effective attack against religion.

The big disappointment behind Prometheus is that it is simply unnecessary. It doesn’t add anything at all to the story that had been crafted in the previous Alien movies, nor is it able to stand on its own as an independent narrative. There are many problems with the film and it doesn’t provide anything of value that might cause us to overlook them.

How LinkedIn Missed Out

Within the last week, LinkedIn, eHarmony, and Last.fm have all announced security breaches that resulted in millions of user passwords exposed to the world. While the passwords were encoded with one-way digests, that didn’t stop attackers from discovering the clear-text passwords for a large percentage of those accounts.

There’s no such thing as a perfectly secure system, and brilliant and determined hackers have a lot of tricks up their sleeve, from technical assaults like exploiting unpatched software vulnerabilities and to social engineering cons like sweet-talking secretaries. But there are a lot of things that LinkedIn and the others should have done to help prevent this kind of breach.

Consider Using Third-Party Authentication

The best way to ensure that attackers can’t break into your system and steal user passwords is for your system to not have any user passwords. Authentication systems like OpenID and OAuth allow you to push the responsibility for authenticating users (and securing their accounts) to a third party. If you’re willing to leave the authentication to an organization like Google, Facebook, or Yahoo, and your users are willing to accept this solution, then you don’t need to worry about storing credentials at all.

Note, however, that passwords may not be the only sensitive information that you need to store in your system. In fact, attackers generally don’t care about user passwords themselves but rather the other information about users that passwords can be used to access. As a result, you should treat all the information that you store about users with the utmost care and sensitivity because any compromise of your system will be bad for both your users and your reputation, regardless of whether that compromise includes login credentials.

It is therefore important that you store your data in a repository that offers the kinds of security features you need to help ensure it is adequately protected. The UnboundID Directory Server offers a wide range of security features, including several that you won’t be able to find in other products. Some of these features are primarily intended to help secure user passwords, but many can be applied for all kinds of information.

Use Salted Password Hashes

The people who designed the security systems at these companies knew enough to use cryptographic digests (also called hashing algorithms) to protect the passwords. These are mathematical algorithms that transform passwords in a way that is believed to be impossible to reverse. Good cryptographic digests (like the SHA-1 algorithm used by LinkedIn) offer a good level of protection because they prevent attackers from knowing useful information like how long a password is or what kinds of characters it might contain, and if they’re guessing passwords then they won’t be able to tell how close any guess is to being right.

But one of LinkedIn’s big mistakes is that they didn’t salt their passwords. One-way digest algorithms always generate exactly the same hash for a given input. This is essential for their use in applications like protecting passwords and verifying data integrity, but it also means that attackers can (and do) prepare ahead of time. I may not be able to look at the string “6367c48dd193d56ea7b0baad25b19455e529f5ee” and know that it’s the SHA-1 digest for the string “abc123”, but if I have a big dictionary of commonly-used passwords, I can just run each of the strings in that dictionary through the SHA-1 digest in order to get the encoded representation, and when I find an encoded password that looks like “6367c48dd193d56ea7b0baad25b19455e529f5ee”, I can use my precomputed dictionary to do a reverse lookup and know that represents the password “abc123”.

Password salting prevents this kind of attack because it adds a random element into each encoded password. When you’re going to create a salted password, you first come up with some random data (for example, “kMPsCwaT”) and prepend it to the clear-text password (like “kMPsCwaTabc123”). Then, you run that through the digest algorithm (to get a hash like “51c4125fe2e2e94bdefa8f7a8e5c12ebfd94833b”), and finally prepend the salt to the hash (e.g., “kMPsCwaT51c4125fe2e2e94bdefa8f7a8e5c12ebfd94833b”). When a user is authenticating, it then becomes necessary to pull the salt off the encoded password and prepend that to the clear-text password that they provide before running it through the digest algorithm.

Because salted passwords contain random data, it’s not possible for an attacker to have a dictionary prepared in advance. Running through a dictionary (or using a brute-force approach to try every possible combination of characters) will take a lot longer to crack a password, and even if you are successful for one user, that won’t help for any other user even if they chose the same password because it will have a different salt and therefore a different encoded representation.

The UnboundID Directory Server supports password salting out of the box in a manner that is completely transparent to clients. It can be used in conjunction with MD5, SHA-1, and any of the 256-bit, 384-bit, and 512-bit SHA-2 variants. It’s on by default, and would have made it a lot harder (or at least taken a lot longer) for attackers to discover the clear-text representations of the stolen passwords.

Use Expensive Encoding Algorithms

If someone gets access to an encoded password and knows how it was encoded, then there really is no way to prevent them from discovering the clear-text password used to generate that hash. If they want it bad enough, they can simply try every possible combination of characters, and with relatively cheap access to distributed computing, it’s possible to generate trillions of hashes per second. The only variables that affect this are the strength of the password (as will be discussed below), and the algorithm used to generate its encoded representation. For example, using the 512-bit SHA-2 instead of the 160-bit SHA-1 just about doubles the length of time required to generate a digest, which in turn means that it just about doubles the length of time an attacker will have to spend trying to crack a password.

To make the process even more expensive, you can have your password encoding process use multiple rounds of hashing. For example, take the clear-text password, salt it, and run that through the digest algorithm. Then take the resulting hash and run it through the digest algorithm again. And again. Repeat this process so that the final encoded password requires 5000 hashes. If you’re using 512-bit SHA-2, then this process is now about ten thousand times more expensive than the simple SHA-1 process used for the leaked passwords, meaning that it will take an attacker ten thousand times longer to crack a password with this encoding scheme than with SHA-1.

The UnboundID Directory Server provides support for password encoding algorithms that employ thousands (or potentially even millions, if you’re really paranoid) of rounds of hashing using the 256-bit or 512-bit SHA-2 algorithms. This algorithm is already available for use in holding login passwords for many Linux and UNIX systems, so it’s been designed by and carefully scrutinized by many security experts and is considered extremely strong.

Reject Weak Passwords

If an attacker obtains an encoded password, then the biggest risk of that password being cracked comes from the strength of the password itself. A password that is a word from the dictionary or a name or date or other common string will almost certainly be broken in a fraction of a second. If a password is relatively short, then so also will be the time required to discover it even if it’s necessary to try every possible combination of characters. For example, if a beefy system can generate 100 billion hashes per second, then it will only take about two seconds to try every possible combination of eight lowercase ASCII letters.

The two biggest factors in password complexity are the length of the password and the set of possible characters it may contain (which we’ll call the password alphabet), and they’re related by the mathematical formula al, where a represents the size of the password alphabet and l is the length of the password. For example, if the alphabet is the set of lowercase ASCII letters and the length is eight characters, then there are 268 = 208,827,064,576 possible password combinations (which seems like a big number, until you realize how fast computers are at performing these computations). However, if you instead consider both uppercase and lowercase letters, numeric digits, and a number of symbols, then the alphabet can grow to about 95 characters, and there would then be 958 = 6,634,204,312,890,625 possible values, which is nearly 32,000 times larger and would take the better part of a day to crack on a system capable of trying a hundred billion passwords per second. And increasing the length to ten characters takes the time to crack from a little over eighteen hours to a little over eighteen years.

The best way to ensure that users have strong passwords is to configure your system to enforce restrictions around password length, the kinds of characters that may be used, and other kinds of constraints. The UnboundID Directory Server ships with support for a number of password validators, including:

  • A dictionary validator, which can be used to ensure that users aren’t allowed to supply passwords that exist in a given dictionary file (optionally including testing the reversed password).
  • A length validator, which can be used to ensure that users aren’t allowed to choose a password that is too short (or potentially too long, although there’s little reason to configure a maximum length).
  • A character set validator, which can be used to ensure that passwords include at least a specified minimum number of characters from a number of different character sets.
  • A unique characters validator, which can be used to ensure that passwords contain at least a specified number of different characters.
  • A repeated characters validator, which can be used to ensure that passwords don’t contain repeated strings.
  • An attribute value validator, which can be used to ensure that the supplied password does not match the value of any other attribute in the user’s entry.
  • A regular expression validator, which can be used to ensure that the supplied password matches (or alternately, does not match) a given regular expression.
  • A similarity validator, which can be used to ensure that when a user is changing his or her password, the new password is not too similar to the previous password.

In addition, the UnboundID Server SDK can be used to develop additional custom password validators if those provided with the server by default are not sufficient. It also provides a password history feature that can prevent users from repeatedly using the same set of passwords.

When allowing users to choose their passwords, it is also important to ensure that those passwords are always supplied in clear-text. Some systems allow users to provide the password in a form that is already encoded in a manner that the server can interpret. This is undesirable, because if a user is allowed to supply a pre-encoded password, then the server has no idea what the clear-text representation is, and therefore cannot determine whether it satisfies all of the configured password quality requirements.

Of course, strong passwords aren’t much good if users can’t remember them. This is a very real problem that needs to be considered, and it is compounded by the fact that your users will likely need to have accounts in other systems. In reality, this means that users will probably choose one of the following options:

  • They will use a password manager that automatically keeps track of all the usernames and passwords they use across all systems they access. This is the best solution, and one that you should probably recommend, since it means that they only have to remember one password for the password manager, and let it remember all the others. Unfortunately, less experienced users may find this prospect kind of scary.
  • Write their passwords down or keep them in a file. This is kind of the low-tech version of a password manager, and as long as all copies of the password list is protected, then it’s reasonably safe.
  • Use the same password (or a small set of passwords) for all sites they access. This is dangerous, because if their password is compromised on one site, then it may be used to gain access to other sites. There’s not much that can be done to prevent this (other than requiring multifactor authentication), but unless it’s an account that has elevated privileges, it will be more likely to adversely affect that one user than the overall security of your data store.
  • Forget the password they chose and rely on the “I forgot my password” mechanism to reset it each time they need to access your system. If the reset process is automated and requires them to receive an e-mail or SMS message, then it may be a relatively secure approach (assuming that the e-mail address and/or phone number were previously verified), but if it involves talking to a human then it will probably raise your support costs and may allow a skilled social engineer to convince the support personnel to grant them access to someone else’s account.

It is unfortunate that non-technical users will be the ones who find strong password requirements to be the most onerous and unpleasant, but it is important to decide whether end user convenience is more important than end user security.

Prevent Online Access to Passwords

While it isn’t clear exactly how the attackers were able to obtain these large lists of encoded passwords, it’s likely that they were able to manipulating the identity store (or an application using it) into performing a query that exposed this information to the requester. For example, if they were using a relational database, then maybe they discovered a flaw in an application that allowed for an SQL injection.

Identity data stores (whether relational databases, LDAP directory servers, or some other kind of repository) should be like roach motels for passwords: passwords can go in, but they can’t come out. It shouldn’t be possible for even an all-powerful user to perform a query that can retrieve password information, and the system should also require that all passwords supplied to it (whether validating credentials during authentication or supplying a new password) be processed over a secure communication channel so that anyone with the ability to observe the network traffic cannot examine it in order to learn passwords.

The UnboundID Directory Server includes a sensitive attributes feature that makes it possible do exactly this for passwords and other kinds of sensitive information. You can easily configure the server so that passwords will be stripped from results even for requests from root users, and to require that any operations attempting to manipulate the values of such attributes will be allowed only over a secure connection. It is possible to configure this restriction to be in effect across the server, but it is also possible to tailor the behavior to the requester (based on a number of characteristics, like who’s asking, how they’re authenticated, where they’re coming from, whether the connection is secure, etc.), so that if there is an application that does have a legitimate need to be able to retrieve this information, the server can be configured to only return the data to that application.

The UnboundID Directory Server also includes very powerful and flexible logging capabilities, and it is possible to configure the server to log information about any operation in which passwords (or other attributes which may contain sensitive data) is returned to the client. This can be useful for auditing purposes so that if an attacker is somehow able to issue a query that returns sensitive information, you can see exactly which entries and which attributes were accessed.

Encrypt Server Data, Including Backups and Data Exports

Even if they weren’t able to get the data store to expose the passwords via a network request, it’s possible that they were able to get the password data in some other way. For example, if they were able to obtain access to the system on which the data was stored, then perhaps they were able to examine the database files directly, or perhaps they were able to obtain a backup or export of the data that included passwords.

It is important to ensure that adequate protection is in place for all copies of the server data, whether on the live running system or in backups. Certainly this includes things like restricting access to systems which can access this information and ensuring that only authorized users are able to access the data files, but it is also recommended that you encrypt such information so that even if an attacker does gain access to it, they won’t be able to extract anything useful from it.

The UnboundID Directory Server makes it easy to enable encryption for all data so that it is never stored in the clear. It also provides the ability to encrypt backups and LDIF exports so that the information is protected in these forms as well.

Prevent Repeated Authentication Attempts

If you have adequately protected your system to prevent retrieving passwords from the data store, and if all copies of the data are encrypted, then attackers should be prevented from obtaining encoded passwords for users. However, there may be other ways to crack user passwords. The most common of these approaches is simply to try to repeatedly authenticate as that user with different passwords until you finally get it right. This will be much slower than the offline attacks that are available with access to encoded passwords, but given enough time, determination, and luck, it may just work. Of course, these kinds of attacks can be thwarted by limiting the number of unsuccessful authentication attempts that will be allowed for a user account before that account is locked.

The UnboundID Directory Server can be configured to lock accounts after too many authentication failures so that any subsequent attempts will fail even if the right credentials are given. This lockout can be either temporary (so that additional login attempts will be allowed after a specified period of time) or permanent (so that the user will not be allowed to authenticate at all until an administrator resets the password). It can also be configured to log and/or notify administrators when an account is locked as a result of failures, along with a number of other significant password policy events.

Enforce Authentication Restrictions

In many environments, it is common for each application to have its own account that will be used to perform operations in the server, and that application account may have more rights than normal user accounts. If an attacker is able to compromise an application account, then he or she may be able to wreak more havoc than with other user accounts.

To help prevent this, it is advisable to restrict application accounts so that they are less likely to be useful to attackers even if their credentials are discovered. For example, you may want to restrict their use to a certain range of IP addresses and/or to only allow them to authenticate in certain ways. The UnboundID Directory Server provides a number of features like this, including restrictions based on client address, authentication type, and communication security, as well as restrictions around the use of proxied authorization. In addition, client connection policies can also be used to permit or restrict operations based on a number of characteristics about the client.

Support Multifactor Authentication

One great way to mitigate the risk of compromised passwords is to make use of multifactor authentication, which require the user to provide multiple pieces of information to confirm his or her identity. This is usually manifest as two-factor authentication combining something you know (like a password) with something you have (e.g., some kind of device capable of generating one-time passwords or PINs). In a system that uses multifactor authentication, if an attacker discovers a user’s password, then they won’t be able to do anything with it unless they also have a way of obtaining the other credentials.

Multifactor authentication used to be a rather inconvenient prospect because it required that you actually provide your users with a physical device like a SecurID token (which has a numeric display with numbers that change every minute), and if you didn’t have that token with you, then you couldn’t authenticate. However, the proliferation of mobile phones has made this a much more realistic possibility. For example, you can configure your Google account to require multifactor authentication, combining a password with a one-time code obtained in one of the following ways:

Using the Google Authenticator app, which uses the time-based one-time password (TOTP) algorithm defined in RFC 6238. This option does not require any kind of network communication.
By having a one-time password sent to your mobile phone as a text message.
By having a one-time password read to you by a speech synthesizer over a voice call.

With multifactor authentication support enabled, an attacker will need to get access to your mobile phone in addition to figuring out your password before they’ll be able to access your Google account.

Similarly, Facebook can be configured to require a one-time code sent as an SMS message any time you log in from a system it doesn’t recognize. There are a number of other applications which provide some level of support for multifactor authentication, but it’s unfortunate that there are still so many who do not offer it as an option so that their more technical and security-conscious users can take advantage of the additional security that it can provide.

At present, the UnboundID Directory Server supports multifactor authentication in the form of a password combined with a PIN generated using the TOTP algorithm (and is therefore compatible with the Google Authenticator app, along with other software capable of generating these codes). However, support for additional multifactor authentication schemes may be added in the future.

Plan for Disaster

No matter how tightly locked down your system may be, you should have a plan for dealing with a security breach in which an attacker is able to successfully obtain passwords and/or other sensitive information from your system. Hopefully you’ll never have to put this plan into action, but it’s far better to have a strategy you may not use than to find yourself without one when you really need it.

The first thing that you should do is to identify what information may have been compromised, and then tell your users about it. Trying to cover it up may be illegal, and it prevents affected users from trying to mitigate the risk of the attack while giving the bad guys more time to use the data they stole. It will also likely be more damaging to your reputation if users hear about a breach in your systems from someone else before they hear it from you.

If information about passwords may have been exposed, regardless of whether the passwords were encoded, then you should encourage or require users to change their passwords as soon as possible (and the UnboundID Directory Server offers a feature that can be used to require users to change their passwords by a given date/time). However, you should also assume that if login credentials were obtained, an attacker could have authenticated using those credentials and obtained access to other information about the account.

You should also try to determine how the attack was conducted so that you can make any changes in your system to help prevent the attack from recurring. If there isn’t enough information available to determine the attack vector, then you may need to make broad changes to tighten the overall security of the environment. You will likely also want to ensure that appropriate logging is in place to make it easier to discover and analyze attacks in the future.

Finally, you should work with the vendors of any software that attackers were able to breach so that they can better understand how their software is being targeted and identify whether any changes may be needed to help prevent future problems. Even if the software you’re using has features which could have prevented the attack from succeeding, the vendor may wish to consider enabling those features by default or better highlighting them in their documentation. Certainly we at UnboundID would be very interested to hear of attacks (whether successful or not) against our software so that we can continue to reevaluate the product features and default configuration. And if you have suggestions for improvement, we’d love to hear them as well.

Piranha 3DD

Despite its name, Piranha 3DD did not include any three-breasted women. I’m pretty sure about that because most of the women in the film were topless and had their breasts exposed for all to see, and the others (naturally including all actresses you’re likely to recognize from classier movies) wore skimpy bikinis. But getting only two-thirds of the breasts we were promised is far from the biggest problem with the movie.

Chet (David Koechner) and his step-daughter Matty (Danielle Panabaker) are co-owners of a water park that is about to open for the summer. While Matty was away at college learning to be a marine biologist, Chet was busy getting the park ready for their grand opening with touches like the world’s first aquatic strip club. He didn’t really have a license to do that, but since he was already paying off the local police to overlook some building code violations, that wasn’t really a problem for him. Matty wasn’t thrilled about Chet’s contributions, but there’s no time to do anything about it.

The water park is situated right on the edge of Cross Lake, which appears to be separated from Lake Victoria (where the events of Piranha 3D went down), except that they’re connected underground. The piranha have discovered this connection, much to the dismay of those who wander into the lake. A farmer was the first to encounter the piranha, but he didn’t live long enough to warn anyone else. Neither did the kids whose sexual activities caused their van to roll into the water. But surely there’s no way that piranha can get into the water park’s swimming pools, right?

As you would expect, Piranha 3DD is simply ridiculous. The plot is stupid, which you probably knew going in, but it also fails at the elements that are supposed to make it enjoyable. There’s a lot of nudity, but most of the women on display are so skanky that the piranha that bite them are probably worse off than their victims, and not even the attempts at gross-out comedy are properly executed. The only semblance of horror comes in the form of jump scares and poorly-rendered gore, and the funniest moments come when the movie is making fun of itself or its predecessor.

I only had the option to see the film in 3D, and there I was also disappointed. While it seems to have been shot that way rather than post-converted, the 3D adds absolutely nothing to it. It’s really only noticeable when something goes wrong like when you see ghosting of the characters at certain depths, or when a lens flare provides an artificial flat plane in front of you. There aren’t any moments when you feel the need to dodge anything coming at you, nor are there breasts so large and three-dimensional that they appear to be poking out of the screen.

There are some things to enjoy from the movie. If you liked Piranha 3D (and why would you see the sequel if you didn’t like at least something about the first one?), then you’ll probably appreciate the returning characters, and even if you’re going in completely blind, there are a couple of fun new cameos. There are a couple of moments of decent comedy, and if you’re the kind of person who likes bad movies then there are things about this one that may work for you. But ultimately, unless you’re one of those weirdos that actually likes 3D, there’s no reason to see this one in the theater when it’s also already available through video on demand (and probably for quite a bit less than the price of a theater ticket, especially if you’re going to see it with multiple people).

God Bless America

Americans love to watch television, but there’s rarely anything worth watching. The 24-hour news channels like to say how much they love America but seem to hate most Americans. Reality TV is frequently a showcase of the worst our culture has to offer, from spoiled rich kids claiming their lives are over because their parents bought them a luxury car in the wrong color, to people falling over themselves to do repulsive acts for money, to “performers” who are either too stupid to know or too shameless to care that they have to talent. Like people who watch auto racing just for the crashes, people clamoring for the worst of our society are contributing to its destruction. And if that’s not bad enough, not only do people lap up whatever television serves up to them, but they also feel the need to talk incessantly about what they’ve seen whenever there’s no screen around.

Frank (Joel Murray) is living in this hell. He’s been having headaches that have been keeping him up at night, and watching TV to help pass the time only seems to make things worse. He rarely gets to see his daughter since his divorce, but he has enough contact with her to know that she’s turning into just the kind of spoiled brat that he has come to hate on television. He hates his neighbors and his coworkers are idiots, but this latter problem is solved for him when he finds himself out of a job. And the hits just keep coming when his doctor informs him that his headaches are being caused by a brain tumor, for which the surgery to remove it is just as likely to kill him as the tumor itself.

And with that, he can’t take it anymore. He can’t stand the world he lives in, but also can’t bring himself to commit suicide. So the only logical choice that remains is for him to kill everyone that’s making the world a miserable place. He “borrows” a neighbor’s car and drives across the country to kill a whiny bitch in the wrong car her parents bought for her. And it feels good.

God Bless America certainly isn’t the first film to decry the fall of civilization and plead for change, and it has more than a little in common with other films like Network, Falling Down, and Idiocracy (although it doesn’t quite match the first two in quality or the third in comedy). However, it also feels the most authentic of them because it’s exactly a product of our times. When I saw this film at the Alamo Drafthouse, the real TV clips included in the pre-show entertainment are virtually indistinguishable from those featured in the movie itself, which helped give it a greater impact. This probably also means that God Bless America will quickly become outdated as the world progresses to ever lower forms of debauchery and stupidity, just like the kinds of things that caused women to faint at the beginning of the twentieth century are humorously tame by today’s standards.

While the film mostly takes the high road, there are a few gags that seem beneath it. For example, a late-night advertisement for a farting pig app seems more like the lowbrow fare of Idiocracy than a lot of the other TV clips that we’re shown, and the next-door neighbors exhibit a level of stupidity that’s not entirely realistic. These elements just don’t seem as funny as the more realistic scenes, and they drag the film down a little. But these are minor nits about an otherwise hilarious yet too-close-to-home movie that is another feather in Bobcat Goldthwait’s directorial cap.

Chernobyl Diaries

In one of my favorite episodes of Pinky and the Brain, the plan to take over the world involves staging an accident involving a microwave and non-dairy creamer, because nobody really knows how they work. It’s funny because the audience is in on the gag and isn’t supposed to take it seriously. In Chernobyl Diaries, radioactivity is treated in kind of the same way, but this time it doesn’t have the same effect, in part because they’re trying to be serious but are treating us in the audience like we’re idiots.

Chris (played by Jesse McCartney) hasn’t seen his brother Paul (Jonathan Sadowski) in a couple of years, ever since Paul moved to Russia. But they’re going to remedy that with a Eurasian vacation on a trek from London to Moscow. Chris brought along his long-time girlfriend Natalie (Olivia Dudley), who in turn brought her recently-single friend Amanda (Devin Kelley). Things are going well and they’re having a great time, but when they reach Kiev, Paul learns of a once-in-a-lifetime opportunity to make their trip even more special. He met a man named Uri (Dimitri Diatchenko) who’s offering them the chance to explore the site of the Chernobyl reactor, infamous its 1986 meltdown. The area is still contaminated and isn’t exactly open to the public, but Uri can get them in, and if they only stay for a couple of hours they won’t have enough exposure to cause any damage.

Although Chris is understandably hesitant to go, the allure is too great for Paul, Amanda, and Natalie, and Uri provides stereotypically Russian overly-masculine assurances that everything will be fine, so Chris is outvoted. They meet up with Michael and Zoe (Nathan Phillips and Ingrid Berdal), a couple of other tourists lured in by Uri, and head off for Pripyat, the name of the city that housed the reactor. When the disaster struck, residents had only minutes to gather their belongings and evacuate, so Pripyat is like a ghost town. There aren’t really even any animals around during the day, so they have the whole place to themselves. But there are creatures that come out at night, and when Uri can’t get the van started when it’s time to leave, they’re going to have much more contact with those creatures than they’d like.

On the surface, Chernobyl Diaries is a lot like the horror classic The Hills Have Eyes set in Ukraine. But the differences make all the difference. In The Hills Have Eyes, we get to know and understand the creatures, we learn how they came to be, and we can even empathize with them. But in Chernobyl Diaries, we don’t really even get a good look at the creatures, much less form any kind of bond with them. We don’t know anything about them, and the film unnecessarily muddies the water about how they came to exist in the first place.

The film also fails on an artistic level. In addition to an excess of darkness, we also get a lot of annoying 360-degree shots in which a camera makes a tight circle around a character from low to the ground so we see a lot of empty sky. There are also some strange audio choices, with once scene drowning out the characters’ dialogue with music, and another featuring the faint and completely out of place sound of a heartbeat. Since we don’t really ever get to see the creatures, sound is often the only way we know they’re around, but nothing we hear is really all that ominous.

But the biggest problem with the movie is that it is not believable. The characters make too many obviously-bad choices, and the climax (if you can call it that, since there’s no anxiety or sense of urgency) relies on a mistake that I simply can’t imagine anyone making, even in the dark in an unfamiliar place and when being chased by unknown beings. The film has no respect for the intelligence of its audience, but perhaps the most intelligent ones are the people who don’t see it at all.

Indie Game: The Movie

Once upon a time, most video games were created by individuals. Even the first console games were more likely to be written by one or two people than big groups. It’s true that not just anyone could get their game onto a cartridge that would show up on store shelves, but it was much more possible for people developing for home computers. And now that the major game consoles are connected to the Internet and can play downloaded content, anyone with the right skills and enough determination can get their games into the hands of the masses.

Jonathan Blow knows a little something about that, because he created Braid, which was the first of the truly successful “indie” games. At the time of its release, it was the top-rated game on the Xbox Live Arcade (XBLA), and one of the most highly-rated Xbox games period. Even if its revenue didn’t match that of even a flop from a major game studio, it also didn’t have to be split up amongst many developers, executives, and investors, and was therefore quite a profitable endeavor for him. Since then, others have tried to recreate that success, and although most are unabashed commercial failures, others have achieved great things in their own right.

Edmund McMillen and Tommy Refenes hoped to be one of the success stories with their Super Meat Boy, a platform game featuring a main character with no skin who must avoid all kinds of peril while trying to save his bandage-covered girlfriend from an evil fetus in a jar. Phil Fish had similar aspirations for his game Fez, in which a 2D character must learn to navigate through a 3D world. And Jonathan Blow hopes lightning will strike twice with his next game, The Witness.

The documentary primarily follows Edmund and Tommy as they work to finish Super Meat Boy in time for a promotional launch that could give them prominent placement in the XBLA where they’ve got the best chance of attracting buyers, and also Phil as he works to get Fez ready for the Penny Arcade Expo (PAX) gaming showcase and tries to make peace with a former business partner who could create legal trouble for him if he tries to release the game. For both games, the developers are anxious to see what may come of the sleep, sanity, and social lives they’ve invested over the last few years of their lives. There’s potentially a lot of money on the line if things go well, while failure could strike a blow to their reputations and psyches from which recovery may be impossible. And it probably doesn’t help much that it’s all being filmed so that their ultimate success or failure (not to mention the ups and downs along the way) will be put on display for potentially millions of people to see.

What you’re not going to see in the film is a lot of encouragement for someone looking to break into the business. Making it easier for indie game developers to make their content accessible doesn’t make it easier for them to create good games, and Indie Game does a pretty good job of showing just how much work really goes into creating even a relatively simple game. We’re long past the days of Pac Man and Donkey Kong, so unless you’ve got a truly innovative concept that’s easy to learn and doesn’t require a lot of flashy graphics and expansive levels (think Tetris), you’re not going throw together something great after only a few days of working on it in your spare time. And I think that’s a good thing, because it thins the herd while highlighting the talent. If only the indie music scene had the same kind of hurdles, the world might be a better-sounding place.

Men in Black 3

It’s been a decade since the disappointing Men in Black 2 was released, and I can’t imagine anyone was clamoring for a third installment except the people with the potential to make money from it. Hopefully not even those people will have any aspirations of making a fourth.

Boris (a role played by and making me lose respect for Jermaine Clement) is a particularly nasty alien who looks mostly human except that he has hand vaginas capable of shooting out darts. Fortunately, he’s securely locked up in a moon prison where there’s no way he can possibly escape, unless they’re stupid enough to allow his girlfriend to visit and bring him a cake with something hidden in it. Unfortunately, they’re stupid enough to allow his girlfriend to visit and bring him a cake with something hidden in it. Boris escapes and vows to kill the man who locked him up in the first place, who just happens to be MiB Agent K. But he’s not going after K in the present (as played by Tommy Lee Jones). He’s planning to go back in time to 1969, so he can kill the much younger Agent K (as played by Josh Brolin) before he had a chance to make the arrest.

Boris’ plan works, because one day Agent K is there constantly being annoyed by his partner Agent J (Will Smith), and the next it’s like he was just erased from existence and no one can remember him except for J. Only old-timer Agent O (Emma Thompson) seems to have any memory of him, but that’s only because she was around when he was killed in 1969 (when O was played by Alice Eve). But J manages to convince O that something is amiss, and she recommends that he talk to Jeff (Michael Chernus), a time travel specialist,who just happens to be the one who helped send Boris back to kill K. And J convinces Jeff to also send him back so that he can kill Boris before Boris kills K.

There are a lot of things to hate about Men in Black 3. Nearly all the scenes set in the present day verge on intolerable. The prison break is absurd, and the interactions between J and K and aliens are always annoying (way beyond anything we saw from Tony Shalhoub in either of the first two movies) and occasionally racist. J and the aliens are often pretty unlikeable in the past too, but usually not to the same degree. And a scene with Andy Warhol (played by Bill Hader) is supposed to be funny but fails miserably.

But there are three things that save the film from being a complete disaster. The first is Josh Brolin, who really does cease to be Josh Brolin and instead becomes a young Tommy Lee Jones. The voice and mannerisms are spot on, and it also doesn’t hurt that he’s playing a more upbeat and less jaded version of the character. The second is the inclusion of Griffin (played by Michael Stuhlbarg), an alien who is able to experience five-dimensional spacetime and can see all possible versions of the future. He was used just infrequently enough to avoid overexposure and evoked pleasant thoughts of the improbability drive from The Hitchhiker’s Guide to the Galaxy. And the third positive is the film’s ending, which manages to take a break from mediocrity long enough to form a truly touching moment that changes your perspective on other elements of the film.

Unfortunately, the positive elements of the film aren’t enough to excuse the negatives. There are certainly things to like about it, but there are also enough things to hate to keep from being a good movie.

The Turin Horse

Prior to The Turin Horse, I’d never before seen a film by Hungarian director Béla Tarr, but I was familiar with his reputation for dark, slow-paced films, was aware of his highly-praised film Satantango (primarily because of its 7.5 hour runtime), and knew that he’d said The Turin Horse (a mere 2.5 hours long) is to be his last feature.

The film opens with Hungarian dialogue over a black screen (save for the English subtitles) which explains that German philosopher Friedrich Nietzsche went mad after seeing a man beating a horse, but nothing is known of the man who owned that horse. It then proceeds to depict one possible account of his life, starting shortly after his encounter with Nietzsche. The man arrives home, puts away the horse and cart, and goes inside to his daughter. Dinner that night, and every other meal depicted in the film, consists of a single boiled potato, eaten with bare hands while it’s still so scalding hot that they have to blow on their fingers while pulling off the peel. The man’s job is hindered by the fact that he’s had a stroke and is unable to use his right arm, and despite his impatience at tearing into his potato, he never seems to eat more than half of it. Entertainment is primarily limited to staring out the house’s lone window watching the constantly-raging wind blow leaves and dirt about the yard, and conversation is at a premium.

When every day is usually the same as the one before it, differences are generally welcome. But the second day of the film shows that’s not always the case. On this day, and the several that follow, the horse refuses to pull the cart. It also refuses to eat or drink. And so the man can’t do whatever it is he usually does during the day, so it’s just more staring out the window and drinking palinka while the wind howls outside.

The Turin Horse is one of the most deliberate and pensive films I’ve seen in quite a while. There are only about 30 shots in the entire movie, so there’s no fast cutting or back-and-forth exchanges like in most films. It doesn’t try to fool the audience into thinking it’s one long, seamless shot — the cuts are obvious, and often the camera lingers when the action has ceased as if forcing you to reflect on what you’ve just seen. And what you’ve seen will have been a bleak, low-budget, minimalist representation of daily life for these people that’s hard to call beautiful but is nonetheless raw and effective. The soundtrack has a similar single-minded focus to it. Most of the time, you hear the wind, but occasionally that’s replaced with a simple and repetitive cello score, and on the rarest of occasions we may hear someone speak. But none of these seems to happen at the same time, so when there is something to be said, the other sounds are diminished.

The lack of color, the scant visuals and sounds, and minimalist plot all work together to ensure that you suffer along with the man and his daughter. Further, there are elements of the story which seem to have been left intentionally vague as yet another way of torturing the audience. It may blur the line between art and boredom more than any film I’ve seen in recent years, but it also somehow manages to have a powerful lasting effect on the viewer.