Jetendo CMS login security upgraded - again

Sun, Nov 10, 2013 at 4:35PM

Scrypt now used for login tokens and password hashing

Jetendo CMS now has a second option for password hashing integrated with it, which has become the default for all my clients.

I'm using the Scrypt java project now:

which is based on

Scrypt has 1 major benefit over other commonly used password hashing approaches like bcrypt and pbkdf2.  In addition to having support for consuming more CPU time and a larger key size, you can also define how much memory it takes to hash a password.

Why is this important?  Well a lot of password cracking can be done much faster by regular people with free tools like hashcat, which uses the power of the GPU (Graphics Processing Unit) to scale up to billions more operations per second then can be done with regular CPUs.  This is significant.  In the case of a md5 hash, it can process over 150 million password cracking attempts per second on a single cheap GPU today.   Some hash algorithms like md5 are significant weaker because of their speed.  Most people have switched to SHA / SHA2 now, but even they can be cracked with enough time brute forcing.  With short / simple passwords that most people use, it is now possible to recover them very fast, it just may take a few minutes, hours or days.

Scrypt makes hashcat and other GPU hacking more expensive because it allows you to configure it to use a larger amount of memory, thereby increasing the cost or time to crack the password.   You can also configure how much CPU & memory it uses, so as computers get faster, you can increase the work load required to generate a hash.   GPU memory is currently more expensive compared to CPU memory because it is faster, and more specialized.

As users login to Jetendo CMS again, they will automatically be upgraded to the current default password security setting.  This will allow developers using Jetendo to migrate between different hashing system easily by just changing one configuration variable.  Jetendo CMS doesn't force one password hashing system to be used.  You can even disabling password hashing if you need to.

Password expiration policy added for more security

Surely, a great deal of the passwords Adobe was storing were for accounts that have been inactive for months or years, and now all those accounts are available to the public as described here.   Perhaps, it would be a good idea to set an expiration date for password storage on your inactive accounts.  When they expire, you simply delete the hash and related security information and require the user to reset their password before logging in again.   Reseting the password requires the user to confirm their email address.  

I found less then 3% of the user database for all my clients had actually logged in during the last 6 months.   A lot of the accounts used to be created based on the user making a free account on the web sites, but if they never come back, their password is at risk of being cracked if the database is ever stolen.  Now only the most active users are being stored, at the slight inconvenience of people who less frequently use the system having to reset the password.

Because Jetendo may be deployed on many different servers by many developers in the future, you can configure this password expiration policy many to be as long or short as you wish.   Other developers may not be as good at managing their security and Jetendo aims to make security easier by protecting passwords.

The new password expiration scheduled tasks deletes the password and related security information for these users automatically after 180 days of inactivity.  In the event the database is stolen, it won't have anywhere near the impact that it would if I kept everyones passwords forever like Adobe did.

Bookmark & Share