Scratch

I do think we should design this forum from scratch, rather than modding an existing one or what's the point?

I may be old fashioned since I hear CSS lets you create round-edged divs now but don't curved edges take longer to load than square?

I agree there aren't really any security issues with the fora, we have enough knowledge between us not to make such mistakes.

I also agree with Magnie that AJAX post checking could execute a heavy toll on the bandwidth where people may not want it. For this reason we probably shouldn't us it for that purpose or have it turned off by default with an optional checkbox to activate it.

nXIII wrote:

sparks wrote:

I may be old fashioned since I hear CSS lets you create round-edged divs now but don't curved edges take longer to load than square?

Only if you want them to look round in every browser

I thought that border-radius was fully supported. 

Yeah, I remember now, you need different pieces of code for each browser ¬_¬

I am thinking nXIII's block renderer should replace the existing one.

scimonster wrote:

nXIII wrote:

scimonster wrote:

I thought that border-radius was fully supported. 

It's not supported in IE6, IE7, or IE8.

Stupid IE. ^^

...but that's no reason not to use it 

scimonster wrote:

sparks wrote:

Yeah, I remember now, you need different pieces of code for each browser ¬_¬

I am thinking nXIII's block renderer should replace the existing one.

Just border-radius:npx;-webkit-border-radius:npx.  Firefox has been fully supported for a while.

But.. may as well put in -moz-border-radius: npx

Zeusking19 wrote:

when are we starting? I have dreamweaver. That could help.

We are in the Planning Stage right now ( Create The Idea > Plan It > Create a Draft > Create the Actual Thing > Release It and add Updates When Needed ).

Also, this is my idea with authenticating in the forums:
Also, if we are going to require the users to have an account on Scratch, then we can skip a lot of the "Account Creation" stuff and all we need is a "token" from scratch.mit.edu.

I think something like the Open ID system should be used to authenticate with the Scratch site. Then the user can just login, and if the user doesn't exist in the forum database, the forum can just create it.

I think the user table should be something like this:

[id | username | cookie | group | topics | posts]
id : Unique ID for the user ( Auto-Increment )
username : Scratch Username they login with
cookie : It will sort of act like the "password" but when the Scratch site authenticates the login, it may give us a specific cookie to use to authenticate the user with. This will also be the cookie placed on the user's browser. ( We can use sessions instead if needed )
group : This will be the user-group that the user belongs to, like Admins, Moderators, Scratchers. ( Maybe even transfer the user's rank on here to the other forums too? )
topics : Amount of topics they've created.
posts : Amount of posts they've created.

The last two will probably be used just for record keeping, so we can drop those if needed, we should probably just stick with the things that are needed ( like the id, username and cookie ).

Anything that we should also take into account? Security problems? Things that we should add?

I've got a basic protocol that we could put into place:
[1] The user goes to the forum and clicks the Login button
[2] The login button links them to a login page on Scratch ( not the actual forums they are logging into )
[3] The user logs in and the Scratch site sends the user back to the forums with a key
[4] The forums validate the key and username with the Scratch site
[5] If the username and key are valid, the forums save the key into the database with the username and saves two cookies on the user's browser ( username, key )
[6] Then the forums validate the two cookies, username and key, with the ones in the database for each page request and then lets the user in.

So basically, the Scratch site sends the key with the user and the user gives their Scratch username and key to the forums and the forums validate it with the Scratch site.

If the user skips the logging in part of the Scratch site and just gives the forums a fake key, then when the forums try to validate it, it won't work. So the user can't spoof as another user or skip the login process.

Also, please notice that the forums only validate the key and username once with the Scratch site. This saves resources both for the forums and the Scratch site and still provides the necessary authentication required.

Lets skip the man-in-the-middle attacks, since I'm currently not good enough with cryptography and digital signing to deal with that sort of stuff, but as an example of what a user could do: The user can send a fake name and key to the forums, then forums send the username and key to the Scratch site but the user intercepts it then sends a fake validation as a reply allowing them to login as a fake user on the forums. Though if you have any idea on how to fix that, be my guest and tell me. 

Now obviously a lot of this needs more thinking through, but... any thoughts?

Last edited by Magnie (2012-01-03 14:03:50)

Magnie wrote:

Zeusking19 wrote:

when are we starting? I have dreamweaver. That could help.

We are in the Planning Stage right now ( Create The Idea > Plan It > Create a Draft > Create the Actual Thing > Release It and add Updates When Needed ).

Also, this is my idea with authenticating in the forums:
Also, if we are going to require the users to have an account on Scratch, then we can skip a lot of the "Account Creation" stuff and all we need is a "token" from scratch.mit.edu.

I think something like the Open ID system should be used to authenticate with the Scratch site. Then the user can just login, and if the user doesn't exist in the forum database, the forum can just create it.

I think the user table should be something like this:

[id | username | cookie | group | topics | posts]
id : Unique ID for the user ( Auto-Increment )
username : Scratch Username they login with
cookie : It will sort of act like the "password" but when the Scratch site authenticates the login, it may give us a specific cookie to use to authenticate the user with. This will also be the cookie placed on the user's browser. ( We can use sessions instead if needed )
group : This will be the user-group that the user belongs to, like Admins, Moderators, Scratchers. ( Maybe even transfer the user's rank on here to the other forums too? )
topics : Amount of topics they've created.
posts : Amount of posts they've created.

The last two will probably be used just for record keeping, so we can drop those if needed, we should probably just stick with the things that are needed ( like the id, username and cookie ).

Anything that we should also take into account? Security problems? Things that we should add?

I've got a basic protocol that we could put into place:
[1] The user goes to the forum and clicks the Login button
[2] The login button links them to a login page on Scratch ( not the actual forums they are logging into )
[3] The user logs in and the Scratch site sends the user back to the forums with a key
[4] The forums validate the key and username with the Scratch site
[5] If the username and key are valid, the forums save the key into the database with the username and saves two cookies on the user's browser ( username, key )
[6] Then the forums validate the two cookies, username and key, with the ones in the database for each page request and then lets the user in.

So basically, the Scratch site sends the key with the user and the user gives their Scratch username and key to the forums and the forums validate it with the Scratch site.

If the user skips the logging in part of the Scratch site and just gives the forums a fake key, then when the forums try to validate it, it won't work. So the user can't spoof as another user or skip the login process.

Also, please notice that the forums only validate the key and username once with the Scratch site. This saves resources both for the forums and the Scratch site and still provides the necessary authentication required.

Lets skip the man-in-the-middle attacks, since I'm currently not good enough with cryptography and digital signing to deal with that sort of stuff, but as an example of what a user could do: The user can send a fake name and key to the forums, then forums send the username and key to the Scratch site but the user intercepts it then sends a fake validation as a reply allowing them to login as a fake user on the forums. Though if you have any idea on how to fix that, be my guest and tell me. 

Now obviously a lot of this needs more thinking through, but... any thoughts?

Every username could have an accociated key, so the key is used internally, instead of being entered by the user. Otherwise, I am not sure. Anyway, it seems we are going to do something. Maybe I will start on a front page.

About the groups, when the admin changes the group through ScratchBB, the username has that group written to the database. Hmm. I see this becoming a good project that may go outside of scratch one day.

Last edited by Zeusking19 (2012-01-03 15:54:36)

Sparks: With my current protocol, all the Scratch site will do is validate that the key is part of that user. So all the user needs to do is redirect the communication from the forums to the user themself instead of Scratch and then send the fake validation back to the forums.

To be honest, the hardest part is for the Man In The Middle to get between the forums and the Scratch site. It's a ton easier to get between a client and a server than between a server and a server. If you are in the middle of the client and the server, like if a client is on a computer, and you are in control of the router, you can do two things, 1) get all the data being sent to and from the client and possibly modify it as well 2) imitate/redirect the communication from the client and server.

In case you haven't noticed yet, the user has to get between the server the forums are hosted on, and the Scratch site since the communication isn't being done through the user trying to login.

Zeus: I guess you could have Scratch send the username and key associated with it and give the same values to the client wanting to login to the forums. But the problem is how the Scratch site will send that data securely to the forums so it can save it into the database.

So I think my current protocol is still the most secure way at the moment. ( For the user, forums, and Scratch site )

Last edited by Magnie (2012-01-03 16:29:55)

Lightnin: Also, how do you plan on adding Authentication from other sites ( like, if I had my own site and I wanted users to authenticate as a user from Scratch )? Will there be a special protocol ( to keep everyone's passwords, etc secure ) or will it be the plain text way where the site they are logging in from just send the username and password to the Scratch site and Scratch will reply if the username and password are correct or not (thus the Scratchers' passwords could easily be logged by the Third-Party site)?

Anyway, here is the links to the scratchbb logo i made.

ScratchBB

http://i40.tinypic.com/21ad1lf.png

ScratchBB With Imagine - Discover - Share

http://i44.tinypic.com/atrx1h.png

Zeusking19 wrote:

Magnie wrote:

Lightnin: Also, how do you plan on adding Authentication from other sites ( like, if I had my own site and I wanted users to authenticate as a user from Scratch )? Will there be a special protocol ( to keep everyone's passwords, etc secure ) or will it be the plain text way where the site they are logging in from just send the username and password to the Scratch site and Scratch will reply if the username and password are correct or not (thus the Scratchers' passwords could easily be logged by the Third-Party site)?

I saw an api thing for this, but i dont remember the link.

Yeah, I have too, but it's insecure, you give the third-party site your Scratch Username and Password and then the site checks if they really are your username and password.

Can you tell me what security issues we have other than the Man-In-The-Middle one? Since these forums won't be holding any passwords, I don't see what will be "encrypted" or hashed. I'm pretty sure the Scratch site hashes all it's users' passwords.

Last edited by Magnie (2012-01-04 10:25:21)

Lightnin wrote:

Magnie wrote:

Lightnin: Also, how do you plan on adding Authentication from other sites ( like, if I had my own site and I wanted users to authenticate as a user from Scratch )? Will there be a special protocol ( to keep everyone's passwords, etc secure ) or will it be the plain text way where the site they are logging in from just send the username and password to the Scratch site and Scratch will reply if the username and password are correct or not (thus the Scratchers' passwords could easily be logged by the Third-Party site)?

We're not certain exactly how this will work yet. Sdg1, who is working on the back end of Scratch 2.0, is away right now but when he returns we'll definitely talk about this. It might be best to implement an open-source established protocol, like openid or something. But really sdg is the one who knows about this stuff - It's really beyond my expertise.

But the reason I'd like to use a protocol that someone else has thought through already is that there are many many bright minds working out all the security issues related to that platform. If you roll your own, then it's up to you to imagine all the zillion different ways it can be attacked (and patch them). That can quickly get overwhelming.

Yeah, I agree. Thanks for the info. 

Lightnin wrote:

Magnie wrote:

Lightnin: Also, how do you plan on adding Authentication from other sites ( like, if I had my own site and I wanted users to authenticate as a user from Scratch )? Will there be a special protocol ( to keep everyone's passwords, etc secure ) or will it be the plain text way where the site they are logging in from just send the username and password to the Scratch site and Scratch will reply if the username and password are correct or not (thus the Scratchers' passwords could easily be logged by the Third-Party site)?

We're not certain exactly how this will work yet. Sdg1, who is working on the back end of Scratch 2.0, is away right now but when he returns we'll definitely talk about this. It might be best to implement an open-source established protocol, like openid or something. But really sdg is the one who knows about this stuff - It's really beyond my expertise.

But the reason I'd like to use a protocol that someone else has thought through already is that there are many many bright minds working out all the security issues related to that platform. If you roll your own, then it's up to you to imagine all the zillion different ways it can be attacked (and patch them). That can quickly get overwhelming.

It is still fun though.