Wednesday, October 22, 2014

Your password doesn't suck, the server does


I read an article the other day that outlined the exact issue with passwords nowadays. Every website or application that requires a password always talks about the user creating a complex password. You know the routine:

    1 capital letter
    1 number
    1 special character
    no repeating characters

In this article I will outline why it's not your password that is insecure but rather admins not securing their code and/or servers well enough.

What complex passwords protect against

There are only two things a complex password actually helps protect against.

    Brute force attacks
    Dictionary attacks
Brute force attacks are pretty easily circumvented by adding a maximum password attempt before locking the account out. This is assuming that it is not an offline brute force attack, but we'll get to this later in the article. As for Dictionary attacks, that's easy circumvented by adding just an alpha/numeric into the password. So essentially a password as simple as password123 is a "secure" password; albeit it's something that could be easily guessed.

Offline brute force attacks

Offline brute force attacks are done by the attacker either having physical access to the server or the sever was not secure and the user was able to extract the password file. Which back to the title would tell me your password doesn't suck because the attacker should have never gotten to the point of getting the password file. Which leads me to my next point

Hybrid Attacks

Hybrid attacks complicate the "complex password" again by using standard dictionary attacks and adding numbers and symbols to them. And while this can take longer to crack, with the given technology even with a 15 character password can take less than an hour to crack offline.

Password Mangling attacks

If you've ever dealt with end users you know their passwords are very basic. Usually something simple that they add a number to the end, typically the current year or month. Password mangling is taking a dictionary attack, and adding rules to those lists. For instance adding a number to the end of basic password (i.e. - Summer to Summer14). Which can make cracking most typical user passwords very easy to crack. Again this can be circumvented by having strong server side security.


If servers are saving your password on the server in plaintext, there's absolutely zero reason to have a password. Which is a huge indication that the administrator has no idea what security is let alone how to use it.

End user problems

Saving your password on a piece of paper, or a text file. This is a no-no but with how many different passwords we need these days, and all have different requirements it's almost become impossible to remember all passwords. If there was more security on server side, there could be a standard for passwords that would make it easier to remember, especially if using common password for multiple websites/applications.

Other issues end users can face are a bit tougher to tackle such as spyware/malware/keyloggers. However going to back to server security we could see at least a 25% drop in drive-by malware/spyware if servers were more secure. While I'm a big advocate of "If it can be built it can be broken", I still believe we can get rid of at minimum 25%.

Virus definitions or signatures are what the anti-virus program looks at to determine if it's malicious piece of code or not. These definitions are so easy to get around based on how the programmer codes it. By reverse engineering and looking at both virus signature definitions and actual code of the virus we can easy stop more and more malicious software; albeit the more signatures there are the more false positives can be had as well.

Sever hardening

So what can be done server side to prevent having to have strong complex passwords?

Password attempt rules

Adding the security of locking out an account after x amount of failed password attempts fixes the issue with brute forcing the server. However it can't start and stop at the surface. There are many components especially server side that will need to be locked down the same. SQL server, Web App, Web Server root account, SSH, Telnet, etc. Anything that requires a log on for the server needs to be locked down with a lockout rule.

Default Accounts

This is one of my pet peves and something that is often over looked. Far to often a system gets compromised because of default username/password not being changed. I believe it was Target that was a victim of their SQL database being compromised due to default password being used on the server side. All default accounts should be disabled or removed and a new one created.


I could go into a lot more depth of how to properly secure a server but this article is not a how-to but rather an insight as to what common problems are with password security and why it's not your password that is horrible but instead the server and admins that are. Following best practices and learning basic server hardening can circumvent a lot of security breaches, and need for complex passwords.