How would I redirect to login page AUTOMATICALLY, if my Identity cookie has expired at "ExpireTimeSpan" value? I do understand there is an event "OnRedirectToLogin" but that doesn't get triggered unless a request comes through. Is there a way, I can redirect to login right after the cookie has expired rather than keep sending requests to verify it has timed out?
Unless I misunderstand, what you want is the server to reach out to the client, but standard client/server HTTP works the other way around. The client is supposed to send requests to the server, and at some point to get redirected if its authentication cookie has expired, but if the cookie expires and the client never ask the server for anything more ever, then it doesn't have to be told anything has expired. Communication the other way around, where servers notify clients can be achieved by several means but is to be reserved for very particular needs. Are you sure you need that?
Related
We have a customer having their own client UI application (www.myclient.com). When they make an API call to our server (www.iamserver.com), we set cookies (Set-Cookie header) and send back in the response. We expect these cookies to be sent in the subsequent requests from the client. [Third-Party-Cookies scenario]
Problem: Recently, due to some org policy, our client browsers have been blocked from using third party cookie. Obviously, calls to our server are not going through since the cookies are not set.
Is there any workaround from server side that we can do without doing any change in the client application? Looking for answers only from the server side.
I tried changing the domain of the cookie we set to that of the client domain. It still won't work because the browser blocks the cookie saying "domain attribute was invalid with regards to the current host url".
Browser: chrome
Any references/pointers are deeply appreciated.
Thanks in advance.
I have built a game server in nodejs using socket io.
I am planning to remove express and cookies from the authentication procedure and instead use webstorage and a client which attempts to log in during the socket io handshake.
However, I am using http and sending the user id and password in cleartext. Please, have mercy on me! I believe using https for the entire socket connection would add a huge overhead since updates are sent every 100ms. My current solution has worked for development, but I am sure it is insecure.
I should mention I have never set up/used https, so correct me if I am wrong regarding the overhead, which I know is a very debated topic. An ideal solution appears to be authenticating users over a https connection and then transmitting game state stuff over http, but I have no idea if or how this could be achieved.
Finally, I have 2 options for logging users in. I could allow the socket io connection on the server and just emit the log in credentials from the client. Then disconnect them if they are incorrect.
However, a cleaner solution would be to send the user id and pw in the http header for the handshake, and then authenticate the user from a socket.io middleware, but I am not sure if sending the data this way would be safe.
I do not think this is such a niche problem that a standard practice does not exist, however it may be to just use https. I believe there is no advantage to encrypting the users credentials as the data can still be snooped between the client and server. Any information on how I can achieve this is appreciated,
Or just point me in the right direction :)
Use one https connection for the login authentication and reply back to the client with a unique security token if the username/password is valid.
Use ordinary http connections for the rest of the dialog between client and server. Include the security token in the dialog if the client is requesting something that requires validation. Your client can store the security token in a cookie if you find that convenient, as the token can only be used for one session.
Have the server purge session tokens once a client signs off, or after the token has been idle for some period of time.
This is cheap and effective for medium-security applications. Variations on this scheme get used in many applications. It is not foolproof - a packet sniffer may be able to grab the security token in transit.
If the security token is constructed from a hash of the client IP address and a server timestamp, then it is easy for the server to validate the token in every message and very difficult for a 3rd-party to hijack the session.
I have a restful api written in Go. I want to authenticate each request. To do so, the server and the client share a secret.
To authenticate a GET request to /foo/bar/, the client add a nonce parameter with a timestamp to the url, /foo/bar/?nonce=13899932199128265, and then add the hmac of data with the secret to the url. It gives something like /foo/bar/?nonce=13899932199128265&hmac=hd7nd7s9s702j
To verify the validity of an incoming request, the server verify that no requests from the client arrived after the time stamp and that the hmac is valide.
I believe it is a common way to authenticate requests. For instance, mtgox uses a similar process.
The problem that I have is that my client will likely require a list of urls [url1, ... urln] at the same time. In that case, nothing guarantee that the first request sent by the client will arrived first to the server. Indeed, any permutation of the requests will result in 403 errors.
My first question is simple: is that a real problem? Is it likely that request order will change during transport?
Second, is it entirely to the client to verify no 403 errors happen?
Is there better way to do?
Thanks a lot!
I would like to use the HTTPS to secure the communication between my client and the server. The first encrypted communication will be used to authenticate the user - i.e. checking his/her user name and password.
After the user credentials will be successfully checked by server I would like to start getting some data in subsequent requests. BUT how the server will determine that the subsequent request is send by the user, whose credentials were already checked?
Since the TCP connection might be closed between login and subsequent HTTPS requests, (I think) this means that the SSL context must be released by the server, so with the new GET request, the new TCP connection must be established and the new SSL(TLS) handshake must be done (i.e. new shared password for the encryption must be exchanged by both sides, etc.)
For this I think server needs to send back to the client in 200 OK response for the initial authentication request some randomly generated nonce (which is valid for a certain time), which I will include in every subsequent request, so the server will be able to detect, based on this randomly generated nonce, which user name is behind the request and check that this user is already logged in. Is my understanding correct?
Thanks a lot for the reply
BR
STeN
The simplest method is to require all communication to go via HTTPS (so the data is confidential; nobody other than the client and the server can see it) and to use simple username and password on every request inside that secure connection. This is dead simple to do in practice (the username and password actually go over the connection as an HTTP header, which is OK here because we're using HTTPS) and the server can check every time that the user is allowed. You don't need to worry about the SSL handshakes; that's the SSL/HTTPS layer's responsibility (and that's why HTTPS/SSL is nice).
Alternatively, the login can be done with any method and generate some kind of magic number (e.g., a UUID or a cryptographic hash of a random number and the user's name) that is stored in a session cookie. Subsequent requests can just check that the magic number is one that it recognizes from session start (and that not too much time has passed since it was issued); logout just becomes forgetting the magic number on the server side (and asking the client to forget too). It's a bit more work to implement this, but still isn't hard and there are libraries for server-side to handle the donkey work.
The first option is particularly good for where you're writing something to be used by other programs, as it is really easy to implement. The second option is better where the client is a web browser as it gives users more control over when their browser is authorized (program APIs don't tend to need that sort of thing). Whenever the client is going to be a browser, you need to take care to armor against other types of attack too (e.g., various types of request forgery) but that's pretty much independent of everything else.
Inventing custom authentication mechanism in your case is very risky - it's easy to make a mistake that will let lots of wrong doing. So the right approach, as for me, would be to use HTTPS and pass user credentials with each request.
I note that some sites (such as gmail) allow the user to authenticate over https and then switch to http with non-secure cookies for the main use of the site.
How is it possible to have http access to a session but this still be secure? Or is it not secure and hence this is why gmail gives the option to have the entire session secured using https?
Please give an example of how this works and avoids session hijacking attacks, whilst still allowing access to authenticated content over http. I want to be able to implement such a scheme if it's secure, to avoid having to have a whole site as https for performance reasons.
As Thilo said, but I'll explain a little further :)
A webserver is stateless! This is really the problem of the authentication-case. You can't just log in, and then say "from now in, this user is logged in" - you need some way to identify which user it is that's requesting a new site this time.
A common way of doing this is by implementing sessions. If you packet-sniff your network traffic while logging into, and then browsing a site you'll commonly notice something like this:
Logging in: You will transmit your username and password to the server. Completely unencrypted! (SSL / HTTPS will encrypt this request for you to avoid man-in-the-middle attacks)
Response: You will receive a randomly generated string of a lot of weird characters. These will typically be stored in a cookie.
Request of some site only you should have access to: You will transmit the randomly generated string to the server. The server will look this string up, and see that it's associated with your session. This allows the server to identify you, and grant you access to your sites.
.. Now, HTTP in itself is not secure. This means that your password and your session-cookie (the randomly generated string) will be transmitted completely un-encrypted. If someone has access to your traffic (through trojans, router hijacking, whatever), he will be able to see your username / password when you log in, if you're not using HTTPS. This will grant him access to your site untill you change your password (unless he changes it first :P ). In the rest of the requests he will be able to get your session cookie, which means he could steal your identity for the rest of that cookie lifecycle ('till you log out, or the session expires on the server).
If you want to feel secure, use HTTPS. Realistically though, it's a lot easier to social engineer a keylogger into your computer than it is to read all your traffic :)
(Or as others have pointed out, use cross-site-scripting to read your session cookie)
It is only secure insofar as the password is not transmitted in the clear. It is possible (and has been done) to intercept and abuse the GMail session cookie in HTTP mode.
To avoid session hijacking, you need to stay in HTTPS mode (which GMail now offers, I think).
This is just a tiny bit more secure than plain HTTP - the login name/password doesn't go over the wire in plaintext. Apart from that, it works exactly like a normal HTTP cookie-based session (because that's what it is); therefore, all the session hijacking issues apply.
It's not really possible and not secure. That's why we got "secure cookies". Although it's good against passive sniffing attacks because username/password won't be exposed however session hijacking is still possible.
Also check out this SSL Implementation Security FAQ paper.