I work on web application and I want to have live notifications to a user via websockets. These notifications should be received only by a user whose notifications belong to.
I wonder if it's good idea to pass an temporary authentication token (which would be unique for a user) to javascript and the script connects to websocket server and pass the authtoken as a parameter to make a handshake. Is it secure solution to pass auth token to javascript and then login via websocket using this authentication token? Of course web app is secured by ssl and web socket server also.
You can try
User authenticate to Web app Server
Web app Server will generate 1 Key Code for this session ( Maybe Md5 with salt is username) if user are valid
Web app Server send this key to Web Socket server
Web app Server send this key to client-side
Client will send this key to websocket server to authenticate
If socket contained this key -> user is valid -> OK, continue to transfer data between socket and client, Else Web socket server will stop this connection.
It will be secure because authenticate key is unique and SSL will make it be better.
Hope it'll help you. And this was our solution for building a FOREX System : Authenticate via CAS ( Single Sign ON ) and Websocket to send the index data. In our case, CAS server will generate 1 Single Sign On ID, and we use it to validate.
Related
The story is, I have 2 potocol in my sails.js server, this sails server is only for API access, and some API are MUST logged-in to access, the websocket is also running on this server.
In the sails when I login then put the user data in req.session.me, this will save the user data in session, next time I through http to access then I can get save data from req.session.me.
Reference: http://sailsjs.com/documentation/concepts/sessions
The question is saving data in user session req.session.me through http to access the server then cannot get back req.session.me through websocket to access the server.
Many Thanks!
Sorry if this has been asked a few times, but can't quite find out a solid response.
I want to secure the login procedure and session (kind of) between an HTML5 app and a PHP web service. I present the user with a login screen that uses HTTPS with the server, and then give the client a random GUID that is stored in a database with their time of login and last request time, and their actual user ID that I store for their row on a users table. So the GUID might be different every time but the user ID it maps to on login can only be seen server side.
I'm vary weary when it comes to authentication and never really dealt with a HTML5/JS app against a web service like this. I've usually developed ASP .NET sites and used sessions.
I've recently discovered JWT tokens which encrypts data stores in the token string that is contained on the client and passed to/from the server. Is this safer than what I'm doing? Should I be using JWT as opposed to this GUID mapping I have now?
What I'm aiming for is a session-less request to a web farm which could put you on to any specific web server, and the request is validated to see if that request has came from a valid logged in user.
Any advice would be welcome :).
Thanks.
Using a JWT token is totally safe provided you don't encode sensitive data in the token because the token can be decoded without the secret.
What you can do is to have two key pairs (private/public) RSA keys.
Private for encoding the token and sending it to the client on login success
the client saves the token to maybe a cookie, HTML5 localstorage e.t.c,
on every request, the client passes the token via the request header back to the web server, then the web server verifies the token with the public key. whilst decoding the token and getting the GUID from the token and can then proceed with the request.
This workflow can work across several server side languages as there are many JWT libraries for them.
I create a simple login/password html5 application. Login/password I send via websocket to server to control and set in server side some permissions etc.
How can I connect to this socket in next pages and server can sending correct data which permissions available etc.
Or this login password have I sending always when I connect to socket in every page?
You can store token/session id in cookie.
On following navigation pages you can send that token to websocket to authenticate. Upon successful authentication you can response.
P.S. you need to create new websocket on every page load.
You can use regular web authentication using cookies.
WebSocket HTTP negotiation will carry cookies over. So you can return a cookie when the user connects with an generated UID if there is no any in the request, and then when the user authenticates, consider that UID as authenticated and associated with a User. Each time you get a connection with that UID you know it is that User.
What is the challenge/response method to securely authenticate with a Server without HTTPS (without sending out password)?
I have an app (Javascript client) that connects over CORS (authenticate) to our backend which in turns will return a token containing the claim (JWT) over non-HTTPS. The REST is stateless so we do token-based and not have session at all.
When the client gets that token, (containing claim) it is added to the header for each request of the client and therefore the backend knows which User Id is doing that request and do the appropriate thing. So far this works for us. My concern is with the authentication process and with the security of each request.
To authenticate the clients sends out email and hashed password pair, however I want to know if there's a more secure way even without using HTTPS for now. I've read to not send the password but do a challenge/response, but what is the implementation of that idea?
And last question would be, even if we get around with the authentication process securely, how about on each request which contains the token with claim can it be secured also?
There is no possible way to do this securely without HTTPS. For your server to authenticate users, you need some kind of token (cookie, adding to requests like you have, etc.) However, the problem is that, without https, an eavesdropper can add javascript to your page. They can then capture the token and use it themself (stealing all the user's data), or modify it. If you want your product to be in any way secure, you need HTTPS.
Edit: I guess you could store some information about the device sending the request (user agent and such), and only allow the token to be used on that device. However, an attacker could just fake the user agent when they reuse the token, so this wouldn't be too hard to bypass.
Challenge response is a mechanism to send passwords in non-clear way.
1°/ client and server must share a cyphering key : best is to manually add certificate on client but could be a little bit heavy. Another solution is to store the key only one time into localStorage.
2°/ client requests a challenge to server : this is a "phrase" generated by server
3°/ client concats its password with this "passphrase", ciphers and send response to server : Challenge => Response
4°/ server decrypt message, search and remove its passphrase to get password.
I'm building a web/mobile app using Node.js(Express) server on the backend and Angular.js for the frontend. I'm using passport for sessions and I have some problems with a client side authorization validations.
On user login the server responses with a json cookie containing some session information like username and role. I want to make angular.js route authorization to limit the user access based on hit role. On every redirection I first check the cookie. If the cookie is there and the user's role matches the path's access requirement everything is ok and the redirection is done. If some request from the client side to the server side fails with a Not authorized response the session cookie is deleted and so on...
What is the problem... There are a lot of session validations on the server side but checking the cookie on the client side isn't very secure. Every one can see the cookie format (it's a simple json) and change it. For example everyone can change the role property of the cookie to 'admin' and only with cookie validation the client side will give access for example to the admin's panel view. Access only to the view! A further requests to the backend with this cookie will fail but it's not good to give them access to the views...
The server uses the SSL protocol but this encrypts only the communication, the stored cookie on the client side isn't encrypted.
I was thinking the sent cookie to be encrypted and the client side to decrypt it for authorization validation. But the user can open the clients js files and find out the decrypting key if it's stored in a plane text. If the server sends the key to the client side and the client side stores it in a variable the key will be not visible to the user but it will be lost on a page refresh. It will be not very smart to keep it in cookie :D
Of course the client side can send authorization request to the server for every authorization validation but this can be a lot of request.
Can you propose my some solutions?
Thank you very much and have a nice day :)