Tonight we're going to party like it's 1999!

All the cool kids are doing it...

So let's say you have a website you want to protect? Should you use .htaccess?  That's not a horrible idea.  A .htaccess file is good for basic authentication and is great because you can set permissions/directives at the directory level rather than the server level.  Yeah, you can set directives at the directory level in a server configuration file, but the .htaccess files are great when you don't want to give users access to the server level configurations. 

Enter Barracuda networks

Apparently .htaccess files are apparently how Barracuda networks administers their site.  I can think of lots of reasons for this, but none of them are good.  All of them emphasize usability over security.  Let's face it: usability is always at odds with security.  When you run a security company, I suggest you err on the side of security.  Reputations are hard to replace.  It's hard to sell security when you are making dumb security mistakes yourself.  The .htaccess files specify who can access what website areas while credentials are usually stored in a separate .htpasswd file.

  

Here's where things take a turn towards stupid

The first rule of .htpasswd files: never talk about .htpasswd files.  Okay, not really, the first rule of .htpasswd files is KEEP THEM OUT OF THE WEB ROOT!  For obvious reasons, the web server process must have read permissions to the .htpasswd file.  But if you store one in the web root, they can be stolen by attackers by navigating there in a web browser.

So what can you find in an .htaccess/.htpasswd file?

Among other things, you can find out where the most sensitive files and directories are.  That information would be located in the .htaccess file.  One of the great things about the .htaccess file is being able to see who the important users are.  Hint: they are the ones who can access a directory nobody else can.  Then you can concentrate your efforts on brute force attacking the passwords of legitimate users who can log in.  The .htpasswd file can reveal usernames and password hashes.  Combined with the .htaccess files, it's like a road map for an attack.  It can be like finding a copy of /etc/shadow, only for the web server directories it is protecting.

How easy are the hashes to crack?

Well, usually pretty easy.  Most use relatively weak encryption (salted MD5 or SHA1).  To put it easily, the protection on these is better than most unsalted MD5 hashes used by some poorly written sites.  For instance, go to eHarmony for a mate, not salted password hashes (eHarmony was one such site hacked last year that failed to implement basic security measures such as salting password hashes).

Well at least the hashes are salted, right?

Sure enough.  As long as you are using password hashes in the first place.  For ease of administration, the .htpasswd specification (rather myopically) allows for plaintext passwords.  But surely no serious company would use plaintext passwords, right? Well, that's where Barracuda networks comes in.  Apparently, they not only use .htpasswd files, but they also stored one in the web root directory.  Then, to compound things, they decided to make sure the passwords were stored in plaintext.  Since we all know people reuse passwords, this is a HUGE problem for Barracuda.

Best practices:

Before I go, here are a few thoughts on some best practices

• Avoid .htaccess files if you can get away with using server level configurations
• Don't trust security to .htaccess/htpasswd files alone
• If you use .htpasswd files, don't store the files in the web root
• If you use .htpasswd files, don't use plaintext passwords - it's 2013, not 1999

Reference:

http://thehackernews.com/2013/07/Barracuda-network-Password-disclosure-vulnerability_24.html

Edited 2013-07-25: Thanks to Ebrahim Hegazy (@Zigoo0) for pointing out an error in the posting here where I was ambiguously (and incorrectly) interchanging the .htaccess and .htpasswd file names.  The actual attack on Barracuda involved the disclosure of the .htpasswd file (the passwords/hashes), not the .htaccess file (the configuration).