[DBTech] DragonByte Security [Paid] 4.0.1

[DragonByte Tech]

DragonByte Tech submitted a new resource:

DragonByte Security - Improve your forum's security

DragonByte keeps a watchful eye over your forum even when you are not there, and has the capability to alert you of any suspicious activity.

Uses
DragonByte is the ideal product for forums that are concerned about security, or wish to be alerted when something suspicious happens. Featuring multiple "Security Watchers" such as Failed Logins and Failed AdminCP Logins, you can set up different "tiers" of actions to be taken when certain thresholds are met. For example, if...

Read more about this resource...

 

[Slavik]

So,

Assuming someone has gotten access enough to be able to make edits to the config file or upload/install addons.

What is to stop them simply, disabling this one?

 

[DragonByte Tech]

So,

Assuming someone has gotten access enough to be able to make edits to the config file or upload/install addons.

What is to stop them simply, disabling this one?

Nothing, I'm not rightly sure if that can be stopped though short of file edits and/or encoding the XenForo files.

If you're referring to the config.php tampering, that was included because it was a vBSecurity feature. In vBulletin, it was very easy to overwrite the $vbulletin->config variable via plugins - it was a very common permission elevation vector.


Fillip

 

[Mouth]

For the password functionality, can I enforce password change for users if they have not logged in for xx days?
Eg. A daily cron job runs, and for all users that have not logged in for > 183 it resets their password, if the do not have two-step active. Thus, requiring that user to utilise the password reset functionality (email them link for password reset) to log-on again.

 

[DragonByte Tech]

For the password functionality, can I enforce password change for users if they have not logged in for xx days?
Eg. A daily cron job runs, and for all users that have not logged in for > 183 it resets their password, if the do not have two-step active. Thus, requiring that user to utilise the password reset functionality (email them link for password reset) to log-on again.

That's a good idea, I'll add it to next week's update

I'll make the changes two-fold; I'll add an optional "user has not logged on for X days" limiter on the "mass password reset" maintenance action, and add this new cron job

They'll be emailed a new password right away, they won't need to manually go click the link for password reset. Skipping that step helps improve usability, since we're only ever emailing the user's registered email address anyway.


Fillip

 

[Fred.]

They'll be emailed a new password right away, they won't need to manually go click the link for password reset. Skipping that step helps improve usability, since we're only ever emailing the user's registered email address anyway.

But then you have the password in the e-mail which can be insecure. Clicking the link for password reset would be more secure.

 

[DragonByte Tech]

But then you have the password in the e-mail which can be insecure. Clicking the link for password reset would be more secure.

Respectfully, I disagree, for a number of reasons.

Before I get into the reasons themselves, I want to say a sincere thank you for your interest and your feedback. It makes me really happy when someone takes enough of an interest in something I build to post their feedback to help me make it even better. It really is the best thing a coder could wish for (that isn't considered legal tender in their country of choice, anyway ).

In short, thank you

Now then:

1. Password reset links expire.
   If this mod sent links to users for them to be given a new password, we would be assuming that everyone who was registered to the forum was able to check their email and click the link within 15 minutes. That isn't really feasible as I'm sure you can understand.
   If we were to make a new password reset link that was permanent, I don't see how there would be a difference between this link and the new temporary password being sent in plain text, as any attacker that had broken in to the user's email provider to click this link would then simply wait for 30 seconds until the password arrived in the inbox.
   
   
2. It's less user friendly.
   I believe that requiring people to click a link only to receive a password is an extra step that would complicate the process for the user. When considering that attackers who had breached the security on the email provider could just as easily click the link to receive the password, I don't believe we should require users to do it.
   
   
3. It's meant to be a temporary password.
   If an attacker breaches the security on the email provider later down the line, the password would ideally be changed already by the user.
   If the user has not changed the temporary password, and uses an easy-to-guess password for their email provider, and did not delete the "this is your new password" email, then I don't believe there would be a difference if there was a password reset link or not.
   There's only so much we can do to keep a user safe from themselves, after all
   
   
4. Displaying the password on-screen after they click the link could lead to users being locked out.
   Let's say we made a completely new system where the password reset link was permanent and instead of emailing users their new password, we display it on the page once they click their confirmation link. That would bypass any of the issues I've highlighted thus far, and would ideally be a completely secure system where any attackers breaking into the email account would see a dead, useless reset link.
   However, I know from experience that some users would not expect the password on that page and would close it before copying their password. That's not to mention the rare scenario where their browser crashes on load, and the tab restoration feature on re-launch failed to load this new tab.
   If we immediately invalidated the confirmation link once the page had loaded, this would force users to reset their passwords again, which is something that we might end up receiving complaints about, from forum admins that in turn received complaints from their users.
   I know it's a rare occurrence, but part of my job is to build a system where the system doesn't completely fail to work if the user either makes a minor mistake or experiences something entirely out of their control.
   
   
5. We can't account for users' email accounts not being secure.
   I don't have much to say on this to be honest. Since I want to build a system that is a healthy mix of security and user friendliness, at some point I have to make a concession and assume that the user's email accounts are secure. As far as I'm aware, every major email provider supports two-factor authentication for their email systems (personally I use Gmail and have it set up for all of my accounts) so in my opinion, it's reasonable to assume that a user's email account is safe enough to deliver this temporary password.

I formatted it the way I did because I wanted to make it easier to refer to my individual points if you - or anyone else for that matter - disagree with anything I've said here. If you're reading this and you do disagree, please do tell me. I'm often wrong, and I'm always willing to listen

If you made it this far then thank you for your time


Fillip

 

[Steve F]

It's meant to be a temporary password.
If an attacker breaches the security on the email provider later down the line, the password would ideally be changed already by the user.

Temp password is fine, but there should be a forced change after the user logs in.

 

[DragonByte Tech]

Temp password is fine, but there should be a forced change after the user logs in.

This can be done at the admin's discretion if they run the other maintenance action. Running both will first reset the user's password, and once they log in with it, they are immediately taken to the password security page.

That being said, instead of forcing admins to run two separate actions, I can add a flag that asks the admin if they also want to force password change when the user has logged in


Fillip

 

[Floyd R Turbo]

Very interesting addon. Gotta agree with @Slavik tho, when someone hacks in to the point where they can start changing things, disabling this addon would be first on the list.

Solution: make the ability to disable this addon at a higher level somehow...chew on that one...

 

[DragonByte Tech]

Very interesting addon. Gotta agree with @Slavik tho, when someone hacks in to the point where they can start changing things, disabling this addon would be first on the list.

There's a potentially infinite number of things attackers can do that does not involve FTP access, or AdminCP access with the Manage Add-Ons / Manage Options permissions. Those kind of permissions should be given sparingly, and two-factor authentication should always be forced for staff members. These are XenForo core features.

Surely yourself and @Slavik would agree with this as well

Solution: make the ability to disable this addon at a higher level somehow...chew on that one...

I try not to speak in absolutes, but there is literally no way of getting around someone editing the config.php file to disable all event listeners. Even if I instructed all our users to edit their XenForo files to make this addon part of the core, instead of using the Event Listener / Template Mods / XFCP system, there is nothing stopping someone who has FTP access from simply editing all of those XenForo files to remove this mod's code.

I'm sorry if I don't seem open to listening to this, it's just that I feel like saying "make it impossible to disable this mod even if they have full access to all your site's files" is an unreasonable request. Do you honestly believe there is a way around this?


Fillip

 

[Fred.]

Respectfully, I disagree, for a number of reasons.

Before I get into the reasons themselves, I want to say a sincere thank you for your interest and your feedback. It makes me really happy when someone takes enough of an interest in something I build to post their feedback to help me make it even better. It really is the best thing a coder could wish for (that isn't considered legal tender in their country of choice, anyway ).

In short, thank you

Now then:

1. Password reset links expire.
   If this mod sent links to users for them to be given a new password, we would be assuming that everyone who was registered to the forum was able to check their email and click the link within 15 minutes. That isn't really feasible as I'm sure you can understand.
   If we were to make a new password reset link that was permanent, I don't see how there would be a difference between this link and the new temporary password being sent in plain text, as any attacker that had broken in to the user's email provider to click this link would then simply wait for 30 seconds until the password arrived in the inbox.
   
   
2. It's less user friendly.
   I believe that requiring people to click a link only to receive a password is an extra step that would complicate the process for the user. When considering that attackers who had breached the security on the email provider could just as easily click the link to receive the password, I don't believe we should require users to do it.
   
   
3. It's meant to be a temporary password.
   If an attacker breaches the security on the email provider later down the line, the password would ideally be changed already by the user.
   If the user has not changed the temporary password, and uses an easy-to-guess password for their email provider, and did not delete the "this is your new password" email, then I don't believe there would be a difference if there was a password reset link or not.
   There's only so much we can do to keep a user safe from themselves, after all
   
   
4. Displaying the password on-screen after they click the link could lead to users being locked out.
   Let's say we made a completely new system where the password reset link was permanent and instead of emailing users their new password, we display it on the page once they click their confirmation link. That would bypass any of the issues I've highlighted thus far, and would ideally be a completely secure system where any attackers breaking into the email account would see a dead, useless reset link.
   However, I know from experience that some users would not expect the password on that page and would close it before copying their password. That's not to mention the rare scenario where their browser crashes on load, and the tab restoration feature on re-launch failed to load this new tab.
   If we immediately invalidated the confirmation link once the page had loaded, this would force users to reset their passwords again, which is something that we might end up receiving complaints about, from forum admins that in turn received complaints from their users.
   I know it's a rare occurrence, but part of my job is to build a system where the system doesn't completely fail to work if the user either makes a minor mistake or experiences something entirely out of their control.
   
   
5. We can't account for users' email accounts not being secure.
   I don't have much to say on this to be honest. Since I want to build a system that is a healthy mix of security and user friendliness, at some point I have to make a concession and assume that the user's email accounts are secure. As far as I'm aware, every major email provider supports two-factor authentication for their email systems (personally I use Gmail and have it set up for all of my accounts) so in my opinion, it's reasonable to assume that a user's email account is safe enough to deliver this temporary password.

I formatted it the way I did because I wanted to make it easier to refer to my individual points if you - or anyone else for that matter - disagree with anything I've said here. If you're reading this and you do disagree, please do tell me. I'm often wrong, and I'm always willing to listen

If you made it this far then thank you for your time


Fillip

Thanks Fillip for the explanation.
You are right, It should be safe enough. I'm a security freak, I don't like the idea of plain text passwords in email.
I agree it should be a temporary password. But how many people change it?
If people change it it should be alright.

I had something in mind like your 4th point. But I know it's a lot of extra work.
I keep an eye on this add-on for now because I like it.

I always used your add-ons when I was still on vB so I know they are

 

[DragonByte Tech]

Thanks Fillip for the explanation.
You are right, It should be safe enough. I'm a security freak, I don't like the idea of plain text passwords in email.
I agree it should be a temporary password. But how many people change it?
If people change it it should be alright.

I had something in mind like your 4th point. But I know it's a lot of extra work.
I keep an eye on this add-on for now because I like it.

I always used your add-ons when I was still on vB so I know they are

The next version will have an option to require users who have their password reset to change their password immediately after login, so this shouldn't be an issue going forward (unless of course the email account is broken into)

Thanks for your kind words


Fillip

 

[Floyd R Turbo]

Do you honestly believe there is a way around this?

I don't know website structure and security pretty much at all. I was just asking. Your answer was very thorough and I learned a lot from it! Had I know that, I wouldn't have asked the question...

 

[DragonByte Tech]

I don't know website structure and security pretty much at all. I was just asking. Your answer was very thorough and I learned a lot from it! Had I know that, I wouldn't have asked the question...

I've been informed by someone at DBTech that my post probably came across as a bit rude at the end there. Just wanted to apologise if that's the case, it wasn't my intention. I'm Norwegian and English is my second language, so I sometimes struggle with the nuances of tone in text


Fillip

 

[sbj]

I'm not server-savvy, are these scenarios hypothetically possible?:

1)
Let's say first a customer installs your addon.
Second thing is, that a customer puts a block of code, which was prepared by you, manually in some XF files via direct editting of files.

Now both (the block of code and your addon) cross-checks each other. So if someone disables all listeners or your addon, this block of code sees that and fires an e-mail to a defined e-mail address. If someone removes this block of code, your addon fires an e-mail. I assume it is very unlikely that both get removed at the same time. So as 1 will be removed first, the other one has enough time to react and send an e-mail and warn the owner. Of course you can add more blocks of codes, than you would have more cross-checking.

2)
Let's say it is still likely that both can be disabled at the same time, so both can't cross-check each other.
How about a cron job installed via your addon, which pings every minute a server outside of your server? So if someone disables your addon or deletes all files of XF, as the cron job wouldnt run, there would be no pinging, and no pinging, the other server wouldnt receive anything. So this time the other server could fire an e-mail or shutdown the server or whatever.

3)
Also this block of code and your addon, can't they just check the file size of the config file? So whenever someone changes the config file, just because the file size changed, it will send an alert-email or something

Would those stuff hypothetically be possible to accomplish? I know, probably not realistic to implement those stuff, and I am not in need of something like that. I was just reading this thread and those ideas came to my mind. So I thought I just ask to learn something.

 

[Floyd R Turbo]

I've been informed by someone at DBTech that my post probably came across as a bit rude at the end there. Just wanted to apologise if that's the case, it wasn't my intention. I'm Norwegian and English is my second language, so I sometimes struggle with the nuances of tone in text

I could have taken it that way but that would have meant that I would have to assume the tone of your message and apply my inner voice to it and conclude "man this guy is a real jerk" but I figured you probably weren't a jerk. It's all good!

 

[DragonByte Tech]

Would those stuff hypothetically be possible to accomplish? I know, probably not realistic to implement those stuff, and I am not in need of something like that. I was just reading this thread and those ideas came to my mind. So I thought I just ask to learn something.

Definitely the cron job would be needed, although it would be quite the task indeed to actually create that system

Having some form of external health check would be needed to ensure the mod wasn't simply uninstalled or disabled. Honestly though, I feel that every forum should enforce 2FA for administrators which significantly reduces the chance that anything like this would be an issue.


Fillip

 

[Alpha1]

I would just like to say that the vbulletin version of this addon has been a life saver for my big board. With 4 million monthly users we are regularly targeted by hackers. This addon provides a large scope of tools to not only enhance security but also to quickly detect a number of suspect events that normally stay under the radar.

@DragonByte Tech has been very responsive to feature requests. I am certain that this addon will get many updates.
Fillip, thank you for fulfilling my request to port this addon to XenForo.

I'll surely go through all options and post a list of feature requests. Do you have an arrangement for vbsecurity users?

 

[ManagerJosh]

I'd love to see YubiKey's be leveraged in some fashion for XF.

https://developers.yubico.com/OTP/