I'm trying to connect to gmail using a simple java program (like this one). But my question is:
Is there a way to do this with encrypted password and not the real password, for security reasons of course!! something like how we do in java-Oracle db ?
By default, the only authentication mechanism for IMAP is the LOGIN command, which takes an unencrypted username and password. You can add an encryption layer on top of it, either by connecting via IMAPs or starting a TLS layer via the STARTTLS command, but it still requires the client to know the cleartext password.
A server can optionally also provide SASL authentication methods invokable via the AUTHENTICATE command. The server advertises which SASL mechanisms it supports in its response to the CAPABILITY command. For instance, if the server includes the capability "AUTH=PLAIN", the client can use the PLAIN SASL authentication method via the AUTHENTICATE PLAIN IMAP command.
Gmail supports only one SASL authentication mechanism, XOAUTH:
C: 1 capability
S: * CAPABILITY IMAP4rev1 UNSELECT IDLE NAMESPACE QUOTA XLIST CHILDREN XYZZY
SASL-IR AUTH=XOAUTH
S: 1 OK Thats all she wrote! dv32if2169247ibb.17
XOAUTH is a nonstandard SASL authentication mechanism using OAuth. (The leading 'X' means it's not standardized.) Google has published a document defining the XOAUTH SASL mechanism. They've also provided a google-mail-xoauth-tools package, which includes sample code showing how to use JavaMail with Gmail via XOAUTH.
Related
We have a client/server based application that is developed internally. Clients and server communicate over a TCP/IP connection with an application-specific protocol. The clients run on Windows and the server runs on Linux. All machines are in the same Active Directory/Kerberos domain/realm.
Currently, the user enters a username and password when they start the application. The server checks the username and password (authentication). Based on the username, the server also determines access to resources (authorization).
We want to add Single Sign-On (SSO) capabilities to the application. That is, we do not want the user to enter a username and password but we want to automatically logon as the current Windows user.
Of course, determining the current Windows user has to be done securely.
I have come up with the following setup:
I use SSPI (Negotiate) on Windows and GSSAPI on Linux.
When the client connects to the server, it uses AcquireCredentialsHandle (Negotiate) to get the credentials of the current Windows user.
The client uses InitializeSecurityContext (Negotiate) to generate a token based on these credentials.
The client sends the token to the server.
The server uses gss_acquire_cred() to get the credentials of the service. These are stored in a .keytab file.
The server receives the token from the client.
The server uses gss_accept_sec_context() to process the token. This call also returns the "source name", that is the current Windows user of the client.
The server uses the "source name" as the username: the server performs no additional authentication. The server still performs authorization.
This works but I do have some questions:
Is this secure? It should not be possible for the client to specify any other username than the Windows user of the client process. If a user has the credentials to create a process as another user (either legally or illegally) than this is allowed.
Should I perform additional checks to verify the username?
Are there alternative ways to achieve SSO in this setup? What are their pros and cons?
What you've described here is the correct way to authenticate the user. You should not have to worry about the user specifying a different name; that's what Kerberos takes care of for you.
If the client is able to obtain a service ticket, then they must have been able to authenticate against the KDC (Active Directory). The KDC creates a service ticket that includes the user's name, and encrypts it with the service's secret key.
The client would not be able to create a ticket for the server with a fake name, because it doesn't have the necessary key to encrypt the ticket.
Of course, this all assumes that you've set everything up correctly; the client should not have access to the service's keytab file for example, and the service should not have any principals in its key tab except its own.
There's a pretty detailed explanation of how it works here.
With the PassNTLMv2 configuration option one can pass authenticate to a corporate proxy.
Is it also possible to use kerberos credentials with CNTLM? Or is there a way to obtain the NTLMv2 password automatically from a Kerberos ticket?
Kerberos and NTLM have nothing in common. This won't work. NTLM requires the pw to be available to calculate the challenge while Kerberos relies on the TGT, i.e., the password can be thrown away as soon as you have the TGT.
See BPF
It's something like CNTLM but for Kerberos proxy. Beside, it has a graphical interface.
If a SSL SMTP server requires a STARTTLS command to be used (java mail property: mail.smtp.starttls.required), do we also need to enable Plaintext Authentication over TLS?
I'm not sure exactly what you mean by "plaintext authentication over TLS".
If the server requires STARTTLS, a plain text (non-SSL) connection is made to the server, TLS (SSL) is started on the connection, and then authentication is done. Authentication can use any authentication mechanisms supported by both client and server, including the PLAIN authentication mechanism.
Does kerberos encrypt only the authentication process or all client communications?
I was under the impression it was like a VPN for the LAN.
So that all LAN communications are encrypted. Just like all internet communications are encrypted with a VPN.
Regards
Aubrey
Kerberos is quite capable of encrypting traffic between client and server, but depending on exactly how kerberos is used in the application, it may or may not be using the kerberos session keys to encrypt the traffic.
The kerberos protocol provides the means to exchange a session key that can be used to encrypt message traffic after the initial authentication exchange. Encrypted message exchange is generally the default for protocols that actually use GSSAPI. See gss_wrap documentation
GSSAPI is a generalized API for doing secure network applications. Kerberos is the mostly commonly used driver underneath GSSAPI.
If the application does not use GSSAPI, or the native kerberos messaging libraries, then it is likely using TLS to encrypt the traffic or the traffic is not encrypted.
Kerberos message encryption was designed to support relatively long lived tcp based client/server applications ( think telnet or ssh ). The API does not always map well to the way current applications are architected. Kerberos support is often bolted on well after the application is under construction
and is only used for authentication.
Kerberos is an distributed service that is generally used for secure authentication only. It does neither ensure that a user has the required permissions to access a resource (that would be Authorization) however it may be used to encrypt arbitrary data. As per RFC 3961 "Encryption and Checksum Specifications" which extends and correct aspects of RFC 1510 the Kerberos protocol provides confidentiality and integrity services.
While Kerberos can be used to encrypt information passed between authenticated peers in many cases it only performs the authentication step. Thus, you will find that Kerberos is used as component in a secure environment to ensure a secure authentication with other components and protocols handling the authorization and the secure transport.
In the end, it heavily depends on your usa-case to determine if the tradeoffs between using Kerberos or something else as a transport protocol make sense for you.
While the Kerberos protocol can be used to provide encryption services on most platforms, microsoft provides no mechanism to do this directory. Instead GSSAPI may be used to call these services.
For example, Active Directory uses Kerberos for message integrity.
Similarly, you could use e.g. TLS or IPsec to encrypt your data on the wire and combine it with Kerberos for authentication. But again, this is another protocol performing the actual transport encryption and just using Kerberos as an authentication component.
I am trying to connect a server to a XMPP server, using the MD5 Digest SASL handshake. But the XMPP server always rejects my response to the challenge. The RFC says the response should look like:
username="example.org",realm="somerealm",\
nonce="OA6MG9tEQGm2hh",cnonce="OA6MHXh6VqTrRk",\
nc=00000001,qop=auth,digest-uri="xmpp/example.org",\
response=d388dad90d4bbd760a152321f2143af7,charset=utf-8
But the value of response (which I have correctly generated based on the inputs) relies on the username and password. For server-to-server communication, which username and password should it be using? The example.org username in the spec doesnt seem right..
You've probably solved this by now, but this is for the record. See RFC3920, section 6.1, item 6: "If provision of a 'simple username' is supported by the selected SASL mechanism (e.g., this is supported by the DIGEST-MD5 and CRAM-MD5 mechanisms but not by the EXTERNAL and GSSAPI mechanisms), during authentication the initiating entity SHOULD provide as the simple username its sending domain (IP address or fully qualified domain name as contained in a domain identifier) in the case of server-to-server communications or its registered account name (user or node name as contained in an XMPP node identifier) in the case of client-to-server communications."
At least, that conditionally takes care of the username. The password I couldn't even guess at. I'm writing a client-to-server script, so I'll be using my own gmail username and password, but that isn't likely to work for server-to-server.