When you authenticate against active directory as described in this answer, how is the exchange sent over the network? Is it encrypted? If not, what is the correct way to ensure that it is not sent in clear text?
If the PrincipalContext class implements the Kerberos protocol to authenticate the user against the Active Directory, the users credential is protected according the Kerberos protocol. Basically both sides makes use of a secret key to create a secure channel using a key exchange protocol like Diffie-Hellman.
You can find a quick explanation about the Kerberos protocol in wikipedia, but the RFC 4120 is the official source.
In other hand if it uses plain LDAP queries, the security will be on the transport protocol.
Related
I want to build a server using Node.js, which acts as some kind of proxy. The clients that connect to my server use NTLMv2 for authentication (there is no chance to change this), but the upstream server my server shall connect to requires a Kerberos token.
So, my question is pretty simple: How do I, using Node.js, transform the information provided by NTLMv2 into a Kerberos token? On npm, so far I have found modules for NTLMv2 authentication, but I somehow would probably need to talk to Windows to translate NTLMv2 data of a user into a token for this user.
Any hints on this, how to approach this problem?
Absolutely not! NTLM and Kerberos operate completely different. First of all, I would highly recommend get rid off NTLM as fast as you can.
You can solve your problem in an easy fashion if you can access C interfaces. I also assume you MIT Kerberos on a Unix-like OS like CentOS or FreeBSD, etc.
NTLM will provide you the downlevel logon name. You need first to convert the NetBIOS domain to a DNS domain via LDAP (use libopenldap) then you can construct the Kerberos principal or the enterprise principal for your client. Then create a service account in your KDC and enable protocol transition and contrained delegation on that account for the target service. Now request a TGT on behalf of that user principal and request a service ticket for the user, voila you can access your Kerberos backend.
Here is a decent read: https://k5wiki.kerberos.org/wiki/Projects/Services4User
If you run HTTPd as your reverse proxy, it might handle all the magic for your with mod_auth_gssapi.
On Windows, this is a bit of a pain with the security API and SSPI. While the the principal transformation comes for free with Windows. You'll need LsaLogonUser with KERB_S4U_LOGON, impersonate with that handle and then require SSPI to acquire a cred handle...
If your KDC allows constrained delegation, you can setup your intermedaite server to allow impersonation. This way it can established security context with the client in one mechanism (in your case, NTLM), and talk to the backend server on behalf of the client in another mechanism (Kerberos). Google for "constrained delegation" and "protocol transition" for more information. Hope this helps.
I am confused about different protocols and mechanisms for Kafka authentication.
Similar to this question here:
Can Kafka be provided with custom LoginModule to support LDAP?
I have kind of made my own PlainLoginModule that uses LDAP to authenticate the username/password provided by the client.
Is there any way for me to make this more secure? It does not seem safe to send plaintext passwords for the authentication. I would also prefer to not use plaintext password in the client side jaas file if possible.
If I were to use SSL could I still use LDAP server to authenticate? How would the kafka configuration change. Current conf:
listeners=SASL_PLAINTEXT://:9092
advertised.listeners = SASL_PLAINTEXT://kafka:9092
security.inter.broker.protocol=SASL_PLAINTEXT
sasl.mechanism.inter.broker.protocol=PLAIN
sasl.enabled.mechanisms=PLAIN
You have two options how to make it more secure:
Use SASL_SSL listeners to wrap the SASL authentication into SSL encryption. You will still be able to use your LDAP through custom module.
Use one of the more secure SASL mechanisms. PLAIN mechanism will send the password over the network which is not secure. You can instead use one of the supported SCRAM mechanisms which will not send the password over the network and will use a more sophisticated handshake instead. Kafka supports SCRAM-SHA-256 and SCRAM-SHA-512. However the SCRAM mechanisms would not work with LDAP - they store the credentials (not directly passwords) in Zookeeper. The SCRAM mechanisms can be of course also combined with SSL.
Yes you can use a SASL_SSL listener. This will use SASL to authenticate and then encrypt the data sent using SSL. If you want more secure authentication, you should consider using the GSSAPI SASL mechanism. ldap and Kerberos integration is a common practice and then you don't have exposed credentials.
When creating any kind of application web,api etc; This days the best practices recommend to secure endpoints by using TLS, but what we can learn from the cloudbleed issue, is that it may not be enough.
Therefore I would like to know what could be done to keep a certain level of security even when TLS is compromised.
For web applications what I currently use is jsencrypt, basically encrypts all data on client browser side before it is sent, but in order to to this I need first to exchange a shared secret (token/cookie) between the server and client, but when dealing with API's that don't support javascript what could be used?
Regarding the exchange of tokens, by instinct it may be obvious to say use OAUTH, OpenID Connect, json tokens , but all of them require or delegate trust to TLS, and again when this is compromised it became useless.
If I am right OpenID could be used without SSL to share a "common secret" by doing Diffie–Hellman key exchange, is there something similar that could be implemented keeping in mind that if TLS gets compromised, easy measure could be taking like revoking tokens or changing "salts" ?
For now I think by following the gpg or rsa (private/public) keys is the way to go, in a way that probably everyone could have access to the public keys but will not be available to see the content of some data signed to a specific user.
But question remains in how to exchange that very first "known secret" between client and server avoiding a possible man in the middle attack considering TLS can't be trusted.
The problem of exchanging the first "known secret" is the same for all protocols, SSL or not. SSL is a public key infrastructure where the basic information that needs to be distributed is the public key of the root certificate of the certificate issuer. The public keys for all ssl certificate issuers are distributed with the browser installation.
Any protocol will depend on some information that is communicated between the server and client in a different channel from the channel where the communication is established. If you don't trust the SSL infrastructure, you will have to send this information by email, postal mail, sms, or by some other means.
However, your problem does not start with the keys neccesary for the encryption libraries you are using in you web application. Your very web application (the javascript files) are also sent from the server to the web browser over SSL. If your SSL communication is compromised by a man-in-the-middle, this man-in-the-middle is also probably able to change the web pages and javascript code that you send to the browser. He could just rewrite your application and remove all encryption code, add new fields and messages for the user, send the user to a different site and so on.
The SSL infrastructure is really a cornerstone in web security, and a neccessity for web applications. Without it, you would have to build a custom protocol for sending encrypted web pages and write a custom browser that would understand this protocol.
With all that said, it is of course possible to add a tiny layer of extra security on top of SSL. You may i.e. create a private/public keypair for each user, send a public key to the user and encrypt all messages from your server to the user with the private key. This could protect against a scenario where a main-in-the-middle is able to listen to the communication but not able to change your messages.
We're building a REST API that will only be accessed from a known set of servers. My question is, if there is no access directly from any browser based clients, what security mechanisms are required.
Currently Have:
Obviously over HTTPS
Have HTTP auth enabled, API consumers have a Key & password
Is it neccessary to:
Create some changing key, e.g. md5(timestamp + token) that is formed for the request and validated at the endpoint?
Use OAuth (2-legged authentication)?
Doesn't matter - from browser or not.
Is it neccessary to:
Create some changing key, e.g. md5(timestamp + token) that is formed
for the request and validated at the endpoint?
Use oauth (2-legged authorization)?
Use OAuth, it solves both these questions. And OAuth usage is good because:
You aren't reinventing wheel
There are already a lot of libraries and approaches depending on technology stack
You can also use JWT token to pass some security context with custom claims from service to service.
Also as reference you can look how different providers solve the problem. For example Azure Active Directory has on behalf flow for this purpose
https://learn.microsoft.com/en-us/azure/active-directory/develop/v1-oauth2-on-behalf-of-flow
Use of OAuth2/OpenID Connect is not mandatory between your services, there are other protocols and alternatives and even custom. All depends in which relationships are services and either they both are in full trust environment.
You can use anything you like but main idea not to share sensitive information between services like service account credentials or user credentials.
If REST API security is main requirement - OAuth2/OpenID Connect is maybe the best choice, if you need just secure (in a sense of authentication) calls in full trust environment in a simplest way - Kerberos, if you need encrypted custom tunnel between them for data in transit encryption - other options like VPN. It does not make sense to implement somthing custom because if you have Service A and Service B, and would like to make sure call between them is authenticated, then to avoid coupling and sharing senstive information you will always need some central service C as Identity provider. So if you think from tis pov, OAuth2/OIDC is not overkill
Whether the consumers of your API are web browsers or servers you don't control doesn't change the security picture.
If you are using HTTPs and clients already have a key/password then it isn't clear what kind of attack any other mechanism would protect against.
Any compromise on the client side will expose everything anyway.
Firstly - it matters whether a user agent (such as a browser) is involved in call.
If there are only S2S calls then 1 way SSL HTTPS (for network encryption) and some kind of signature mechanism (SHA-256) should be enough for your security.
However if you return sensitive information in your api response, its always better to accept 2 way ssl HTTPS connections (in order to validate the client).
OAuth2 doesn't add any value in a server to server call (that takes place without user consent and without any user agent present).
For authentication between servers:
Authentication
Known servers:
use TLS with X.509 client certificates (TLS with mutual authentication).
issue the client certificates with a common CA (certificate authority). That way, the servers need only have the CA certificate or public key in the truststore, and new client certificates for additional clients/servers can be issued without having to update the truststores.
Open set of servers:
use API keys, issued by a central authority. The servers need to validate these keys on each request (and may cache the hashes of the keys along with the validation result for some short time).
Identity propagation
if the requests are executed in the context of a non-technical user, use JWT (or SAML) for identity propagation of the user principal and claims (authorize at security proxy/WAF/IAM, and issue JWT signed by authentication server).
otherwise the user principal refers to the technical user and can can be extracted from the client certificate (X.509 DName) or be returned with a successful authentication response (API key case).
If radius is Authuntication protocol why use kerberos,pap,chap,... ?
The Remote Authentication Dial-In User Service (RADIUS) protocol provides authentication, authorization, and accounting (AAA) for dial-in infrastructures, and it uses the same account and password to log into your company network through modem, WiFi, or a VPN tunnel. RADIUS has many carrier-grade features (the whole accounting part, for example) and is designed to operate in explicitly configured backbone networks.
But it is not well suited for PC and workstation networks and doesn't have the single-sign-on capability offered by Kerberos.
On the Other Hand, Kerberos provides an encrypted authentication service using shared secret keys. Kerberos can also support authentication via public key cryptography, but this is not covered by RFC 4120. Kerberos does not provide an authorization service, but Kerberos does support pass-through to other authorization services. Kerberos does not provide an accounting service.
For More Information about the PAP and CHAP, refer the following url
http://www.zeroshell.net/eng/kerberos/
and this url too you can refer
http://www.firewall.cx/ftopict-2679-.html
RADIUS (Remote Authentication Dial In User Service), defined in RFC 2865, is a protocol for remote user authentication and accounting.
Kerberos is a network authentication protocol. It is designed to provide strong authentication for client/server applications by using secret-key cryptography.
Suppose you have Vodafone or Orange Telecom operator's connectivity at your home for internet connectivity.so,you will be needing a particular user id and password to access that.
Here Radius Protocol is used.
Technically, if you see the network file(.pcap file) that Wireshark Tool uses.
You will see that it contains Attribute Value Pairs that contains user name, password fields.
Radius uses CHAP password.So, it is more secured in terms of middle attack.
I hope you got my point