Status Update 028 - Progress

My thought is that maybe we can add account to the user table and if they get it wrong two or three times their account deactivates. Even with three guesses out of a million I feel pretty secure with that

Sorry... Add a count

There was a comment for them in my build notes, you might not have seen the file though:

SQL:
Added 'title' column to 'pages' table, updated insert sql with default titles

I increased my own vericode length and implemented the brute force checks that I listed in another thread, along with other password changes.

I seen it...but it broke the SQL for some reason on import...we'll have to take a look at it again...

It seems like a version difference in phpMyAdmin caused this problem. My version lists table alterations within the create table blocks, while the US version has them at the end of the file. I tested my updated branch and it works for me.

I've definitely had that problem. I broke something with that recently.

So what's on the to-do list? What kind of issues are you all having with the menu system? Maybe we can get this knocked out and go beta. Things are still busy at work, but I can get away to do some coding now.

From what I can tell the "new" buttons don't work on the menu system. I did repair the sql dump.

Vericode security
Password security (try x times)
Username Ajax
(other things that were discussed in that thread)

Not sure what else tbh

I fixed the new menu item bugs. We're getting closer.

Ok. Sounds good. Just checking to make sure I didn't overstep.

Oh gosh don't worry about that! We're contributing, you're the project manager per say! When you going to push a new code would love to hammer at it for the day?

I just pushed out some code. There is a fix for the db import, new db dump, and I added oneclickedit to some of the admin_menu stuff.

I'm about to tackle the vericode and forcing the "order" on the menu to be an integer in oce.

what do you want to work on?

I don't know there is much more I'm good at doing! Lol

@karsen had mentioned the ajax username check and password system I don't know if that meant he was going to do it or just mentioning it...not sure I'll be any good at the ajax part...

I'm horrific at ajax. I break it all the time. I'll work on my oce parser file first and see what happens.

I do however think we're almost ready!

We are definitely getting there! Do you want to make the enable/disable db menus feature?

Hmm. So I had a thought. Since the user doesn't have to login in order to use the vericode system, someone could basically put whatever they want in the url and DOS attack the system to lock users out. Basically you could keep requesting password resets with random vericodes to get the system to lock out a particular user. That could be bad.

So that leads me to a bigger picture thought. With all this logging, I wonder if we want to create a banned ip list and ban the ip instead of the user. We'd also need a whitelist though because I have a static ip for my company, so if someone just screwed up inside the office, they'd lock out the entire office.

I'm not sure that there's a great way to do this that doesn't cause more harm than good.

Banned IP would probably be best tbh...

Whitelist yes would be necessary.

What about Session ID?

We've recently done a lot of fraud work at our company lately and one thing we've noticed is Fraudsters don't worry about changing a session ID (clearing their cache and stuff)...that might be best practice...

Also: How do you want the active/inactive formatted? Do you want it on OCE format or on the menu item page?