MD5 hash unsecure for passwords!

Post your ideas on features for CrazyStat, improvements, wishes etc. here.
Forum rules
You can find my list of todos here to see what is already planned for CrazyStat. But feel free to request anything that comes to your mind, even if it is already on the list (but don't complain if I just answer "already on the todo" then... ;-) ). A "+1" reply is always welcome.

Preferred language of discussion is English so most users can profit from your threads, but German is okay as well.

Bevorzugte Sprache ist Englisch, damit möglichst viele Nutzer von den Threads profitieren können, aber Deutsch wird auch akzeptiert.
Post Reply

MD5 hash unsecure for passwords!

Post by Diego » Wed Aug 05, 2015 11:05 pm

Hello guys,

please read here: ... s.fasthash
and learn, that md5 is unsuitable for password management.

Sure, your add a salt string, but a bruteforce attack is a easy, cheap and fast solution for cracking that; we don't live in a 486-world anymore...

Have a nice day

Site Admin
Posts: 162
Joined: Sat Mar 03, 2012 10:30 pm
Location: Germany

Re: MD5 hash unsecure for passwords!

Post by Christopher » Thu Sep 03, 2015 10:52 am

It's for sure correct that MD5 nowadays is not the best hashing algorithm for passwords. Feel free to improve CrazyStat, it is open source.

But I consider the way CrazyStat encrypts passwords still secure enough. First, the password only protects your website's statistics and logs. I doubt this information is worth a brute-force attack for most websites using CrazyStat.
Second, CrazyStat hashes the password on the client side if the browser supports javascript (and warns you, if it does not). This means the password is never sent in cleartext over the network (without the user being warned beforehand). This is by far more secure than most login mechanisms of modern scripts. E.g. Piwik sends passwords unencrypted over the network, thus allowing easy man-in-the-middle attacks.

And if an attacker gets access to the salted password stored in config_pass.php, you have got a much bigger problem anyway. The attacker can read protected files on your file system, so he can also read your log files, which is everything the password protects. Why should he bother brute-forcing the has if he can already read the information protected by it? It would only make sense if the password is also used somewhere else.

Of course if I would write this today, I would use another hashing algorithm. I would not write my own password protection, but use a proven one offered by a framework. But for what it protects, I still consider CrazyStat's login mechanism secure enough.
I try to support my users as best as I can.
Please support me and CrazyStat in return. Thanks.

Post Reply