passwords crypted with md5 - isn't it too weak ?

[YoJoe]

I'm not  a security specialist, but when it goes to personal data I'm always a bit worried.
I've looked what's the method of storing passwords in WB 2.8.2, and I still can't believe that passwords are stored only as a md5 hashes. There's not even a salt being used along with md5 function.
Am I wrong ? Because the only salt I've seen is used for sessions.

Were there any thoughts about switching to sha1 method ?
At least a bit more advanced md5 encryption like md5($salt.md5($pass)) would be appreciated, or both methods: sha1($salt.md5($pass).$salt).

Any word on this ? I've got a feeling that I overlooked something important in WB's code.

[testör]

Doesn't WB 2.8.2 use salt? I think so...

[jrast]

Were there any thoughts about switching to sha1 method ?
At least a bit more advanced md5 encryption like md5($salt.md5($pass)) would be appreciated, or both methods: sha1($salt.md5($pass).$salt).

Any word on this ? I've got a feeling that I overlooked something important in WB's code.

Actually it doesn't really matter which method is used, as both are very fast in computation. Of course it's better to use a saver algorithm, but if someone does a brute force attack, both methods will fail. The salt is a important thing to have, but only if it is long enough.

A better way is to run the crypt-algorithm multiple times, so if someone does a brute force attack, he'll need more time and makes the attack less attractive!

Once I found a very nice article out there in the Internet, but i can't find it anymore. I just found this:
http://www.bucabay.com/web-development/secure-password-hashing-storage-ph/

So, maybe this would be a good idea for the next WB-Version!

EDIT:

Ok, found the article, but it's in german:
http://www.d-mueller.de/blog/hashverfahren-und-sicherheit/

And here a topic from stackoverflow with a few useful links on password security:
http://stackoverflow.com/questions/348109/is-double-hashing-a-password-less-secure-than-just-hashing-it-once

[YoJoe]

Links you provided brings exactly the thing I wanted to point.
Rainbow tables are breaking md5 hashes (made from 6-8 letter passwords) within minutes, and lately even rainbow tables aren't needed to generate pass with adequate hash.
And WB's default policy are min. 3 letter passwords, and usernames.

Salts do not have to have a minimum of 10 chars, as more secure solution is to generate unique 4-5 char salts for every user, than store the salt as plain text in a file/dbase.
Nevertheless it's always about time needed to crack the passes, and fetching needed data makes it more complex.
That's why a bit more complex method, involving sha1, md5, salts, pass, username and any other string provided by user (salt may be even a timestamp), and repeating the algorithm backwards  would do the job.

Of course it would be awesome if WB could come up with setting default passwords policy like: minimum amount of special chars, letters, numbers.

Dream situation would be to have a passwords made of 2 words divided by space (involving even 2 input fields)
As those tend to be lately harder to break using known methods, than 12-letter passwds created with above mentioned policy. And are easier to be remembered.

ps. I'm testing every's CMS passwords policy. And none of those I've tried in this year allowed to use spaces in passwords and usernames.
Pity

[NorHei]

.... just a few thoughts ...

1. Changing the password algorithm makes updates to a new WB version impossible as you cannot restore the passwords to encrypt em again.

2.  To use rainbow tables you need access to the WB database , if you have access to the database tables , you simply reset passwords to a value you like.  No rainbowtables needed at all.

3. Adding a salt is questionable too, as if someone gets acces to the database to read the hashes , he does not need to hack the hashes anymore (see above) and having the salt stored in the same DB makes it even more worthless.

4. If i plan to attack a CMS site  i would first try to figure out some usernames , after that i would go and set a bot to test the 500 most used passwords against that accounts , chances are very good that you succeed. 

5.

Of course it would be awesome if WB could come up with setting default passwords policy like: minimum amount of special chars, letters, numbers.

Don't dream , write  a replacement for WB registration. Just a few additional filters and you are done.

6. Allowing spaces does not help much, its just one additional charakter to take care off.

7. One really usefull thing to slow down brute force or dictionary attacks to your website is to slow down the login process if someone entered a wrong password. If you wait 10 Seconds  to  say "hey, wrong password " most attacks would take a really long time.

8. Slowing down the login whith 10000 times hashing a string is plain silly It fully eats up your Server resources fo no gain in security . Simply use sleep() in combination whith an IP block.

9. Multiple hashing makes the use of rainbow tables a lot harder and slows down brute force on the hash, but again if an attacker managed to get that far you are lost anyway .  This still makes a lot of sense if you are protecting the password file on your server.

10. Ensuring save passwords is good, but do not overdo it or you users will kill you (customers maybe simply go away) or start storing their paswords in their browsers.

11. As a result of the things mentioned before fixing security issues that let you access sensitive parts like user management or MYSQL DB are first priority.
 
12. WB only uses Salt in its FTAN /IDKEY system for now , but all security systems will undergo a complete rework step by step.

[YoJoe]

.... just a few thoughts ...

1. Changing the password algorithm makes updates to a new WB version impossible as you cannot restore the passwords to encrypt em again.

Agreed.
But that's nothing new. Every system after having its access algorithms changed, have to allow users to login somehow.
Mostly by resetting all user pass, and sending a step by step procedure to change pass.

2.  To use rainbow tables you need access to the WB database , if you have access to the database tables , you simply reset passwords to a value you like.  No rainbowtables needed at all.

Getting a dbase = getting all datas along with passwords pretty easy, and fast,  if they are are encrypted only with md5.
Except if they are somehow encrypted/decrypted also with 3rd party tools (aes256?)
Can't remind myself an opensource content management solution with such feature.

From the other hand there are also so called "pass hash attacks".
But you mentioned about blocking connections in further part of reply.

3. Adding a salt is questionable too, as if someone gets acces to the database to read the hashes , he does not need to hack the hashes anymore (see above) and having the salt stored in the same DB makes it even more worthless.

As I mentioned above.

4. If i plan to attack a CMS site  i would first try to figure out some usernames , after that i would go and set a bot to test the 500 most used passwords against that accounts , chances are very good that you succeed.  

hehe
We all know that users are the weakest links in all IT systems

5. Don't dream , write  a replacement for WB registration. Just a few additional filters and you are done.

Kingdom for the one, who understands regular expressions, and could teach me them :/
I have to stay with my dreams...  

6. Allowing spaces does not help much, its just one additional charakter to take care off.

Not exactly.
Normal users tend to use dictionary, easy to remember passwords.
If they were able to use a sentence-like passwords, consist of 3 words, this would make very difficult to break the password, as solution in your 4th point won't handle it
And it's not about replacing spaces with dashes, or using whole sentence as a 1 long string.

7. One really usefull thing to slow down brute force or dictionary attacks to your website is to slow down the login process if someone entered a wrong password. If you wait 10 Seconds  to  say "hey, wrong password " most attacks would take a really long time.

Fully agreed.
Users won't correct their pass faster than within couple (3-5) seconds.

Haven't go deeply in WB's functions, but is there anything more than blocking login access with a cookie/session ?
What about automatic attempts ?

8. Slowing down the login whith 10000 times hashing a string is plain silly It fully eats up your Server resources fo no gain in security . Simply use sleep() in combination whith an IP block.

Combined methods are the way to go.
IP block isn't imo a reliable solution, although attacks tend to come from 1 machine/network.

Other thing are server security options, and protection from resource overloading.
That's what cms can't handle/protect fully on its own.

ps. what sort of nerd would hash passwords using e.g. 50x loop with sha algorithm ?
This wouldn't make any sense, as attacks based generating identical hashes came tru last year (or 2?).
But they still take too much time to be efficient

9. Multiple hashing makes the use of rainbow tables a lot harder and slows down brute force on the hash, but again if an attacker managed to get that far you are lost anyway .  This still makes a lot of sense if you are protecting the password file on your server.

50 x sha1.salt.timestamp loop ?

10. Ensuring save passwords is good, but do not overdo it or you users will kill you (customers maybe simply go away) or start storing their paswords in their browsers.

I know the problem. 1 special character in the password makes them too complicated in most of cases.
Real pain to maintain user pass security.

11. As a result of the things mentioned before fixing security issues that let you access sensitive parts like user management or MYSQL DB are first priority.

Making small steps is always a good approach.
Wait, wasn't it about humanity ?

Anyway I don't know about all vulnerabilities of WB. Just pointed the thing with passwords stored as a simple md5 hash.
As a sidenote quite many systems hold pass in plain text. But their protection bases on other levels of accessing the data.
Don't know much about such methods. I was just curious why novadays some biggest players in interwebz still holds user passwords in plain text format.

12. WB only uses Salt in its FTAN /IDKEY system for now , but all security systems will undergo a complete rework step by step.

That would be a nice changelog entry.


Forgot to add, that some "scientists" are testing a method of drawing password images.
I've seen a similar method used in captcha, where drawn picture has to have a minimum 5% diffraction, to detect bots

[NorHei]

Don't know much about such methods. I was just curious why novadays some biggest players in interwebz still holds user passwords in plain text format.

Again , if you got access to DB you simply set the password to an value you like , you dont need to decrypt anything.

But in general its better to hash paswords as it limits abuse from co admins and other internal personal.

Guess i would choose 20-100 x sha512( md5(user salt) + md5(global salt) + md5(userid)+ md5(password) ) . Where global salt is randomly generated and stored in a file in the install process and user salt is stored in DB encoded whith a decrypable format whith its key stored in the config.
so you always need both , config and DB and you can store the config just outside your webroot.

Kingdom for the one, who understands regular expressions, and could teach me them :/
I have to stay with my dreams...  Wink

There are many tutorials about REGX in the web , but if you need something speciffic for this task  maybe just ask me
What regex you need ?
Teachng is not that easy as it would take many days or maybe even weeks.

Concerning Spaces :
Pepole will still use : "ho ho ho" or maybe "H0 H0 H0" or "I am strong" so dictionarys still work.

Haven't go deeply in WB's functions, but is there anything more than blocking login access with a cookie/session ?
What about automatic attempts ?

Not much

[pcwacht]

Hmmm, talking baout pasword hashing etc
What about using https? Never saw anything about it, maybe because most webspaces don't do https....

since wb as most other cms (or other webbased systems) use simple http every ippacket is uncoded.

I think wb has a good allready built in defense by blocking logging in after three times (though it is cookie/session based)
Maybe blocking ipadres (segment) from wich assumed attack comes from after six invalid logins, then block it for 12 hours or so, then brute force won't be fun anymore. I think this could be easely coded.

But remember, from my poiint of view, each webbased system has its leaks due to other users on same server......
Ever tried to read files in other webspaces on same server?

It has nothing to do with hashing or overcomplex hashing....

And every clever idea wich is coded is readable since WB, as are most webbased progs, is opensource.


John

[jrast]

Hey NorHei!

I'm sorry, but I can't agree with you in most of the points you mentioned.

1. Changing the password algorithm makes updates to a new WB version impossible as you cannot restore the passwords to encrypt em again.

Actual situation: md5($pwd) is saved in the DB
Assume that the new password will be encoded like this:

Code: [Select]

$sec_pwd = md5($salt.md5($pwd));
for($i = 0; $i < 1000; $i++) {
  $sec_pwd = md5($sec_pwd);
}

Now for updating all the pwd's from the db we have to do something like this:

Code: [Select]

$sec_pwd = md5($salt.$pwdFromDB);
for($i = 0; $i < 1000; $i++) {
  // the same as above
}
// now save the sec_pwd back in DB

So, it can't be an argument if you say it's impossible to update!


2.  To use rainbow tables you need access to the WB database , if you have access to the database tables , you simply reset passwords to a value you like.  No rainbowtables needed at all.

3. Adding a salt is questionable too, as if someone gets acces to the database to read the hashes , he does not need to hack the hashes anymore (see above) and having the salt stored in the same DB makes it even more worthless.

Most of all hackers don't want to get access to your system, they want username/email/pwd combinations. Because lot of useres don't use unique
passwords on different pages, the hacker can try to use the same password for an e-mail-account. They are more interested in things like
e-mail accounts as they contain more sensitive material.

4. If i plan to attack a CMS site  i would first try to figure out some usernames , after that i would go and set a bot to test the 500 most used passwords against that accounts , chances are very good that you succeed.  

Here I can agree with you. To avoid this you need a system which blocks the login if a someone does a lot of login attempts

7. One really usefull thing to slow down brute force or dictionary attacks to your website is to slow down the login process if someone entered a wrong password. If you wait 10 Seconds  to  say "hey, wrong password " most attacks would take a really long time.

8. Slowing down the login whith 10000 times hashing a string is plain silly It fully eats up your Server resources fo no gain in security . Simply use sleep() in combination whith an IP block.

Assume that someone has hacked your DB (to have access to all your username/mail/pwd combinations). And as WB is opensource, he can build his own functions which does the same as the WB-login function. So if you just use a sleep comand, he just leave away this statement and can generate pwd's as fast as if we just use md5 (or can also use rainbowtables and look up the combination). But if WB uses his very unique function which needs alot of iterations, he can't just simplify the function to run faster and there are no rainbowtables for this unique operation. The WB-function itself won't realy slow down your page because the login action is used only once per user per login.  

9. Multiple hashing makes the use of rainbow tables a lot harder and slows down brute force on the hash, but again if an attacker managed to get that far you are lost anyway .  This still makes a lot of sense if you are protecting the password file on your server.

Wrong argumentation. Of course, if someone hacks your DB your f***ed but think a little bit further: maybe he's not interested in your page, but in all the userdata which is in the DB. So he don't just override this information, he'll copy it and use this data for hacking or accessing other boards/e-mail-accounts, ...

11. As a result of the things mentioned before fixing security issues that let you access sensitive parts like user management or MYSQL DB are first priority.

Totaly agree with you! If your DB is "unhackable" the pwd's are save!

@pcwacht:

And every clever idea wich is coded is readable since WB, as are most webbased progs, is opensource.

Maybe a littlebit overkill, but a nice idea:
Just create the salt or even the number of iterations during installation of WB.
For example:
1. generate a random number, md5 or sha1 it and use it as salt
2. generate a random number between x and y and use it as count of itterations

So nobody who don't have access to your webroot knows your personal hashing routine despite WB is opensource!

[NorHei]

@pcwacht

Https is good if you want a really secure login you absolutely need https.

I think wb has a good allready built in defense by blocking logging in after three times (though it is cookie/session based)

Nope that one is completely useless, you can savely remove it and still have the same security level.

Maybe blocking ipadres (segment) from wich assumed attack comes from after six invalid logins, then block it for 12 hours or so, then brute force won't be fun anymore. I think this could be easely coded.

Jep, on failed logins start collecting IP is there are more than 3-4 failures lock the IP for 5 Minutes if there are 4 more failures lock it for an hour.  Same whith username , 3-4 failed logins to a username , block it for 5 Minutes  , 4 more failures block it for an hour , 4 more block it for a day.

But remember, from my poiint of view, each webbased system has its leaks due to other users on same server......

Some Sysadmins say 80% of all hack attacks come from inside, thats why you have to protect yourself agains attacks from inside.

Ever tried to read files in other webspaces on same server?

Completely impossible on some Webspaces, no problem on others. Depends on your hosting company.   

And every clever idea wich is coded is readable since WB, as are most webbased progs, is opensource.

Most modern encryptions are "opensource" thats why they are secure . Everyone can test them for security holes and every one nkows how long it takes to brute force em.

The principle of using tokens against CSRF attacks is well known , functional and secure . If ever someone finds a hole , someone else will make a patch. At least after that hole is exploited a few times.

@jrast

Code: [Select]

$sec_pwd = md5($salt.$pwdFromDB);
for($i = 0; $i < 1000; $i++) {
  // the same as above
}Good idea! Perfect , thx !

Most of all hackers don't want to get access to your system, they want username/email/pwd combinations. Because lot of useres don't use unique
passwords on different pages, the hacker can try to use the same password for an e-mail-account.

 
If you got into WB DB System you can do a lot of really bad things. Add a page whith a webshell , create landingpages for your bakn fraud or v*** spammails. Add additional login requests to get userpasswords whithout cracking a hash , create your own adminaccounts and a lot of other nastie stuff. so thats really really bad . Next step , get the /etc/passwd via webshell and say goodbye to your server.
Getting even more userpasswords via decrypting hashes does make it only slightly worse.

Assume that someone has hacked your DB (to have access to all your username/mail/pwd combinations). And as WB is opensource, he can build his own functions which does the same as the WB-login function. So if you just use a sleep comand, he just leave away this statement and can generate pwd's as fast as if we just use md5 (or can also use rainbowtables and look up the combination). But if WB uses his very unique function which needs alot of iterations, he can't just simplify the function to run faster and there are no rainbowtables for this unique operation. The WB-function itself won't realy slow down your page because the login action is used only once per user per login. 

He can even add fake logins to a single page thats what i said above , but no hashing helps against. that.
I agree that  some unique operation for hashing is good but doing enough re-hashing to create a 10 seconds timeout is suicide to you resources. Doing a nice mixture of algos and a repeated sha512 maybe for 20-30 time should do the job.

Wrong argumentation. Of course, if someone hacks your DB your f***ed but think a little bit further: maybe he's not interested in your page, but in all the userdata which is in the DB. So he don't just override this information, he'll copy it and use this data for hacking or accessing other boards/e-mail-accounts, ...

Thats quite an argument , and btw. hashing helps against some minor admins or editors that have access to the code or droplets module and want to go after some userpasswords. Or maybe even a module author that has criminal tendencies.
Btw i already stated :

Guess i would choose 20-100 x sha512( md5(user salt) + md5(global salt) + md5(userid)+ md5(password) )Where global salt is randomly generated and stored in a file in the install process and user salt is stored in DB encoded whith a decrypable format whith its key stored in the config.
so you always need both , config and DB and you can store the config just outside your webroot.