Prototype

[xarn]

I still don't really get it precisely.

You could just use the standard authentication method with cookie and token ID.

For HTTP, it's standard yes. However, direct websocket connections have nothing to do with HTTP, nor urls, nor cookies.

That would allow you to avoid storing the user's password on the browser, you would never store the password thus preventing anyone else from taking it.

It think the HTML5 session storage should is as safe as a cookie: it works the same way, same access rights, just simplier to use ...it should actually be even more secure since it's not stored on your hard drive ...but I agree it's a valid security concern to have a close eye upon.


What would be more useful is if you could share you DB infos:
- address/port, etc
- how exactly is the table structured
- how are the passwords encrypted (if they are)

I'll take care of connecting to it / using it.

[Knitter]

I still don't really get it precisely.

You mentioned that you'll use re-authentication every time the user changes a page, how exactly are you expecting to re-authenticate? The re-authentication process is where the cookie method could be used, it will, naturally, depend on how you will be making the authentication.

For HTTP, it's standard yes. However, direct websocket connections have nothing to do with HTTP, nor urls, nor cookies.

Since they are usually started with a HTTP request and the server replies with a HTTP response, in this step both ways mix a bit. I would expect that the authentication takes place in the inicial request for the socket creation since it depends on the server.

It think the HTML5 session storage should is as safe as a cookie

If you don't store the password in the client, it's the same. The important point it to never store the password in any session storage, be it server or client side.

What would be more useful is if you could share you DB infos:
- address/port, etc

This will depend on what instance you're trying to access, currently I'm trying to configure a Sandscape installation in the WTactics server, but access to this database will require an SSH tunel, that could be a problem. The initial testing server doesn't offer an access to the database, my setup doesn't allow for it. You can install Sandscape in your development computer though.

- how exactly is the table structured

You can see that in the code , but here is a snippet for the current version:

Code: Select all

`userId` INT UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT ,
`email` VARCHAR( 255 ) NOT NULL UNIQUE ,
`password` VARCHAR( 40 ) NOT NULL ,
`name` VARCHAR( 15 ) NOT NULL UNIQUE ,
`admin` TINYINT NOT NULL DEFAULT 0 ,
`active` TINYINT NOT NULL DEFAULT 1 

- how are the passwords encrypted (if they are)

Passwords are not encrypted, have no use for that, but they are hashed with SHA1 and the usual salt string. And this reminds me that that could be a problem since you won't have access to the salt string, so a local install would probably work best.

[xarn]

Hi again,

I had to catch a train last time so my response was rather rough and incomplete.

My point is that this discussion mixes two very different things:

1. The first is returning "customized" htnl pages
That is, the username in the corner instead of a login form, the person's deck names, etc...
This is content created at the server side, by php, and the resulting HTML is sent to the client browser which then just displays it. Therefore, when receiving a HTTP request, it has to know from whom it comes, hence the cookie sent along to authentify it

2. The second is establishing a connection at client side
All this happens after the client side receives the customized HTML page. Upon loading the document, it'll try to open a permanent bidirectional TCP connection to the server, using websockets. This connection also has to be authentified. Once the channel is open, some form of indentification and proof has to be sent over.

In order to do this, i imagined simply using username/password would be the easiest. However, we can think of alternatives if you prefer, for example using a temporary ID/pass tokens ...but in these kind of situation, I usually favor simplicity and would simply send the password a second time and check on the same underlying DB.

As for the session storage, I don't see how you could corrupt that, but you are free to enlighten me.

[Knitter]

As for the session storage, I don't see how you could corrupt that, but you are free to enlighten me.

We're talking about HTML5 Session Storage right? If so, this is storage in the client, thus subject to the usual problems that cookies have plus some more due to how HTML5 Session Storage is designed to work.

DNS spoofing attacks and cross-directory attacks are mentioned in the W3C draft, and Microsoft's implementation mentions:

The data stored in local storage is much more public than that stored in cookies, which can be limited to a certain path within a domain. Even picking a hard-to-guess key won't provide any privacy because the Storage object provides a way to enumerate them (...)[(quote]

XSS attacks are the same as with cookies, the only difference is that the attacker would need to know the key for the data he's trying to access, but a simple inspect of the JS code reveals all the keys. Also, HTML5 Session Storage offers no "HTTPOnly" flag that exists in cookies.

Simply put, any data that is sensitive should never be stored in the client side as that date is easily available and modifiable by users.

[xarn]

Wow! ...this deserves nearly a new thread "security".

Despite I think these discussions drive us away from the main goal, I also agree it doesn't harm trying to make things right directly.

First, XSS: cross-site-scripting attacks. Obviously, cookies and session storage are equally vulnerable to this. Whether you steal the cookie or the session storage content is the same. In both cases you will be able to impersonate that person. To avoid it, one must make sure that input (for example when sending messages to other users) is properly filtered.
I like the following tutorial: http://www.steve.org.uk/Security/XSS/Tutorial/
It's nice and concise.

I don't know about DNS spoofing attacks, but here also I guess both are equally vulnerable. I mean, both can be retrieved the same way using some javascript injection. As for cookies having the additional granularity of having the ability to be limited to a certain subdirectory, I think it's irrelevant. I assume a domain level cookie will be used anyway.

What I want to say with this is that both methods share the same vulnerabilities. And it's not a matter of using one or the other, but instead we have to ensure to protect against javascript injections and such. Lastly, malware on a computer can find cookies on hardware but not in session storage which is in memory.

[xarn]

Hi,

So today I continued working on it, facing the usual same issue.
Basically, once "in" the game, there is no problem, the messages are exchanged in a straightforward way and it's really easy and intuitive.

The problem arises to "connect the different screens", to manage the flow between lobby and in-game for instance.

First, I decided to divide the servers:
- one for lobby
- one for in-game

the thing is that "lobby server" registers the new game
but "game server" will be actually responsible for the in-game communication
in other words, the "game server" must know about the games created in "lobby server"
this latter fact implies some inter-process communication
...all in one, it's not easy
Once the game has been created and joined:
- the "lobby server" notifies the "game server" of this (game name, player A, player B)
- the users will disconnect from "lobby server"
- redirect to the in-game web page
- connect to the "game server", re-authentify
- the game server will assign them to the game freshly created
- the game server will dispatch incoming requests to the adequate game handler

So well, there is a lot of work to do... and there is complexity...

Currently, I restructured both the client code and server code to make it nicer. It is now broken down into several pages and servers, instead of a single page/server handling all requests like previously. Automatic (simplified) authentification appears to work, so that's already a nice point.

The big part of work is now:
- notifying a game to the game server
- handling join_game / create_game and so on in the lobby
- the game server itself

...like I mentionned before, the servers themeselves are rather simple. The complexity arises more from "combining" the screens since it faces technical hurdles (connection reset, re-authentification, inter-process communication)

I guess making a single web page / server would have been fairly simpler at this stage. However, I strongly believe that in the long term, splitting it up in several servers/UIs will be advantageous. After all, it's always easier to deal with a few small chunks rather than a single huge one.

[xarn]

Hello guys!

I will use this like a news thread if you don't mind!
...just to keep you up to date

So, last time, I worked on the transition between "screens" which needed automatic re-authentification.
(new page, new connection, knock knock, who's there?)

yesterday, I worked a little on the game server itself. It's currently able to join games for players but it's just that for now. I fight more and more with technical details in ruby programming, which makes me loose lots of time.

Observations so far:

1. usage of websockets
it is pretty straightforward to set up on client-side and works out of the box on firefox and chrome. The resulting event driven model is very nice and intuitive. I still think it has tremendous advantages over classic http update polling. Not only performance wise but also how the code is structured.

2. plain text messages as protocol
I chose plain text in the very beginning for simplicity reasons. It turns out to be very practical and the right choice:
- it's easier to handle than json data whose content has to be checked anyway
- when dumping incoming and outgoing messages, the logs are very readable
- you cn easely interact with the server using command line only

3. ruby as server side language
I heard many good things about it, the websocket API was simple, so I wanted to give it a shot. I experienced using ruby as extremely inefficient and impractical. Perhaps it is because I'm fairly new to ruby but it takes me loads of time to get things right since ruby is fairly unintuitive in many situations.
- since it's "dynamically typed" you cannot know a method is incorrect before running and testing the server
- debugging is time consuming
- refactoring is problematic
- ...in the end, it's just a pain in the ass.
I think that, because of the stage of the prototype, I will finish it using ruby. However, once its done, I strongly recommend re-implementing the prototype server in a more structured language like java.


...and if someone wants to assist, you're very welcome!

[xarn]

An "alpha" version of the game server is almost ready. Like previously, i'll give you the ip to play around with it and see what it is like. Stay tuned.

Currently, I only have a pure text client. That is, you submit a message to the server and it replies to you accordingly, or notifies you when the other player did something.

The source code starts to grow in amount and in complexity. Since I don't want to do all by myself, I'm urgently seeking some interested people to get their hands into it.

Next steps:
- put a demo of the server on the web
- the graphical html client should also take a few days to develop
- finish the lobby and handle the transition from lobby server to game server
- add card flipping

[snowdrop]

I'm urgently seeking some interested people to get their hands into it.[/i]

We're only a handful of people in here, and most of us are already working on something. As yourself, they try to combine that with a real life, studies, job (searching), kids, dog and whatnot

I think it's good you ask for help, but I wouldn't expect it to come in here due to the above. It would be good if you promoted the project in as many other places as possible. After you have done so I'll make a ping so your call for help is posted on our facebook, twitter etc as well.

Sadly, and this goes for everything and not your work specifically, people are much more interested in helping out when you have a finished release: Then they will believe in your project and your skills. So while they're the most needed they're usually not around