I'm building a Haskell web application for which I need authentication. My organization runs an LDAP server, and I would prefer not to reinvent the wheel. However, when I inspect the source code for LDAP.Init.ldapSimpleBind from the ldap-haskell package, I discover that it calls the C routine ldap_simple_bind_s. As far as I can tell, this API call is going to send my users' passwords in the clear to an LDAP server. Not acceptable.
Have I understood correctly what ldap-haskell is doing?
If so, is there a secure way for me to authenticate my users to an LDAP server from an application written in Haskell?
Passwords must be sent in the clear over a secure connection to an LDAP server that supports password policy checks. Failure to do so will result in the server being unable to manage password history and password quality checks. If the server does not support password policy and history checks, then that server should not be used for non-trivial, mission critical applications. Use either SSL, or failing that, an unsecure connection promoted to TLS using the StartTLS extended operation.
Can you use port 636 (secure LDAP) instead of port 389 to connect to your LDAP server? In this case you would at least have SSL protection.
Related
I am integrating an application with LDAP in my organisation.
I am implementing HTTPS to send the password from the frontend to my application server, and then forwarding the password from my application server to the LDAP server using TLS. This keeps the password safe in transit.
However there is still the problem that my application server is still able to see the password in plaintext before it forwards the password to the LDAP server.
If I hash it on the front end then the password will not match the password on the LDAP server.
Is this a risk that I need to accept in order to integrate my application with LDAP? Or am I implementing this incorrectly somehow?
My application server is a python flask application and I am implementing LDAP3.
Thanks in advance.
For the question:
Is this a risk that I need to accept in order to integrate my
application with LDAP?
Yes.
The use of SASL Mechanisms which are supported by most LDAP Server Implementations can SASL authentication, this is However, this requires the LDAP Client (DUA) to be able to present an encoded value that contains the SASL mechanism name and an optional set of encoded SASL credentials.
Maybe you could use SASL with a ServerLess Architecture?
Regardless of the technology implemented, any password based authentication would require the user providing credentials which, at some point need to be gathered and therefore subject to this risk.
THe use of OpenID Connect could limit the exposure so the to the OpenID Provider's Authorization Server; but the risk is still present.
WebAuthn eliminates passwords and may be an option.
-jim
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'm looking for a simple authentication protocol (OpenID, Active Directory, ??) for users to log into my website. It's hosted on Windows Azure. High levels of security are required. What can you recommend and why that particular choice?
Note: At this point in time I will not be using SSL so no plain-text passwords can be transmitted. I will however be transitioning to an SSL environment in the future.
Is the data that your site/service is going to be transmitting across the wire private, sensitive, proprietary, etc? If so, it is ESSENTIAL that you implement SSL in order to prevent anyone with a packet sniffer from being able to syphon data straight from the wire.
In order to perform secure authentication you will need to employ something like SSL to establish a secure communications transport over which you can request and receive a SAML (or similar) identity token from an identity provider.
If you don't use SSL to protect your communications, it's trivial for a malicious 3rd party to steal the identity token and masquerade as the authenticated user and/or to log/monitor/modify every request for any user of your system!
What are your reasons for not using SSL?
I'm trying to learn more about Integrated Windows Authentication but everything I read introduces me to three new acronyms, many of which incorporate other acronyms, and I don't feel I know anything about the mechanics.
I understand that if an HTTP client doesn't support Integrated Windows Authentication there is a chain of fallbacks that can identify the client and might involve prompting for a username and password. Is there ever a case where it will fallback to HTTP Basic Authentication or any other plain text username / password communication?
I'm trying to determine if I need to provide SSL to protect user credentials and I'm hoping that all authentication is secured in some way.
There is no plain-text credential for the SSPs available to IWA in a default installation (NTLM and Kerberos). In principle you could deploy some other SSP and make it available to IWA via NegoEx, and that SSP might implement password checking in the clear, but that's pretty unlikely.
Of course there is nothing stopping a web application from returning a response requesting HTTP Basic Authentication or Forms Authentication, independently of IWA, so you would have to check no applications were doing that.
I'm trying to determine if I need to provide SSL to protect user credentials and I'm hoping that all authentication is secured in some way.
If you're only interested in complying with a corporate policy against cleartext passwords, then IWA should be enough.
If you have a real threat model and it includes a snooper on the network, then you have much more to worry about - such an attacker can just as easily do active man-in-the-middle attacks and make the web application appear to do something like create a bogus NTLM login box that leaks passwords. That's why you might want SSL.
I'm developing a client-server app, the client is an iPhone device that communicants with my c# server. The client and server use a textual protocol that i have designed to exchange messages over TCP sockets. Can someone please give me some guidelines how to add basic security to this app?
At this moment the only security element i have is client authentication with log in username and password. But for example anybody can see and read the messages sent between client and server without any problem...
In the mobile environment the user of the application has more control over the device than you do as a developer. There is no way to hide a secret password or key. You must account for a malicious client, so be careful about the functionality that you expose.
Sending the username and password in plain text is a violation of OWASP a9. You should consider using SSL/TLS or HTTPS.
Have you looked at openssl? SSL are cryptographic protocols that provide secure communication. SSL will prevent others from listen on the stream between your client and server.
One thing more you should do is to validate all server input, to prevent executing malicious code on your server. For example if you have a database where you store user input you should take a look at SQL injection.