I'm trying to authenticate a client to my secure WebSocket server (wss) for registered member area.
Once a member is connected to the web server, I record, in a database, a unique token (associated to the member) that I displayed in a hidden field on the page initiating the connection to the Web Socket server.
Then the token is sent to the WebSocket server that authenticates the account using the token.
I'm really not a security expert, and I wanted your opinion as to the security of my authentication.
Are there any risks (except cookie hijacking)? Are there any better way to proceed considering that WebSocket doesn't prescribe any particular way that servers can authenticate clients during the WebSocket handshake.
I use Ratchet WebSocket.
Yes, one option is to use cookies (and TLS to avoid cookie hijacking):
Have the cookie set after "plain old HTML form based" login, transmit the cookie to WebSocket server, and use the cookie to authenticate the WebSocket.
Here is a complete example of doing Mozilla Persona based authentication with WebSocket.
You asked about Ratchet. This example is not Ratchet, but it might give you some clues - which is why I think it's ok to point to.
Are there any risks ...
Yes, lots. PKI/PKIX and SSL/TLS has a number of architectural defects. For the full treatment, see Peter Gutmann's Engineering Security.
Also, WebSockets does not allow you to query attributes of the underlying connection. So, as far as I know, you can't even tell if you are actually using SSL/TLS. The only thing you will know is you requested it.
Are there any better way to proceed considering that WebSocket
The last time I checked, WebSockets is pretty lame. All you get to do is open, read and write. They are intended to be easy to use, but lack anything useful related to security.
For completeness, the last time I checked was March 2013 while performing a security evaluation on app that used them. Things may have changed by now.
I also tried engaging the WebSockect RFC authors, and the RFC editor about some of the issues form a security point of view. All of the emails went unanswered.
UPDATE (2015): It gets even better... Browsers and other users agents have Host Public Key Pinning now.
But if you look at the details, it should be called "Host Public Key Pinning with Overrides". The built-in overrides allow an attacker to break a good pinset. Worse, the browser is complicit in the cover-up because it MUST suppress the failed pin report.
You can read more complaints about it (and the rebuttal) at Comments on draft-ietf-websec-key-pinning.
Its a junk standard that never should have been standardized. Its more insecure browser junk.
