atm I am building my own auth system. But today I stumbled over a small problem.
How do I differentiate clients with the same ip ?
I first thought "hey no problem just look at their macip". But HTTP does not include the mac ip address and i can't run a python programm on the client.
So I would have to use some sort of javascript.
But this feels like a hack.
So I did some investigation
Differentiating Between Two Computers On The Same Intranet
But how can I access the "clientport"? And is this a good solution ?
Give the client a token on his first visit that he must send back to the server on each request to identify himself. In a web browser, that's a cookie with a session id or similar unique identifier. On non-web browser systems you can do something similar. There's no way to do this on a protocol level, since the underlying protocols (TCP/IP, HTTP) have been designed to route packets to their destination, unique identification is not part of that process.
From your question I deduce you're writing an authentication system based on HTTP, not just bare TCP. In this case, you could use cookies, which provides exactly the kind of tracking mechanism you need, and are the preferred choice for HTTP login mechanisms.
In generale, with HTTP you shouldn't have to worry and deal about IP addresses, you're a level higher in the stack.
Related
I have a WebApp(PHP) to which the user sends requests to my server, it processes this data and queries on a social network and returns the information to the user.
But I'm having problems where social networks are blocking the IP of my server because of the volume of queries.
Below is my current flow:
I would like to know if there is a way to return this information to my user's browser and make queries from his computer, since it is a new and residential IP.
I do not know if you can make a proxy server with websocket where you would use the user's machine to send the requests.
Here is the flow you want:
Maybe have some way using websocket with a node.js server.
Thank you very much in advance.
You cannot use a client side proxy as such. Protocols built on top of connection-oriented(TCP) protocol will need a valid IP to get response. Establishing a two-way connection will become difficult once you send different request IPs. Even if you are able to do this by some kind of IP spoofing, which I am unaware of, you'll most likely will not be able to have the solution at scale for your app's users.
The best known method would be to use some kind of desktop based solution for such problems and thereby having organic request IPs. If that is not what you want, then you can use proxy servers, that might even be good if you have fewer users, but that might not scale.
Let's say I write a piece of code that makes an http call to a web api, something like:
$http.get('www.myapi.com/api/controller/endpoint').then(function(resp){...})
I then give this code to two people that live in different cities and they hit my API from their respective houses (just from some browser). What information can my API get out of the http request that will allow me to tell apart person A and person B calling it? Is the IP always available? Is the MAC address ever available? What else is there?
How can person A pretend to be person B when calling my API?
Furthermore, what if person C calls my Web API from their own Web API (backend)? Will the same information be available, or what will be different?
This is a general question, but if you want to get specific, let's assume ASP.NET Web API 2 is receiving the http requests.
You're describing a desire for pre-authentication.
The IP will always be available. You could restrict the service to only those IP ranges. It's not a good way to do authentication.
Trying to get around having to perform authentication is not safe. You should use a proper authentication method. Combining IP restrictions with other methods is fine.
John Meyer's answer is essentially pre-shared token based user authentication. Having a valid token constitutes being constantly logged in. The token can be compromised far more easily than a typical token based user authentication that establishes a temporary token with a limited lifetime.
If you decide to go the pre-shared token route, please use a method that supports proper rotation or permutation of the token over time, such that it isn't vulnerable to replay attacks.
Your best option for this scenario is typical session-token based user authentication.
If you're actually not interested in who is using your service, only that they be uniquely identified, you can safely establish a session (or permanent, or arbitrary lifetime) cookie per user by the http Set-Cookie header that all clients should automatically respect and support, then use that as your method of tracking.
My team has accomplished this by requiring that an identification header be included on all requests. This does require some customization on the part of the calling party, but does not necessarily require that the user be logged in. Of course, the value of the header could be change by malicious users so if these calls need to be very secure you will need traditional authentication.
you seem really confused about this. what you are looking for is called authentication.
as you tagged C#, i am assuming you are developing your api in C#. I recommend checking Web Api.
there are a couple of authentication methods available these days. if you are developing a rest api, you can use json web tokens.
you can get a lot of information about the client calling your api via http headers.
I think you can always go with fully authenticated. I see your desire to go for a semi secured set of endpoints but I don't think any of the approach would serve you best. MAC, ip, user-agent, custom fields anything can be spoofed to be honest. Going with a bearer token or session token is your only bet here. For public apis you can limit user requests based on ip or you can try finding out whether a specific ip is trying to exploit you and thus block it but finding true identity might not be possible anyway.
In order to connect to a third party application, I have to give my users the capability to select one of their installed SSL client certificates and transfer it to the third party which is used by the application server. (My web application does not require SSL, it is the third party that require SSL certificates).
It seems to me that access to this list of certificates is only possible by the browser itself when connecting to a service that require SSL. Is it possible to launch the same dialog box through Javascript or is there any way for a web application to browse the SSL store of the end-user ?
If it is not possible, can I simply open a file dialog box and upload the client certificate as any standard file ?
I have to support any browser from IE9 and no plug-ins are allowed in our application.
Thanks.
If it is not possible, can I simply open a file dialog box and upload the client certificate as any standard file ?
Firstly, that's not the way SSL/TLS client authentication works at all. It's simply not a matter of uploading the certificate. The private key matching the certificate is used to sign some content (in the CertificateVerify TLS message) during the TLS handshake. That's what performs the authentication.
Coming back to your main question, for security reasons, the SSL/TLS stack is handled outside the scope of the JavaScript code. Selecting the client certificate is part of that.
You could potentially have some sort of API to let the JavaScript code access some of the cryptographic features of the browser (and there has been work in this area). However, there would be security considerations to take into account.
Even if certificates only contain public information to some extent, that doesn't mean it's public information that is to be distributed to anyone in the world, at least not necessarily in conjunction with the act of browsing any website.
If you had the ability to list the user's list of certificate from the JavaScript code sent by your server, you'd certainly have the ability to send that list back to yourself almost transparently with an Ajax call. While some people are concerned about the privacy implications of being tracked by cookies, being tracked by which client certs you may have takes this to another level (e.g. Subject DN with CN=John Smith and Issuer DN with CN=Department/Ministry of Health/Defence: that would be a bit of a giveaway).
My web application does not require SSL, it is the third party that require SSL certificates.
Here, you're not saying whether that third party is accessed directly by the user's browsers, or if you expect the users to delegate their credentials for you to interact with that third party (without direct user involvement).
If the users have direct access to that third party (via another request), their browser should prompt them for the certificate they with to use.
If it's about credential delegations, that's another problem entirely, since users you never give you the private key for their own client certificate to be able to sign in their name. (It's might be technically possible for users to just give you their PKCS#12 file, for example, but it defeats the point of putting up in place this sort of authentication in the first place).
There has been work done about authentication delegation with certificates using proxy certificates (RFC 3820). Essentially, your EEC (End-Entity Certificate) is used as a mini-CA, despite not having the CA flags, to issue a short-lived certificate with the remote party will accept. This sort of mechanism is generally not well integrated in browsers.
Another, more realistic approach, would be to look into the world of SSO, SAML and Shibboleth, for example. That does work with existing browsers, but the overall architecture is a bit different (so you'll need to discuss that with the third party).
The certificate isn't part of the DOM, so no, this won't be possible.
In a browser environment, is it possible to obtain list of SSL certificates in JavaScript?
The WebCrypto API allows you to discover some things, like shared and derived keys. But looking at their charter and use cases, its not clear to me if they allow enumeration and discovery of certificates.
I see it was discussed in the past and an issue was raised. Here's the discussion: Crypto-ISSUE-15: Discovering certificates associated with (private) keys. But I can't find anything on Issue 15 in the WebCrypto Tracker.
Also see Will the WebCrypto API allow discovery/enumeration of certificates? question on the WebCrypto Mailing list. Hopefully there will be a simple, YES/NO answer.
But don't be surprised if its not available through WebCrypto. The browser security engineers have a particular way of looking at things, and that usually does not include client certificates. Client certificates would effectively stop MitM attacks (see, for example, Origin Bound Certificates), and browsers don't make stopping MitM a priority. Instead, they are OK with mishandling credentials like passwords; and they opt for a One Time Password (OTP) using U2F.
In a reality stranger than fiction, the browsers will even (1) use Public Key Pinning for HTTP, and then (2) break a known good pinset because the user was phished! You can't make this stuff up...
Cryptico seems like a super slick RSA encryption library.
cryptico.wwwtyro.net
In regards to JavaScript applications, suppose I want to send data to the client, have them do something to the data, and pass it back. How can I use RSA to ensure that the data clients send back to the server is not tampered with? Since JavaScript is easily reverse-engineered, is there any practical client-side application of cryptico?
Do you - by your example - mean that you want to hide from the user what his client is doing with the data? If so - it's impossible.
You should never trust any data which comes from the client.
If you send encrypted data to the client to process - you must assume that the user knows (or will know if he wants) the encryption key, otherwise it will be impossible to process. In other words there is no secure way to hide from the user what his client processes. Obfuscation - like you've noticed can always be cracked no matter what language you use.
I think that the most common and practical client-side application for this library would be encrypting user's data and sending them to server or vice-versa. There may be some cases you can't use SSL. Moreover, you can make -for example- an encrypted post on facebook which only your friend will be able to decrypt (because he knows the key).
There is a solution to what you seek (I'm sure there is more than one). My answer requires two non-conventional approaches to what we call a 'secure connection' and how you receive the 'client code'.
You need a physically pre-shared key that initiates a secure connection, and because it's pre-shared it doesn't have to be RSA, which then opens up speed opportunities and higher levels of encryption security for you.
Physically pre-share your client code in a similar manner, i.e., download the code from a cd in a magazine or from a pre-paid card sold in a market. This stops the MITM from sending you tampered and exploited clients, which ssl allows. Once client is known to be secure, and a real secure connection, mentioned in (1), is established, the client code can be updated.
With the combination of a pre-shared key that develops a secure connection and client code that can pass a checksum, you can achieve what you are after.
Ideally, we should have pre-shared secure connection keys available in the market now, but we don't. So, for you to do it alone, would require to implement something similar for you website specifically until people in this country get their act together with some real security. You would have to give them keys over your phone, through the mail, etc. And your client code would most likely have to be a browser extension to install it due to cross domain security issues.
Here's the idea:
If I can get something unique about a computer with JavaScript from an HTML page (probably the MAC address), then can I use this data as another security check?
Is that possible?
I am not going to check the computer at client side, i am going to send it to server to check. If nothing sent, user will be blocked. So it is not something that any developer+firebug combination can bypass. I just want to send one more string with username and password which is unique to computer and no one else knows if they don't entered to the system from that computer. Like a password hidden from user itself.
You can try using a tracking cookie; note however that such mechanisms are considered transient (e.g. cookies can be erased). In-browser JavaScript is sandboxed so that it does not have access to components outside the page. Note also that any feeling of security you'll gain with JavaScript is illusory - the script runs on the client side, where it can be modified (therefore there's no way to tell whether the "unique" piece of data is genuine or faked) or disabled altogether.
If you're trying to prevent random people from hacking at your app, you may want to ban them after a certain number of failed attempts. This will not get you any security, it's more of a flytrap - it limits the annoyances somewhat.
Finally, if you want actual security, go for HTTPS with real (NOT self-signed) server certificates and client-side certificates - see e.g. this for an implementation (that example, however, uses self-signed server certificates, which is not very secure). This is a mechanism that is well-implemented in the browser itself, and provides you with a somewhat secure system (complete with a secure keystore) of identifying your users (as opposed to a fundamentally flawed JS "security", or relying on user-readable files). Oh, and your data is encrypted while on the wire, that's a bonus.
SSL actually does what you're asking for: verifies that the client machine has a certificate issued to that user. This mechanism works inside the browser, not just inside the webpage; thus, it is much harder to subvert this than an in-page JavaScript. It stores a large unique identifier (clientside certificate) in a secure way, and it can prove to the server that it actually has that identifier - which is pretty much your initial requirement.
(Incidentally, using SSL, the data will be protected in transit, and the client can validate the server's identity; those weren't your requirements, but they're more or less necessary to assure that you're actually talking to the real client and real server)
JavaScript within a Web browser executes within a sandbox and has no access to the underlying hardware. Besides, MAC addresses aren't guaranteed to be unique.
No. And you shouldn't implement security with JavaScript only as any competent developer with Firebug will get around it in no time.