Advertisement:

Author Topic: [MOD] [PENDING] Password security  (Read 33174 times)

Offline Sorunome

  • Semi-Newbie
  • *
  • Posts: 30
    • Sorunome on GitHub
[MOD] [PENDING] Password security
« on: December 09, 2015, 02:41:51 PM »
A forum I'm helping with administration got hacked recently through other means than SMF, the result was a stolen database.
That wouldn't have been quite as bad, if it weren't for the horrible design of password security SMF 2.0.x uses, as I found out afterwards investigating the code to know what the attackers could have stolen.

It turns out that SMF 2.0.x uses sha1 for password-hashing, a method never designed for hashing passwords, a very insecure one on top of that. It doesn't take too long to brute-force such a password!

Doing some more digging into the source I found out that the answers to the security questions are hashed using md5, they aren't even salted! This made me wonder if there is anybody on the SMF team who knows how to write secure code......

Ironically SMF 2.1 uses bcrypt for hashing passwords, which is the current way of doing things "the right way", so the team must know of this issue, and as 2.0.x is still supported it made me wonder, especially since 2.1 isn't ready for production yet, why there was no update made at all to imporve the security of password hashes!

So I wrote a quick mod for passwords to be converted to bcrypt in the same way 2.1 hashes and fixed a few other minor security things I found/thought of: https://github.com/Sorunome/SMF-bcrypt

This post is not meant as an advertisment for this mod, more as a heads-up and wondering as to why 2.0.x recieves such horrible security!
« Last Edit: December 14, 2015, 04:27:40 PM by Kindred »

Online Kindred

  • The Mean One
  • Support Specialist
  • SMF Legend
  • *
  • Posts: 55,121
  • Gender: Male
    • Kindred-999 on GitHub
Re: Password secuirty
« Reply #1 on: December 09, 2015, 02:53:24 PM »
First and foremost --  SMF does not "receive such horrible security"
SMF has one of the BEST security records out of ALL forum script softwares.


second -- sha1 is not a bad method to hash/encrypt -- many systems use it.   However, realize that SMF 2.0 is several years old at this point, and sha1 was definitely a good selection when it was made.  The change to bcrypt for 2.1 is intentional because, yes, it is considered more secure... but sha1 is not "insecure"


It's nice of you to make a mod....
However, since the mod has not been passed through ANY sort of review by the SMF team, I recommend that people use EXTREME caution if they desire to use it.


In all, your insults are unnecessary (and, since this is not a support question, I'm going to move it -- probably to the unreviewed mods board)
Please do not PM, IM or Email me with support questions.  You will get better and faster responses in the support boards.  Thank you.

Offline Sorunome

  • Semi-Newbie
  • *
  • Posts: 30
    • Sorunome on GitHub
Re: Password secuirty
« Reply #2 on: December 09, 2015, 02:56:26 PM »
SHA1 was meant to check files for differences, thus a hashing method to produce different kind of hashes based on large amounts of data. As passwords are small amount of data the hashing happens way quicker than with methods designed for passwords, thus making brute-forcing even easier. That many systems use it doesn't make it more secure, either. (source: http://codahale.com/how-to-safely-store-a-password/ )
I do unserstand that SMF 2.0 is old software, but it should still be recieving important security updates.

I am sorry if i came accross as rude, I meant to stress a very important point concerning security.

Offline Eeems_

  • Newbie
  • *
  • Posts: 3
Re: Password secuirty
« Reply #3 on: December 09, 2015, 03:09:59 PM »
While this isn't specifically a support question, it does bring up an interesting discussion about SMF's security.

Full disclosure I am another one of the administrators at the site Sorunome mentioned.

Just because something has one of the best security records of all "forum script softwares" doesn't mean it actually has great security on all facets. The fact that the yet unreleased 2.1 has already switched over to using bcrypt instead of sha1 and md5 for hashing things already means that the team is aware that they need to make things more secure on the back-end.

Our site wasn't "hacked" in the means of someone forcing their way in through a security hole in the software itself (They somehow managed to get another admins password). What is concerning though, is that the attacker(s) were able to brute force a number of passwords after they took a database dump and get into a number of our members email accounts, and other accounts. The fact that the current stable release of SMF has such a blatantly huge security hole (albeit one that requires database level access) is cause for huge concern.

As Sorunome mentioned, SHA1 may be used by many systems but it was never intended for that use. A quick google search will show that using SHA1 and MD5 to hash secure information is extremely frowned upon by the security community. For good reason too, as we have painfully found out.

Is there any work being done to backport the security changes from the 2.1 codebase to the 2.0.x branch?

While this mod hasn't gone through a technical review by the SMF team, it is in use in the wild and has the code open for review by anybody due to it being hosted in a git repository on github. Feel free to review it and determine if it's safe. If you see issues please report them and if possible open a pull request to patch them out.

Offline margarett

  • SMF Friend
  • SMF Super Hero
  • *
  • Posts: 19,761
  • Gender: Male
Re: [MOD] [WIP] Password security
« Reply #4 on: December 09, 2015, 03:21:41 PM »
(They somehow managed to get another admins password).
(...)and get into a number of our members email accounts, and other accounts.

Human error is always the way to go. We were hacked that way, MyBB was hacked that way, vB was hacked that way... You can have the best security measures in place (or the worse): 99% of the cases it's the human factor to be exploited.
Password reuse is, by far, the worse security issue.

We are aware of that. The same way we upgraded MD5 from 1.0 to 1.1 and then 2.0, we upgraded 2.1 to bcrypt. It's how things evolve, really.

Take a look at this, from 2010
http://stackoverflow.com/questions/2772014/is-sha-1-secure-for-password-storage
Not so ugly at that time, hey? :)

I understand and agree with you concerns, really do. What we generally assume is that, after the database is dumped, are bets are off. MD5, SHA1, SHA-whatever, bcrypt, you-name-it.
Se forem conduzir, não bebam. Se forem beber... CHAMEM-ME!!!! :D

Quote
Over 90% of all computer problems can be traced back to the interface between the keyboard and the chair

Offline margarett

  • SMF Friend
  • SMF Super Hero
  • *
  • Posts: 19,761
  • Gender: Male
Re: [MOD] [WIP] Password security
« Reply #5 on: December 09, 2015, 03:30:32 PM »
Just another thought: 2.1 has bcrypt because we boosted the minimum PHP version to 5.3.something. You'd be surprised with the number of hosts out there with 5.2 or less ;)
SMF 2.0 officially supports PHP 4.something (yeah, it's about time :P ) so we can't really enforce bcrypt in it ;)
Se forem conduzir, não bebam. Se forem beber... CHAMEM-ME!!!! :D

Quote
Over 90% of all computer problems can be traced back to the interface between the keyboard and the chair

Offline Eeems_

  • Newbie
  • *
  • Posts: 3
Re: [MOD] [WIP] Password security
« Reply #6 on: December 09, 2015, 03:34:41 PM »
(They somehow managed to get another admins password).
(...)and get into a number of our members email accounts, and other accounts.

Human error is always the way to go. We were hacked that way, MyBB was hacked that way, vB was hacked that way... You can have the best security measures in place (or the worse): 99% of the cases it's the human factor to be exploited.
Password reuse is, by far, the worse security issue.

We are aware of that. The same way we upgraded MD5 from 1.0 to 1.1 and then 2.0, we upgraded 2.1 to bcrypt. It's how things evolve, really.

Take a look at this, from 2010
hxxp:stackoverflow.com/questions/2772014/is-sha-1-secure-for-password-storage [nonactive]
Not so ugly at that time, hey? :)

I understand and agree with you concerns, really do. What we generally assume is that, after the database is dumped, are bets are off. MD5, SHA1, SHA-whatever, bcrypt, you-name-it.
Thanks for the response.

Yes password reuse is bad. It would be nice if everybody moved to using two factor authentication everywhere to help mitigate things even further. I agree that after the database has been dumped that you have to assume that everything stored on it is accessible. Passwords and all. It would be nice to know it might take them a bit longer to get at the passwords due to stronger encryption.
The fact that users had their email accounts accessed after our database was dumped is a huge cause for concern about still working with SHA1 on the latest stable release of SMF.
Just another thought: 2.1 has bcrypt because we boosted the minimum PHP version to 5.3.something. You'd be surprised with the number of hosts out there with 5.2 or less ;)
SMF 2.0 officially supports PHP 4.something (yeah, it's about time :P ) so we can't really enforce bcrypt in it ;)
Alright, well doing feature detection and then using bcrypt if it is available is still an option though. You may not be able to enforce bcrypt on the 2.0.x branch, but you can at least make it available.

Offline margarett

  • SMF Friend
  • SMF Super Hero
  • *
  • Posts: 19,761
  • Gender: Male
Re: [MOD] [WIP] Password security
« Reply #7 on: December 09, 2015, 03:42:32 PM »
We will. It's actually great you created a MOD for it and you can be sure it'll be looked at ;)
Se forem conduzir, não bebam. Se forem beber... CHAMEM-ME!!!! :D

Quote
Over 90% of all computer problems can be traced back to the interface between the keyboard and the chair

Offline Sorunome

  • Semi-Newbie
  • *
  • Posts: 30
    • Sorunome on GitHub
Re: [MOD] [WIP] Password security
« Reply #8 on: December 09, 2015, 03:55:28 PM »
Just another thought: 2.1 has bcrypt because we boosted the minimum PHP version to 5.3.something. You'd be surprised with the number of hosts out there with 5.2 or less ;)
SMF 2.0 officially supports PHP 4.something (yeah, it's about time :P ) so we can't really enforce bcrypt in it ;)
After some digging I came accross http://nl3.php.net/manual/en/function.crypt.php (available in PHP4) which allows you to hash your passwords using bcrypt, you'd have to manually generate the salt, though.

Offline Sorunome

  • Semi-Newbie
  • *
  • Posts: 30
    • Sorunome on GitHub
Re: [MOD] [WIP] Password security
« Reply #9 on: December 09, 2015, 04:44:31 PM »
[...]
In all, your insults are unnecessary (and, since this is not a support question, I'm going to move it -- probably to the unreviewed mods board)
After re-reading my first post I do see now that it was actually worded quite rudely, and I wanted to apologize for that. Things can't be unsaid, I could explain my situation but that doesn't make things better anyways, so I am sorry for being so rude in my first post.

But yeah, I still want to stress the point of sha1 not being secure for passwords, the attacker managed to brute-force passwords within an hour, which is basically no time at all.


Again, sorry for being so rude in the top post.

Online Kindred

  • The Mean One
  • Support Specialist
  • SMF Legend
  • *
  • Posts: 55,121
  • Gender: Male
    • Kindred-999 on GitHub
Re: [MOD] [WIP] Password security
« Reply #10 on: December 09, 2015, 05:47:18 PM »
apology accepted. :)
Please do not PM, IM or Email me with support questions.  You will get better and faster responses in the support boards.  Thank you.

Offline CoreISP

  • Server Admin
  • Server Team
  • SMF Super Hero
  • *
  • Posts: 16,990
  • Gender: Male
  • CoreISP.net
    • liroyvh on LinkedIn
    • @liroyvh on Twitter
    • CoreISP Corporation :: WebHosting, Dedicated Servers, and more!
Re: [MOD] [WIP] Password security
« Reply #11 on: December 09, 2015, 11:26:14 PM »
Hello!

First of all I'd like to thank you for your comments, and taking the time to extensively argue your point of view. :)
I understand your concerns, and I'm happy that you've taken the time to come to talk to us; it unfortunately doesn't always happen that people come to talk if something bothers them, whilst communication is something we need in order to learn about all the concerns our users may have! (Either legitimate or not.) 

Quote
The fact that users had their email accounts accessed after our database was dumped is a huge cause for concern about still working with SHA1 on the latest stable release of SMF.

I just wanted to comment; please keep in mind this might have various factors involved though, for example;
1.) They could also have re-used passwords elsewhere, making it look quick; but potentially even resulting from a similar or even the same hack that got someone the admin password (from another site, probably).
2.) They could've used poor passwords, eg dictionary based or the legendary "qwerty" or "password" type of phrases. This can indeed lead to a GPU for example popping the password out in a matter of seconds. (And sure, that'd be slower if a stronger algo was in place; but wouldn't stop it forever.)

I'm not saying the encryption can't be improved by the way (I mean... That'd be a lie, and 2.1 indeed proves it can be. :) (Though more factors are in play.)), just pointing out that it isn't necessarily the hashing method involved that led to easily cracking any password. Whilst suspicious, the blame shouldn't be on SHA1 instantly. If you have a high password-strength, it shouldn't be possible to get it done so quickly at all; even if you'd use a known broken algo. But alas, we do have to remember a lot of people use shiiiii.... um... insecure passwords. And we're absolutely in favor of trying to protect everyone the best we reasonably can, within parameters. (Though have to reiterate here: you can't cure idiocy...)

There's a few constraints that limit us in the available options to upgrade the hashing method, but it is being looked at.

Quote
Just because something has one of the best security records of all "forum script softwares" doesn't mean it actually has great security on all facets.

Of course it doesn't have to mean that, but it was merely being pointed out that the SMF software has a good security trackrecord as oppossed to having "horrible security". :) We're known for having good security in our code, and we do our utmost best to keep offering one of the most secure pieces of open-source community software on the market. SMF gets regular reviews and there are currently zero known security vulnerabilities within our codebase, and we're quite happy and proud of that! We do our best to keep our users secure, but the users of our users as well. (And yep, there's room for improvement on the DB side; and yes: this is recognized by the devs as SMF 2.1 shows.) Taking the database is impossible unless there's access to the files already, as you've also noticed. (Usually thanks to insecure software (eg: WP with crappy unupdated plugins) running on the same hosting account; or indeed: by stealing an admin password.)

We'll absolutely take your comments in to consideration, and thank you for making them. :) It helps and keeps us focused.
And there's probably always going to be room for improvement with the speed new (security) features are released for the server software by the way, it's just not always possible to implement (due to backward compatibility.). ;) But we're pretty resourceful, and this is absolutely being looked at to see how we can improve the hashing whilst not leaving anyone out in the cold/with a broken install. :) Our users rely on LTS solutions.
Rest assured that it's taken very seriously, and we've been thinking about this for a while! 

Just to repeat what has already been said though: what is considered secure today, including awesome latest of the greatest crypto, might not be considered secure tomorrow... So if your database get's stolen one way or another, no matter what hashing method is used: *always* update all passwords, and encourage your members to do the same thing!
Always stay guarded, no matter what. The past years in open-source land really has shown us that. (Heartbleed? POODLE? VENOM? Shellshock? etc.) 


Either way, thank you for commenting about this to us; and I hope you've implemented a "no password recycling!!!" rule for administrators! :)
- CoreISP.net Corporation -
  WebHosting, Colocation, Domain Registration & Network Services
- DedicatedBox.us Servers -
  Low priced Servers in a high-quality Network, the place for all your (advanced) server needs.
  We specialize in hosting big boards. Contact us!

((U + C + I)x(10 − S)) / 20xAx1 / (1 − sin(F / 10))
President/CEO of Simple Machines - Server Manager
Please do not PM for support - anything else is usually OK.

Offline nend

  • SMF Friend
  • SMF Hero
  • *
  • Posts: 1,755
  • 2 deep n2 the code
    • sicommnend on GitHub
    • SIComm.us
Re: [MOD] [WIP] Password security
« Reply #12 on: December 10, 2015, 01:08:51 AM »
My SMF sites a attacker has to know the users email address to log in to their account.  Usernames are only used for display and cannot be used to log in.
http://www.sicomm.us/login/

Will look into your mod also, never can have enough security.

Offline CoreISP

  • Server Admin
  • Server Team
  • SMF Super Hero
  • *
  • Posts: 16,990
  • Gender: Male
  • CoreISP.net
    • liroyvh on LinkedIn
    • @liroyvh on Twitter
    • CoreISP Corporation :: WebHosting, Dedicated Servers, and more!
Re: [MOD] [WIP] Password security
« Reply #13 on: December 10, 2015, 10:03:48 AM »
My SMF sites a attacker has to know the users email address to log in to their account.  Usernames are only used for display and cannot be used to log in.

IIRC, that actually weakens the login security... Not improve it.
- CoreISP.net Corporation -
  WebHosting, Colocation, Domain Registration & Network Services
- DedicatedBox.us Servers -
  Low priced Servers in a high-quality Network, the place for all your (advanced) server needs.
  We specialize in hosting big boards. Contact us!

((U + C + I)x(10 − S)) / 20xAx1 / (1 − sin(F / 10))
President/CEO of Simple Machines - Server Manager
Please do not PM for support - anything else is usually OK.

Offline Eeems_

  • Newbie
  • *
  • Posts: 3
Re: [MOD] [WIP] Password security
« Reply #14 on: December 10, 2015, 12:57:20 PM »
Hello!

First of all I'd like to thank you for your comments, and taking the time to extensively argue your point of view. :)
I understand your concerns, and I'm happy that you've taken the time to come to talk to us; it unfortunately doesn't always happen that people come to talk if something bothers them, whilst communication is something we need in order to learn about all the concerns our users may have! (Either legitimate or not.)
Thanks for not dismissing what we had to say. Sorry if we came across rather strongly at the start, it was a rather stressful last couple of days.

Quote
The fact that users had their email accounts accessed after our database was dumped is a huge cause for concern about still working with SHA1 on the latest stable release of SMF.

I just wanted to comment; please keep in mind this might have various factors involved though, for example;
1.) They could also have re-used passwords elsewhere, making it look quick; but potentially even resulting from a similar or even the same hack that got someone the admin password (from another site, probably).
2.) They could've used poor passwords, eg dictionary based or the legendary "qwerty" or "password" type of phrases. This can indeed lead to a GPU for example popping the password out in a matter of seconds. (And sure, that'd be slower if a stronger algo was in place; but wouldn't stop it forever.)

I'm not saying the encryption can't be improved by the way (I mean... That'd be a lie, and 2.1 indeed proves it can be. :) (Though more factors are in play.)), just pointing out that it isn't necessarily the hashing method involved that led to easily cracking any password. Whilst suspicious, the blame shouldn't be on SHA1 instantly. If you have a high password-strength, it shouldn't be possible to get it done so quickly at all; even if you'd use a known broken algo. But alas, we do have to remember a lot of people use shiiiii.... um... insecure passwords. And we're absolutely in favor of trying to protect everyone the best we reasonably can, within parameters. (Though have to reiterate here: you can't cure idiocy...)

There's a few constraints that limit us in the available options to upgrade the hashing method, but it is being looked at.
Weak, or reused passwords is a huge security hole that only the users themselves can fix. All we can do is attempt to mitigate it.
I'm not sure what the password strength was on the users who were hit, I never got around to asking them. We can assume that since most of them were for their older accounts that they were weak or reused passwords.
If only we could cure idiocy haha. That would resolve so many problems we developers have to deal with. Including many we ourselves introduce.

Quote
Just because something has one of the best security records of all "forum script softwares" doesn't mean it actually has great security on all facets.

Of course it doesn't have to mean that, but it was merely being pointed out that the SMF software has a good security trackrecord as oppossed to having "horrible security". :) We're known for having good security in our code, and we do our utmost best to keep offering one of the most secure pieces of open-source community software on the market. SMF gets regular reviews and there are currently zero known security vulnerabilities within our codebase, and we're quite happy and proud of that! We do our best to keep our users secure, but the users of our users as well. (And yep, there's room for improvement on the DB side; and yes: this is recognized by the devs as SMF 2.1 shows.) Taking the database is impossible unless there's access to the files already, as you've also noticed. (Usually thanks to insecure software (eg: WP with crappy unupdated plugins) running on the same hosting account; or indeed: by stealing an admin password.)

We'll absolutely take your comments in to consideration, and thank you for making them. :) It helps and keeps us focused.
Thank you again for taking us seriously and looking into our concerns. I'm going to again apologize (There's the Canadian in me coming out again) for coming across so strongly at the start of this.

And there's probably always going to be room for improvement with the speed new (security) features are released for the server software by the way, it's just not always possible to implement (due to backward compatibility.). ;) But we're pretty resourceful, and this is absolutely being looked at to see how we can improve the hashing whilst not leaving anyone out in the cold/with a broken install. :) Our users rely on LTS solutions.
Rest assured that it's taken very seriously, and we've been thinking about this for a while!

Just to repeat what has already been said though: what is considered secure today, including awesome latest of the greatest crypto, might not be considered secure tomorrow... So if your database get's stolen one way or another, no matter what hashing method is used: *always* update all passwords, and encourage your members to do the same thing!
Always stay guarded, no matter what. The past years in open-source land really has shown us that. (hxxp:heartbleed.com [nonactive] hxxp:en.wikipedia.org/wiki/POODLE [nonactive] hxxp:venom.crowdstrike.com [nonactive] hxxp:en.wikipedia.org/wiki/Shellshock_(software_bug) [nonactive] etc.) 


Either way, thank you for commenting about this to us; and I hope you've implemented a "no password recycling!!!" rule for administrators! :)
Yes, backwards compatibility is a PITA. I'm so glad I don't have to work on a project at work where I have to support IE7 anymore. There are ways to conditionally have new features but still support systems that wont work with the new features. Fully investigating the impact of doing so is very important. It would be great to have a security review of our mod by your team to make sure it's up to your standards since we are now using it in our production site. I believe Sorunome is currently looking into how to add PHP4 support to it.
We have for sure asked our administrators (Well all of our users.. those emails took a while to send) to change their passwords. I'm not entirely sure how many of them are not doing password reuse. We have also disabled the attack vector (File editing) that was used by after the attacker gained access to the admin panel. I would eventually love to get two factor authentication setup for our admins but that isn't natively supported in the 2.0.x branch. I also don't have the time right now to develop a mod to implement it on our site as of yet.

Offline Sorunome

  • Semi-Newbie
  • *
  • Posts: 30
    • Sorunome on GitHub
Re: [MOD] [WIP] Password security
« Reply #15 on: December 10, 2015, 01:40:37 PM »
[...]
Yes, backwards compatibility is a PITA. I'm so glad I don't have to work on a project at work where I have to support IE7 anymore. There are ways to conditionally have new features but still support systems that wont work with the new features. Fully investigating the impact of doing so is very important. It would be great to have a security review of our mod by your team to make sure it's up to your standards since we are now using it in our production site. I believe Sorunome is currently looking into how to add PHP4 support to it.
[...]
Indeed I am, it currently looks like I'll be able to improve password hashing on PHP4 and, with the optional dependency of PHP5 let it reach the same level of security as SMF2.1 currently has.

Offline nend

  • SMF Friend
  • SMF Hero
  • *
  • Posts: 1,755
  • 2 deep n2 the code
    • sicommnend on GitHub
    • SIComm.us
Re: [MOD] [WIP] Password security
« Reply #16 on: December 10, 2015, 07:11:30 PM »
My SMF sites a attacker has to know the users email address to log in to their account.  Usernames are only used for display and cannot be used to log in.

IIRC, that actually weakens the login security... Not improve it.

I lost you there. I don't get how requiring email address for login weakens the login security, wouldn't it make it more secure as emails are not usually giving out?

Offline Sorunome

  • Semi-Newbie
  • *
  • Posts: 30
    • Sorunome on GitHub
Re: [MOD] [WIP] Password security
« Reply #17 on: December 11, 2015, 05:49:50 AM »
Ok so ironically it looks to me like https://github.com/SimpleMachines/SMF2.1/blob/release-2.1/Sources/Subs-Password.php is exactly what you need for backwards-compability with PHP4, except to replace $2y$, which was added in PHP 5.3.7, with $2a$. A version-check would be actually better, so that if version >= 5.3.7 you use $2y$ and else $2a$.

Offline Sorunome

  • Semi-Newbie
  • *
  • Posts: 30
    • Sorunome on GitHub
Re: [MOD] [WIP] Password security
« Reply #18 on: December 11, 2015, 07:16:08 AM »
So, I added now theoretical support for PHP4, backporting that Subs-Password.php from SMF2.1
Can somebody please confirm this on an actual install? I only had http://sandbox.onlinephpfunctions.com/ to test the hashing itself. (Mod: https://github.com/Sorunome/SMF-bcrypt )

Offline live627

  • SMF Friend
  • SMF Hero
  • *
  • Posts: 5,265
  • Gender: Male
  • Cat: Destroy!
    • live627 on Facebook
    • live627 on GitHub
    • live627 on LinkedIn
    • @live627 on Twitter
    • livemods
Re: [MOD] [WIP] Password security
« Reply #19 on: December 11, 2015, 06:51:40 PM »
Actually, it'll work on PHP 5.3.7+

See the Requirements section of https://github.com/ircmaxell/password_compat#requirements
Try not to become a man of success, but rather try to become a man of value.
- Albert Einstein