Securing Passwords in your Web Application

These days, every other site’s database gets hacked and user login details are made available online. Whatever is happening is pretty sad but it’s really not possible to make ourselves 100% secure and hack proof. But yes, it’s definitely possible to be extra cautious to avoid heavy loss in these kind of situations.

The most important part in the user database is “password hashes”. I think these days, most of the sites have adopted one way encryption. Yeah, there are few large sites who still prefer storing their user passwords in simple text or 2 way encryption format, but let’s not talk about those.

So, coming back to one way encryption. The simple method to do this is by using MD5 hashes or SHA-1 hashes. It’s pretty much secured with no major issues with decryption. Yeah, hashes can be matched with huge list of words in the dictionary (or any collection of words) and this is what generally hackers do.

So, in short, storing passwords in simple MD5 / SHA-1 hashes is not enough too. Say, in case of breach like LinkedIn, the passwords were stored in simple SHA-1 hash, so the hackers compared the hashes with huge list of words and were able to decrypt millions of passwords.

So, how do we prevent something like this in future? Here is how:

  • Use Salt. You can create one key of say 64 characters and every time a user registers, the password hashes will be merged with the salt and a new hash will be generated with this combination. So, if you use this, all the user passwords will be merged with same salt. It will become impossible to compare the hashes with list of words without the salt hash.
  • Above method is generally used in recent times but this is what you can do, if you still want to add one more layer of security. At the time of user registration, generate a random salt for that particular user, store salt in the database along with the password. The password hash will now have, hashes of password merged with hashes of the salt. On the top of it, you can merge one more salt value which can be stored in your config file. So, this way, your password will have be unique combination of hashes every time. Yeah, the hackers will get access to your random salt from database (in case of database hack) but it will surely make their life difficult at the time of decryption or comparing with the list of words.
  • Another thing you can do is, implement any of the above points, create a new table for password & map user IDs to it. So, even if the password table is hacked, the usernames won’t be revealed as both are not in the same table.

I guess, above points should add a decent security layer on your web site / application. Obviously, whatever I have mentioned is not rocket science, your site won’t turn to hack proof if you implement any of the above points or any other methods but it will surely make decryption difficult.

Like always. Suggestions are welcome.


  1. i have d2h hd stb with hdmi i buy lg hd led e2351vr monitor having vga,dvi,hdmi port.i connet stb with monitor by hdmi cable, but i cant see tv channels on monitor.why this happen? What will i do to watch channels on it.plz guide me.

  2. Very well written, Deep. All these methods are excellent- but vulnerable brute force attacks of varying complexity, even with hashes and Salt. After years of web application development, I have realized that the best approach to manage authentication/authorization in a web application is to not do it at all, in the web application i.e. delegate these functions to an Active Directory. You could lease one single domain controller server for multiple applications, each using a separate directory of users. The web applications could then use LDAP to go out to the active directory for wide variety of things – ranging from authentication to authorization of capabilities and also for retrieving user profiles and list of capabilities. This way, the application itself does not need to store or manage a user database.

  3. Thanks Amit. Active Directory won’t be possible in every case, specially when the application has nothing to do with the Windows computer. Bruce force will be possible in many cases but if you use different salt, it will be difficult to crack the passwords as every password will be encrypted with unique salt.

  4. Hi Deep,

    Active Directory can be used even when application has absolutely nothing to do with Windows. For example, consider a web application written in Java deployed into Tomcat or even a PHP application deployed on Apache, both in a Linux, AIX or Solaris environment. Even such applications may use a remote Active Directory controller server as a repository of its users — and use an LDAP client (like openLDAP) to communicate with it.
    You may use the AD repository for authentication alone and use a local database table for profile and authorization OR you may even decide to use AD for profile and authorization in conjunction with authentication. These combinations are possible.
    As for using a unique salt for encrypting password or password hashes, if an attacker gains access to your table mapping usernames to corresponding salts then, it is only a matter of adding an extra step in the brute force routine to get past that hurdle.
    I have built applications with local user databases for many years and more recently started using AD to avoid having to manage user accounts locally – because managing user base locally is too much of a risk. AD is virtually impenetrable. With TLS between your application (that incorporates a LDAP client) and the AD controller, it is virtually impossible to see the password in plain text, ever.


  5. I see that a lot of your work is in PHP. The good news is that it is very easy to integrate a PHP application with AD. If your client only wants a WordPress blog, even better – there are a couple of plugins out there that will take care of everything without a single line of code. If your client already uses AD (chances are, they use it to manage access to their Windows based workstation network for employees), you can reuse that. Or, you can lease one active directory server, and user it for tens, even hundreds of customers (different clients) by setting up multiple organizations and hierarchies in the AD. Charge them a small extra fee and your costs of leasing the domain controller will be covered. 🙂

  6. BTW, let me just say this to clarify – while Microsoft’s Active Directory is one of the cleaner, more secure directory systems out there, it is by no means the only one. There are scores of alternatives available, one of which, you could use – some of these free and open source – like Apache Directory Server and OpenDS. In all my comments above, just replace ‘Active Directory’ with any one of these open directory systems and they would provide the same service – i.e. the ability to isolate user and capability management from application. While choosing a Directory Service platform (eg: Active Directory, ApacheDS, OpenDS etc.) just make sure that the one you choose is LDAP complaint so that you are able to integrate with it from your application using an available LDAP client.

Leave a Reply

Required fields are marked *.

This site uses Akismet to reduce spam. Learn how your comment data is processed.