Intro
The users of our web application must log in in order to use the app. Communication uses (along the XMLHttpRequest) the WebSocket API.
The questions
Is storing the user name + password in a <input type="hidden"> of a <form> and then sending their data values to a login script sufficiently safe? If not, what could we do here?
Is it possible to store an arbitrary object (say, class User {...}) in the WebSocket's Session such that I can type in the login script:
session.setAttribute("web_app_user", user)
user = (User) session.getAttribute("web_app_user")
such that it is not possible to hack the web app in any way?
Generally speaking, as long as you are using WSS protocol (as opposed to WS), you are communicating with the server in a secure and encrypted manner. That said, there are a lot of different methods to further ensure safety.
I think a fairly acceptable method is sending username and password once, along with some kind of session ID that is unique to the client. If the credentials are verified acceptable by the server, just the session ID can be passed along with further calls to the server. This cuts down on the amount of times you expose a user's password.
You may want to further secure your credential verification method with some kind of cryptography algorithm such as SALT.
Related
As the title says is there a cannonical safe way to implement login in GRPC (I'm using Java). I'm currently sending the login and password over TLS, checking them at the server and sending back a Session ID that needs to be sent with each message but I was wondering if there is a better/simpler way to do this.
Yes/No, possibly... If your API is not public then you could consider using a basic ApiKey instead of a session id.
If it's public then you have bigger things to consider.
With your current implementation, how long is the Session ID valid for?
What happens when the Session ID expires?
How do you refresh the Session ID?
How do you revoke the Session ID?
Take a look at the documentation here: https://grpc.io/docs/guides/auth/ for some ideas.
I'd also recommend reading up on oAuth2.
We are trying to implement Oauth2 on our app, in our App we are login using Sign In with Google, and this returns a lot of stuff like : UID, ACCESS_TOKEN, REFRESH_TOKEN, etc.. we are thinking to send from APP to server-side the UID and store it to DB linked with user like if it was its password.
From server side we want to on each call for instance : get_products, we are thinking to use an access_token but we don't know if it's the UID from user itself or we have to create another access_token with its refres_token with expiration time. So we have one UID from user and another access_token and refresh_token from oauth.
I'm not sure about the value you refer by UID. May be it's something that I haven't come across before.
But if it stands for USER IDENTIFIER, then you should not use it to identify the end user and maintain a session. UID could be a public identifier so anyone who knows will be able to communicate to your server. Also, think about user login through multiple devices. Your server won't be able to identify the correct session.
User access_token to initiate a session. In your server, use user-information endpoint to obtain validity details and end user information. Alternatively you may choose OpenID Connect.
When user access a website for the first time, the initial server response may include a SET-Cookie header to set the session ID. Such as:
Set-Cookie: JSESSIONID=04427E42C4AE7A5DD1CCE86B8B5F7110; Path=/TestSite/; HttpOnly
Then client will carry it in cookie header for subsequent HTTP requests: Such as:
Cookie: JSESSIONID=04427E42C4AE7A5DD1CCE86B8B5F7110
My question is:
So the real session object is some data structure created and maintained on server. Server just send its index key to client. When subsequent requests come, server will use that key to find session data store on server. And if necessary, server can use database to store the session data. Is this mind picture correct?
The following Java code is actually manipulating the session data which is stored on server. Though it looks like it is manipulating the request object. Right?
request.getSession().setAttribute("accountId", user.getId());
The following code is essentially key (sessionid) looking up process. It looks for a session object on server by looking up for a session id cookie sent from client. Right?
Session s = (String) request.getSession();
Is there any chance server doesn't send the Set-Cookie header? Or is it mandatory?
It seems some key-value store like Redis is very suitable for session store. Has anyone tried that?
So the real session object is some data structure created and maintained on server.
With a servlet session, yes. But in general, you could also store "real data" in the session cookie itself. Has the downside that the user can see it and mess with it, and that it can only be quite small, but has the advantage that the server does not have to store the state (and share it with others in a cluster).
The following Java code is actually manipulating the session data which is stored on server
That's right. The Servlet API provides for this interface through the request, because that way it is associated to the session key (and the individual user).
Is there any chance server doesn't send the Set-Cookie header? Or is it mandatory?
You could turn that off. If you need sessions, but don't want cookies, it gets a bit complicated. You could attach a query parameter to every URL.
It seems some key-value store like Redis is very suitable for session store. Has anyone tried that?
Yes, that's a common setup.
The default setup for servlet containers is to store the session in memory. This does not need any configuration or preparation, but works well only for single-server deployments. If you have more than one server, you need to either share the session information (using something like Redis), or have "sticky session" (configure the network to always send the same user to the same server).
everybody.
Say, I have a web server and a client, which connects to it for the first time. The authentication mechanism is:
1) parse the client's UsernameToken element and retrieve its username, password and
nonce.
2) evaluate a hash: SHA2 (username + password + nonce)
3) check if a Data Base contains such a hash.
Let's assume that there is such a hash. The question is, how to know that the client is already authenticated, when it connects the second time?
Searching the DB is rather expensive, so I can't do it at every connect.
Saving the clients hash in memory will increase the performance, but how long should it present in such a registry and it seem to be a huge security hole.
Session parameter? But how can it be implemented in the web-services context?
I need to implement a simple remember me option in a java servlet with cookies, without using any advanced framework.
First, at login, I create the cookie and send it in response to the browser (client). The value to be stored in the cookie is just a simple hash from username + password.
How should I manage the incoming request from the browser, sending the cookie?
My approach is to check between registered users if there is any user that has the hash from username + password equal to the value in the cookie?
Is this approach correct?
Also, I did not understand exactly what is the mechanism of the expiration date. Does the browser delete the cookie when it is expired, it not, how do I check if the cookie is expired?
As long as you're not using HTTPS the method you suggest is highly insecure. I would suggest to generate some sort of session token (e.g. use java.util.UUID.randomUUID()) and set this as cookie and store it somewhere on the server side so you later can identify the user associated with this session id in the cookie.
This gives you the opportunity to reset a certain session cookie if you think there's some fraud happening and there's no direct relation between the user name/password and the cookie id you use. But note: this method is still vulnerable to a man-in-the-middle attack.
Concerning the expiration: yes the cookie becomes invalid and might get deleted by the browser if it is expired. But you can set the cookie to something in the year 3000, so it lives forever.