Jump to content


Photo
* * * * * 1 votes

A proposal toward improving IP.Board security


  • Please log in to reply
41 replies to this topic

#21 Rimi

Rimi

    Strip Me

  • +Clients
  • 6,066 posts

Posted 29 March 2012 - 03:35 PM

Somewhat related to this topic. Thought I'd share this story.

I was just registering on a site. I enter my usual 6 character password that I use for everything that I don't consider to be important. The anti-spam measure was annoying as heck. It had a picture of a clock and you had to tell the time..thing is it looked like the clock had 6 hands. Anyway I got through that and clicked register and it tells me the password needs to be 8 characters long. So first piece of advice, if you're going to implement password requirements please list them on the registration page. Second issue. I was provided with a go back link which I clicked. My entire form was wiped out and I had to type my email and username again. Not a big deal but no unintuitive.

#22 Ryan H.

Ryan H.

    Watch how I soar.

  • +Clients
  • 2,953 posts

Posted 29 March 2012 - 07:18 PM

Thanks, Matt. I appreciate the feedback.

Blowfish/Crypt: I'm not against this but there are different algorithms and not all machines have the same algorithm which could mean all your password hashes become 'lost' if you move hardware. This will certainly end up back in our lap via a support ticket "I moved to a new host and now no one can log in".

It hadn't occurred to me that different bcrypt variants might pose a problem. Hard to find much info on the matter. PHP 5.3+ has Blowfish integrated, but it's not clear whether that's always used or only as a fallback. In any event, the suite supports 5.2 too, which would definitely be a problem.

As for changing algorithms, it's possible to do on a live system, but it's not particularly pretty. On login, check the form factor of the hash to determine whether it's old or new [or have some boolean to that effect]. If it's old, validate it under the former system, then generate and replace it with the new hash if it checks out. -Even so, you're right, you'll have users who don't log in for months or years, so the conversion never totally finishes. I suppose the best option would be to define some cutoff and simply wipe any old hashes still in the system at that point. Even then, maintaining the login methods in parallel is not particularly desirable. I can understand that.

SMS: It's just too costly and too involved to be a standard feature. It may make a nice mod but generally we're looking to lower the bar for registration and I think requiring a mobile phone number will put people off. For specialised more tolerant communities I'm sure it'd be fine.

Fair enough. As PeterUK noted, I envision such a system as being opt-in, rather than mandatory on registration. I agree that making registration any more involved than necessary is undesirable.


Once they are in and have access to the database/file information anything done front end wise becomes a bit irrelevant. Making the password length longer with a minimum, possibly with an option to expire old passwords and then trying to make sure your users don't re-use passwords across systems is the only real solution. And naturally the most important of all is that anyone with admin access must be forced to realise that they have to take password security seriously as they are the real way in fr these people most of the time.

Once someone gets unfettered access, then yes, naturally all bets are off. The goal is to never allow them to reach that point. That's where policy and architecture improvements have their use. As for file access, that has protections of its own you can set up if you're on a VPS or dedicated box--use SFTP rather than FTP, and consider an IP access list on top of authentication.

Ryan Hoerr / "No1 1000"

 

IP.Board 3.4 Resources bullet_star.pngbullet_star.pngbullet_star.pngbullet_star.pngbullet_star.png

App Advanced Tags & Prefixes

App Easy Pages

Skin Graphite

Skin Thoreau


#23 bfarber

bfarber

    RBT-KS

  • IPS Management
  • 28,403 posts

Posted 29 March 2012 - 07:45 PM

One thing that could be done...

We currently do md5( md5(salt) . md5(password) ). This is stored as the hash (along with the salt) for later comparison. We could take this and then run it through another hashing algorithm (bcrypt, etc.) and then store that. If we did that, we can update existing passwords in the database (just take the value from members_pass_hash and run through bcrypt or whatever is used).
  • Ryan H. likes this

Brandon Farber
Development Manager / Senior Support

If it sounds like fun, it's not allowed on the bus!

php5_zce_logo_new.gif     

Invision Power Services, Inc.


#24 CessPoolCleaner

CessPoolCleaner

    Code GooRoo

  • Visitors
  • PipPipPipPipPip
  • 771 posts

Posted 29 March 2012 - 07:50 PM

Once someone gets unfettered access, then yes, naturally all bets are off. The goal is to never allow them to reach that point. That's where policy and architecture improvements have their use. As for file access, that has protections of its own you can set up if you're on a VPS or dedicated box--use SFTP rather than FTP, and consider an IP access list on top of authentication.


I am not against making things better security wise, far from it. The thing to bear in mind is that most admins are not technowiz types what would make your eyes bleed (and mine) bad practice-wise would get a shrug from most other people. That's the admins for the users, generally, it is worse it is hair pulling difficult to get people to realise that reuse of password on multiple systems is a bad idea.

Making the 'front end' forum more secure is irrelevant against bad personal practices. All I am trying to get across is that changing the db storage hash is not going to achieve all that much, whatever method is used it can be reverse engineered by brute force. Making passwords into pass phrases is an improvement but even a pass phrase like 'James Kirk is the best Captain fer sher!' is side tracked if used on multiple systems. One bad egg capturing the plain text and using them not as brute force but trying the username/password pair is all it takes to bypass the best security.

FWIW I use RoboForm, for each site I get it to generate a unique password, it keeps them for me in an encrypted file and that is the only 'password' I need to remember it then will log me in, that's my solution trying to make users security aware is like eating soup with a fork.
  • Ryan H. likes this

JLogica .. has left the building .. Hope you all have a lovely and productive life.

 


#25 Ryan H.

Ryan H.

    Watch how I soar.

  • +Clients
  • 2,953 posts

Posted 29 March 2012 - 08:03 PM

Making the 'front end' forum more secure is irrelevant against bad personal practices. All I am trying to get across is that changing the db storage hash is not going to achieve all that much, whatever method is used it can be reverse engineered by brute force. Making passwords into pass phrases is an improvement but even a pass phrase like 'James Kirk is the best Captain fer sher!' is side tracked if used on multiple systems. One bad egg capturing the plain text and using them not as brute force but trying the username/password pair is all it takes to bypass the best security.

I agree, the hash is only a small way of addressing a much larger problem. It's totally irrelevant in all cases except where the database was compromised in one way or another.

The best way to counteract brute-force attacks beside increasing password entropy is to slow them down. Use a method that takes them a few milliseconds to calculate instead of a few nanoseconds [as with MD5 and SHA]. By doing that, you just increased the time to crack a single password one million times over. That's basically what I suggested for that part.

The other more practical change is to add something so that the password isn't the only piece needed to get into the account. That's where 2-step verification comes into play. It doesn't matter how strong or unique your password is in that case.

Ryan Hoerr / "No1 1000"

 

IP.Board 3.4 Resources bullet_star.pngbullet_star.pngbullet_star.pngbullet_star.pngbullet_star.png

App Advanced Tags & Prefixes

App Easy Pages

Skin Graphite

Skin Thoreau


#26 CessPoolCleaner

CessPoolCleaner

    Code GooRoo

  • Visitors
  • PipPipPipPipPip
  • 771 posts

Posted 29 March 2012 - 09:12 PM

The other more practical change is to add something so that the password isn't the only piece needed to get into the account. That's where 2-step verification comes into play. It doesn't matter how strong or unique your password is in that case.


The only really useful 2-factor system would be using the token generators like Banks/PayPal use. The ones where the device has a unique id number and generates a 6 digit pin on every press. Now if Invision (sorry Matt) came up with one of them that might work but is everyone going to buy one even if they are only $5?

JLogica .. has left the building .. Hope you all have a lovely and productive life.

 


#27 Ryan H.

Ryan H.

    Watch how I soar.

  • +Clients
  • 2,953 posts

Posted 29 March 2012 - 09:20 PM

The only really useful 2-factor system would be using the token generators like Banks/PayPal use. The ones where the device has a unique id number and generates a 6 digit pin on every press. Now if Invision (sorry Matt) came up with one of them that might work but is everyone going to buy one even if they are only $5?

Such a system can be roughly approximated [much more cheaply and accessibly] by sending user-specific keys via text message or with a smartphone app. It can be equally effective, and avoids the need for special-purpose hardware.

Ryan Hoerr / "No1 1000"

 

IP.Board 3.4 Resources bullet_star.pngbullet_star.pngbullet_star.pngbullet_star.pngbullet_star.png

App Advanced Tags & Prefixes

App Easy Pages

Skin Graphite

Skin Thoreau


#28 CessPoolCleaner

CessPoolCleaner

    Code GooRoo

  • Visitors
  • PipPipPipPipPip
  • 771 posts

Posted 29 March 2012 - 09:29 PM

Such a system can be roughly approximated [much more cheaply and accessibly] by sending user-specific keys via text message or with a smartphone app. It can be equally effective, and avoids the need for special-purpose hardware.


That's just not on .. I am not the only person who lives outside the coverage of mobile towers. To work it has to be one in all in.

JLogica .. has left the building .. Hope you all have a lovely and productive life.

 


#29 Enkidu

Enkidu

    IP.Badass

  • Members
  • PipPipPipPipPipPip
  • 2,243 posts

Posted 29 March 2012 - 09:45 PM

I agree with everything except for minimum password length. I like to keep my password 1 character long (no hacker would EVER think a site's admin has a 1 character password!) Jk... :wink:

Good suggestions!


this post should be nominated for the worst idea of the century. The first thing a hacker would do is assume that your password is something easy to remember such as a word from the dictionary (hence dictionary attack) and in case of a brute-force attack, your password will be cracked in a fraction of a second.

See my other mods here

Latest: Adf.ly integration


#30 PeterUK

PeterUK

    IPB Full Member

  • +Clients
  • 181 posts

Posted 29 March 2012 - 11:15 PM

One thing that could be done...

We currently do md5( md5(salt) . md5(password) ). This is stored as the hash (along with the salt) for later comparison. We could take this and then run it through another hashing algorithm (bcrypt, etc.) and then store that. If we did that, we can update existing passwords in the database (just take the value from members_pass_hash and run through bcrypt or whatever is used).


That certainly couldn't hurt to do and should be fairly easy to implement. With a high enough work factor that should pretty much eliminate the problem for 99% of the crackers out there, and it certainly discounts rainbow tables completely. Look at phpBB3's algorithm (which as has been said, is using blowfish), it's a nightmare for password crackers for two reasons:
a) Because it's slow to generate for; and
b) Because there's very few tools to crack it anyway, certainly not the CUDA/Brook tools which are so widely available for MD5.


That's just not on .. I am not the only person who lives outside the coverage of mobile towers. To work it has to be one in all in.


You're saying you have a phone but live outside of mobile coverage? For most of the above mentioned systems that's irrelevant. A proper token generates a key without any Internet or mobile network access. Google Authenticator for Android/iOS/Blackberry is completely time based and once you've scanned in the barcode for your generator it can run entirely independently, even if you take the SIM card out of your phone and turn WiFi off.

this post should be nominated for the worst idea of the century. The first thing a hacker would do is assume that your password is something easy to remember such as a word from the dictionary (hence dictionary attack) and in case of a brute-force attack, your password will be cracked in a fraction of a second.


He said he was joking. ^

#31 raindog308

raindog308

    Advanced Member

  • +Clients
  • 268 posts

Posted 30 March 2012 - 02:25 PM

2-step authentication via sms? It's just a board. I would never register.

If you want security, require each user to buy a SecureID token :-(
VPSadvice.com: My experiences with VPS companies.

#32 Kyanar

Kyanar

    Let's say my yearly license expired in...

  • +Clients
  • 5,189 posts

Posted 01 April 2012 - 06:44 AM

Just take the phpBB approach - build in optional support for Yubikeys, and users can choose to buy a token ($25) if they want. If they don't, well, whatever.
Mat / Fusion Digital Entertainment Limited
Our Website: http://www.fusiondigital.co.nz/
Our Forums: http://community.fusiondigital.co.nz/

Chronicle, the desktop time tracker for Windows • Fusion Menu, the leading navigation enhancement application for IP.Board • CommunityContact, the in development community newsletter application


#33 PeterUK

PeterUK

    IPB Full Member

  • +Clients
  • 181 posts

Posted 01 April 2012 - 09:00 AM

Just take the phpBB approach - build in optional support for Yubikeys, and users can choose to buy a token ($25) if they want. If they don't, well, whatever.


Or build in optional support for Google Authenticator. People only need a smartphone (and to me it seems likely that if they were willing to pay $25 for a key, they'd have a smartphone), and it's free.

#34 AndyMillne

AndyMillne

    Needs Serious Help

  • IPS Staff
  • 1,780 posts

Posted 24 June 2012 - 06:56 PM

Just take the phpBB approach - build in optional support for Yubikeys, and users can choose to buy a token ($25) if they want. If they don't, well, whatever.

Or build in optional support for Google Authenticator. People only need a smartphone (and to me it seems likely that if they were willing to pay $25 for a key, they'd have a smartphone), and it's free.


Take your pick.

YubiKey - http://community.inv...authentication/
Google Authenticator - http://community.inv...authentication/
  • Feld0 and Brett L like this

#35 XTF

XTF

    IPB Full Member

  • +Clients
  • 117 posts

Posted 26 June 2012 - 12:23 PM

it is worse it is hair pulling difficult to get people to realise that reuse of password on multiple systems is a bad idea.

How about emailing a generated password on registration (in the activation email)?
Don't expect users to come up with good (new) passwords themselves, they won't.

#36 Rimi

Rimi

    Strip Me

  • +Clients
  • 6,066 posts

Posted 26 June 2012 - 12:47 PM

How about emailing a generated password on registration (in the activation email)?
Don't expect users to come up with good (new) passwords themselves, they won't.

I always change the password to something easier for sites that do that.

#37 XTF

XTF

    IPB Full Member

  • +Clients
  • 117 posts

Posted 26 June 2012 - 12:50 PM

To one used on multiple sites I guess?

#38 Rimi

Rimi

    Strip Me

  • +Clients
  • 6,066 posts

Posted 26 June 2012 - 03:41 PM

To one used on multiple sites I guess?

Yeah. The usual 123456.

#39 Axel Wers

Axel Wers

    Senatus Populusque Romanus

  • +Clients
  • 3,743 posts

Posted 27 June 2012 - 03:29 AM

SMS: It's just too costly and too involved to be a standard feature. It may make a nice mod but generally we're looking to lower the bar for registration and I think requiring a mobile phone number will put people off. For specialised more tolerant communities I'm sure it'd be fine.

This can be optional for new members. Who wants can use SMS notification during login process.

FreeSpace - FreeSpace Forum - Twitter - Facebook - WebMiesto
 
Axel Wers, on 28 Nov 2012 - 7:22 PM, said:
iArcade should be regular app in IP.Suite. Currently IPB looks much more social network than common forum. And games are very popular in social networks.


#40 The Guy

The Guy

    Advanced Member

  • +Clients
  • 264 posts

Posted 27 June 2012 - 05:38 AM

Nice try with your reverse psychology, but I am still going to get into your site's ACP.


Yes but with 24 letters in the alphabet and 10 numbers in the numpad (0-9), that leaves the hacker 34 guesses. Oh and of course there is the ALT= Symbolism which lead up to 400+ guesses.

For example:
ALT+11=♂

The keyboard is larger then you think :P




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users