I'm wondering how LDAP associates requests with a previous BIND request on a technical level.
For example you issue a BIND request to LDAP that authenticates you to do searches or whatever then you UNBIND.
How does LDAP associate your subsequent SEARCH/ADD etc. requests after the BIND?
I'm currently digging through a packet capture of a bunch of LDAP requests and I don't see the bindResponses returning a session token or anything like that ... does it just consider an IP authenticated or something?
Thanks if anyone can shed some light on the internal mechanism here!
edit: using SIMPLE auth BINDs
Are you talking to the LDAP server using UDP or TCP?
With TCP, it's simple - you do a BIND, then that TCP connection remains authenticated for any subsequent operations issued on the connection, until the connection closes or you issue an UNBIND.
Related
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.
If LDAPv3 is being used with BIND authentication mechanism, then are multiple connections created between client and ldap server? Or just multiple sessions?
As per my understanding,
using ldapv3, for a deployed application, only a single connection will be created from client to LDAP server using manager dn and password. Every BIND request from the client using user's login credentials does not create a connection. It just creates a new session - rebinding happens with different credentials over a single connection created using manager dn and password.
Can BIND requests be sent concurrently to the LDAP server over a single connection?
I think we need some context.
LDAP uses TCP as a transport protocol. Once the transport connection over TCP is made, LDAP can then perform a LDAP requests within the TCP Connection.
You can establish a TCP Connection and bind as one user and then bind as a different user of the same TCP Connection.
Of course, TCP connections do die typically when not used based on the TCP Timeout values and maybe closed by either the Client or server. (Or a load balancer in the middle)
ONLY talking about LDAPv3 RFC 4511 (section 4.2.1) states that bind operations cannot be processed on a connection that has any other outstanding operations. In particular "Before processing a Bind Request, all uncompleted operations MUST either complete or be "abandoned" and "After sending a Bind Request, clients MUST NOT send further LDAP PDUs until receiving the Bind Response."
LDAP is an inherently asynchronous protocol, EXCEPT for BindRequests, meaning that, in most cases, you can issue multiple concurrent requests over the same connection and the client will be able to correlate the responses with their appropriate requests.
Most of the JAVA LDAP SDKs and other LDAP API function calls have both Synchronous Operation and Asynchronous Operation versions.
-jim
This is all completely confused. Bind requests are created over an existing connection. They either succeed or fail. They create an LDAP session of sorts, if successful, but it only lasts as long as the connection it was established with, or until another BIND request. LDAP connections are shortlived in general: they are only there to authenticate the user, or retrieve information about him from the DIT. They are not long-lived or persistent: at least they shouldn't be, if correctly programmed.
Can BIND request be sent concurrently to the LDAP server over a single connection?
Nothing can be sent concurrently to anything over a single connection. The question doesn't make sense. [Multiplexed protocols excluded, but LDAP is not one of them.]
I'm developing a client-server application which uses WebSocket. I have implemented token-based authentication with JWT. Once my client has a valid token, a WebSocket connection is opened indefinitely.
Is it a good idea to send the token within each request? Is there any chance of anyone to hijack the connection?
My question actually applies to any TCP-based connection which requires authentication.
Is there any chance of anyone to hijack the connection? ... My question actually applies to any TCP-based connection which requires authentication.
Yes it is possible to hijack existing TCP connections or just be the man in the middle when you start a new one. The protection against this is not to send the authentication within each message because these could be simply replicated by the attacker. Instead use encryption, i.e. wss:// in case of WebSockets or TLS, IPSec or similar in other cases. These protect against both active man in the middle attacks (hijacking) and passive sniffing.
There's this thing I don't understand concerning LDAP (conceptually speaking, and - at least so I think - not tied to a particular implementation).
I noticed that a typical LDAP client library(for example apache DS) does a connect() first (for which some servers might require username/password), and then executes a bind() operation (which also requires username and password).
Questions:
What is the point of this two step operation in LDAP?
Does it add extra security?
Why not just a single step ?
What is the conceptual signification of these two steps ?
When an LDAP client connects to an LDAP server, that connection is unauthenticated. Clients use the BIND operation to authenticate the connection. The server then processes requests on the connection using the authorization state of the connection with the privileges and access control thereto.
Some (if not most) LDAP APIs offer a single-step connection and BIND, for which one must provide the credentials of the user, or a pre-constructed BIND request (there are different types of BIND requests, simple and SASL). In the case you describe, the API is most likely establishing a connection to the server and then issuing the BIND request to the server. If this is successful, then the connection's authorization state is set. This would be a "convenience" method for clients.
Separating the connection from the BIND (the two steps you mention), is done so that the same connection can be used with different authorization states. Each BIND resets the authorization state of the connection. The LDAP client can connect, then BIND using one user and credentials, perform some operations as that user, then send another BIND request on the same connection to change the authorization state to that of a different user. This enables the client and server to be more efficient since the connection need not be made more than once. This is supported by LDAPv3.
The UNBIND request's name is a relic of LDAPv2, which did not allow multiple authorization states per connection. UNBIND is not the opposite of BIND, and it does disconnect as you discovered. LDAP clients using LDAPv3 can transmit a BIND request to change the authorization state of the connection. The misnamed UNBIND request does not "un-authorize" a state, it merely disconnects the LDAP client from the LDAP server.
see also:
LDAP: Programming Practices
LDAP: Authentication Best Practices
Actually, there is a difference!
Connect() refers to the connection to a LDAP server on a specified hostname and port, as the bind () binds to the LDAP directory with specified RDN and password.
Hope this is helpful!
I am creating a secure web based API that uses HTTPS; however, if I allow the users to configure it (include sending password) using a query string will this also be secure or should I force it to be done via a POST?
Yes, it is. But using GET for sensitive data is a bad idea for several reasons:
Mostly HTTP referrer leakage (an external image in the target page might leak the password[1])
Password will be stored in server logs (which is obviously bad)
History caches in browsers
Therefore, even though Querystring is secured it's not recommended to transfer sensitive data over querystring.
[1] Although I need to note that RFC states that browser should not send referrers from HTTPS to HTTP. But that doesn't mean a bad 3rd party browser toolbar or an external image/flash from an HTTPS site won't leak it.
From a "sniff the network packet" point of view a GET request is safe, as the browser will first establish the secure connection and then send the request containing the GET parameters. But GET url's will be stored in the users browser history / autocomplete, which is not a good place to store e.g. password data in. Of course this only applies if you take the broader "Webservice" definition that might access the service from a browser, if you access it only from your custom application this should not be a problem.
So using post at least for password dialogs should be preferred. Also as pointed out in the link littlegeek posted a GET URL is more likely to be written to your server logs.
Yes, your query strings will be encrypted.
The reason behind is that query strings are part of the HTTP protocol which is an application layer protocol, while the security (SSL/TLS) part comes from the transport layer. The SSL connection is established first and then the query parameters (which belong to the HTTP protocol) are sent to the server.
When establishing an SSL connection, your client will perform the following steps in order. Suppose you're trying to log in to a site named example.com and want to send your credentials using query parameters. Your complete URL may look like the following:
https://example.com/login?username=alice&password=12345)
Your client (e.g., browser/mobile app) will first resolve your domain name example.com to an IP address (124.21.12.31) using a DNS request. When querying that information, only domain specific information is used, i.e., only example.com will be used.
Now, your client will try to connect to the server with the IP address 124.21.12.31 and will attempt to connect to port 443 (SSL service port not the default HTTP port 80).
Now, the server at example.com will send its certificates to your client.
Your client will verify the certificates and start exchanging a shared secret key for your session.
After successfully establishing a secure connection, only then will your query parameters be sent via the secure connection.
Therefore, you won't expose sensitive data. However, sending your credentials over an HTTPS session using this method is not the best way. You should go for a different approach.
Yes. The entire text of an HTTPS session is secured by SSL. That includes the query and the headers. In that respect, a POST and a GET would be exactly the same.
As to the security of your method, there's no real way to say without proper inspection.
SSL first connects to the host, so the host name and port number are transferred as clear text. When the host responds and the challenge succeeds, the client will encrypt the HTTP request with the actual URL (i.e. anything after the third slash) and and send it to the server.
There are several ways to break this security.
It is possible to configure a proxy to act as a "man in the middle". Basically, the browser sends the request to connect to the real server to the proxy. If the proxy is configured this way, it will connect via SSL to the real server but the browser will still talk to the proxy. So if an attacker can gain access of the proxy, he can see all the data that flows through it in clear text.
Your requests will also be visible in the browser history. Users might be tempted to bookmark the site. Some users have bookmark sync tools installed, so the password could end up on deli.ci.us or some other place.
Lastly, someone might have hacked your computer and installed a keyboard logger or a screen scraper (and a lot of Trojan Horse type viruses do). Since the password is visible directly on the screen (as opposed to "*" in a password dialog), this is another security hole.
Conclusion: When it comes to security, always rely on the beaten path. There is just too much that you don't know, won't think of and which will break your neck.
Yes, as long as no one is looking over your shoulder at the monitor.
I don't agree with the statement about [...] HTTP referrer leakage (an external image in the target page might leak the password) in Slough's response.
The HTTP 1.1 RFC explicitly states:
Clients SHOULD NOT include a Referer
header field in a (non-secure) HTTP
request if the referring page was
transferred with a secure protocol.
Anyway, server logs and browser history are more than sufficient reasons not to put sensitive data in the query string.
Yes, from the moment on you establish a HTTPS connection everyting is secure. The query string (GET) as the POST is sent over SSL.
You can send password as MD5 hash param with some salt added. Compare it on the server side for auth.